HP 3000 Manuals HP 3000 Manuals
Preprocessor Input and Output (continued)
Preprocessor-Generated Include Files
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:
$INCLUDE 'sqlconst'$
$INCLUDE 'sqltype'$
.
.
$INCLUDE 'sqlvar'$
$INCLUDE '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:
:FILE SQLCONST=MYCONST
:FILE SQLTYPE=MYTYPE
:FILE SQLVAR=MYVAR
:FILE SQLEXTN=MYEXTN
:FILE SQLIN=MYPROG
:FILE SQLOUT=MYSQLPRG
. Then the Pascal preprocessor is invoked
. in full preprocessing mode. Later, when the
. Pascal compiler is invoked, the following
file equations must be in effect:
:FILE SQLCONST=MYCONST
:FILE SQLTYPE=MYTYPE
:FILE SQLVAR=MYVAR
:FILE SQLEXTN=MYEXTN
:PASCAL MYSQLPRG, $NEWPASS, $NULL
For each SQLVARn file of a subprogram specify:
:FILE SQLVARn=MYVARn
and the reverse after preprocessing.
_____________________________________________
| |
| const |
| SQLOWNER = 'SOMEUSER@SOMEACCT ';|
| SQLMODNAME = 'PASEX2 ';|
| |
_____________________________________________
Figure 2-8. Sample Constant Include File
______________________________________________________
| |
| type |
| ownername_type = string[20]; |
| modulename_type = string[20]; |
| smallint = shortint; |
| SQLIND = shortint; |
| SQLREC1 = record |
| PartNumber1 : packed array [1..16] of char;|
| end; |
| SQLREC2 = record |
| PartNumber1 : packed array [1..16] of char;|
| PartName2 : packed array [1..30] of char; |
| SalesPrice3 : longreal; |
| SalesPriceInd4 : sqlind; |
| end; |
| SQLREC3 = record |
| DUMMY1, DUMMY2 : SQLREC2 |
| end; |
| SQLREC4 = packed array[1..132] of char; |
| SQLCASES = 0..4; |
| SQLCA_TYPE = record |
| SQLCAID : packed array [1..8] of char; |
| SQLCABC : integer; |
| SQLCODE : integer; |
| SQLERRM : string[255]; |
| SQLERRP : packed array [1..8] of char; |
| SQLERRD : array [1..6] of integer; |
| $if 'XOPEN_SQLCA'$ |
| SQLWARN0, SQLWARN1, SQLWARN2, |
| SQLWARN3, SQLWARN4, SQLWARN5, |
| SQLWARN6, SQLWARN7 : char; |
| $else$ |
| SQLWARN : packed array [0..7] of char; |
| $endif$ |
| SQLEXT : packed array [1..8] of char; |
| end; |
______________________________________________________
Figure 2-9. Sample Type Include File
_________________________________________________________
| |
| SQLFORMAT_TYPE = packed record |
| SQLNTY, SQLTYPE, SQLPREC, SQLSCALE : smallint;|
| SQLTOTALLEN, SQLVALLEN, SQLINDLEN : integer; |
| SQLVOF, SQLNOF : integer; |
| SQLNAME : packed array [1..20] of char; |
| end; |
| SQLDA_TYPE = record |
| SQLDAID : packed array [1..8] of char; |
| SQLDABC : integer; |
| SQLN : integer; |
| SQLD : integer; |
| SQLFMTARR : integer; |
| SQLNROW : integer; |
| SQLRROW : integer; |
| SQLROWLEN : integer; |
| SQLBUFLEN : integer; |
| SQLROWBUF : integer; |
| end; |
| SQLTEMPV_TYPE_P = @SQLTEMPV_TYPE; |
| SQLTEMPV_TYPE = record case SQLCASES of |
| 0 : (dummy : integer); |
| 1: (REC1 : SQLREC1); |
| 2: (REC2 : SQLREC2); |
| 3: (REC3 : SQLREC3); |
| 4: (REC4 : SQLREC4); |
| end; |
| |
_________________________________________________________
Figure 2-9. Sample Type Include File (page 2 of 2)
_____________________________________
| |
| var |
| SQLVAR1 : string[264]; |
| SQLVAR2 : string[16]; |
| SQLVAR3 : string[8]; |
| SQLVAR4 : string[8]; |
| SQLVAR5 : string[56]; |
| SQLTEMPV : SQLTEMPV_TYPE; |
| |
_____________________________________
Figure 2-10. Sample Variable Include File
_____________________________________________
| |
| procedure SQLXBFE |
| (SQLCAP : integer; |
| owner : ownername_type; |
| xmodule : modulename_type; |
| section : integer; |
| parms : integer; |
| inparms : integer; |
| outarray : integer; |
| entrysize : integer; |
| nentry : integer; |
| firstrow : integer; |
| nrow : integer); external;|
| procedure SQLXBIN |
| (SQLCAP : integer; |
| owner : ownername_type; |
| xmodule : modulename_type; |
| section : integer; |
| inarray : integer; |
| entrysize : integer; |
| nentry : integer; |
| firstrow : integer; |
| nrow : integer); external;|
| procedure SQLXCNH |
| (SQLCAP : integer; |
| msgstrp : integer; |
| xstrlen : integer; |
| isvarchar : integer); external;|
| procedure SQLXCON |
| (SQLCAP : integer; |
| var stmt : string); external;|
| procedure SQLXDDU |
| (SQLCAP : integer; |
| xmodule : modulename_type; |
| section : integer; |
| parms : integer; |
| inparms : integer; |
| var stmt : string); external;|
| procedure SQLXDEX |
| (SQLCAP : integer; |
| SQLDAP : integer; |
| xmodule : modulename_type; |
| section : integer); external;|
| procedure SQLXDFE |
| (SQLCAP : integer; |
| SQLDAP : integer; |
| xmodule : modulename_type; |
| section : integer); external;|
_____________________________________________
Figure 2-11. Sample External Procedures Include File
_____________________________________________
| |
| procedure SQLXDOPK |
| (SQLCAP : integer; |
| SQLDAP : integer; |
| owner : ownername_type; |
| xmodule : modulename_type; |
| section : integer; |
| parms : integer; |
| inparms : integer; |
| kpcval : integer); external;|
| procedure SQLXDSB |
| (SQLCAP : integer; |
| SQLDAP : integer; |
| xmodule : modulename_type; |
| section : integer; |
| ifinput : integer); external;|
| procedure SQLXEXI |
| (SQLCAP : integer; |
| queryptr : integer; |
| querysize : integer); external;|
| procedure SQLXEXU |
| (SQLCAP : integer; |
| xmodule : modulename_type; |
| section : integer; |
| parms : integer; |
| inparms : integer; |
| var formats : string; |
| nhv : integer; |
| nentry : integer; |
| firstrow : integer; |
| nrow : integer); external;|
| procedure SQLXFET |
| (SQLCAP : integer; |
| owner : ownername_type; |
| xmodule : modulename_type; |
| section : integer; |
| parms : integer; |
| inparms : integer; |
| outparms : integer; |
| isselect : boolean); external;|
| procedure SQLXIDU |
| (SQLCAP : integer; |
| owner : ownername_type; |
| xmodule : modulename_type; |
| section : integer; |
| parms : integer; |
| inparms : integer; |
| isbulk : boolean); external;|
_____________________________________________
Figure 2-11. Sample External Procedures Include File (page 2 of 3)
_____________________________________________
| |
| procedure SQLXOPK |
| (SQLCAP : integer; |
| owner : ownername_type; |
| xmodule : modulename_type; |
| section : integer; |
| parms : integer; |
| inparms : integer; |
| kpcval : integer); external;|
| procedure SQLXOPU |
| (SQLCAP : integer; |
| owner : ownername_type; |
| xmodule : modulename_type; |
| section : integer; |
| parms : integer; |
| inparms : integer; |
| var formats : string; |
| nhv : integer; |
| kpcval : integer); external;|
| procedure SQLXPLN |
| (SQLCAP : integer; |
| msgstrp : integer; |
| xstrlen : integer; |
| isvarchar : integer); external;|
| procedure SQLXPRE |
| (SQLCAP : integer; |
| queryptr : integer; |
| querysize : integer; |
| xmodule : modulename_type; |
| section : integer); external;|
| procedure SQLXSECT |
| (SQLCAP : integer; |
| owner : ownername_type; |
| modul : modulename_type; |
| section : integer); external;|
| procedure SQLXSTP |
| (SQLCAP : integer); external;|
| procedure SQLXSVPT |
| (SQLCAP : integer; |
| xstrlen : integer; |
| var hexstr : string; |
| svptrec : integer); external;|
| |
| |
| |
| |
| |
| |
_____________________________________________
Figure 2-11. Sample External Procedures Include File (page 3 of 3)
ALLBASE/SQL Message 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:
SQLCTxxx.PUB.SYS
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:
SQLCT000.PUB.SYS
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:
1. A banner:
WED, OCT 25, 1991, 1:38 PM
HP36216-02A.E1.00 PASCAL Preprocessor/3000 ALLBASE/SQL
(C)COPYRIGHT HEWLETT-PACKARD CO. 1982,1983,1984,1985,1986,1987,1988,
1989,1990,1991. ALL RIGHTS RESERVED.
2. A summary of the preprocessor invocation conditions:
SQLIN = PASEX2.SomeGrp.SomeAcct
DBEnvironment = PartsDBE
Module Name = PASEX2
3. Warnings and errors encountered during preprocessing:
32 SalesPriceInd : SQLID;
|
****** Unsupported type syntax for host variable. (DBERR 10933)
SELECT PartNumber, PartName, SalesPrice INTO :Partnumber, :PartName,
:SalesPrice :SalesPriceInd FROM PurchDB.Parts WHERE ParNumber =
:PartNumber;
****** ALLBSE/SQL errors (DBERR 10952)
****** in SQL statement ending in line 127
*** ALLBASE/SQL alignment error on column 3 in buffer 5. (DBERR 4200)
There are errors. No sections stored.
4. A summary of the results of preprocessing:
2 ERRORS 0 WARNINGS
END OF PREPROCESSING.
PROGRAM TERMINATED IN AN ERROR STATE. (CIERR 976)
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:
:FILE SQLMSG=MyMsg;Rec=-80,16,f,ASCII
:FILE SQLIN=PASEX2
:RUN PSQLPAS.PUB.SYS;INFO="PartsDBE"
WED, JUL 22, 1991, 1:38 PM
HP36216-02A.E1.00 PASCAL Preprocessor/3000 ALLBASE/SQL
(C)COPYRIGHT HEWLETT-PACKARD CO. 1982,1983,1984,1985,1986,1987,1988,
1989,1990,1991. ALL RIGHTS RESERVED.
2 ERRORS 0 WARNINGS
END OF PREPROCESSING.
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.
________________________________________________________________________
| |
| :EDITOR |
| HP32201A.07.00 EDIT/3000 FRI, OCT 27, 1991, 10:20 AM |
| (C) HEWLETT-PACKARD CO. 1990 |
| /T SQLMSG;L ALL UNN |
| FILE UNNUMBERED |
| . |
| . |
| |
| |
| 29 SalesPriceInd : SQLID; |
| | |
| ****** Unsupported type syntax for host variable. (DBERR 10933)|
| There are errors. No sections stored. |
| . |
| . |
| 2 ERRORS 0 WARNINGS |
| END OF PREPROCESSING |
________________________________________________________________________
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.
_____________________________________________________________________________
| |
| :EDITOR |
| HP32201A.07.00 EDIT/3000 FRI, OCT 27 1991, 10:20 AM |
| (C) HEWLETT-PACKARD CO. 1990 |
| /T SQLMSG;L ALL UNN |
| FILE UNNUMBERED |
| |
| SQLIN = PASEX2.SOMEGRP.SOMEACCT |
| DBEnvironment = PartsDBE |
| Module Name = PASEX2 |
| |
| SELECT PartNumber, PartName, SalesPrice INTO :Partnumber, :PartName,|
| :SalesPrice :SalesPriceInd FROM PurchDB.Parts WHERE ParNumber = |
| :PartNumber; |
| | |
| ****** HP SQL warnings (DBWARN 10602 ) |
| ****** in SQL statement ending in line 125 |
| *** Column PARNUMBER not found. (DBERR 2211) |
| |
| 1 Sections stored in DBEnvironment. |
| |
| 0 ERRORS 1 WARNINGS |
| END OF PREPROCESSING. |
| |
_____________________________________________________________________________
Figure 2-13. Sample SQLMSG Showing Warning
Installable Module File
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:
:RUN PSQLPAS.PUB.SYS;INFO = "DBEnvironmentName&
(MODULE (InstalledModuleName) DROP)"
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:
:SAVE SQLMOD
:RENAME SQLMOD, MYMOD
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.
:ISQL
In order to install the module, you need CONNECT or DBA authority in the
target DBEnvironment:
isql=> CONNECT TO 'PARTSDBE.SomeGrp.SomeAcct';
isql=> INSTALL;
File name> MYMOD.SOMEGRP.SOMEACCT;
Name of module in this file: SomeUser@SomeAcct.PASEX2
Number of sections installed: 1
COMMIT WORK to save to DBEnvironment.
isql=> COMMIT WORK;
isql=>
Stored Sections
In full preprocessing mode, the preprocessor stores a section for each
embedded SQL command except:
BEGIN DECLARE SECTION INCLUDE
BEGIN WORK OPEN
CLOSE PREPARE
COMMIT WORK RELEASE
CONNECT ROLLBACK WORK
DECLARE CURSOR SAVEPOINT
DELETE WHERE CURRENT START DBE
DESCRIBE STOP DBE
END DECLARE SECTION SQLEXPLAIN
EXECUTE TERMINATE USER
EXECUTE IMMEDIATE UPDATE WHERE CURRENT
FETCH WHENEVER
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:
1. Sections for executing the SELECT command associated with a
DECLARE CURSOR command.
2. Sections for executing the SELECT command associated with a CREATE
VIEW command.
3. Sections for all other commands for which the preprocessor stores
a section.
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:
* NAME: This column contains the name of the module to which a
section belongs. You specify a module name when you invoke the
preprocessor; the module name is by default the program name from
the Pascal program. If you are supplying a module name in a
language other than NATIVE-3000 (ASCII), be sure it is in the same
language as that of the DBEnvironment.
* OWNER: This column identifies the owner of the module. You
specify an owner name when you invoke the preprocessor; the owner
name is by default the logon UserName@AccountName associated with
the preprocessing session. If you are supplying an owner name in
a language other than NATIVE-3000 (ASCII), be sure it is in the
same language as that of the DBEnvironment.
* DBEFILESET: This column indicates the DBEFileSet with which
DBEFiles housing the section are associated.
* SECTION: This column gives the section number. Each section
associated with a module is assigned a number by the preprocessor
as it parses the related SQL command at preprocessing time.
* TYPE: This column identifies the type of section:
1 = SELECT associated with a cursor
2 = SELECT defining a view
0 = All other sections
* VALID: This column identifies whether a section is valid or
invalid:
0 = invalid
1 = valid
___________________________________________________________________________________
| |
| isql=> SELECT NAME,OWNER,DBEFILESET,SECTION,TYPE,VALID FROM SYSTEM.SECTION; |
| |
| SELECT NAME,OWNER,DBEFILESET,SECTION,TYPE,VALID FROM SYSTEM.SECTION; |
| --------------------------------------------------------------------------- |
| NAME |OWNER |DBEFILESET |SECTION |TYPE |VALID |
| --------------------------------------------------------------------------- |
| TABLE |SYSTEM |SYSTEM | 0| 2| 0 |
| COLUMN |SYSTEM |SYSTEM | 0| 2| 0 |
| INDEX |SYSTEM |SYSTEM | 0| 2| 0 |
| SECTION |SYSTEM |SYSTEM | 0| 2| 0 |
| DBEFILESET |SYSTEM |SYSTEM | 0| 2| 0 |
| DBEFILE |SYSTEM |SYSTEM | 0| 2| 0 |
| SPECAUTH |SYSTEM |SYSTEM | 0| 2| 0 |
| TABAUTH |SYSTEM |SYSTEM | 0| 2| 0 |
| COLAUTH |SYSTEM |SYSTEM | 0| 2| 0 |
| MODAUTH |SYSTEM |SYSTEM | 0| 2| 0 |
| GROUP |SYSTEM |SYSTEM | 0| 2| 0 |
| VIEWDEF |SYSTEM |SYSTEM | 0| 2| 0 |
| HASH |SYSTEM |SYSTEM | 0| 2| 0 |
| CONSTRAINT |SYSTEM |SYSTEM | 0| 2| 0 |
| CONSTRAINTCOL |SYSTEM |SYSTEM | 0| 2| 0 |
| CONSTRAINTINDEX |SYSTEM |SYSTEM | 0| 2| 0 |
| COLDEFAULT |SYSTEM |SYSTEM | 0| 2| 0 |
| TEMPSPACE |SYSTEM |SYSTEM | 0| 2| 0 |
| PARTINFO |PURCHDB |SYSTEM | 0| 2| 0 |
| VENDORSTATISTICS |PURCHDB |SYSTEM | 0| 2| 0 |
| PASEX2 |KAREN@THOMAS |SYSTEM | 1| 0| 1 |
| EXP11 |KAREN@THOMAS |SYSTEM | 1| 1| 1 |
| EXP11 |KAREN@THOMAS |SYSTEM | 2| 0| 1 |
| ----------------------------------------------------------------------------|
| Number of rows selected is 16. |
| U[p], d[own], l[eft], r[ight], t[op], b[ottom], pr[int] <n>,or e[nd]> |
___________________________________________________________________________________
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:
isql=> DROP MODULE PASEX2;
or
:RUN PSQLPAS.PUB.SYS;INFO="PartsDBE (MODULE(PASEX2) DROP)"
Stored sections are marked invalid when any of the following occur:
* The UPDATE STATISTICS command is executed.
* Tables accessed in the program are dropped, altered, or assigned
new owners.
* Indexes or DBEFileSets related to tables accessed in the program
are changed.
* Module owner authorization changes occur that affect the execution
of embedded commands.
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.