| United States-English |
|
|
|
![]() |
ALLBASE/SQL Pascal Application Programming Guide: HP 3000 MPE/iX Computer Systems > Chapter 2 Using the ALLBASE/SQL Pascal PreprocessorPreprocessor Input and Output |
|
Regardless of the mode you use, the following files must be available when you invoke the Pascal preprocessor, as shown in Figure 2-3 “Pascal Preprocessor Input and Output”:
As Figure 2-4 “Compiling Preprocessor Output” points out, the Pascal preprocessor creates the following output files:
When you run the preprocessor in full preprocessing mode, the preprocessor also stores a module in the DBEnvironment accessed by your program. The module is used at run time to execute DBEnvironment operations. If the source file is in a language other than ASCII, the modified source file, and all generated files will have names in the native language and extensions in ASCII. If you want to preprocess several ALLBASE/SQL application programs in the same group and account and compile and link the programs later, or you plan to compile a preprocessed program during a future session, you should do the following for each program:
When you are ready to compile the program, you must equate the include file names to their standard ALLBASE/SQL names. See "Preprocessor Generated Include Files" in this section for more information. The source file must be a file that contains at a minimum the following constructs:
When parsing the source file, the Pascal preprocessor ignores Pascal statements and most Pascal compiler directives in it. Only the following information is parsed by the Pascal preprocessor:
The runtime dialog for a sample program that selects and displays data is shown in Figure 2-5. Figure 2-6 illustrates an SQLIN file of the sample program using the following SQL commands:
As the following interactive sample dialog illustrates, the program begins a DBE session for PartsDBE, the sample DBEnvironment. It prompts the user for a part number, then displays information about the part from the table PurchDB.Parts. Warning and error conditions are handled with WHENEVER and SQLEXPLAIN commands with the exception of explicit error checking after the SELECT command. The program continues to prompt for a part number until the user enters a slash (/) or a serious error is encountered. Figure 2-5 Interactive Runtime Dialog of Program PASEX2
Figure 2-6 Program PASEX2: Using Simple Select
The Pascal preprocessor output files are temporary files. When the SQLIN illustrated in Figure 2-6 is preprocessed, the attributes of the output files created are as follows:
As the Pascal preprocessor parses the source file (SQLIN), it copies lines from the source file and any file(s) included from it into the modified source file (SQLOUT), comments out embedded SQL commands, and inserts information around each embedded SQL command. In both preprocessing modes, the Pascal preprocessor:
If you change non-preprocessor-generated constructs in SQLOUT, make the changes to SQLIN, re-preprocess SQLIN, and re-compile the output files before putting the application program into production. The following modified source file is the result of preprocessing program pasex2 (shown previously). In the listing, the boundaries of code that has been changed or added by the preprocessor is shaded for easy reference. Figure 2-7 Modified Source File for Program PASEX2
SQLCONST, SQLTYPE, SQLVAR, SQLVARn, and SQLEXTN are preprocessor generated include files which contain declarations for constants, types, variables, and external procedures for the preprocessor generated statements in SQLOUT. Figure 2-8 through Figure 2-11 illustrate, respectively, the SQLCONST, SQLTYPE, SQLVAR, and SQLEXTN files that correspond to the SQLOUT file in Figure 2-7. Note that the preprocessor inserts the following four Pascal compiler directives to reference SQLCONST, SQLTYPE, SQLVAR, and SQLEXTN:
These four directives are always inserted into the global declaration part of a main program. For each declare section in a subprogram, an SQLVARn include file is generated and the compiler directive $INCLUDE 'sqlvarn``'$ is inserted in the local declaration part. The value of n is from 01 through 99. Even if you use file equations to redirect the include files, the preprocessor still inserts the same $INCLUDE directives. Therefore when you compile preprocessor output, ensure that the preprocess-time file equations are in effect so the correct include files are compiled:
For each SQLVARn file of a subprogram specify:
and the reverse after preprocessing. Figure 2-8 Sample Constant Include File
Figure 2-9 Sample Type Include File
Figure 2-10 Sample Variable Include File
Figure 2-11 Sample External Procedures Include File
Messages placed in the ALLBASE/SQL message file (SQLMSG) come from the ALLBASE/SQL message catalog. The formal file designator for the message catalog is:
where xxx is the numerical value for the current language. If this catalog cannot be opened, ALLBASE/SQL looks for the default NATIVE-3000 message catalog:
If the default catalog cannot be opened, ALLBASE/SQL returns an error message saying that the catalog file is not available. If the NATIVE-3000 catalog is available, the user sees a warning message indicating that the default catalog is being used. SQLMSG messages contain four parts:
When you equate SQLMSG to $STDLIST, all these messages appear at the terminal during a session or in the job stream listing. When SQLMSG is not equated to $STDLIST, parts 1 and 4 are still sent to $STDLIST, and all parts appear in the file equated to SQLMSG:
If you want to keep the message file, you should save the file you equate to SQLMSG. It is created as a temporary file. As illustrated in Figure 2-12, a line number is often provided in SQLMSG. This line number references the line in SQLIN containing the command in question. A message accompanied by a number may also appear. You can refer to the ALLBASE/SQL Message Manual for additional information on the exception condition when these numbered messages appear. Figure 2-12 Sample SQLMSG Showing Errors
As Figure 2-13 illustrates, the preprocessor can terminate with a warning message. Although a section is stored for the semantically incorrect command, the section is marked as invalid and will not execute at run time if it cannot be validated. Figure 2-13 Sample SQLMSG Showing Warning
When the Pascal preprocessor stores a module in the system catalog of a DBEnvironment at preprocessing time, it places a copy of the module in an installable module file. The name of this file by default is SQLMOD. If at preprocessing time SQLMOD already exists, it is overwritten with the new module. The module in this file can be installed into a DBEnvironment different from the DBEnvironment accessed at preprocessing time by using the INSTALL command in ISQL:
If you want to preserve the SQLMOD file after preprocessing, you rename SQLMOD so it is not over written the next time the preprocessor is invoked to preprocess the same source code:
Before invoking ISQL to install this module file, you may have to transport it and its related application program file to the machine containing the target DBEnvironment. After all the files are restored on the target machine, you invoke ISQL on the machine containing the target DBEnvironment.
In order to install the module, you need CONNECT or DBA authority in the target DBEnvironment:
In full preprocessing mode, the preprocessor stores a section for each embedded SQL command except:
The commands listed above either require no authorization to execute or are executed based on information contained in the compilable preprocessor output files. Note that if the DELETE WHERE CURRENT or UPDATE WHERE CURRENT command is dynamically preprocessed, a section does exist in the module. When the preprocessor stores a section, it actually stores what is known as an input tree and a run tree. The input tree consists of an uncompiled command. The run tree is the compiled, executable form of the command. If at run time a section is valid, ALLBASE/SQL executes the appropriate run tree when the SQL command is encountered in the application program. If a section is invalid, ALLBASE/SQL determines whether the objects referenced in the sections exist and whether current authorization criteria are satisfied. When an invalid section can be validated, ALLBASE/SQL dynamically recompiles the input tree to create an executable run tree and executes the command. When a section cannot be validated, the command is not executed, and an error condition is returned to the program. ALLBASE/SQL creates the following three types of sections:
Figure 2-14 illustrates the kind of information in the system catalog that describes each type of stored section. The query result illustrated was extracted from the system view named SYSTEM.SECTION by using ISQL. The columns in Figure 2-14 have the following meanings:
Figure 2-14 Information in SYSTEM.SECTION on Stored Sections
The first eleven selected rows in this query result describe the sections stored for the system views. The next two rows describe the two views in the sample database: PurchDB.PartInfo and PurchDB.VendorStatistics. Views are always stored as invalid sections, because the run tree is always generated at run time. The remaining rows describe sections associated with two preprocessed programs. PASEX2 contains only one section, for executing the SELECT command in the program illustrated in Figure 2-6. EXP11 contains two sections, one for executing the SELECT command associated with a DECLARE CURSOR command and one for executing a FETCH command. Stored sections remain in the system catalog until they are deleted with the DROP MODULE command or by invoking the preprocessor with the DROP option:
Stored sections are marked invalid when any of the following occur:
When an invalid section is validated at run time, the validated section is committed when the program issues a COMMIT WORK command. If a COMMIT WORK command is not executed, ALLBASE/SQL must revalidate the section again the next time the program is executed. For this reason, you should embed COMMIT WORK commands even following SELECT commands, since the COMMIT WORK command may be needed even when data is not changed by a program. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||