You can define a symbol to make invoking the SQL module processor
easier. For example:
$ SQLMOD == "$SQL$MOD"
You then can invoke the SQL module processor with or without a
module file specification:
o If you invoke the SQL module processor without a module file
specification, the module processor prompts you for it. For
example:
$ SQLMOD
INPUT FILE> module-file-specification
o If you invoke the SQL module processor with a module file
specification as part of the DCL command line, SQL starts
processing your module file immediately after you press the
Return key. For example:
$ SQLMOD module-file-specification
Either way, there are several qualifiers you can specify with
the file specification that control how SQL processes the module
file. The syntax diagram shows the format for those qualifiers.
1 – Format
(B)0[m[1mmodule-file-spec-qual = [m
[1m [m
[1;4mSQLMOD[m[1m qqqq> module-file-spec qwqqqqqqqqqqqqqqqqqqqqqqqqqwqq> [m
[1m tq> <context-file-name> qqu [m
[1m tq> module-qualifiers-1 qqu [m
[1m mq> module-qualifiers-2 qqj [m
[1m [m
(B)0[m[1mmodule-qualifiers-1 = [m
[1m [m
[1mqqwwqwqq> no-qualifiers-1 qqwqqqqqqqqqqqqqqqqqwwq> [m
[1m xx mqq> no-qualifiers-2 qqj xx [m
[1mxtq>[m [1m/[1;4mARCHITECTURE[m[1m = architecture_options[m [1mqqux[m
[1m xtq> [1;4m/C_STRING[m[1m = c-string-options qqqqqqqqqqux [m
[1m xtq> [1;4m/CONSTRAINT_MODE[m[1m = qwq> [1;4mIMMEDIATE[m[1m qqqqqux [m
[1m xx tq> [1;4mDEFERRED[m[1m qqqqqqux [m
[1m xx tq> [1;4mOFF[m[1m qqqqqqqqqqqux [m
[1m xx mq> [1;4mON[m[1m qqqqqqqqqqqqux [m
[1m xtq> [1;4m/CONTEXT[m[1m = qwq> [1;4mNONE[m[1m qqqqqqqqqqqqqqqqqqux [m
[1m xx tq> [1;4mALL[m[1m qqqqqqqqqqqqqqqqqqqux [m
[1m xx [m [1m mq> procedure-list qqqqqqqqux [m
[1mxtq> [1;4m/FLOAT[m [1m= qwq> D_FLOAT[m [1mqqqqqqqqqqqqqqqqqux[m
[1mxx[m [1m [m [1mtq>[m [1mG_FLOAT[m [1mqqqqqqqqqqqqqqqqqux[m
[1mxx[m [1mmq>[m [1mIEEE_FLOAT[m [1mqqqqqqqqqqqqqux[m
[1m xtq> [1;4m/USER_DEFAULT[m[1m = <username> qqqqqqqqqqqqux [m
[1m xmq> [1;4m/PASSWORD_DEFAULT[m[1m = <password> qqqqqqqqjx [m
[1m mqqqqqqqqqqqqqqqqqqqqq<qqqqqqqqqqqqqqqqqqqqqqj [m
[1m [m
(B)0[m[1mno-qualifiers-1 = [m
[1m [m
[1mq> / wqqqqwqwq> [1;4mALIGN_RECORDS[m[1m qqqqqqqqqqqqqqqqqqqqqqqqqqqqwq> [m
[1mm [1;4mNO[m[1m j[m [1mtq>[m [1;4mC_PROTOTYPES[m[1m qqwqqqqqqqqqqqqqqqqqqqqqwqqqqu[m
[1mx[m [1mmq> = <file-name> qqj[m [1mx[m
[1m tq> [1;4mCONNECT[m[1m qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu [m
[1m tq> [1;4mEXTERNAL_GLOBALS[m[1m qqqqqqqqqqqqqqqqqqqqqqqqqu [m
[1m tq> [1;4mFLAG_NONSTANDARD[m[1m qqwqqqqqqqqqqqqqqqqqqqwu [m
[1m x tq> = [1;4mMIA[m[1m qqqqqqqqqux [m
[1m x tq> = [1;4mSQL89[m[1m qqqqqqqux [m
[1m x mq> = [1;4mSQL92_ENTRY[m [1mqjx [m
[1m tq> [1;4mG_FLOAT[m[1m qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu [m
[1m tq> [1;4mINITIALIZE_HANDLES[m[1m qqqqqqqqqqqqqqqqqqqqqqqu [m
[1m tq> [1;4mLIST[m[1m qqqqwqqqqqqq>qqqqqqqqqwqqqqqqqqqqqqqqu [m
[1m x mq> = <file-spec> j x [m
[1mtq>[m [1;4mLOWERCASE_PROCEDURE_NAMES[m[1m qqqqqqqqqqqqqqqqu[m
[1m mq> [1;4mMACHINE_CODE[m[1m qqqqqqqqqqqqqqqqqqqqqqqqqqqqqj [m
[1m [m
(B)0[m[1mno-qualifiers-2 = [m
[1m [m
[1mq> / wq>qqwqwq> [1;4mOBJECT[m[1m qqwqqqqqqq>qqqqqqqqqwqqqqqqqqqqqqqqqqwqqq>[m
[1m m [1;4mNO[m[1m j x mq> = <file-spec> j [m [1m x [m
[1m tq> [1;4mPACKAGE_COMPILATION[m[1m qqqqqqqqqqqqqqqqqqqqqqqqu [m
[1m tq> [1;4mPARAMETER_CHECK[m[1m qqqqqqqqqqqqqqqqqqqqqqqqqqqu [m
[1mtq>[m [1;4mPRAGMA[m[1m = ( q> [1;4mIDENT[m[1m = string-literal q> ) qqu[m
[1mtq> [1;4mPROTOTYPES[m[1m qqwqqqqqqqqqqqqqqqqqqqqqqqqwqqqqqu[m
[1mx[m [1mmq> = <prototypesfile> qqj[m [1mx[m
[1m tq> [1;4mQUERY_ESTIMATES[m[1m qqqqqqqqqqqqqqqqqqqqqqqqqqqu [m
[1mtq>[m [1;4mQUIET_COMMIT[m [1mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu[m
[1m tq> [1;4mTRANSACTION_DEFAULT[m[1m qwqqqqqqqqqqqqqqqqqqwqqqu [m
[1m x tq> = [1;4mIMPLICIT[m[1m qqqqu [m [1m x [m
[1m x mq> = [1;4mDISTRIBUTED[m[1m qj [m [1m x [m
[1m mq> [1;4mWARN[m[1m qwqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqqqqj [m
[1m [m [1m m> = ( w> warning-option w> ) qqj [m [1m [m
[1mmqqqqqq , <qqqqqqqj[m
(B)0[m[1mwarning-option = [m
[1m [m
[1mqqqwqqqwq> [1;4mWARNING[m[1m qqqqqqwqqwq> [m
[1m x tq> [1;4mNOWARNING[m[1m qqqqu x [m
[1m x tq> [1;4mDEPRECATE[m[1m qqqu x [m
[1m x mq> [1;4mNODEPRECATE[m[1m qj x [m
[1m mqqqqqqqqq , <qqqqqqqqqqqj [m
(B)0[m [1marchitecture_options =[m
[1m [m
[1mqwq> [1;4mGENERIC[m [1mqwqq>[m
[1m tq> [1;4mHOST[m[1m qqu [m
[1m tq> [1;4mEV4[m[1m qqu [m
[1m tq> [1;4mEV5[m[1m qqu [m
[1m tq> [1;4mEV56[m[1m qqu [m
[1mtq>[m [1;4mPCA56[m[1m qqu[m
[1mtq>[m [1;4mEV6[m[1m [m [1mqqu[m
[1mtq>[m [1;4mEV67[m[1m qqu[m
[1mtq>[m [1;4mEV68[m[1m qqu[m
[1mmq>[m [1;4mEV7[m[1m qqj[m
[1m [m [1m [m
[1m [m
(B)0[m[1mc-string-options = [m
[1m [m
[1mqwwqqwqqqqqqw> [1;4mBLANK_FILL[m[1m qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqw>[m
[1m xx m> [1;4mNO[m[1m qj x [m
[1m xmqqwqqqqqqw> [1;4mFIXED_CDD_STRINGS[m[1m qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu [m
[1m x m> [1;4mNO[m[1m qj x [m
[1m m> ( wqqqqqw> [1;4mBLANK_FILL[m[1m q> , wqqqqqqw> [1;4mFIXED_CDD_STRINGS[m[1m q> ) j [m
[1m m> [1;4mNO[m[1m j m> [1;4mNO[m[1m qj [m
[1m [m
(B)0[m[1mmodule-qualifiers-2 = [m
[1m [m
[1mqqqqwwq> /database-options qqqqqqqqqqqqqqqqqqqqqqqwwq> [m
[1m xtq> /optimization_options qqqqqqqqqqqqqqqqqqqux [m
[1m xtq> [1;4m/QUERY_TIME_LIMIT[m[1m = <total-seconds> qqqqqux [m
[1m xtq> [1;4m/QUERY_MAX_ROWS[m[1m = <total-rows> qqqqqqqqqqux [m
[1m xtq> [1;4m/QUERY_CPU_TIME_LIMIT[m[1m = <total-seconds> qux [m
[1m xmq> [1;4m/ROLLBACK_ON_EXIT[m[1m qqqqqqqqqqqqqqqqqqqqqqqjx [m
[1m mqqqqqqqqqqqqqqqqqqqqq<qqqqqqqqqqqqqqqqqqqqqqqqj [m
(B)0[m [1m [m [1m [m [1m [m
[1moptimization-options= [m
[1mqqqq> [1;4mOPTIMIZATION_LEVEL[m[1m= qwqqqq> [1;4mDEFAULT[m[1m qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwq> [m
[1mmqq> ([m [1mqwwq> [1;4mAGGRESSIVE[m[4m_[1;4mSELECTIVITY[m[1m qqwqqwq[m [1m)[m [1mqj[m
[1m [m [1mxtq> [1;4mFAST[m[4m_[1;4mFIRST[m[1m [m [1mqqu[m [1mx[m [1m [m
[1m [m [1mxtq> [1;4mSAMPLED[m[4m_[1;4mSELECTIVITY[m [1mqqqqu[m [1mx[m [1m [m
[1m [m [1mxmq> [1;4mTOTAL[m[4m_[1;4mTIME[m[1m [m [1mqqqqqqqqqqqqj[m [1mx[m [1m [m
[1mmqqqqqq[m [1m, <qqqqqqqqqqqqqqqqqqqqqqj[m
[1m [m
[1m [m
(B)0[m[1mdatabase-options = [m
[1m [m
[1mqqwqq> [1;4mELN[m[1m qqqqqqqqqqqqqqqqqqqqqwqq> [m
[1m tqq> [1;4mNSDS[m[1m qqqqqqqqqqqqqqqqqqqqu [m
[1m tqq> rdb-options qqqqqqqqqqqqqu [m
[1m tqq> [1;4mVIDA[m[1m qqqqqqqqqqqqqqqqqqqqu [m
[1m tqq> [1;4mVIDA=V1[m[1m qqqqqqqqqqqqqqqqqu [m
[1m tqq> [1;4mVIDA=V2[m[1m qqqqqqqqqqqqqqqqqu [m
[1m tqq> [1;4mVIDA=V2N[m[1m qqqqqqqqqqqqqqqqu [m
[1m tqq> [1;4mNOVIDA[m[1m qqqqqqqqqqqqqqqqqqu [m
[1m tqq> [1;4mDBIV1[m[1m qqqqqqqqqqqqqqqqqqqu [m
[1m tqq> [1;4mDBIV31[m[1m qqqqqqqqqqqqqqqqqqu [m
[1m mqq> [1;4mDBIV70[m[1m qqqqqqqqqqqqqqqqqqj [m
[1m [m
(B)0[m [1mrdb-options = [m
[1m [m
[1mqwq> [1;4mRDBVMS[m[1m qqwqq>[m
[1m tq> [1;4mRDB030[m[1m qqu [m
[1m tq> [1;4mRDB031[m[1m qqu [m
[1m tq> [1;4mRDB040[m[1m qqu [m
[1m tq> [1;4mRDB041[m[1m qqu [m
[1mtq>[m [1;4mRDB042[m [1mqqu[m
[1mtq>[m [1;4mRDB050[m [1mqqu[m
[1mtq>[m [1;4mRDB051[m [1mqqu[m
[1mtq>[m [1;4mRDB060[m [1mqqu[m
[1mtq>[m [1;4mRDB061[m [1mqqu[m
[1mtq>[m [1;4mRDB070[m [1mqqu[m
[1mmq>[m [1;4mRDB071[m [1mqqj[m
(B)0[m[1mprocedure-list = [m
[1m [m
[1mqq> ( qwq> <procedure> wqqqqqqqqqqqqqqqqqqqwwq> ) q> [m
[1m x mqq> : <entry-name> jx [m
[1m mqqqqqqqqqqqqqqq , <qqqqqqqqqqqqqqqqqj [m
[1m [m
2 – Arguments
2.1 – ALIGN_RECORDS
Syntax options:
ALIGN_RECORDS
NOALIGN_RECORDS
Aligns the fields in an SQL module procedure record parameter.
If your host language is C, the default is ALIGN_RECORDS;
otherwise, the default is NOALIGN_RECORDS.
2.2 – ARCHITECTURE
Syntax options:
ARCHITECTURE=GENERIC
ARCHITECTURE=HOST
ARCHITECTURE=EV4
ARCHITECTURE=EV5
ARCHITECTURE=EV56
ARCHITECTURE=PCA56
ARCHITECTURE=EV6
ARCHITECTURE=EV67
ARCHITECTURE=EV68
ARCHITECTURE=EV7
For improved performance of generated code, the ARCHITECTURE
command line qualifier can be used on OpenVMS Alpha systems. The
ARCHITECTURE qualifier is ignored on Itanium systems.
The ARCHITECTURE qualifier specifies the lowest version of the
Alpha architecture where this code will run. This allows the
compiler to generate more efficient code, with the tradeoff that
code may not run on older systems.
All Alpha processors implement a core set of instructions and, in
some cases, the following extensions:
o Byte/word extension (BWX) - The instructions that comprise the
BWX extension are LDBU, LDWU, SEXTB, SEXTW, STB, and STW.
o Square-root and floating-point convert extension (FIX) - The
instructions that comprise the FIX extension are FTOIS, FTOIT,
ITOFF, ITOFS, ITOFT, SQRTF, SQRTG, SQRTS, and SQRTT.
o Count extension (CIX) - The instructions that comprise the CIX
extension are CTLZ, CTPOP, and CTTZ.
o Multimedia extension (MVI) - The instructions that comprise
the MVI extension are MAXSB8, MAXSW4, MAXUB8, MAXUW4, MINSB8,
MINSW4, MINUB8, MINUW4, PERR, PKLB, PKWB, UNPKBL, and UNPKBW.
The Alpha Architecture Reference Manual describes the extensions
in detail.
The keyword specified with the ARCHITECTURE qualifier determines
which instructions the compiler can generate and which coding
rules it must follow.
o GENERIC - Generate instructions that are appropriate for all
Alpha processors. This option is the default and is equivalent
to /ARCH=EV4.
o HOST - Generate instructions for the processor that the
compiler is running on (for example, EV56 instructions on
an EV56 processor, EV7 instructions on an EV7 processor, and
so on).
o EV4 - Generate instructions for the EV4 processor (21064,
20164A, 21066, and 21068 chips). Applications compiled with
this option will not incur any emulation overhead on any Alpha
processor.
o EV5 - Generate instructions for the EV5 processor (some 21164
chips). (Note that the EV5 and EV56 processors both have the
same chip number - 21164.) Applications compiled with this
option will not incur any emulation overhead on any Alpha
processor.
o EV56 - Generate instructions for EV56 processors (some 21164
chips). This option permits the compiler to generate any
EV4 instruction plus any instructions contained in the BWX
extension. Applications compiled with this option may incur
emulation overhead on EV4 and EV5 processors.
o PCA56 - Generate instructions for PCA56 processors (21164PC
chips). This option permits the compiler to generate any EV4
instruction plus any instructions contained in the BWX and MVI
extensions. Applications compiled with this option may incur
emulation overhead on EV4 and EV5 processors.
o EV6 - Generate instructions for EV6 processors (21264
chips). This option permits the compiler to generate any
EV4 instruction, any instruction contained in the BWX and
MVI extensions, plus any instructions added for the EV6
chip. These new instructions include a floating-point square
root instruction (SQRT), integer/floating-point register
transfer instructions, and additional instructions to identify
extensions and processor groups. Applications compiled with
this option may incur emulation overhead on EV4, EV5, EV56,
and PCA56 processors.
o EV67 or EV68 - Generate instructions for EV67 and EV68
processors (21264A chips). This option permits the
compiler to generate any EV6 instruction plus the new bit
count instructions (CTLZ, CTPOP, and CTTZ). However, the
precompilers do not currently generate any of the new bit
count instructions and the EV67 and EV68 have identical
instruction scheduling models so the EV67 and EV68 are
essentially identical to the EV6. Applications compiled with
this option may incur emulation overhead on EV4, EV5, EV56,
and PCA56 processors.
o EV7 - Generate instructions for the EV7 processor (21364
chip). This option permits the compiler to generate any EV67
instruction. There are no additional instructions available
on the EV7 processor but the compiler does have different
instruction scheduling and prefetch rules for tuning code
for the EV7. Applications compiled with this option may incur
emulation overhead on EV4, EV5, EV56, and PCA56 processors.
The OpenVMS Alpha operating system includes an instruction
emulator. This capability allows any Alpha chip to execute and
produce correct results from Alpha instructions even if some of
the instructions are not implemented on the chip. Applications
using emulated instructions will run correctly but may incur
significant emulation overhead at run time.
Of the available extension types, the Byte/word extension (BWX)
will often be beneficial for increased performance of Rdb-based
applications. In addition, for those Alpha implementations
that support quad-issue of instructions (the EV6 and later
processors), the compiler does have different instruction
scheduling and prefetch rules for tuning code.
For highest levels of performance of generated code, Oracle
recommends that the ARCHITECTURE qualifier be specified with
the keyword that most closely matches the lowest processor type
of the machine where the program will execute.
LANGUAGE COMPILER SUPPORT FOR ARCHITECTURE
If specified, the ARCHITECTURE qualifier is passed on the
command line to the specified language compiler by the SQL
Precompiler. The language compiler being used must support
the ARCHITECTURE qualifier and the architecture keyword
value when the ARCHITECTURE qualifier is specified.
2.3 – C_PROTOTYPES
Syntax options:
C_PROTOTYPES=file-name
NOC_PROTOTYPES
This qualifier is deprecated and will not be supported in a
future release. It has been replaced by the PROTOTYPES qualifier.
2.4 – C_STRING
Syntax options:
C_STRING=[NO]BLANK_FILL
C_STRING=[NO]FIXED_CDD_STRINGS
C_STRING=([NO]BLANK_FILL, [NO]FIXED_CDD_STRINGS)
Specifies how to handle C host language character strings:
o [NO]BLANK_FILL (default: BLANK_FILL)
Controls whether or not C character strings are filled with
blanks as required by the SQL89 and ANSI/ISO SQL standards or
if the null terminator is placed after the last data byte of
the source string.
o [NO]FIXED_CDD_STRINGS (default: NOFIXED_CDD_STRINGS)
Controls whether or not SQL treats C character strings from
Oracle CDD/Repository record definitions as fixed-length
character strings or C null-terminated strings.
2.5 – c-string-options
Controls how SQL handles C host language character strings.
Use either or both of the [NO]BLANK_FILL and [NO]FIXED_CDD_
STRINGS keywords with the C_STRING qualifier to control C string
characteristics.
2.6 – CONNECT
Syntax options:
CONNECT
NOCONNECT
Specifies whether or not SQL allows multiple user sessions and
access to global databases across modules. All SQL modules in
an application must be compiled with connections enabled or
disabled.
The default setting is NOCONNECT.
2.7 – CONSTRAINT_MODE
Syntax options:
CONSTRAINT_MODE=IMMEDIATE
CONSTRAINT_MODE=DEFERRED
CONSTRAINT_MODE=ON
CONSTRAINT_MODE=OFF
You can optionally specify either the CONSTRAINT_MODE=IMMEDIATE
or CONSTRAINT_MODE=DEFERRED qualifier on the SQL module language
command line to set the default constraint evaluation mode for
commit-time constraints. (This qualifier does not affect the
evaluation of verb-time constraints.) The default is DEFERRED;
that is, commit-time constraints are evaluated at commit time.
Setting constraints ON causes each of the affected constraints
to be evaluated immediately, as well as at the end of each
statement, until the SET ALL CONSTRAINTS OFF statement is issued
or until the transaction completes with a commit or rollback
operation.
The SET ALL CONSTRAINTS statement overrides the CONSTRAINT_
MODE=IMMEDIATE or the CONSTRAINT_MODE=DEFERRED qualifier.
SQL users who require ANSI-standard SQL compatibility should set
constraints IMMEDIATE. The default (CONSTRAINT_MODE=DEFERRED) is
acceptable for most other users.
You can use the ON keyword instead of IMMEDIATE and the OFF
keyword instead of DEFERRED.
2.8 – CONTEXT=
Instructs the SQL module processor to execute module language
procedures in the context of a particular distributed
transaction. When you use this qualifier, SQL generates an
additional parameter for the procedures and places the parameter
as the last parameter declared in the procedure.
Following are the options you can specify with the CONTEXT=
qualifier:
o NONE
Specifies that the SQL module processor does not add a context
parameter to any procedure in the module.
o ALL
Specifies that the SQL module processor adds a context
parameter to every procedure in the module.
o procedure-list
Specifies that the SQL module processor adds a context
parameter to each procedure listed. If you specify an entry
name for a procedure in the list, the SQL module processor
changes the name of that procedure to the name specified.
For example, you can specify the following qualifier on the
command line:
/CONTEXT=(OPEN_PROC :OPEN_PROC_DIST, FETCH_PROC :FETCH_PROC_DIST,-
CLOS_PROC :CLOS_PROC_DIST)
SQL passes the context parameter to the OPEN_PROC, FETCH_
PROC, and CLOS_PROC procedures and gives them the new names
specified. For more information, see the Oracle Rdb7 Guide to
Distributed Transactions.
Your application must use the context structure to pass the
address of the distributed TID from the host language program
to procedures in the module that are involved in the distributed
transaction. You pass the context structure to procedures that
contain executable SQL statements, except statements that
you cannot execute when a transaction is already started or
statements that you cannot use when you explicitly call the
DECdtm system services. the Oracle Rdb SQL Reference Manual
lists the nonexecutable statements that do not take a context
structure.
You can also use the CONTEXT qualifier to specify a new name for
a procedure.
Qualifiers used with the CONTEXT qualifier specify which
procedures receive context parameters, and whether or not the
names of the procedures are changed.
Because you cannot use batch-update transactions with distributed
transactions, you should define the SQL$DISABLE_CONTEXT logical
name as True before you start a batch-update transaction.
(Distributed transactions require that you are able to roll back
transactions. Because batch-update transactions do not write to
recovery-unit journal (.ruj) files, batch-update transactions
cannot be rolled back.)
If you attempt to start a distributed transaction using a batch-
update transaction, what happens depends upon whether you call
the DECdtm system services implicitly or explicitly and which SQL
statement you use to start the transaction:
o If you start a batch-update transaction and explicitly call
the DECdtm system services, SQL returns an error at compile
time.
o If you start a batch-update transaction and implicitly call
the DECdtm system services, SQL takes the following actions:
- If you use a SET TRANSACTION statement with the BATCH
UPDATE clause, SQL starts a nondistributed transaction.
- If you use a DECLARE TRANSACTION statement with the BATCH
UPDATE clause, SQL returns an error at compile time.
The two-phase commit protocol applies only to distributed
transactions. For more information about distributed
transactions, see the Oracle Rdb7 Guide to Distributed
Transactions.
2.9 – context-file-name
A SQL command procedure containing DECLARE statements that you
want to apply when your program compiles and executes. See the
Oracle Rdb SQL Reference Manual for more information.
2.10 – database-options
Specifies that the SQL module processor will process a program
for access to the specified database type.
For more information regarding database options, see the Oracle
Rdb SQL Reference Manual
2.11 – DEPRECATE
Syntax options:
DEPRECATE
NODEPRECATE
The DEPRECATE and NODEPRECATE qualifiers specify whether or
not the SQL module processor writes diagnostic messages about
deprecated features.
Deprecated features are currently allowed features that will
not be allowed in future versions of SQL; that is, they will
be obsolete. For example, one deprecated feature is the use
of obsolete keywords such as VERB_TIME instead of VERB TIME.
A complete list of deprecated features appears on line in the
interactive SQL Help utility.
You can specify the WARN=WARNING qualifier if you prefer to have
all warning messages except those about deprecated features.
You can specify the WARN=(NOWARNING, DEPRECATE) qualifier if you
prefer only the deprecated feature messages. The WARN qualifier
alone is equivalent to the WARN=(WARNING, DEPRECATE) qualifier,
which means that SQL writes informational and warning messages,
plus messages about deprecated features. The NOWARN qualifier
alone is equivalent to the WARN=(NOWARNING, NODEPRECATE)
qualifier, which means that SQL does not write any messages.
2.12 – EXTERNAL_GLOBALS
Syntax options:
EXTERNAL_GLOBALS
NOEXTERNAL_GLOBALS
Specifies whether or not alias references are coerced into alias
definitions. An alias definition is an alias declared with the
GLOBAL keyword (the default) in the DECLARE ALIAS statement. An
alias reference is an alias declared with the EXTERNAL keyword in
the DECLARE ALIAS statement.
The EXTERNAL_GLOBALS qualifier treats alias references as alias
definitions. This qualifier provides compatibility with versions
prior to V7.0.
The NOEXTERNAL_GLOBALS qualifier treats alias references as alias
references. The NOEXTERNAL_GLOBALS qualifier may be useful on
OpenVMS if your application shares an alias between multiple
shareable images.
The default setting is EXTERNAL_GLOBALS.
For information on using aliases and shareable images, see the
Oracle Rdb Guide to SQL Programming.
2.13 – FLAG_NONSTANDARD
Syntax options:
FLAG_NONSTANDARD
FLAG_NONSTANDARD =SQL92_ENTRY
FLAG_NONSTANDARD =SQL89
FLAG_NONSTANDARD =MIA
NOFLAG_NONSTANDARD
Specifies whether or not SQL identifies nonstandard syntax.
Nonstandard syntax, called an extension, refers to syntax that
is not part of the ANSI/ISO SQL standard or the Multivendor
Integration Architecture (MIA) standard. You can specify the
following options:
o FLAG_NONSTANDARD
Notifies you of syntax that is an extension to the ANSI/ISO
SQL standard.
o FLAG_NONSTANDARD=SQL92_ENTRY
Notifies you of syntax that is an extension to the ANSI/ISO
SQL standard. This qualifier has the same effect on flagging
as does the FLAG_NONSTANDARD qualifier.
o FLAG_NONSTANDARD=SQL89
Notifies you of syntax that is an extension to the ANSI/ISO
1989 standard.
o FLAG_NONSTANDARD=MIA
Notifies you of syntax that is an extension to the MIA
standard.
o NOFLAG_NONSTANDARD
Prevents notification of extensions.
Preventing notification of extensions (NOFLAG_NONSTANDARD) is the
default.
2.14 – FLOAT
Syntax options:
FLOAT=D_FLOAT
FLOAT=G_FLOAT
FOAT=IEEE_FLOAT
The /FLOAT qualifier determines the conversion that SQL Module
language performs on SQL Module Language procedure parameters
declared as single or double precision floating point SQL
datatypes. SQL floating point datatypes are FLOAT(n), REAL, and
DOUBLE PRECISION. See the Oracle Rdb SQL Reference Manual for
details. Internally to Oracle Rdb, single precision floating
point types are represented as F-Floating while double precision
floating point types are represented and G-Floating. See SQL and
Corresponding OpenVMS Data Types for Module Language in Section
3.4 of the Oracle Rdb SQL Reference Manual for more details.
By default, parameters declared as single or double precision
floating point type are expected to be passed by the calling
host language program in F-Floating and G-Floating format,
respectively. This is equivalent to using a qualifier of
/FLOAT=G_FLOAT with the SQL$MOD command.
If the command line for SQL$MOD has /FLOAT=D_FLOAT, then the
single and double precision floating point parameters are
expected to be in F-Floating and D-Floating format respectively.
SQL Module Language will convert the double precision parameters
between D-Floating and G-Floating formats for both input and
output.
If the command line for SQL$MOD has /FLOAT=IEEE_FLOAT, the single
and double precision floating point parameters are expected to
be in IEEE S-Floating and IEEE T-Floating format, respectively.
SQL Module Language will convert between these formats and the
internal F-Floating and G-Floating formats for both input and
output.
If a parameter of an SQL Module Language procedure is of a record
type, any fields of the record which are of floating point types
follow the same rules as described above.
The floating point formats of the host language program actual
parameters must agree with the format expected by the SQL Module
Language actual parameter. See the Oracle Rdb SQL Reference
Manual for information concerning actual and formal parameter
agreement.)
NOTES
Oracle Rdb always stores floating point numbers internally
using the VAX 32-bit and 64-bit types called F-Floating (F_
FLOAT) and G-Floating (G_FLOAT), respectively. This means
that when IEEE formats are used in a host language program,
Oracle Rdb converts back and forth between the VAX and IEEE
formats. There are differences in the number of available
bits in the fraction and exponent between these formats.
Additionally, the IEEE formats have certain exponent values
reserved for infinity values. These differences can cause
floating point overflow or underflow as well as rounding
errors during the conversion process. See Appendix A of the
Portable Mathematics Library in the OpenVMS Operating System
documentation for data on the maximum and minimum values for
VAX versus IEEE floating point formats.
When /FLOAT=IEEE_FLOAT is used, floating point data types
may not be imported from the Common Data Dictionary.
2.15 – G_FLOAT
Syntax options:
G_FLOAT
NOG_FLOAT
The /G_FLOAT and /NOG_FLOAT qualifiers are for backwards
compatibility. They are equivalent to /FLOAT=G_FLOAT and
/FLOAT=D_FLOAT, respectively. You should not specify both /FLOAT
and /[NO]G_FLOAT qualifiers.
2.16 – INITIALIZE_HANDLES
Syntax options:
INITIALIZE_HANDLES
NOINITIALIZE_HANDLES
Specifies whether or not alias definitions are coerced into alias
references. The NOINITIALIZE_HANDLES qualifier causes all alias
declarations to be treated as alias references.
An alias definition is an alias declared with the GLOBAL keyword
(the default) in the DECLARE ALIAS statement. An alias reference
is an alias declared with the EXTERNAL keyword in the DECLARE
ALIAS statement.
The NOINITIALIZE_HANDLES qualifier may be useful for existing
source code on OpenVMS in coercing alias definitions into alias
references. Because there is usually no distinction between a
definition and a reference on OpenVMS, your application might
declare an alias definition where an alias reference is needed.
If you reorganize your application into multiple images that
share aliases, you must distinguish the alias definition from
the alias reference. In this case, use the NOINITIALIZE_HANDLES
qualifier to coerce a definition into a reference without
changing your source code.
If your application correctly declares alias references with the
EXTERNAL keyword, use the NOEXTERNAL_GLOBALS qualifier, instead
of the [NO]INITIALIZE_HANDLES to override the default on OpenVMS
and cause SQL to treat alias references properly as references.
The default setting is INITIALIZE_HANDLES. This qualifier
overrides the [NO]EXTERNAL_GLOBALS qualifier.
This qualifier is maintained for compatibility with previous
versions of Oracle Rdb. Use the [NO]EXTERNAL_GLOBALS qualifier,
which provides more precise control over alias definition. For
information on using aliases and shareable images, see the Oracle
Rdb Guide to SQL Programming.
2.17 – LIST
Syntax options:
LIST
NOLIST
Determines whether or not the SQL module processor creates a list
file containing the original module list along with any error
messages from the processing, and, if it does, what it is named.
The NOLIST qualifier is the default. If you specify the LIST
qualifier and do not include a file specification, the SQL module
processor creates a list file with the same file name as your
module source file with the file extension .lis.
2.18 – LOWERCASE_PROCEDURE_NAMES
Syntax options:
LOWERCASE_PROCEDURE_NAMES
NOLOWERCASE_PROCEDURE_NAMES
Forces the names of the module language procedures to be in
lowercase. This qualifier not only assumes that the SQL module
procedure names are in lowercase, it overrides the case in any
quoted SQL module procedure.
The default setting is NOLOWERCASE_PROCEDURE_NAMES.
2.19 – MACHINE_CODE
Syntax options:
MACHINE_CODE
NOMACHINE_CODE
Oracle Rdb determines whether or not the SQL module processor
includes machine code in the list (.lis) file; however, to
generate the list file with the machine code in it, you must
also specify the LIST qualifier.
The NOMACHINE_CODE qualifier is the default.
2.20 – module-file-spec
The file specification for an SQL module source file. The default
file extension for the source file is .sqlmod.
2.21 – module-qualifiers
A set of qualifiers that you can optionally apply to the SQL
module processor command line.
2.22 – no-qualifiers
You can add the NO prefix to negate any qualifier in this group.
2.23 – OBJECT
Syntax options:
OBJECT
NOOBJECT
Specifies whether or not the SQL module processor creates an
object file when compiling the source file if the compilation
does not generate fatal errors; and, if an object file is
produced, what the file is named. The OBJECT qualifier is the
default. If you specify the OBJECT qualifier and do not include
a file specification, the SQL module processor creates an object
file with the same file name as the source file and with the file
extension .obj.
2.24 – OPTIMIZATION_LEVEL
Specifies the optimizer strategy to be used to process all
queries within your SQL module language program. Select the:
o AGGRESSIVE_SELECTIVITY option if you expect a small number of
rows to be selected.
o DEFAULT option to accept the Oracle Rdb defaults: FAST_FIRST
and DEFAULT SELECTIVITY. strategy.
o FAST_FIRST option if you want your program to return data to
the user as quickly as possible, even at the expense of total
throughput.
o SAMPLED_SELECTIVITY option to use literals in the query to
perform preliminary estimation on indices.
o TOTAL_TIME option if you want your program to run at the
fastest possible rate, returning all the data as quickly as
possible. If your application runs in batch, accesses all the
records in a query, and performs updates or writes reports,
you should specify TOTAL_TIME.
You can select either the TOTAL_TIME or the FAST_FIRST option in
conjunction with either the AGGRESSIVE_SELECTIVITY or SAMPLED_
SELECTIVITY option. Use a comma to separate the keywords and
enclosed the list in parentheses.
The following example shows how to use the OPTIMIZATION_LEVEL
qualifier:
$ SQL$MOD/OPTIMIZATION_LEVEL=(TOTAL_TIME,SAMPLED_SELECTIVITY) APPCODE.SQLMOD
Any query that explicitly includes an OPTIMIZE WITH, or OPTIMIZE_
FOR clause is not affected by the settings established using the
OPTIMIZATION_LEVEL qualifier.
You affect the optimizer strategy of static SQL queries with the
optimization level qualifier; however, the default optimizer
strategy set by the OPTIMIZATION_LEVEL qualifier can be
overridden by the default optimizer strategy set in a top-level
SELECT statement.
In contrast, the SET OPTIMIZATION LEVEL statement specifies the
query optimization level for dynamic SQL query compilation only;
the statement does not affect the SQL compile-time environment
nor does it affect the run-time environment of static queries.
2.25 – PACKAGE_COMPILATION
Syntax options:
PACKAGE_COMPILATION
NOPACKAGE_COMPILATION
Determines if a package specification is produced and loaded into
the ACS library.
Oracle Rdb produces a package specification when you process
a module with the LANGUAGE ADA clause specified in the module
header unless you specify the NOPACKAGE_COMPILATION qualifier.
The NOPACKAGE_COMPILATION qualifier prevents the package
specification from being loaded in the ACS library, but still
creates and compiles the .ada file.
The PACKAGE_COMPILATION qualifier is the default.
2.26 – PARAMETER_CHECK
Syntax options:
PARAMETER_CHECK
NOPARAMETER_CHECK
Specifies whether or not the SQL module processor compares
the number of formal parameters declared for a procedure with
the number of parameters specified in the SQL statement of the
procedure:
o PARAMETER_CHECK (default)
Checks that parameter counts match and generates an error at
run time (not compile time) when they do not.
o NOPARAMETER_CHECK
Suspends checking parameters to improve module compilation
time. Consider using the NOPARAMETER_CHECK qualifier after you
have debugged your SQL module.
SQL checks parameter counts by default. To improve module
compilation time, you must explicitly use the NOPARAMETER_CHECK
qualifier.
2.27 – PASSWORD_DEFAULT
Specifies the user's password at compile time.
If you use the USING DEFAULT clause of the DECLARE ALIAS
statement, you use this qualifier to pass the compile-time user's
password to the program.
2.28 – PRAGMA
Syntax options:
PRAGMA = IDENT = string-literal
NOPRAGMA
Using the IDENT keyword with the PRAGMA qualifier allows the user
to pass a text string to the SQL Module Language compiler to be
written to the Object Module Header. This is a way to note the
generation of the compiler module.
If the PRAGMA (IDENT ...) clause is used as part of the DECLARE
MODULE statement, then that value will override any value used on
the command line.
The ANALYZE/OBJECT and LIBRARY command can be used to display
this ident string, and the value will be displayed in LINKER map
files.
OpenVMS limits the IDENT string to a 15 octet string. If the
string is longer than this (even with trailing spaces) then an
error will be reported by the SQL precompiler.
The following example demonstrates the use of the qualifier to
establish the generation of the compiler module.
$ SQL$MOD TEST/PRAGMA=IDENT="v1.2-32"
2.29 – PROTOTYPES
Syntax options:
PROTOTYPES[=prototypesfile]
NOPROTOTYPES
The PROTOTYPES qualifier uses the LANGUAGE clause from the module
to generate routine declarations for the following languages: C
(C++), Pascal, and BLISS. The qualifier is ignored for all other
language values.
The prototypes file specification defaults to the same device,
directory, and file name as the module language source. The file
types default to .h for C, .PAS for Pascal, and .REQ for BLISS.
For the BLISS language, the PROTOTYPES qualifier generates
EXTERNAL ROUTINE declarations for each SQL module language
procedure.
For the Pascal language, the generated external procedure
declarations are suitable for inclusion in either a Pascal
program or module. Structured types (RECORD ... END RECORD),
SQLDA, and SQLCA used by the SQL module language procedures are
declared as UNSAFE arrays of bytes to simplify passing structures
via these external definitions. However, care must be taken as
this form of declaration disables the strong typing checks in
Pascal.
The output for the C language includes pre-processor directives
to conditionally include C++ "extern C" syntax and also allow
multiple #include references.
The default setting is NOPROTOTYPES.
2.30 – QUERY_CPU_TIME_LIMIT
Limits the amount of CPU time used to optimize a query for
execution. If the query is not optimized and prepared for
execution before the CPU time limit is reached, an error message
is returned.
The default is unlimited time for the query to compile. Dynamic
SQL options are inherited from the compilation qualifier.
2.31 – QUERY_ESTIMATES
Syntax options:
QUERY_ESTIMATES
NOQUERY_ESTIMATES
Specifies whether or not SQL returns the estimated number of
rows and estimated number of disk I/O operations in the SQLCA
structure. If you specify the default, which is the QUERY_
ESTIMATES qualifier, SQL returns the estimated number of rows
in the field SQLCA.SQLERRD[2] and the estimated number of disk
I/O operations in the field SQLCA.SQLERRD[3]. The value of
SQLCA.SQLERRD[2] and SQLCA.SQLERRD[3] is normally 0 after you
execute an OPEN statement for a table.
The following example shows interactive SQL output from a
statement that accesses the INTRO_PERSONNEL database. The
database was loaded using the sample program SQL$INTRO_LOAD_
EMPL_C.SQLMOD with the QUERY_ESTIMATES qualifier on the module
language command line. The SQLCA.SQLERRD[2] field shows that SQL
estimates 100 rows. The SQLCA.SQLERRD[3] field shows that SQL
estimates 16 disk I/O operations.
$ SQL$
SQL> ATTACH 'FILENAME intro_personnel';
SQL> DECLARE MY_CURSOR
cont> TABLE CURSOR FOR
cont> SELECT * FROM EMPLOYEES;
SQL> OPEN MY_CURSOR;
SQL> SHOW SQLCA;
SQLCA:
SQLCAID: SQLCA SQLCABC: 128
SQLCODE: 0
SQLERRD: [0]: 0
[1]: 0
[2]: 100
[3]: 16
[4]: 0
[5]: 0
SQLWARN0: SQLWARN1: SQLWARN2:
SQLWARN3: SQLWARN4: SQLWARN5:
SQLWARN6: SQLWARN7:
2.32 – QUERY_MAX_ROWS
Limits the number of records returned during query processing by
counting the number of rows returned by the query and returning
an error message if the query exceeds the total number of rows
specified.
The default is an unlimited number of record fetches. Dynamic SQL
options are inherited from the compilation qualifier.
2.33 – QUERY_TIME_LIMIT
Limits the number of records returned during query processing
by counting the number of seconds used to process the query and
returning an error message if the query exceeds the total number
of seconds specified.
The default is unlimited time for the query to compile. Dynamic
SQL options are inherited from the compilation qualifier.
2.34 – ROLLBACK_ON_EXIT
Rolls back outstanding transactions when a program exits from
SQL.
On OpenVMS outstanding transactions are committed when a program
exits from SQL by default. Therefore, if you want to roll back
changes, specify this qualifier on the command line.
2.35 – TRANSACTION_DEFAULT
Syntax options:
TRANSACTION_DEFAULT=IMPLICIT
TRANSACTION_DEFAULT=DISTRIBUTED
NOTRANSACTION_DEFAULT
Specifies when SQL starts a transaction and how SQL handles
default distributed transactions. You can specify the following
options:
o TRANSACTION_DEFAULT=IMPLICIT
Causes SQL to start a transaction when you issue either a SET
TRANSACTION statement or the first executable SQL statement in
a session.
o TRANSACTION_DEFAULT=DISTRIBUTED
Causes SQL to use the distributed transaction identifier (TID)
for the default distributed transaction established by the
DECdtm system service SYS$START_TRANS. Using this option
eliminates the need to declare context structures in host
language programs and to pass context structures to SQL module
procedures. Because it closes all cursors, it also eliminates
the need to call the SQL_CLOSE_CURSORS routine.
You must explicitly call the DECdtm system services when you
use this option.
This option provides support for the Structured Transaction
Definition Language (STDL) of the Multivendor Integration
Architecture (MIA) standard.
If you specify the TRANSACTION_DEFAULT=DISTRIBUTED option with
the CONTEXT qualifier, you must declare a context structure
and pass the context structure to the statements named in
the CONTEXT qualifier or, if you specify CONTEXT=ALL, to most
executable statements involved in the distributed transaction.
See the Oracle Rdb SQL Reference Manual for information
about which executable statements do not require a context
structure.
o NOTRANSACTION_DEFAULT
Prevents SQL from starting a transaction unless you execute
a SET TRANSACTION statement. If you use this qualifier and
issue an executable statement without first issuing a SET
TRANSACTION statement, SQL returns an error.
The default is TRANSACTION_DEFAULT=IMPLICIT.
2.36 – USER_DEFAULT
Specifies the user name at compile time.
If you use the USER DEFAULT clause of the DECLARE ALIAS
statement, you use this qualifier to pass the compile-time user
name to the program.
2.37 – WARNING
Syntax options:
WARNING
NOWARNING
You can use combinations of the warning options to specify which
warning messages the SQL module processor writes. If you specify
only a single warning option, you do not need the parentheses.
The WARNING and NOWARNING qualifiers specify whether or not the
SQL module processor writes informational and warning messages.
2.38 – warning-option
Specifies whether the SQL module processor writes informational
and warning messages to your terminal, a list file, or both.
The WARN qualifier is the default. You can specify two warning
options with the WARN qualifier to customize message output.
You cannot specify warning options if you specify the NOWARN
qualifier.
3 – Example
Example 1: Compiling and linking a program with an SQL module
$ SQLMOD :== $SQL$MOD
$ SQLMOD LIST_EMP_PASMOD.SQLMOD
$ PASCAL LIST_EMP.PAS
$ ! This LINK command requires that the logical name
$ ! LNK$LIBRARY is defined as SYS$LIBRARY:SQL$USER.OLB
$ LINK LIST_EMP.OBJ, LIST_EMP_PASMOD.OBJ
$ RUN LIST_EMP.EXE
Matching Employees:
Alvin Toliver
Louis Tarbassian