旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � DB/C Newsletter � � May 1992 � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� Editor's Welcome I hope you enjoy this first issue of the DB/C newsletter. We plan to publish it on the first day of each month on the DB/C bulletin board located in Oak Brook, Illinois, USA. The newsletter is not copyrighted. We hope you will copy it (either in printed or computer form) and circulate it to others who are interested in DB/C or DATABUS. There are several objectives that we hope the newsletter will achieve. The primary objective is to enhance the image of DB/C in the general computing market. As we all know, DATABUS and DB/C are niche languages in the family of 3rd generation computer languages. DB/C has many advantages that keep us all programming with it. The newsletter may help get the word out to others who could gain from using DATABUS and DB/C. Other objectives of the newsletter are (in no particular order): . To announce DB/C software and its availability . To provide helpful tips about the use of DB/C . To tell you how people and businesses are using DB/C . To provide general DATABUS information (e.g. the status of ANSI Standard) . To summarize the discussions and what's available on the Oak Brook BBS I am new to the newsletter business, so it will have a very simple format. There will be announcements, articles and two regular columns. The regular columns will be called "DB/C In Use" and "Tips". The "DB/C In Use" column will contain an overview of actual DB/C applications that are in production. I am the author of "DB/C In Use" this month, but I am hoping that newsletter readers will submit articles about their own applications that can be used there. The "Tips" column will be give you helpful hints on using DB/C. We have set up a message area in the BBS to provide a forum for feedback about the newsletter. The message area is called "Newsletter Feedback". Please tell us what you like and disklike about the newsletter. We also would appreciate any ideas that you may have for topics to discuss in future issues. DNW The Oak Brook DB/C BBS The Oak Brook DB/C BBS is not the first bulletin board that Subject, Wills & Company (SWC) has been associated with. SWC had previously attempted to support a general purpose DATABUS bulletin board located in Dallas, Texas. Unfortunately, very little activity occurred on that bulletin board and no other DATABUS compiler vendors seemed to care about it. It was also not convenient for Subject, Wills & Company personnel to transfer software to and from it for debugging, support and bug fix transmission. Therefore, about six months ago we decided to set up a bulletin board in the home office of SWC. We tested a few BBS software packages and decided on the MAXIMUS-CBCS Version 2.00 for OS/2 package. The primary reason for using OS/2 was because we thought that it would handle serial ports better, and being a real multitasking operating system, that it had more growth potential. After trying various hardware and software configurations we finally got it to be reasonably responsive and only somewhat unstable. The BBS is running on the first release of OS/2 2.0. The file storage area is on our central Netware 3.11 file server. The BBS is connected to the outside world via a serial port and a Courier HST modem (1200/2400/9600). We will add more telephone lines if usage warrants it. The following paragraphs give descriptions of the things we hope to accomplish and the intend use of the bulletin board. The primary use is to support DB/C programming. Many of the questions that arise while using DB/C are easier to answer on the BBS than on the phone. Many times program examples are needed before a discussion can even begin with one of the DB/C support staff. The BBS provides a superior method of communi- cating the program examples. Other problems or questions occur after normal business hours. While the problem is fresh on your mind, you can dial up and describe it quickly. Another important use of the BBS is to distribute software fixes. Without a bulletin board, the quickest that software can be sent to customers is by overnight courier. This is expensive and causes hours of delays. In our ever faster paced world, a few hours is important. Software fixes can be made available for downloading immediately after they are resolved. This is good for all involved. Probably the most enjoyable aspect of the BBS is to promote discussion about DB/C. This may sound like a cliche, but DB/C is a living entity. It has a history and it has a future. You are an important part of it. Without you, the programmers who use it, DB/C would die. The message area that is called "DB/C Past, Present and Future" is the forum for you to express anything related to DB/C. Topics for this message area might be suggestions for new language features, new utilities, changes to support, documentation, packaging, pricing, etc. We plan to incorporate many of the ideas that come from this message area. Many of the file areas on the BBS will be dedicated to providing you with a library of software. This is software that is not of interest to most users of DB/C, but that a few people are very interested in. Examples are: C-ISAM support routines, dBASE support routines, special device support routines, and graphics image files. There will be one or more file areas dedicated to contributed DB/C source programs that provide various functions. All of the software in these file areas will be completely free of copyrights or other limits. It will also be provided without any support whatsoever. The DB/C BBS will NOT be a forum for discussion of hardware performance, price or other competitive information. We will always provide you with a list (and explanation) of the platforms on which DB/C runs. We have worked hard to maintain complete neutrality with regard to hardware and we don't want our neutrality compromised. Thus, we won't allow the BBS to be a forum for any information (positive or negative) concerning hardware price/performance. We will be glad to provide you with references for DB/C users of specific computers, but it is up to you to contact them on your own. We hope you use the Oak Brook DB/C bulletin board. DB/C 8.0 We have talked to many DB/C customers about the next release of DB/C. The name of it is DB/C Release 8.0. It has not been officially announced. When it is announced, we will have the text of the Announcement Summary on the BBS. Until then, we will only describe a general overview of some of the features that will be incorporated into it. Here is a list: 1. Support for 8 MB data area and 8 MB program area per module. 2. Graphical User Interface programming as well as character mode support for Windows 3.1, Macintosh System 7, and OS/2 2.0 PM. 3. MS-DOS 386 support for DBCMP.EXE, DBC.EXE and all utilities - this translates into faster execution and no more 640K memory limit problems. 4. A complete REPORT WRITER targeted for use by end-users. 5. A program generation system, FAST PROGRAMMING, for use by programmers. 6. Support for ANSI Standard DATABUS. We will have more information about DB/C 8.0 in the June Newsletter. DB/C In Use The application profile for this first issue of the DB/C Newsletter is about the Contract Management System that is in use at Chrysler Systems Leasing in Oak Brook, Illinois. The system is designed to the specifications of Chrysler Systems Leasing and was programmed by Subject, Wills & Company. The most interesting aspect of the system is that it is a document image storage and retrieval system. Full pages are scanned, stored, retrieved, displayed and printed under control of the DB/C programs. The image system hardware was provided by LaserData Corporation. The hardware consists of scanners, printers, an optical disk jukebox and 19 inch high resolution displays. The scanners, printers and high resolution displays work with a PC card that does image compression and decompression. All of this is connected by Ethernet. The optical juke box is connected to a special server PC. Programs and non-image data resides on a Netware 386 file server. The primary activity of Chrysler Systems Leasing is to lease large capital outlay items (particularly computers) to businesses. Their operation is very paper intensive. There are usually 20 or more pages of contracts, invoices, letters, and miscellaneous documents associated with each lease. In some cases there are hundreds of pages associated with a lease. The clerical costs, space requirements and document losses associated with a paper system justified the cost of an electronic image filing system. The DB/C programs run under an MS-DOS version of dbc.exe that has been linked with special Device Support Routines that allow access the LaserData scanner, printer, display and optical disk server. The special Device Support Routines are written in the C language using the information provided in the DB/C Programmer's Guide. This C module calls functions in a C library provided by LaserData. Functions in this library provide to control imaging hardware. The verbs contained in the DB/C programs are simple. Here are examples: LASERDATA DEVICE VOLNAME DIM 3 IMAGENAME DIM 8 OPEN LASERDATA, "LaserData" CHANGE LASERDATA, "SCAN_AND_DISP" CHANGE LASERDATA, "DISP_WS" CHANGE LASERDATA, "PRINT_WS" CHANGE LASERDATA, "SET_VOLUME"; VOLNAME CHANGE LASERDATA, "WS2OPD" QUERY LASERDATA, "GET_FILENAME"; IMAGENAME CHANGE LASERDATA, "OPD2WS"; IMAGENAME CLOSE LASERDATA WS stands for working storage. OPD stands for optical disk. Working storage is the logical place where an image resides while it is in the workstation. Each of the commands is somewhat self-explanatory. SCAN_AND_DISP causes the scanner to scan a page, store it in working storage and display it on the display screen. WS2OPD means copy the image from working storage onto the optical disk volume specified by the SET_VOLUME operation. LaserData creates the image number for the image just stored and returns it into the variable IMAGENAME when the QUERY "GET_FILENAME" is executed. The Contract Management System was created using these verbs and standard DB/C programming techniques like AIM lookups on the document description field. The pages of documents are organized into logical folders that contain all of the documents for a lease. The entire system consists of fewer than 20 programs, but provides for all facets of managing the lease contract documents. The system has been in operation for about 12 months. The decision was made not to back scan all existing files, but to scan only the documents associated with all new leases. With each passing month, the system becomes more integral (and mission critical) to the entire operation. It has been a great success. Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips The subject of our first Tips column is performance tuning of AIM files. AIM (Associative Index Method) is a feature that is truly unique to DATABUS. Most other business oriented programming languages have ISAM type file systems, but none has anything similar to AIM. I won't go into the algorithm behind AIM in this column. For an overview of that, please refer to an article written several years ago that can be found in the "Articles and Marketing Fluff" file area. The performance characteristics of AIM READs and WRITEs are non-obvious. In general, if more key information is specified on a READ statement, performance is better. Conversely, if more fields (and characters) are contained in the AIM keys, then the WRITE performance gets worse. These are general rules only - specific instances can be shown where these general rules are invalid. These specific instances are usually very data dependent. That is, the actual data stored in the key fields and used in the lookup key fields has a impact on performance. Sometimes this impact is large. Key fields are logically broken up into triplets before they are stored in the AIM index. Each triplet is three non-blank, contiguous characters. Each of these triplets causes one bit to be turned on in the AIM index. Therefore, the time to do AIM WRITEs for two records to the same AIM index file will depend on the number of triplets. The key "HELLO, JOE" contains 5 triplets. The key "HI JOE " contains 1 triplet. The time to write the index information might be as large as 5 times as long for the record containing "HELLO, JOE" than for the record containing "HI JOE". The time comparison will depend on several other factors too: the Z value, the size of data file, the size of the data record, and the operating system buffering. The "HELLO, JOE" record, however, can potentially be read much faster than the "HI JOE " record, if the read specifies both "JOE" and "HELLO" in the list of floating keys to search for. Both "HI" and "JOE" can be specified for the read of the other record, but the "HI" is not used to search the AIM index because it is not a triplet. The -Z and -F options on the AIMDEX command line are the two most important factors in determining performance. The -Z option is also called the Z value. The number specified as the Z value controls the size of the .AIM file in a linear fashion. For files with the same number of records, the AIM file using -Z=400 is twice as big as the AIM file using -Z=200. In general, for larger the Z values, READ performance is better, but WRITE performance is worse. In addition, depending on the keys, certain Z values work better than others. Z values that are prime numbers tend to work better (but not always). It is best to experiment with Z values on your actual production data to find your best performance. The -F option specifies that only fixed length records will be contained in the data file. Always specify this if your file has only fixed length records. Both read and write performance is enhanced by using this option. In summary, tuning AIM indexes is done mostly by trial-and-error. With the knowledge gained here, and by experimenting with your data, you should be able to provide good performance for users of your application. DB/C Class Schedule The next DB/C 7.0 training class is scheduled for June 1, 2 and 3 in the Oak Brook training facility at Subject, Wills & Company. The cost is $500. The only requirement is experience with at least one other business oriented programming language. The class is useful for experienced DATABUS programmers, as well as those without any knowledge of DB/C or DATABUS.