旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � DB/C Newsletter � � December 1992 � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� Editor's Notes We continue this month with the articles about basic concepts of DB/C. This month's article is about user-defined verbs. You will be hearing much more about user-defined verbs in the coming months, so if you aren't familiar with them, this tutorial is required reading. The Draft Proposed ANSI DATABUS Standard has been approved by X3 for public review. Its name is officially changed to just "The Proposed Standard for the Programming Language DATABUS". It has been forward to ANSI which will schedule the public review period. It is expected that the public review will start in December 1992 and will end in March 1993. My plea for contributions is going unheeded. Please help us out by sending a tip (no matter how small) or by giving us an idea for a tip or for an article. DNW DB/C In Use The application profile this month features the ENCORE Property Management System created by ENCORE Systems, Inc. Based in Atlanta, ENCORE Systems, Inc. develops and markets computerized management systems to the travel and leisure industry. ENCORE specializes in property management systems for the lodging segment of the industry and shipboard management systems for the cruise line segment. Using DB/C, ENCORE has developed an array of software systems that allow hotels, resorts, and cruise ships to manage all aspects of their business. The first ENCORE system was installed in 1974. More than 2300 hotels, resorts, casinos, and cruise ships have installed an ENCORE computerized management system. Clients include the Golden Nugget, Hyatt Hotel Corporation, Holiday Inn Worldwide, the Mirage Resort and Casino, Omni Hotels, the Ritz-Carlton Hotel Company, and Royal Caribbean Cruise Line. The design of the ENCORE Property Management System is modular and the system can interface with other applications, such as a telephone call accounting system. Each module features easy-to-learn, menu-oriented operation. There are approximately 700 programs in the core system. The foundation of the ENCORE Property Management System is the Front Office Module and the Back Office Module. Features of the Front Office Module include: the ability to hold reservations for up to five years from the current date, complete guest history records, simplified registration of guests, Accounts Receivable, currency conversion, and instant verification of room availability and housekeeping status. Features of the Back Office Module include: General Ledger, financial statements, Accounts Payable, and accounting history functions. ENCORE Specialty Modules allow a property to manage its other facilities and services. Features of the Specialty Modules include: club membership, budget and forecast modeling, function room booking, banquet event orders, sports scheduling, condominium management, repairs and work order scheduling, limousine scheduling, and luggage tracking. The ENCORE Property Management System is currently running on several platforms including: AT&T (NCR), Hewlett-Packard, IBM, NEC, Stratus, and Tandem. ENCORE selected DB/C as its development environment because it allows easier migration between various operating systems and hardware environments. The fact that DB/C is easy to learn was another important consideration. All of ENCORE's applications are written in DB/C, and ENCORE has been developing applications using DB/C for many years. Currently there are nine DB/C programmers on the ENCORE team. Several contract programmers have recently been added for special projects. DB/C Basics - User Verbs The VERB statement defines a user-defined verb. A user-defined verb may be used just like a regular verb in a DB/C program. However, the user-defined verb executes a CALL statement with parameters instead of being executed by the DB/C run-time. The CALL is to a label that is the same as the name of the user-defined verb. For example: PASSWORD CHAR 8 ERRMSG VERB #CVARLIT MSGPARM CHAR @ WORK1 CHAR 1 LOOP KEYIN *ES, "ENTER PASSWORD:", *EOFF, PASSWORD IF (LENGTHPTR PASSWORD < 8) ERRMSG "PASSWORD MUST BE 8 CHARACTERS LONG" ELSE IF (PASSWORD <> "PLATO!!!") ERRMSG "INVALID PASSWORD" ELSE BREAK ENDIF REPEAT CHAIN "MENU" ERRMSG LROUTINE MSGPARM DISPLAY *P=1:10, "*** ERROR ***", *P=1:11, MSG KEYIN *P=1:12, "TAP ENTER TO CONTINUE ", WORK1 RETURN The user-defined verb, ERRMSG, is defined by the VERB statement. The #CVARLIT operand means that one, and only one, character variable or literal operand is required. The ERRMSG verb can then be used like any other verb. It is used twice in the example. There are three types of operands allowed with user-defined verbs. These operand types are: positional, non-positional, and keyword. The format of a positional operand is: # The format of a non-positional operand is: = The format of a keyword operand is one of: = =: =:: =::: =:::: The syntax is the same as any other DB/C label. It must begin with a letter and it may contains letters, digits and certain other characters. The values for are: ARRAY, AFILE, ANY, CVAR, CVARLIT, CNVARLIT, CNVAR, CARRAY, CARRAY1, CARRAY2, CARRAY3, COMFILE, DEVICE, FILE, IFILE, IMAGE, LIST, LABEL, NVAR, NVARLIT, NARRAY, NARRAY1, NARRAY2, NARRAY3, QUEUE, RESOURCE, VARLIT, VAR ARRAY means that any array variable is allowed. AFILE means that an AFILE variable is allowed. ANY means that any type of variable (including an array element) is allowed. CVAR means that any character variable (either a simple character variable or one variable of a character array variable) is allowed. CVARLIT means that a character variable or literal is allowed. CARRAY means that any 1, 2 or 3 dimensional array is allowed. CARRAY1 means that a 1 dimensional array is allowed. FILE means that a FILE variable is allowed. IFILE means that an IFILE variable is allowed. IMAGE means that an IMAGE variable is allowed. LIST means that a LIST or VARLIST is allowed. LABEL means that a program label is allowed. NVAR means that a numeric variable is allowed. NVARLIT means that a numeric variable, numeric literal or decimal constant is allowed. NARRAY, NARRAY1, NARRAY2, and NARRAY3 specify numeric arrays. QUEUE means that a QUEUE variable is allowed. RESOURCE means that a RESOURCE variable is allowed. VAR means that any single valued (non-array) variable is allowed. VARLIT means that any single valued (non-array) variable or literal is allowed. The syntax of a user-defined verb is defined by the comma-delimited list of operands that follows VERB. The positional operands precede the non-positional and keyword operands. There may only be one non-positional operand, but there may be any number of the other operands. There may also be no operands. The positional operands in the VERB statement define the syntax of the user-defined verb. Each positional operand requires an operand of matching type in each position. The order of the variables and literals in the verb must match the order of the positional operands in the verb definition. The non-positional operand defines the type or types of operands that may be found in a comma delimited list after the required (positional) operands. The keyword operands define the keywords and values that may also be found in the same comma delimited list. Positional operands become the parameters of the CALL with parameters statement that is implicitly created by the user-defined verb. Non-positional and keyword operands are accessed by the GETPARM, LOADPARM and RESETPARMS statements. This example show the use of non-positional and keyword operands: DOPRINT VERB NEWLINE, P=NVARLIT, =CNVARLIT KEYWORD CHAR @ VAR1 VAR @ CHAR1 CHAR @ NUM1 NUM @ VARTYPE NUM 2 DISPLAY *ES, "MAIN PROGRAM STARTS HERE" DOPRINT "LINE 1", P=50, "AT 50", NEWLINE: "LINE 2", NEWLINE STOP DOPRINT LROUTINE LOOP GETPARM KEYWORD, VAR1 RETURN IF OVER IF (FORMPTR KEYWORD = 0) TYPE VAR1, VARTYPE IF (VARTYPE = 1) MOVEADR VAR1 TO CHAR1 PRINT CHAR1; ELSE MOVEADR VAR1 TO NUM1 PRINT NUM1; ENDIF ELSE IF (KEYWORD = "P") MOVEADR VAR1 TO NUM1 PRINT *NUM1; ELSE IF (KEYWORD = "NEWLINE") PRINT *N; ELSE DISPLAY "ERROR" ENDIF REPEAT In the DOPRINT user-defined verb definition, NEW and P are keyword operands. NEWLINE has no values associated with it. P has one - a numeric variable, numeric literal or decimal constant. The non-positional operand may be a character variable, a numeric variable, or a literal. DOPRINT itself is a LOOP/REPEAT that gets the next operand in each iteration. Each operand is returned by GETPARM. When GETPARM sets the OVER flag, the end of the list of keyword and non-positional operands has been reached. User-defined verbs are one of the most powerful features of DB/C. Build a library of them and your programming job will become far easier to do. Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips 1. Have you ever encountered a mysterious I 706 (error during write) error or I 487, I 687 or I 787 (unable to write to file) error on a Novell Netware network? Files that are responsible for the 706 and x87 errors may have a file size that is some power of two. Such a file will not grow regardless of what you try to append to it. These errors are caused when the user that created the troublesome file is deleted from the network. This deletion confuses Novell since the creator of the file is no longer present. When this occurs, Novell does not allow the file to grow beyond certain boundary sizes. The solution to this problem is to use the NDIR utility to determine who created the file. Then use the NCOPY utility to automatically change the creation ID of the copy to that of the current user. 2. The DBC_FILES and DBC_OPENLIMIT environment variables are often misunderstood. The DBC_FILES environment variable determines the size of an internal table that holds information about open files. The default is 100. If you should exceed this limit, you will get an I 665 error. One entry is used for every FILE variable or spool file opened. Each IFILE or AFILE variable that is open uses two entries, even if the IFILE or AFILE is a secondary index. Since there is a 32-byte memory allocation for every table entry allocated, and this memory allocation comes from a limited size memory pool, it is recommended that DBC_FILES not be set significantly higher than the actual number of files that will be opened. Setting this environment variable too high can cause an I 679 error to occur. The DBC_OPENLIMIT environment variable determines the maximum number of operating system file handles that DB/C will try to open concurrently in each DB/C process. The default is no limit. For FILE variables and spool files, one operating system file handle will be used. For IFILE and AFILE variables, two operating system file handles will be used; however, for a secondary index, only one file handle will be used. Typically, there is an operating system or process limit to the total (system-wide) number of file handles that can be opened at one time. To allow the user to open more files in a program than the operating system would otherwise allow, DB/C automatically closes and opens files behind the scenes. This operation is completely transparent to the user. The only files that DB/C does this for are files opened in shared or read-only mode. Typically, this operation takes place when DB/C tries to open a file and an operating system error indicating that either the total system file handle limit has been exceeded or the process limit has been exceeded. When this occurs, DB/C closes the least recently used file and attempts to open the file again. DBC_OPENLIMIT can be used to limit the number of open file handles before the operating system or process limit has been reached. For example, suppose a Novell Netware or UNIX system has a limit of 400 file handles opened by all users combined. Assume there are 11 users, each with an individual limit of 40 open file handles. Now assume that the first 10 users open all of their file handles so that there are 400 handles in use. As a result, the eleventh user is not able to open any files. If DBC_OPENLIMIT is set to 31 (i.e. 400 / 11 - 5) for Netware or 33 (i.e. 400 / 11 - 3) for UNIX, then all 11 users are able to open their files. MS-DOS has a five file handle overhead for each process and UNIX has a three file handle overhead for each process. In MS-DOS, there is one additional feature of DBC_OPENLIMIT. If DBC_OPENLIMIT is set to a value greater than 20, then DB/C calls the MS-DOS function "set handle count" to allow a process to open more than 20 files. The default per process file handle limit for MS-DOS is 20, which only allows 15 operating system file handles to be opened (remember the overhead of five handles are used by MS-DOS). To allow DB/C to open more than the default, use DBC_OPENLIMIT in conjunction with FILES= in the config.sys file or with FILE HANDLES= in the net.cfg file if you are using Novell NetWare. IDUG Update The International DATABUS Users Group (IDUG) Conference and Exhibition is scheduled for January 23-26 in Scottsdale, Arizona. An opening reception is scheduled for the night of January 23rd. The schedule for the conference includes vendor specific conferences on the 24th, the keynote address on 25th and various break-out sessions and forums on the 25th and 26th. The exhibition will feature booths of various vendors of DATABUS products and services. Subject, Wills & Company will be very involved in the conference and will have a booth at the exhibition. Plan to attend - it is a worthwhile event. For more information contact Tim Jenks at: Phone: (616) 242-0209 FAX: (616) 454-3939 Compuserve: 75360,1734 DB/C Class Schedule The next DB/C class is scheduled to begin February 1, 1993 at the Oak Brook, Illinois office of Subject, Wills & Company.