| United States-English |
|
|
|
![]() |
ALLBASE/SQL FORTRAN Application Programming Guide: HP 9000 Computer Systems > Chapter 2 Using The ALLBASE/SQL FORTRAN PreprocessorPreprocessor Input and Output |
|
Regardless of the mode you use, the following input files must be available when you invoke the FORTRAN preprocessor, as shown in Figure 2-3 “FORTRAN Preprocessor Input and Output”:
Figure 2-3 “FORTRAN Preprocessor Input and Output” shows the output file created by the preprocessor. These files are as follows:
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 SourceFileName is in a language other than ASCII, the ModifiedSourceFileName and all generated files will have names in the native language and extensions in ASCII. When you run the preprocessor in full preprocessing mode, also ensure that the DBEnvironment accessed by the program or subprogram unit is available. The preprocessor source file must contain at a minimum the following statements:
When parsing the source file, the FORTRAN preprocessor ignores all FORTRAN statements and any FORTRAN compiler directives that are not supported. Only the following information is parsed by the FORTRAN preprocessor:
Figure 2-6 “Program forex2” illustrates a source file containing a sample program using the following SQL commands:
As the interactive sample dialog in Figure 2-5 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. The program continues to prompt for a part number until the user enters a slash (/) or until a serious error is encountered: Figure 2-5 Runtime Dialog of Program forex2
Figure 2-6 Program forex2
When the source file illustrated in Figure 2-6 “Program forex2” is preprocessed, the attributes of the output files are created as follows:
As the FORTRAN preprocessor parses the source file, it copies lines from the source file into the modified source file, comments out embedded SQL commands, and inserts information around each embedded SQL command. Figure 2-7 illustrates the modified source file generated for the source file pictured in Figure 2-6 “Program forex2”. The shaded lines show the start of original code commented out, the preprocessor-generated code added, and some other key statements. In both preprocessing modes, the FORTRAN preprocessor:
In full preprocessing mode, the preprocessor also:
If you change non-preprocessor generated statements in the modified source file, make the changes to the source file, re-preprocess the source file, and re-compile the output files before putting the application program into production. The following modified source file is the result of preprocessing program forex2 (shown previously). Figure 2-7 Modified Source File for Program forex2
ModifiedSourceFileName.sqlv, the preprocessor-creator include file, contains delcarations for variables referenced in preprocessor-generated statements in the modified source file. Figure 2-8 illustrates the variable declaration include file that corresponds to the modified source file in Figure 2-7. Note in Figure 2-7 that just after inserting the EXEC SQL END DECLARE SECTION declaration into the modified source file, the preprocessor inserted the following FORTRAN compiler directive to reference the variable declaration include file:
This directive is always inserted after the Host Variable Type Declaration Section. Messages placed in sqlmsg 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:
By default, both the banner and the summary of preprocessing output is echoed to the standard output, the terminal, by default. In addition, all sqlmsg messages are written to the file named sqlmsg. As illustrated om Figure 2-9, a line number is often provided in sqlmsg after the error or warning message. This line number references the last line in the 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-9 Sample sqlmsg Showing Errors
As Figure 2-10 “Sample sqlmsg Showing Warning” illustrates, the preprocessor can terminate with the warning message:
This happens 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 syntactically correct but semantically incorrent command, the section is marked as invalid and will not execute at run time if it cannot be validated. Refer to the ALLBASE/SQL Reference Manual for a description of how to delete a stored section. Figure 2-10 Sample sqlmsg Showing Warning
When the FORTRAN 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 ModifiedSourceFileName.sqlm. If at preprocessing time ModifiedSourceFileName.sqlm 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. For example:
If you want to preserve the SourceModifiedFileName.sqlm file after preprocessing, you must rename ModifiedSourceFileName.sqlm so it is not over written the next time the preprocessor is invoked to preprocess the same source code:
Before invoking ISQL to install the module contained in ModifiedSourceFileName.sqlm, you may have to transport it and its related 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 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. 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 an uncompiled command. The run tree is the compiled, executable form of the command. If at runtime 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. There are three types of sections:
Figure 2-11 “Information in SYSTEM.SECTION on Stored Sections” 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-11 “Information in SYSTEM.SECTION on Stored Sections” have the following meanings:
Figure 2-11 Information in SYSTEM.SECTION on Stored Sections
The first eighteen 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. FEXP01D2 contains only one section, for executing the SELECT command in the program illustrated in Figure 2-6 “Program forex2”. FEXP11 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:
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 following SELECT commands since COMMIT WORK may be needed to commit a section, even when data is not changed by a program. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||