HP 3000 Manuals HP 3000 Manuals
POSIX Preprocessor Invocation
You can invoke the C preprocessor in any preprocessing mode, using POSIX
command line options as described in the following sections. The
preprocessor generates output files as POSIX byte-stream files
(compatible with UNIX) using the naming conventions documented in the
ALLBASE/SQL application programming guides for HP-UX.
An existing DBEnvironment name can be specified in the preprocessor
command line in hierarchical file system (HFS) format. An HFS file name
is one beginning with either a '.' or a '/.' The preprocessor converts
the HFS DBEnvironment name to a conventional MPE/iX style file name
(FileName.GroupName.AccountName). In the following example, the
preprocessor converts the DBEnvironment name /SYS/SAMPLEDB/PARTSDBE to
PARTSDBE.SAMPLEDB.SYS.
POSIX> /SYS/PUB/PSQLC /SYS/SAMPLEDB/PARTSDBE -i ./Source.sql -d -m Module
HFS file names of up to 1024 bytes are supported.
You can also specify HFS file names in #INCLUDE statements. These files
are included during preprocessing.
POSIX Full Preprocessing Mode for C Applications
[-i SourceFileName ]
[-p ModifiedSourceFileName]
[-o OwnerName ]
[-m ModuleName ]
[-f FlaggerName ]
POSIX> /SYS/PUB/PSQLC DBEnvironmentName [-a ]
[-N ]
[-n DBEFileSetName ]
[-d [-r] ]
[-W ]
[-t ]
|...|"
Parameters
DBEnvironmentName identifies the DBEnvironment in which a module is
to be stored. This name must be specified in
upper case.
-i SourceFileName identifies the name of the input file containing
the source code to be preprocessed. If not
specified, ./sqlin is the default.
-p identifies the name for the modified source code
ModifiedSourceFileName file. If a name is not specified, the
preprocessor generated code is written to a file
with the same name as SourceFileName and with an
appropriate file extension, as follows:
---------------------------------------------------------------------------------------------
| | |
| Language | File Name Extension |
| | |
---------------------------------------------------------------------------------------------
| | |
| C | SourceFileName.c |
| | |
---------------------------------------------------------------------------------------------
| | |
| COBOL | SourceFileName.cbl |
| | |
---------------------------------------------------------------------------------------------
| | |
| FORTRAN | SourceFileName.f |
| | |
---------------------------------------------------------------------------------------------
| | |
| Pascal | SourceFileName.p |
| | |
---------------------------------------------------------------------------------------------
-o 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 SourceFileName not qualified with an
owner name are qualified with this OwnerName.
-m 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
in upper case as the module name. This
module name is stored in the module file,
ModifiedSourceFileName.sqlm.
-f 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.
-a 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.
-N 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.
-n 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.
-d deletes any module currently stored in the
DBEnvironment by the ModuleName and OwnerName
specified in the command string. If not
specified, any module having these names is not
dropped, and existing RUN authorities for that
module are preserved.
-r is specified when the program being preprocessed
already has a stored module and you want to
revoke existing RUN authorities for that module.
The -r option cannot be specified unless -d is
also specified. If the -r option is not
specified, it is assumed that all existing RUN
authorities for that module are to be PRESERVED.
-W converts preprocessor generated bind warnings to
errors. If -W is not specified, the default bind
warnings will be generated.
-t For C applications only; used to support threaded
applications. When specified, the C preprocessor
will not generate the #include "SQLVAR" line at
the beginning of SQLOUT. The user must insert a
#include "SQLVAR" wherever local variables are
required to compile and utilize application
threads successfully.
POSIX Static Conversion Mode for C Applications
[-i SourceFileName ]
[-p ModifiedSourceFileName.c]
POSIX> /SYS/PUB/PSQLC -D [-f FlaggerName ] |...|"
[-a ]
[-t ]
Parameters
-D indicates that all static SQL statements are to
be converted to dynamic statements, dynamic
statements remain dynamic, and a module is not
created.
-i SourceFileName identifies the name of the input file containing
the source code to be preprocessed. If not
specified, ./sqlin is the default.
-p identifies the name for the modified source
ModifiedSourceFileName code file. If a name is not specified,
SourceFileName.c is the default.
-f 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.
-a preprocesses the application in ANSI mode. The
preprocessorgenerates an SQLCA declaration
automatically and implicit updatability is in
effect. Refer to the sections "Understanding
Implicit Updatability" and "Declaring the SQLCA"
in this manual.
-t For C applications only; used to support threaded
applications. When specified, the C preprocessor
will not generate the #include "SQLVAR" line at
the beginning of SQLOUT. The user must insert a
#include "SQLVAR" wherever local variables are
required to compile and utilize application
threads successfully.
POSIX Syntax Checking Mode for C Applications
[-i SourceFileName ]
[-p ModifiedSourceFileName]
POSIX> /SYS/PUB/PSQLC -s [-f FlaggerName ] |...|"
[-a ]
[-t ]
Parameters
-s causes the preprocessor to only check SQL syntax.
-i SourceFileName
identifies the name of the input file containing
the source code to be preprocessed. If not
specified, ./sqlin is the default.
-p identifies the name for the modified source
ModifiedSourceFileName code file. If a name is not specified,
SourceFileName.c is the default.
-f 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.
-a 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.
-t For C applications only; used to support threaded
applications. When specified, the C preprocessor
will not generate the #include "SQLVAR" line at
the beginning of SQLOUT. The user must insert a
#include "SQLVAR" wherever local variables are
required to compile and utilize application
threads successfully.