HP 3000 Manuals HP 3000 Manuals
The ALLBASE/SQL Pascal Preprocessor
The preprocessor ignores Pascal constructs in your source code, but
generates Pascal constructs, based on the embedded SQL commands in your
code. Figure 1-2 summarizes the four main preprocess-time events:
* Syntax checking of SQL commands and host variable declarations.
* Creation of compilable files: one modified source code file and
four include files.
* Creation of an installable module.
* Storage of a module in the system catalog.
![[]](../../pic3k/M012400/FFN53c50.gif)
Figure 1-2. Preprocess-Time Events
Effect of Preprocessing on Source Code
The Pascal preprocessor scans the source code for SQL commands. If the
syntax of an SQL command is valid, the preprocessor converts the command
into compilable Pascal constructs that call ALLBASE/SQL external
procedures at run time. During preprocessing, for example, ALLBASE/SQL
converts the following SQL command:
EXEC SQL SELECT PartNumber, PartName, SalesPrice
INTO :PartNumber,
:PartName,
:SalesPrice :SalesPriceInd
FROM PurchDB.Parts
WHERE PartNumber = :PartNumber;
The preprocessor produces the following converted modified source code
constructs:
$Skip_Text ON$
EXEC SQL SELECT PartNumber, PartName, SalesPrice
INTO :PartNumber,
:PartName,
:SalesPrice :SalesPriceInd
FROM PurchDB.Parts
WHERE PartNumber = :PartNumber;
$Skip_Text OFF$
begin
SQLTEMPV.REC1.PartNumber1 := PartNumber;
SQLXFET(waddress(SQLCA),SQLOWNER,SQLMODNAME,1,waddress(SQLTEMPV),
16,64,TRUE);
if SQLCA.SQLCODE = 0 then
begin
PartNumber := SQLTEMPV.REC2.PartNumber1;
PartName := SQLTEMPV.REC2.PartName2;
if SQLTEMPV.REC2.SalesPriceInd4 >= 0 then
SalesPrice := SQLTEMPV.REC2.SalesPrice3;
SalesPriceInd := SQLTEMPV.REC2.SalesPriceInd4;
end
else
begin
end;
end;
The embedded SELECT command has been converted into a Pascal comment, and
Pascal constructs that enable ALLBASE/SQL to execute the SELECT command
at run time have been inserted. The names that appear in the inserted
Pascal code identify variables used by the ALLBASE/SQL external
procedures; in this example, the names identify variables used by the
SQLXFET external procedure. Some of these variables are derived from
host variables. As shown in the embedded SELECT command above, you
precede a host variable with a colon when you use it in SQL commands:
:PartNumber
Type declarations used by preprocessor generated code are defined and
initialized in the include files the preprocessor creates:
* SQLCONST, a file that defines ALLBASE/SQL constants.
* SQLTYPE, a file that defines ALLBASE/SQL type declarations.
* SQLVAR, a file that defines variables declared in a main program.
For a subprogram, from one to 100 SQLVARn files are generated, one
for each declare section; for example, SQLVAR1.
* SQLEXTN, a file that contains ALLBASE/SQL's external procedure
declarations.
The preprocessor inserts $INCLUDE directives that reference these files
in the Declaration part of the modified source code:
$Include 'sqlconst'$
$Include 'sqltype'$
$Include 'sqlvar'$ (or $Include 'sqlvarn'$)
$Include 'sqlextn'$
The chapter, "Using the ALLBASE/SQL Pascal Preprocessor," explains how
the SQLEXTN file is derived.
CAUTION Never modify either the constructs inserted by the preprocessor
or the include files the preprocessor creates. Changes to
preprocessor generated information could damage your
DBEnvironment or your system.
Effect of Preprocessing on DBEnvironments
When you invoke the preprocessor, you name an ALLBASE/SQL DBEnvironment.
The preprocessor starts a DBE session for that DBEnvironment when
preprocessing begins and terminates that session when preprocessing is
completed.
When the preprocessor encounters a syntactically correct SQL command, it
usually creates a section and stores it in the system catalog of the
DBEnvironment being accessed. An ALLBASE/SQL section is a group of
stored ALLBASE/SQL instructions for executing one SQL command.
All sections created during a preprocessing session constitute a module.
The preprocessor derives the name of the module from the program heading
unless you supply a different name when you invoke the preprocessor:
:RUN PSQLPAS.PUB.SYS; INFO = 'DBEnvironmentName
(MODULE(ModuleName))'
The main program and the subprograms that comprise an application must
each have a unique name. And no two modules should have the same name.
When the preprocessor terminates its DBEnvironment session, it issues a
COMMIT WORK command if it encountered no errors. Created sections are
stored in the system catalog and associated with the module name.
The Stored Section
A section consists of ALLBASE/SQL instructions for executing an SQL
command. Not every SQL command requires a section. For each SQL command
that does require a section, the preprocessor creates the section and
assigns to it a unique reference number. In the following generated
code, SQLSECNUM contains the number of the stored section.
CALL SQLXFE(SQLTRNE,SQLOWN,SQLMDN,SQLSECNUM,SQLTMP, SQLINLEN,SQLOUTLEN)
Purpose of Sections
A section serves the following two purposes:
1. Access validation: Before executing a stored section at run time,
ALLBASE/SQL ensures that any objects referenced exist and that
runtime authorization criteria are satisfied.
2. Access optimization: If ALLBASE/SQL has more than one way to
access data, it determines the most efficient method and creates
the section based on that method. Indexes, for example, can
expedite the performance of some queries.
By creating and storing sections at preprocessing time rather than at run
time, runtime performance is improved.
Section Validity
A section is assigned one of two states at preprocessing time: valid or
invalid. A section is valid when access validation criteria are
satisfied. If the SQL command references objects that exist at
preprocessing time and the individual doing the preprocessing is
authorized to issue the command, the stored section is marked as valid.
A section is invalid when access validation criteria are not satisfied.
If the SQL command references an object that does not exist at
preprocessing time or if the individual doing the preprocessing is not
authorized to issue the command, the stored section is marked as invalid.
After being stored by the preprocessor, a valid section is marked as
invalid when such activities as the following occur:
* Changes in authorities of the module's owner.
* Alterations to tables accessed by the program.
* Deletions or creations of indexes.
* Updating a table's statistics.
At run time, ALLBASE/SQL executes valid sections and attempts to validate
any section marked as invalid. If an invalid section can be validated,
as when an altered table does not affect the results of a query,
ALLBASE/SQL marks the section as valid and executes it. If an invalid
section cannot be validated, as when a table reference is invalid because
the table owner name has changed, ALLBASE/SQL returns an error indication
to the application program.
When a section is validated at run time, it remains in the valid state
until an event that invalidates it occurs. The program execution during
which validation occurs is slightly slower than program executions
following validation.