HP 3000 Manuals HP 3000 Manuals
Full Preprocessing Mode
Full preprocessing mode includes the following:
* Checking SQL syntax.
* Creating compilable output files.
* Optionally storing an installable module containing sections in a
DBEnvironment. (See the NOINSTALL option below.)
* Creating a file that contains an installable copy of the module.
Full Preprocessing Mode Syntax Specification
Full Preprocessing Mode for C Applications.
{MODULE(ModuleName) }
{OWNER (OwnerName) }
{FLAGGER (FlaggerName) }
{ANSI }
{NOINSTALL }
{INSTALL(DBEFileSetName)}
{{DROP {PRESERVE}} }
RUN PSQLC.PUB.SYS;INFO= "DBEnvironmentName [({{ {REVOKE }} }
{{ } }
{{NODROP } }
{ }
{{WARN } }
{{NOWARN} }
{ }
{THREAD }
|...|)]"
Full Preprocessing Mode for COBOL Applications.
{MODULE(ModuleName) }
{OWNER (OwnerName) }
{FLAGGER (FlaggerName) }
{ANSI }
{NOINSTALL }
{INSTALL(DBEFileSetName)}
RUN PSQLPAS.PUB.SYS;INFO= "DBEnvironmentName [({{DROP {PRESERVE}} }
{{ {REVOKE }} }
{{ } }
{{NODROP } }
{ }
{{WARN } }
{{NOWARN} }
|...|)]"
Full Preprocessing Mode for FORTRAN Applications.
{MODULE(ModuleName) }
{OWNER (OwnerName) }
{FLAGGER (FlaggerName) }
{ANSI }
{NOINSTALL }
{INSTALL(DBEFileSetName)}
RUN PSQLFOR.PUB.SYS; INFO= "DBEnvironmentName [({{DROP {PRESERVE}} }
{{ {REVOKE }} }
{{ } }
{{NODROP } }
{ }
{{WARN } }
{{NOWARN} }
|...|)]"
Full Preprocessing Mode for Pascal Applications.
{MODULE(ModuleName) }
{OWNER (OwnerName) }
{FLAGGER (FlaggerName) }
{ANSI }
{NOINSTALL }
{INSTALL(DBEFileSetName)}
RUN PSQLCOB.PUB.SYS;INFO= "DBEnvironmentName [({{DROP {PRESERVE}} }
{{ {REVOKE }} }
{{ } }
{{NODROP } }
{ }
{{WARN } }
{{NOWARN} }
|...|)]"
Parameters
DBEnvironmentName identifies the DBEnvironment in which a module
is to be stored. You can use a backreference
to a file defined in a file equation for this
parameter.
ModuleName assigns a name to the stored module. Module
names must follow the rules governing
ALLBASE/SQL basic names as described in the
ALLBASE/SQL Reference Manual. If a module name
is not specified, the preprocessor uses the
PROGRAM-ID (for a C application) or the
SourceFileName (for other languages) in upper
case as the module name. This module name is
stored in the module file, SQLMOD.
OwnerName associates the stored module with a
User@Account, a class name, or a group name.
You can specify an owner name for the module
only if you have DBA authority in the
DBEnvironment where the module is to be stored.
If not specified, the owner name is your log-on
User@Account. Any object names in SQLIN not
qualified with an owner name are qualified with
this OwnerName.
FlaggerName is the name of the flagger being invoked. At
this release FIPS127.1 is the only valid
FlaggerName. FlaggerName is not case
sensitive.
Refer to the "Flagging Non-Standard SQL with
the FIPS Flagger" chapter in this manual.
ANSI preprocesses the application in ANSI mode. The
preprocessor generates an SQLCA declaration
automatically and implicit updatability is in
effect.
Refer to the sections "Understanding Implicit
Updatability" and "Declaring the SQLCA" in this
manual.
NOINSTALL indicates that no sections are to be stored in
a DBEnvironment during preprocessing. A module
that can be installed in a DBEnvironment with
the ISQL INSTALL command is generated.
This is the only option for which a
DBEnviromnent name is not required. If a
DBEnvironment name is specified, a connection
is established, and bind errors and warnings
are generated for missing objects. If no
DBEnvironment name is specified, no connection
is made and no bind errors or warnings are
generated.
INSTALL DBEFileSetName identifies the DBEFileSet in which a module's
static sections are to be stored.
A DBEFileSetName specified in the preprocessor
command line overrides any explicit
specification in the IN DBEFileSetName clause
of any ALTER TABLE, CREATE PROCEDURE, CREATE
RULE, CREATE TABLE, CREATE VIEW, DECLARE
CURSOR, or PREPARE statement within the
preprocessed application.
DROP Deletes any module currently stored in the
DBEnvironment by the ModuleName and OwnerName
specified in the INFO string.
PRESERVE Is specified when the program being
preprocessed already has a stored module and
you want to preserve existing RUN authorities
for that module. If not specified, PRESERVE is
assumed. PRESERVE cannot be specified unless
DROP is also specified.
REVOKE Is specified when the program being
preprocessed already has a stored module and
you want to revoke existing RUN authorities for
that module. REVOKE cannot be specified unless
DROP is also specified.
NODROP Terminates preprocessing if any module
currently exists in the DBEnvironment by the
ModuleName and OwnerName specified in the INFO
string. If not specified, NODROP is assumed.
NOWARN Converts preprocessor generated bind warnings
to errors.
WARN Generates the default bind warnings. If
neither NOWARN or WARN is specified, the
default bind warnings are generated.
THREAD For C applications only; used to support
threaded applications. When specified, the C
preprocessor will not generate the #include
"SQLVAR" at the beginning of SQLOUT. You must
insert a #include "SQLVAR" wherever local
variables are required to compile and utilize
application threads successfully.
Description
* Unless you have specified the NOINSTALL option without specifying
a DBEnvironment name, when the program being preprocessed already
has a stored module, be sure to use the DROP option, or else an
error will result. Also, be sure that no one is currently
executing the module when you invoke the preprocessor. To avoid
conflicts, do your preprocessing in single-user mode during
off-hours.
* Unless the NOINSTALL option is specified without specifying a
DBEnvironment name, the preprocessor starts a DBE session in the
DBEnvironment named in the preprocessor command by issuing a
CONNECT TO 'DBEnvironmentName' statement. If the autostart flag
is OFF, the DBE session can be initiated only after a START DBE
statement has been processed (by means of ISQL or an embedded SQL
program). Remember that if multiple, simultaneous users run a
program, you should issue the START DBE statement only once.
* If the DBEnvironment to be accessed is operating in single-user
mode, preprocessing can occur only when another DBE session for
the DBEnvironment does not exist.
* When the preprocessor's DBE session begins, ALLBASE/SQL processes
a BEGIN WORK statement. When preprocessing is completed, the
preprocessor submits a COMMIT WORK statement, and any sections
created are committed to the system catalog. If the preprocessor
detects an error in SQLIN, it processes a ROLLBACK WORK statement
before terminating, and no sections are stored in the
DBEnvironment. Preprocessor warnings do not prevent sections from
being stored.
* Since any preprocessor DBE session initiates only one transaction,
any log file space used by the session is not available for re-use
until after the session terminates. You can issue a CHECKPOINT
statement in ISQL before preprocessing to review the amount of
available log space. Refer to the ALLBASE/SQL Database
Administration Guide for additional information on log space
management, such as using the START DBE NEWLOG statement to
increase the size of the log file.
* During preprocessing, system catalog pages accessed for embedded
statements are locked. In multiuser mode, other DBE sessions
accessing the same objects may have to wait, so there is potential
for a deadlock. You have several options to use to attempt to
avoid a deadlock situation.
* Minimize competing transactions when preprocessing an
application.
* Ask your DBA to specify the system tables that utilize row
level locking. Refer to the ALLBASE/SQL Database
Administration Guide appendix, "Locks Held on the System
Catalog," and to the section "Changing System Table Lock
Types" for further information.
* Use the INSTALL (DEBFileSetName) preprocessor parameter
option to maximize transaction concurrency. This option
specifies the DBEFileSet in which a module's static
sections are to be stored.
* For improved runtime performance, use the UPDATE STATISTICS
statement in ISQL before preprocessing for each table accessed in
a data manipulation statement when an index on that table has been
added or dropped and when data in the table is often changed.
* If you specify an OwnerName or ModuleName in a language other than
NATIVE-3000 (ASCII), be sure that the language you are using is
also the language of the DBEnvironment in which the module will be
stored.
* When you invoke the preprocessor with the FLAGGER option, your
application must contain an ANSI mode compiler directive in order
for the compiler to detect non-standard statements. The following
table lists the appropriate directive for each language:
---------------------------------------------------------------------------------------------
| | |
| Language | Directive |
| | |
---------------------------------------------------------------------------------------------
| | |
| C | ccxl ... ;info='-Aa' |
| | |
---------------------------------------------------------------------------------------------
| | |
| COBOL | $CONTROL STDWARN |
| | |
---------------------------------------------------------------------------------------------
| | |
| FORTRAN | $OPTION ANSI ON$ |
| | |
---------------------------------------------------------------------------------------------
| | |
| Pascal | $standard_level 'ANSI'$ |
| | |
---------------------------------------------------------------------------------------------
* If implicit updatability is specified (using the ANSI option), any
column in a select list can be updated or deleted, so long as the
FOR UPDATE clause has not been used in the SELECT statement
definition. Refer to the later section, "Understanding Implicit
Updatability."
* If a DBEFileSet is specified and the module owner does not have
authority to store sections in that DBEFileSet, a warning is given
and any sections are stored in the default DBEFileSet instead.
Authorization
To preprocess a program, you need DBA or CONNECT authority for the
DBEnvironment specified in the preprocessor command line. You also need
table and view authorities for the tables and views which the program
will access at run time. To store sections in a specified DBEFileSet,
the module owner must have SECTIONSPACE authority on the DBEFileSet.
DBEnvironment CONNECT authority can be explicitly granted. If you have
DBECreator or DBA authority or module OWNER authority, you have CONNECT
authority by default. SECTIONSPACE authority for other than the default
DBEFileSet must be explicitly granted by a DBA. If you have DBA
authority, you can issue the GRANT statement for any DBEFileSet.
Table authorities are implicitly specified at the time the table is
created and depend on the table type (PRIVATE, PUBLICREAD, PUBLIC, or
PUBLICROW). Once a table has been created, its implicit authorities can
be changed by the table OWNER, the DBECreator, or another DBA. Table
authorities are removed by using the REVOKE statement and are added by
using the GRANT statement.
For example, for a PUBLIC or a PUBLICROW table, you are implicitly
granted authority for any type of table access when the table is created.
For a PUBLICREAD table, you must have explicitly granted authority for
any table access except READ access which is an implicit grant. For a
PRIVATE table, there are no implicit grants at table creation time; only
the table OWNER or a DBA can access a PRIVATE table, unless specific
authorities are granted to others.
Note, in the case of the sample database, PartsDBE, the creation script
REVOKEs all implicit table authorities, and desired authorities must be
explicitly granted.
NOTE When preprocessing, you cannot name another user as module owner
unless you are a DBA of the DBEnvironment or you are the current
module owner.
Example of Full Preprocessing of a C Application
:FILE SQLIN=CEX2
:RUN PSQLC.PUB.SYS;INFO=&
"PartsDBE (MODULE(CEX2) OWNER(OwnerP@SomeAcct) REVOKE DROP)"
WED, OCT 25, 1991, 1:38 PM
HP36216-02A.E1.02 C Preprocessor/3000 ALLBASE/SQL
(C)COPYRIGHT HEWLETT-PACKARD CO. 1982,1983,1984,1985,1986,1987,1988,
1989,1990,1991. ALL RIGHTS RESERVED.
0 ERRORS 1 WARNINGS
END OF PREPROCESSING.
END OF PROGRAM
:EDITOR
HP32501A.07.20 EDIT/3000 FRI, OCT 27, 1991, 10:17 AM
(C)HEWLETT-PACKARD CO. 1990
/T SQLMSG;L ALL UNN
FILE UNNUMBERED
.
.
.
SQLIN = CEX2.SOMEGRP.SOMEACCT
DBEnvironment = partsdbe
Module Name = CEX2
SELECT PARTNUMBER, PARTNAME, SALESPRICE INTO :PARTNUMBER, :PARTNAME,
:SALESPRICE :SALESPRICEIND FROM PURCHDB.PARTS WHERE PARTNUMBER =
:PARTNUMBER ;
****** ALLBASE/SQL warnings (DBWARN 10602)
****** in SQL statement ending in line 133
*** User SomeUser@SomeAcct does not have SELECT authority on PURCHDB.PARTS.
(DBERR 2301)
1 Sections stored in DBEnvironment.
0 ERRORS 1 WARNINGS
END OF PREPROCESSING
/
DBEnvironment Access in Full Preprocessing Mode
When you invoke the preprocessor in full preprocessing mode, and specify
an ALLBASE/SQL DBEnvironment, the preprocessor starts a DBE session for
that DBEnvironment when preprocessing begins and terminates that session
when preprocessing is completed.
: RUN PSQLC.PUB.SYS; INFO="DBEnvironment (MODULE (ModuleName))"
When the preprocessor terminates its DBEnvironment session, it issues a
COMMIT WORK statement if it encountered no errors. Created sections are
stored in the DBEnvironment and associated with the module name.
ALLBASE/SQL accesses the specified DBEnvironment during preprocessing,
even if your application does not use SQL statements that store sections
in this DBEnvironment. Therefore, unless you specify the -N option, you
must specify the name of a valid DBEnvironment. Note that a
DBEnvironment name is not required by other preprocessing modes.
Accessing Multiple DBEnvironments in Full Preprocessing Mode.
In some cases an ALLBASE/SQL program is used with one or more
DBEnvironments in addition to the DBEnvironment accessed at preprocessing
time. In these cases, you can use ISQL to install the installable module
created by the preprocessor into each additional DBEnvironment accessed
by your program.
An alternative method of accessing more than one DBEnvironment from the
same program would be to divide the program into separate compilable
files. Each source file would access a DBEnvironment. In each file,
start and terminate a DBE session for the DBEnvironment accessed. Then
preprocess and compile each file separately. When you invoke the
preprocessor, identify the DBEnvironment accessed by the source file
being preprocessed. After a file is preprocessed, it must be compiled so
that no linking is performed before the next source file is preprocessed.
When all source files have been preprocessed and compiled, link them
together to create an executable program.
For example, to preprocess several ALLBASE/SQL application programs in
the same group and account and compile and link the programs later, you
should do the following for each program:
* Before running the preprocessor, equate SQLIN to the name of the
file containing the application you want to preprocess:
:FILE SQLIN = InFile
* Run the preprocessor for each DBEnvironment and module, as in the
following example in C:
:RUN PSQLC.PUB.SYS;INFO="DBEnvironment1 (MODULE (ModuleName1))"
* After running the preprocessor, save and rename the output files
so that they will not be overwritten. For example:
:SAVE SQLOUT
:RENAME SQLOUT, OutFile1
:SAVE SQLVAR
:RENAME SQLVAR, VarFile1
* When you are ready to compile the program, you must equate each
output file name for a given DBEnvironment/module combination to
its standard ALLBASE/SQL name, then issue the compile command, as
in the following example:
:FILE SQLOUT = OutFile1
:FILE SQLVAR = VarFile1
.
.
:CCXL SQLOUT, SQLOBJ1
* After all applications have been complied, link their object
files, as follows:
.
.
:LINK FROM=SQLOBJ1,SQLOBJ2;RL=STDRL.LIB.SYS;TO=SOMEPROG
To preprocess a program, or to use an already preprocessed ALLBASE/SQL
application program, you must satisfy the authorization requirements for
each DBEnvironment accessed.