旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � DB/C Newsletter � � November 1992 � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� Editor's Notes We continue this month with the articles about basic concepts of DB/C. This month's article is about load modules. Load modules are another feature of DB/C that does not exist in other DATABUS compilers. This article should help you take advantage of one of DB/C's most powerful features. The X3J15 committee (the committee creating the ANSI DATABUS Standard) completed its letter ballot after finishing work on the ANSI Standard. The vote was ten in favor and none opposed. The Standard is now being sent to the parent committee to start the public review period. Public review will probably begin in January 1993 and will last four months. The next version of DB/C (known as Release 8.0) is now being beta tested. We have found several minor incompatibilities with DB/C 7.0 during this testing. The article "DB/C 8.0 Planning" should help to make the transition to 8.0 as easy as possible. About 40% of current DB/C sales are to customers outside of the US. The international aspect of DB/C is very important for the future. Therefore we enlisted Jan Eriksen, the DB/C reseller in Scandinavia, to write this month's "DB/C In Use" article. We did come up with one tip for this month's Tips Tips Tips ... column, but as usual, I would appreciate any ideas that you may have for that column or for future articles. DNW DB/C In Use This column was written by Jan Eriksen of Info Vision, Norway. Info Vision is a DB/C reseller. The application profile this month features the TLP2000 Payroll and Personnel Administration system. This application is designed, developed, and marketed by Total Personalsystemer A/S, located in Oslo, Norway. Norway is one of the largest DATABUS strongholds in the world. In a country with a population of approximately four million people, we estimate that there are 3000 installations running DATABUS. The people at Total Personalsystemer all are experts in the field of payroll and personnel administration, and they specialize in this type of system. Their goal is to become Norway's leading distributor of payroll and personnel administration systems and the leading supplier of services in this field. Eventually they want to expand internationally. The TLP2000 system is designed for use both in the private and public sectors of the economy. The TLP2000 system was developed from scratch in DB/C over a period of approximately one year. It now consists of 250 to 300 programs. The system is character based and uses graphical characters for the drawing of lines and boxes. The TLP2000 system is heavily dependent on color, WINSAVE/WINRESTORE, and the use of subwindows. To enhance the user friendliness of the system, pop-up menus and message boxes are used. The system was developed using SysteMaker from Infopro, Inc., with a high level of template customization. It is integrated with GuideMaker (also from Infopro) as a menu system. From the start, it was decided that the system should be highly portable and not dependent on a particular platform. One of the main reasons for choosing DB/C was the range of platforms supported by DB/C and that DB/C has object code portability. DB/C is a very stable product and has features not available with any other DATABUS compiler. Another key consideration was that the compiler must be compliant with the forthcoming ANSI Standard. In addition, experience has proven that you can find yourself in a difficult situation if you choose a solution where you are dependent on just one distributor. Altogether it was a simple decision for Total Personalsystemer: DB/C was the answer. TLP2000 is a highly specialized and sophisticated system. It was developed to meet all the requirements of a payroll and/or personnel department. The design is modular and the system can interface with other applications. It has modules for user-defined calculations and accumulators. It has modules for simulations and for drawing budgets based on real data and calculations. All reports can be previewed on the screen, printed directly, or spooled. There is help text available for every menu item and every data field in the system. TLP2000 also includes an ad-hoc inquiry and report system. Although TLP2000 has been on the market for just a few months, it is already installed at a number of sites, among them the Norwegian National Bank. It is currently running on several platforms, including VAX/VMS, IBM RS/6000 AIX, HP 9000/800 UNIX, Texas Instruments UNIX, Novell, and OS/2. We are currently in the process of implementing support for Oracle SQL using an enhanced DB/C Oracle SQL interface module. Total Personalsystemer has already signed contracts for 21 installations of the Oracle-based version of TLP2000. The next step may be to use DB/C version 8 to implement a graphical user interface in the system. DB/C Basics - Load Modules A compiled DB/C program is called a module. Modules can be primary or secondary. A module is a primary module if it is the first program started by the DB/C run-time or if it is started by the CHAIN verb. A module is a secondary module if it is loaded by the LOADMOD verb or with the DBC_PRELOAD run-time environment variable. Program execution begins with the first statement of a primary module and can continue into secondary modules by execution of GOTO, CALL, BRANCH, PERFORM, or user-defined verbs. Here is an example: Program 1: . THIS IS THE PROGRAM (PRIMARY MODULE) STARTED USING THE DBC COMMAND CHAIN "FIRST.DBC" Program 2: . THIS IS THE PROGRAM (PRIMARY MODULE) NAMED "FIRST" XLABEL EXTERNAL LOADMOD "SECOND" GOTO XLABEL Program 3: . THIS IS THE SECONDARY MODULE NAMED "SECOND" XLABEL ROUTINE DISPLAY "SECOND IS EXECUTING" STOP The CHAIN statement in Program 1 starts execution of a new primary module, named FIRST. The first executable statement of FIRST is a LOADMOD statement that loads the secondary module named SECOND. The GOTO statement causes execution to continue with the label XLABEL in SECOND. The message "SECOND MODULE IS EXECUTING", is displayed and then the STOP statement is executed. There is only one primary module active at any time. There can be multiple secondary modules loaded. There can even be multiple copies of a secondary module loaded concurrently. Each secondary module is loaded by a LOADMOD statement. Each copy of a secondary module is called an instance of a module. The LOADMOD verb is used to create and switch between instances of secondary modules. For example: LOADMOD "SECOND" LOADMOD "SECOND" These two statements load two copies of SECOND. These copies are named and . After the second LOADMOD executes, the instance is the current instance. Each instance uses a shared copy of the program area, but each instance has its own copy of the data area of the module. The current instance implies which copy of the data variables are currently active. The LOADMOD statement is used to change which instance is current. For example: LOADMOD "SECOND" LOADMOD "SECOND" LOADMOD "SECOND" These three LOADMOD statements load two instances of the module named SECOND. The third LOADMOD does not actually load another instance of SECOND; it just makes the instance named be the current instance. The UNLOAD verb is used to destroy one or all instances of a secondary module. UNLOAD can also unload all secondary modules. Execution of the CHAIN verb by the primary module or by a secondary module unloads the previous primary module and all secondary modules that were loaded with LOADMOD statements. Execution continues with the new primary module specified in the CHAIN statement. A module is a permanent secondary module if it is preloaded by using the DBC_PRELOAD=module run-time environment variable. UNLOAD and CHAIN do not affect permanent secondary modules. Like the primary module, there is only one instance of a permanent secondary module. Each program execution label is local to the module in which it is compiled unless the label has been specifically defined as global. A local label is unknown to other modules. A label is made global with the ROUTINE statement. The EXTERNAL statement causes a label reference to refer to a global label that is defined with a ROUTINE statement in another module. Here is an example of the LOADMOD verb used with multiple instances: Program 1: . THIS IS THE MOD1 MODULE LAB1 EXTERNAL LAB2 EXTERNAL LAB3 EXTERNAL LOADMOD "MOD2" CALL LAB1 LOADMOD "MOD2" CALL LAB2 LOADMOD "MOD2" CALL LAB3 UNLOAD "MOD2" UNLOAD STOP Program 2: . THIS IS THE MOD2 MODULE VAR1 DIM 1 LAB1 ROUTINE MOVE "X" TO VAR1 RETURN LAB2 ROUTINE MOVE "Y" TO VAR1 RETURN LAB3 ROUTINE DISPLAY VAR1 RETURN X is displayed as a result of executing the MOD1 program. In the module MOD1, LAB1, LAB2, and LAB3 are defined as external labels because they are not found in MOD1. The first LOADMOD statement loads the program area and the data area of MOD2. The name of this instance is . LAB1 is called and execution continues into the secondary module, MOD2. The letter X is moved to the variable VAR1 in the data area of the module instance. Execution returns to MOD1. The second LOADMOD statement loads MOD2 again, but this time the instance is . A new copy of the data area is created. LAB2 is called and execution continues in the secondary module. The letter Y is moved to VAR1 in the data area of the module instance. Execution returns to MOD1. The third LOADMOD statement causes to be made the current instance of MOD2. Then LAB3 is called and execution continues into MOD2. The variable VAR1 from the data area of the instance is displayed. Its value is X. Execution returns to MOD1. The first UNLOAD statement unloads the instance of MOD2 called . The second UNLOAD statement unloads all currently loaded secondary modules, which by now is just MOD2. DB/C modules allow code to be created that can be used by multiple programs without having to include the code in each program. This powerful feature of DB/C is indispensable in large applications. DB/C 8.0 Planning Two aspects of DB/C 8.0 will cause some changes to occur in existing programs. These two aspects are: 1. DBCMP 8.0 was completely rewritten 2. DB/C 8.0 will be 100% in conformance with the ANSI Standard for DATABUS There have been several small problems that have arisen because DBCMP was rewritten. The most major of these problems is the recognition that the difference between a variable label and a program label was inconsistent. There were a few places in the language that allowed both types of labels. For example: X DISPLAY "Program start" #IFDEF X DISPLAY "X is defined" #ENDIF In DB/C 7.0, this would display "X is defined" because the label X was defined. The ANSI Standard adopted the #IFDEF construct, but changed it to %IFDEF because the # is not available on keyboards outside the US. The DB/C 7.0 documentation and the ANSI Standard both state that the IFDEF compilation directive would succeed if the data variable (only) is defined. That is the way that DB/C 8.0 works. Unfortunately, some programmers found that the DB/C 7.0 compiler worked as in the example. Those programs won't compile the same way under the DB/C 8.0 compiler. We have added %IFLABEL and %IFNLABEL to the DB/C 8.0 compiler to allow testing for the existence or non-existence of program labels and program label variables. Unfortunately, if your programs depended on the way the DB/C 7.0 compiler worked, you will have to change your programs before compiling with DBCMP 8.0. (As always, DBCMP 7.0 and prior .dbc files will execute correctly with DBC 8.0.) We have addressed the data variable names conflict with program label names in other ways also. Here is an example: X DIM 1 X DISPLAY "First program line" Y DISPLAY "Second program line" CALL DOIT USING X CALL DOIT USING Y In this example, the first CALL to DOIT would pass the address of the DIM variable X to the DOIT routine. The second call to DOIT would pass the program label Y to DOIT as if it were a LABEL @ variable. This inconsistency, as well as others, was fixed in DB/C 8.0 by completely separating the program label name space from the data variable name space. The only effect we know of was to CALL and ROUTINE. These verbs will only allow data variables to be passed by CALL and to be the destinations in the ROUTINE list. If you had discovered the trick of CALL using program labels and used it in programs, you will need to change your source. In this case, you can change your source in DB/C 7.0. The way to do this is to change the CALL to a user-defined verb, and to change the ROUTINE to contain VAR @ variables in the ROUTINE list. For example, if your code currently looks like this: LINE DIM 80 LBLVAR LABEL @ GOTO START OUTPUT DISPLAY LINE RETURN START CALL DOIT WITH OUTPUT STOP DOIT ROUTINE LBLVAR MOVE "HELLO" TO LINE CALL LBLVAR RETURN You can change your code to accomplish the same thing: LINE DIM 80 LBLVAR VAR @ LBLWORK LABEL @ DOIT VERB #LABEL GOTO START OUTPUT DISPLAY LINE RETURN START DOIT OUTPUT STOP DOIT ROUTINE LBLVAR MOVEVL LBLVAR TO LBLWORK MOVE "HELLO" TO LINE CALL LBLWORK RETURN Note that the #LABEL operand on the VERB statement is not in the DB/C 7.0 Language Reference, but was added after the manual was printed. Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips The command parameter -P (used with BUILD and other commands) causes records to be selected based upon their content. A problem frequently occurs when a user wants to select a record that contains a character in one position OR another character in a different position within the record. For example, assume the following records exist: ABCD ABDE ACDE The user may want to select any record containing a B in position 2 OR a C in position 3. This presents a problem because when multiple -P parameters are specified on a command line the search specifications are logically AND-ed together. For example, if the user typed the following on the command line: BUILD FILE1 FILE2 -P2=B -P3=C FILE2 would be created with the record ABCD only. This is because the search specification is equivalent to the expression: (-P2=B) AND (-P3=C) Since the DB/C commands do not provide an OR operation for multiple -P parameters, it would seem impossible to use the search specification (-P2=B) OR (-P3=C). However, DB/C commands that allow the -P parameter also provide the -X parameter to reverse the selection specification of -P parameters. We can apply DeMorgan's Law to our desired expression and rewrite (-P2=B) OR (-P3=C) as NOT (NOT (-P2=B) AND NOT (-P3=C)) This last expression may be expressed as: NOT (-P2#B AND -P3#C) Therefore, to achieve the desired result, the following should be typed on the command line: BUILD FILE1 FILE2 -P2#B -P3#C -X This would create FILE2 with the records ABCD and ABDE. 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.