ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ DB/C Newsletter ³ ³ June 1992 ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Editor's Notes Welcome to the second issue of the DB/C Newsletter. A few readers commented that they are interested in downloading the Newsletter. On the DB/C BBS, the file area called DB/C Newsletters contains files that are the text files that are the text of the newsletters. These files do not contain control information necessary for displaying colors. We are working on a way to let you view the Newsletters in color in offline mode. There are several methods to accomplish this with the BBS software, but they require that you have an MS-DOS machine. We don't want to do that so we're still working on a solution. In the meantime, text files will have to suffice. Which brings me to the topic of BBS's - what a Brave New World that is. BBS terminology is as complex and convoluted as the terminology of the computer industry itself. The DB/C BBS is Maximus-CBCS Version 2.00. Here is just a sample of the terms used: AVATAR, BinkleyTerm, Telix, FidoNet, Seadog, LZH, QWK Mail, WaZOO, FOSSIL (Common FOSSILs are X00, BNU and OpusComm). Whew! We are trying to learn the MAXIMUS-CBCS well enough to configure the DB/C BBS to do what we want it to do. If anyone has any suggestions, please talk to us. The DB/C In Use article is (again) about a Subject, Wills & Company system. It was my hope that a few of you might submit articles about applications that you are involved with. I will be more direct this time - PLEASE SEND ME ARTICLES TO PUT IN THE DB/C IN USE COLUMN. The Tips column contains several helpful hints. If you have any tricks that you are interested in sharing, please leave me a message describing your tip. Or if you just have a technical question, ask it and I will attempt to answer it either directly or in the Tips column. We hope you enjoy this issue of the DB/C Newsletter. We would like to know what you think - so please leave us a message in the Newsletter Feedback message area after you have read this issue. All suggestions are welcome. DNW DB/C 8.0 Fast Programming One of the major new features that will be included in the next release of DB/C is a program generator system called Fast Programming. FP is a series of programs (written in DB/C) that generate DB/C source code and programs. In most program generators and CASE tools, the information about the data items, their relationships, and the programs that manipulate the data items, is stored in a dictionary (sometimes called a repository). FP is similar. All file definition information is stored in the Data Dictionary and all program definition information is stored in the Program Dictionary. The programmer or systems analyst enters system design information into these dictionaries. The main menu for FP looks like this: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ MENU ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ Data Dictionary ³ ³ Program Dictionary ³ ³ Generate ³ ³ Edit file ³ ³ Compile program ³ ³ Run program ³ ³ Modify system parameters ³ ³ Set system id ³ ³ Modify colors ³ ³ Report Writer setup ³ ³ Quit ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ The Data Dictionary supports indexed, direct and AIM access. Support for up to 9 indexes, as well as mixed AIM and ISAM access is supported. Standard data types for data items include: character, numeric, date (several types), and YesNo fields. A special feature is the ability to add your own data types. For example, you can create a data type called CUSTNUM that is used instead of C (character) in the data dictionary. CUSTNUM is defined in the Types maintenance function of the Data Dictionary. For example, CUSTNUM could be defined as character length 5, digits only, right justify, zero fill. Any data element defined as CUSTNUM would inherit these attributes. The Program Dictionary creates complete programs. If the program is an entry type program, the screen layout is defined using the screen painter. If the program is a view type program (columnar data display), the screen layout is defined by entering specifications into the dictionary. In some situations, the program is used as a front-end to a processing module that is hand-written. In all cases, special changes to programs are isolated into separate source files. This allows programs to be regenerated without losing any changes that may have been done. The Generate menu function causes file includes and complete programs to be generated. The Edit file menu function does a ROLLOUT to EDIT. Likewise, the Compile Program function does a ROLLOUT to DBCMP. These will work in all versions of DB/C 8 except not in the 8086 MS-DOS version. (It will work fine in the 386 version of DB/C 8.) The Report Writer setup function creates the files necessary for another new feature in DB/C 8 - The Report Writer. This will be discussed in depth in next month's DB/C Newsletter. The Report Writer uses the Data Dictionary part of Fast Programming. Another major aspect of Fast Programming is the Library of User-Defined Verbs. Here is a list of the names of these verbs: ACTION, ACTIONBAR, ACTIONBARMSG, ACTIONEND, BOX, COLOR, COLORGET, COLORRESET, DIALOG, ENDACTION, ENDSCREEN, ENDVIEW, ERASEMSG, ERROR, FBUILDKEY, FCHANGEKEY, FCHECKKEY, FCLOSE, FCREATE, FDELETE, FFIND, FFINDAIM, FFINDBACK, FFINDNEXT, FFINDWITHKEY, FFPOSIT, FGETKEY, FMAKEKEY, FOPEN, FREAD, FREADAIM, FREADBACK, FREADNEXT, FREADNUM, FREADSEQ, FREADWITHKEY, FREREAD, FTRAPIO, FUPDATE, FWRITE, FWRITESEQ, LISTBOX, MENU, SCREEN, SCREENDISPLAY, SCREENERASE, SCREENFORMAT, SCREENGETINDEX, SCREENKEYIN, SCREENKEYINEND, SCREENPAGEBACK, SCREENPAGENEXT, SCREENPAGESET, SHOWMSG, STACKCLEAR, STACKPOP, STACKPUSH, TITLE, TOLOWER, TOUPPER, TRAPSTKCLEAR, TRAPSTKPOP, TRAPSTKPUSH, UNBOX, USEACTION, USESCREEN, USEVIEW, VIEW, VIEWINSAFTER, VIEWINSBEFORE. These verbs provide many higher level functions to make the programmer's job easier. In essence, they constitute a reusable code library. Many of these user verbs are useful by themselves - you do not need to use the rest of Fast Programming to take advantage of them. The first beta test versions of DB/C 8.0 will be for MS-DOS and Windows. They will include Fast Programming and the Report Writer. We expect to begin the formal beta test program by the end of June. DB/C 7 versus ANSI DATABUS The ANSI DATABUS Standard is just a few weeks from public review. All technical issues have been agreed upon and the committee is just tidying up the physical document before submitting it to the public for the mandated public review period. In this article, we will attempt to convey the differences between ANSI Standard DATABUS and DB/C version 7. With one major and several minor exceptions, DB/C 7 is a superset of Standard DATABUS. The one major exception is the print file variable, or PFILE. DB/C 7 does not support it (DB/C 8 will). Here is an example of PFILE: PRINT1 PFILE PRINT2 PFILE SPLOPEN PRINT1, "file1.prt" SPLOPEN PRINT2, "file2.prt" PRINT PRINT1; *F, "This goes to file1.prt" PRINT PRINT2; *F, "This goes to file2.prt" PRINT *F, "This goes to the default printer" SPLCLOSE PRINT1 SPLCLOSE PRINT2 All of the rest of the comparison describes DB/C features that don't exist in ANSI Standard DATABUS. These DB/C data variable types are not included in Standard DATABUS: INTEGER, FLOAT, COMFILE, DEVICE, RESOURCE, IMAGE, QUEUE, VAR, and LABEL. Global variables are not supported. Address variables are not supported. The #IF... verbs are named %IF... These compiler directive statements are not supported: DEFINE, VERB and CVERB. These data manipulation verbs are not included in Standard DATABUS: the exponential functions (EXP, LOG), GETPARM, LCMOVE, LOADADR, LOADLABEL, LOADPARM, MOD, MOVEADR, MOVELABEL, MOVELENGTH, MOVELV, MOVESIZE, MOVEVL, RESETPARM, SET, SQUEEZE, STOREADR, STORELABEL, TEST, UNPACKLIST. These program flow control verbs are not included in Standard DATABUS: CCALL, DISABLE, ENABLE, EXTERNAL, FOR, LOADMOD, ROUTINE, LROUTINE, SWITCH, CASE, DEFAULT, ENDSWITCH, UNLOAD. These other verbs are not included in Standard DATABUS: CONSOLE, DRAW, GETCOLOR, GETCURSOR, GETPOSITION, SOUND, SPLOPT, FLUSHEOF, READLK, READKSLK, READKGLK, READGPLK, UNLOCK. All queue, device, resource, SQL and communications verbs are not supported in Standard DATABUS. The support for expressions is more limited in Standard DATABUS. Several operators are not included (for example, character concatenation (+)). CALL with parameters is not supported. Record locking is not supported. These function key names are not supported: HOME, END, PGUP, PGDN, TAB, BKTAB, INSERT, DELETE, ESC and ENTER. The *EDIT control code in KEYIN is not supported. What's left is called ANSI Standard DATABUS. DB/C In Use The application profile this month is about the Produce Pro produce wholesaler software system. This is vertical market application that Subject, Wills & Company created and is selling to the wholesale produce industry. The first user of the system was Caruso-Cirese, Inc. of Cincinnati, Ohio. Their hardware environment is a Novell Netware LAN with 30 workstations. The application is written completely in DB/C. Much of the system was generated with an older version of Fast Programming (see the article above). It is heavily dependent on color, on WINSAVE/WINRESTORE, and on the concept of load-modules. The use of load-modules makes many system features available from any program, while still living in the 640K memory area of MS-DOS. For example, the customer lookup and maintenance window can be brought up with a function key. The color of the customer window is distinct so that an operator can readily tell which function is currently active. When the customer is located or entered into the system, the customer window is removed and the previously active function continues, with the customer number filled into the appropriate field. This level of functionality would be almost impossible to accomplish without many of the new features of DB/C. Produce Pro consists of Order Processing, Sales Analysis and Lot Profitability, Inventory Control, Purchasing, Accounts Receivable, Accounts Payable, and General Ledger. The system consists of approximately 400 programs and load modules. It has been installed on UNIX and MS-DOS networks. Produce Pro interfaces with many types of printers, print spoolers, FAX gateways and with suppliers and customers via modem (EDI). Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips This month's Tips column contains five helpful hints. 1. In UNIX, all filenames are case sensitive, including executable programs. This can cause a problem with the DB/C utilities which are all distributed with lower case names. For example, the aimdex command is named "aimdex", and therefore any CHAINs that contain an AIMDEX command line will not execute. Renaming "aimdex" to "AIMDEX" is one solution, but when typing at the keyboard, lower case is more convenient. A better solution is to make an alias for "aimdex" with the "ln" command like this: ln aimdex AIMDEX 2. If you are running out of data area (48K limit per module) in a program that would be hard to modularize (turn into 2 or more modules), change one or more of your largest variables into global variables. For example, change: RECORD DIM 500 to: RECORD GDIM 500 Global variables are kept in a separate 48K data area. Beware that global variables do not go away on CHAIN. 3. To speed up CPU intensive sections of code, consider changing FORM variables to INTEGER or FLOAT. FORM variables that are FORM 9 or smaller with no decimal point are candidates for conversion to INTEGER. The only caveat is that when the FORM variable overflows, its value goes back to "0" and the OVER flag is set. This does not occur for INTEGER variables. INTEGER variables are stored as 32 bit signed integers. Calculations can be many times faster than with the same values in FORM variables. FORM variables that contain less than 14 decimal digits are candidates for conversion to FLOAT. DB/C FLOAT variables are 8 byte floating point variables. The same problems occur as with INTEGER, except that rounding and precision problems also occur. If these are not an issue, and if floating point hardware is available, then FLOAT is a good choice. 4. We frequently get reports of problems on standalone MS-DOS machines with files corrupted after power interruptions. This happens because MS-DOS only updates the directory size of a file when it is closed. When a new record is written at the end of the file, the EOF character is overstored with the first byte of the record. The rest of the record is written too, but it is not visible because the file size only includes the first byte of the new record. The BEST SOLUTION to this problem is to buy an uninterruptible power supply (UPS) for a few hundred dollars. The next best solution is to put a FLUSHEOF statement after each WRITE statement. The FLUSHEOF solution has two drawbacks: performance suffers; and it doesn't cause the problem to disappear completely - it will just occur less frequently. 5. The most frequent problem that DB/C support deals with is file locking. DB/C internal errors 1600 through 1699 all are typically caused by a failure to obtain a file lock from the operating system. In UNIX, the most likely cause of this problem is that the kernel is not configured with enough lock handles. In Novell, the most likely cause of the problem is that a station was turned off while it still owned a lock. This situation will eventually fix itself (Netware polls each station once every 5 minutes), but is a major cause for annoyance. TSR programs, network errors and Windows 3.x are also culprits. DB/C Class Schedule The next DB/C training class is tentatively scheduled for September 14, 15, and 16 at the Oak Brook training facility of Subject, Wills & Company. These dates will be finalized in July.