|
|
|
|
|
|
|
|
ALLBASE/SQL C Application Programming Guide: HP 9000 Computer Systems > Chapter 2 Using the Preprocessor
Identifying Preprocessor Output |
|
As Figure 2-2 “Full Preprocessing Mode Input and Output” points out, running the C preprocessor in full preprocessing mode creates the following output files:
Also, a module is stored in the DBEnvironment specified in the preprocessor invocation line. Each of these is described in the following sections. As the C preprocessor parses the source file, it copies lines from it and any include files into the modified source file, inserts conditional compiler directives around the embedded SQL commands, and inserts information around each embedded SQL command. The default modified source file name is SourceFileName.c. You can specify a modified source file name by using the -p option of the preprocessor command line. Figure 2-6 “Sample Modified Source File” illustrates the modified source file generated for the source file pictured in Figure 1-8 “Program cex2: Using Simple SELECT”. The shaded lines contain information generated by the C preprocessor. In both preprocessing modes, the C preprocessor:
In full preprocessing mode, the preprocessor also:
If you change non-preprocessor-generated constructs, make the changes to the source file, re-preprocess it, and re-compile the output files before putting the application program into production. There are three include files, which contain declarations and definitions used by the C functions created by the preprocessor and inserted into the modified source code file:
The sqlmodulename and ownername of sections are defined as global static variables in the .sqlv include file. It is advised that multiple source file applications be preprocessed all at one time so that only one .sqlv file is generated. If the source files are preprocessed and compiled separately and combined at link time, runtime errors occur because the static global sqlmodulename variable from the first source file preprocessed is used and incorrect sections are executed. Therefore, all preprocessed sections in your program must reside in the same file for input to the C compiler. Any extension on the ModifiedSourceFileName is ignored when the preprocessor assigns names to the include files. The ALLBASE/SQL message file is named sqlmsg. Messages generated by the proprocessor in sqlmsg when you preprocess come from the ALLBASE/SQL message catalog. The default catalog is /usr/lib/nls/n-computer/hpsqlcat. For native language users, the name of the catalog is /usr/lib/nls/$LANG/hpsqlcat, where $LANG is the current language. If this catalog is not available, ALLBASE/SQL uses the default instead. Sqlmsg messages contain four parts:
Both the banner and the preprocessing summary results are also echoed to the terminal. As illustrated in Figure 2-3 “Sample sqlmsg Showing Errors”, a line number is often provided in sqlmsg. This line number references the line in the program source file 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-3 Sample sqlmsg Showing Errors
As Figure 2-4 “Sample sqlmsg Showing Warning” illustrates, the preprocessor can terminate with the warning message
when the name of an object in the source file does not match the name of any object in the system catalog. 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-4 Sample sqlmsg Showing Warning
In full preprocessing mode, the preprocessor stores a module in the DBEnvironment you specify at preprocessing time. By default, the preprocessor uses the source file name as the name for the module it stores. You can specify a module name with the MODULE option of the preprocessor command. The module contains a section for each embedded SQL command in your program 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 are known as an input tree and a run tree. The input tree consists of the 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 section 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. There are three types of sections:
Figure 2-5 “Information in SYSTEM.SECTION on Stored Sections” illustrates the kind of information in the system catalog. All stored sections for each module in the DBEnvironment are referenced here. The query result illustrated was extracted from the system view named SYSTEM.SECTION by using ISQL. The columns in Figure 2-5 “Information in SYSTEM.SECTION on Stored Sections” have the following meanings:
Figure 2-5 Information in SYSTEM.SECTION on Stored Sections
The first eighteen rows in the query result shown in Figure 2-5 “Information in SYSTEM.SECTION on Stored Sections” 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. Program cex2 contains only one section, for executing the SELECT command in the program illustrated in Figure 2-6 “Sample Modified Source File”. Program cex7 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 DBEnvironment until they are deleted by using the ISQL DROP MODULE command:
or by invoking the preprocessor with the -d option:
You must have proper table access authority to drop a module. Stored sections are marked invalid when:
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 re-validate 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. When the preprocessor stores a module in the DBEnvironment you named at preprocessing time, it places a copy of the module in an installable module file. 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. In order to install the module, you need CONNECT or DBA authority in the target DBEnvironment. The installable module file is named SQLMOD. The module also has an internal, SQL name, in this case JOANN.CEX2, which is saved as part of the module at preprocessing time. JOANN is the login of the user who preprocessed source file cex2, and JOANN is the owner of the module. Note that ALLBASE/SQL shifts the system login and installable module file names to upper case to form the internal, installable module name.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||
|
|
|
|||||||||
|
|||||||||
