旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � DB/C Newsletter � � August 1992 � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� Editor's Notes This issue of the DB/C Newsletter is smaller than previous issues. That's not by design, but is because of a lack of time. I recall the classic sign the says "PLAN AHEad" with the last letters getting smaller and trailing off into the lower right corner. We have been working hard to get the first beta test version of DB/C 8.0 out the door and have not been paying attention to the calendar. As you may recall, I committed to having the DB/C Newsletter published (on the DB/C BBS) by the first of each month. I will keep that commitment even if it means a smaller newsletter. I've gotten several comments about the newsletter from readers. Thank you for responding to my plea for feedback. The feedback has been mostly positive. Readers seem to enjoy the TIPS section the best, so we will try to make it even more informative than it has been in the past. There were no comments positive or negative about the DB/C IN USE section. I realize that it is probably mostly marketing stuff, and that our readership is mostly interested in technical information. Therefore, we will only have articles about specific applications if they are particularly unusual or are spectacularly successful. Most of you are already running very successful DB/C applications, so talking about others is not very exciting. Thanks for reading the DB/C Newsletter and keep the comments coming. DNW Other File Systems versus DB/C ISAM and AIM When talking about DB/C with computer programmers and other technical people who may not be familiar with DB/C or DATABUS, the discussion ultimately gets around to file systems. The most frequent criticism of DB/C is probably its use of a proprietary ISAM and AIM file structure. In this article, we will discuss some of the issues surrounding this important topic. Datapoint invented the DATABUS language back when there were no standards for any software, with the possible exception of COBOL and FORTRAN on three or four mainframe vendors computer systems. Like everyone else who was inventing languages and operating systems in the 70's, they adopted the best features that they were familiar with. Datapoint's use of split keys on indexes and their use of separate index and data files were actually somewhat unusual features at the time. When they later invented AIM, they were truly breaking new ground. As the computer industry matured, customers started pushing for standards and "open" systems. These are good things, because then customers are not trapped in a particular vendor's product line. The DATABUS language and its ISAM and AIM features are so tightly connected that the two are almost never considered as separate things. In practice, only Datapoint RMS has truly separated the language from the access methods. There many reasons for this connection between DATABUS and ISAM/AIM. Here are a few: 1. The concept of creating and deleting an index as easily as running a command like INDEX or DELETE does not exist in many traditional access methods. 2. The concept of completely separating the keys from the data record is unavailable on most access methods. Systems have been written that store data in an index that is not even in the record. This is done using the INSERT verb. One example is to use the SOUNDEX value as a key for a record that has a name that equates to the SOUNDEX value. The actual value of the SOUNDEX is not contained in the record. Another example is to not even write records to the data file. This is useful if all that is needed is a validation READ. These are probably not good programming practices unless you are restricted by lack of disk space (as were many computers of the 70's). 3. The DATABUS concept of never allowing other than valid numeric values in FORM variables and explicitly specifying the decimal point in the data file are not typical of other languages. In most languages, the programmer specifies the storage value and the printing/display format separately. This is not the case in Standard DATABUS. 4. The features of AIM can not be replicated by any method other than the hash key method used in all complete implementations of DATABUS. In DATABUS, a data file can have both an AIM and one or more ISAM indexes. This last point is probably the most important reason that DATABUS implementations use proprietary file systems. Historically, each operating system has had its own indexed access method. UNIX is the most notable exception to this. Each of these operating systems implements a variety of features in its ISAM package. Because COBOL is the most widely used business language in the world, and because its typical ISAM (ANSI Standard) features are not very complicated, each of the built-in ISAM packages supported COBOL's needs, and not much more. Unfortunately, this set of features is not sufficient for a typical DATABUS program to survive the move from Datapoint DATABUS to another ISAM without a major overhaul. DATABUS compiler vendors compete with one another by claiming to have an easier conversion from older DATABUS to a newer platform. Datapoint actually has the best claim to this with its series of operating systems (although the Datapoint DOS to RMS 1.x DATABUS conversion was not easy at all). To attempt to fit DATABUS ISAM and AIM on another file system and still have any easy conversion is just not realistic. If ease of conversion is not an issue, but using a standard file system is - and you like DATABUS and want to save your years of investment in code, then it makes more sense to implement DATABUS (and DB/C) with another file system - BUT WHICH ONE? Is C-ISAM really the standard for UNIX? Most UNIXs do not come with it installed. Its support for standard LF terminated files is rather strange - when a record is deleted only the LF is converted to hex 00. Separate manipulation of indexes is hard (all indexes reside in a single file). Standard C-ISAM does not contain a positioning READ (when a read fails the file position is set to invalid). There is no support for compressed or even for variable length records. In the MS-DOS world it's much worse: BTRIEVE, dBASE and C-ISAM all compete with literally hundreds of access methods. And none of them comes even close to providing the lookup performance that AIM can provide for non-left justified keys. A leading report writer product, IQ (from IQ Software), advertises that it supports over 60 access methods from various vendors - including support for DB/C ISAM records and files as well as two other DATABUS compiler vendor's file systems. This does not bode well for those folks who dream that all operating systems, file systems and programming languages will converge into a single portable standard. SQL is actually the best hope for a standard file system to emerge. In reality, SQL is not a standard file system at all, it is a standard interface for accessing records - the indexes (or lack thereof) are mostly invisible to the programmer. Don't misunderstand SQL though - it is not a programming language. It is like the READ and WRITE statements of DATABUS - it is embedded in a programming language like COBOL or DATABUS. The guiding philosophy of DB/C is PORTABILITY. The use of the DB/C file systems guarantees this portability. If portability is not your primary concern and access to other file systems is important, you should consider using the Native I/O routines or embedded SQL features of DB/C. There are currently Native I/O routines for C-ISAM, BTRIEVE and dBASE file systems. There is currently SQL support for MS-SQL SERVER (Sybase) and Oracle SQL. In summary, the issue of which file system to use depends on your circumstances. Important factors in choosing a file system are: portability, compatability, end-user acceptance and corporate policy. DB/C offers a wide variety of choices to satisfy many customers needs. Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips This month's Tips column contains three useful hints. 1. When dealing with foreign devices or binary files, a DATABUS program is occasionally required to operate on bytes as if each were a numeric value from 0 to 255. The following ANSI Standard DATABUS code segments are quick ways to convert between a character value and a numeric value. CHAR DIM 1 NVALUE FORM 3 TABLE INIT 001,002,003,004,005,006,007,010,011,012,013,014,015,016,017: 020,021,022,023,024,025,026,027,030,031,032,033,034,035,036,037: 040,041,042,043,044,045,046,047,050,051,052,053,054,055,056,057: 060,061,062,063,064,065,066,067,070,071,072,073,074,075,076,077: 0100,0101,0102,0103,0104,0105,0106,0107: 0110,0111,0112,0113,0114,0115,0116,0117: 0120,0121,0122,0123,0124,0125,0126,0127: 0130,0131,0132,0133,0134,0135,0136,0137: 0140,0141,0142,0143,0144,0145,0146,0147: 0150,0151,0152,0153,0154,0155,0156,0157: 0160,0161,0162,0163,0164,0165,0166,0167: 0170,0171,0172,0173,0174,0175,0176,0177: 0200,0201,0202,0203,0204,0205,0206,0207: 0210,0211,0212,0213,0214,0215,0216,0217: 0220,0221,0222,0223,0224,0225,0226,0227: 0230,0231,0232,0233,0234,0235,0236,0237: 0240,0241,0242,0243,0244,0245,0246,0247: 0250,0251,0252,0253,0254,0255,0256,0257: 0260,0261,0262,0263,0264,0265,0266,0267: 0270,0271,0272,0273,0274,0275,0276,0277: 0300,0301,0302,0303,0304,0305,0306,0307: 0310,0311,0312,0313,0314,0315,0316,0317: 0320,0321,0322,0323,0324,0325,0326,0327: 0330,0331,0332,0333,0334,0335,0336,0337: 0340,0341,0342,0343,0344,0345,0346,0347: 0350,0351,0352,0353,0354,0355,0356,0357: 0360,0361,0362,0363,0364,0365,0366,0367: 0370,0371,0372,0373,0374,0375,0376,0377 . to convert the value in CHAR to NVALUE SCAN CHAR IN TABLE IF EQUAL MOVEFPTR TABLE TO NVALUE ELSE CLEAR NVALUE ENDIF . to convert from NVALUE to CHAR RESET TABLE TO NVALUE CMATCH " " TO TABLE IF EOS RESET CHAR CMOVE 000 TO CHAR ELSE MOVE TABLE TO CHAR ENDIF 2. A little known and used feature of DB/C is the library support. The LIBRARY command allows any type of file to stored in and extracted from a library. This is useful for putting source code includes and .dbc files into, but it is also useful for data storage and retrieval. Any utility can read or write a member of a library. For example: REFORMAT aaa.lib(member1) bbb.lib(member2) -c reads the text file stored as member1 in library aaa.lib and creates a new member named member2 in the existing bbb.lib, while compressing each record. The following DB/C program does exactly the same thing: RECORD CHAR 8192 INFILE FILE VAR=8192 OUTFILE FILE VAR=8192, COMPRESSED SEQ FORM "-1" OPEN INFILE, "aaa.lib(member1)" PREP OUTFILE, "bbb.lib(member2)" NEXT READ INFILE, SEQ; RECORD GOTO DONE IF OVER WRITE OUTFILE, SEQ; RECORD GOTO NEXT DONE CLOSE INFILE CLOSE OUTFILE 3. In the normal operating mode for VGA color monitors in MS-DOS, there are 16 foreground colors, but only 8 background colors. The background colors that are available are the dim versions of the colors (*BGCOLOR=*YELLOW is actually brown). This is because the high order bit of the byte used to hold the attribute of each display character is used to specify the blinking mode (and that's also why underline doesn't work - there is no bit). There is a small executable file stored in the MS-DOS UTILITY PROGRAMS File Area of the DB/C bulletin board that reprograms the VGA controller to use the high order bit for brightness of background so that all 16 colors are available in the background. The name of this file is SETVGAHI.COM. Just put it in autoexec.bat and start using the colors with values 8 through 15 for your background. DB/C Class Schedule The next DB/C training class has been postponed until the first or second week of October. The final dates will be announced in the September Newsletter.