How to Read the Option Syntax
Option specification is different for applications written for mainframe- or network‑attached systems.
Symbol |
Definition |
| (for mainframe-attached systems) |
OR For example, APOST|QUOTE means either APOST or QUOTE (but not both) can be specified. |
[] (for network‑attached systems) |
the enclosed variable is optional. |
Supported PP2 options are:
Syntax for Mainframe‑Attached Systems1 |
Syntax for Network‑Attached Systems |
APOST|QUOTE |
-a | -q |
APOSTSQL|QUOTESQL |
-as | -qs |
CHARSET (charset) |
-cs charset |
CURPREFIX (prefix) |
-c prefix |
DATABASE (dbname) |
-db dbname |
DATE (D|E|I|J|U) |
-d D|E|I|J|U |
DYNPREFIX (prefix) |
-dp prefix |
FLAG (I|W|E|S) |
-f I|W|E|S |
INPUT (file spec) |
-i filespec |
LINECOUNT (integer) |
-lc integer |
– |
-ld logdata |
– |
-lm logmech |
MARGINS (m,n [,c ] ) |
-m m,n[,c] |
NULLSCAN|NONULLSCAN |
-ns | -nns |
OPTIONS|NOOPTIONS |
-lo | -nlo |
PRINT [ (file spec) ] |NOPRINT |
-l [filespec] | -nl |
PUNCH [ (file spec) ] |NOPUNCH |
-o [filespec] | -no |
SOURCE|NOSOURCE |
-ls | -nls |
SQLCHECK (FULL|NOSYNTAX) |
-sc FULL|NOSYNTAX |
SQLFLAGGER (NONE|ENTRY|INTERMEDIATE) |
-sf NONE|ENTRY|INTERMEDIATE |
TDPID (tdpid|network group name) |
-t tdpid|network group name |
TERM [ (file spec) ] |NOTERM |
-e [filespec] | -ne |
TRANSACT (ANSI|COMMIT|BTET|2PC) |
-tr ANSI|BTET|COMMIT |
USERID (userid [,password [,accountid ] ] ) |
-u userid[,password[,accountid]] |
VERSION (COBOL|COBOLII|MF1|MF2|LPI) |
-v COBOL|COBOLII|MF1|MF2|LPI |
XREF|NOXREF |
-lx | -nlx |
Note: Whenever the DATABASE or USERID option values contain any Kanji or other multibyte character set characters, the CHARSET option must precede them in the preprocessor invocation line.
The file‑spec variable used with some options takes the following forms:
Client Type |
File Spec |
z/OS mainframe |
ddname |
Network‑attached |
name[.xtn] |
Note: If associated PP2 options are specified more than once (for example, both TERM and NOTERM), the rightmost specification prevails.
The next pages describe PP2 options in detail. The UNIX system‑style syntax appears below the standard syntax.
APOST|QUOTE
-a | -q
Purpose
APOSTSQL specifies that for embedded SQL statements, the string delimiter is the apostrophe (') and that the SQL escape (name) delimiter is the quotation mark (").
Usage Notes
Abbreviation for QUOTE |
Mutually Exclusive |
Q |
APOST and QUOTE |
This specification… |
Is the default for… |
Notes |
APOST |
COBOL and may be changed. Refer to the Notes column. |
QUOTE can be explicitly specified for COBOL; if so, also specify the COBOL compiler QUOTE option. |
APOST |
PL/I and may not be changed. |
|
QUOTE |
C and may not be changed. |
|
Host language statements generated by PP2 obey the same conventions. These options do not affect string and SQL escape (name) delimiters in embedded SQL statements. See “APOSTSQL|QUOTESQL -as | -qs” on page 66.
APOSTSQL|QUOTESQL
-as | -qs
Purpose
APOSTSQL specifies that for embedded SQL statements, the string delimiter is the apostrophe (') and that the SQL escape (name) delimiter is the quotation mark (").
QUOTESQL specifies that in embedded SQL statements, the string delimiter is the quotation mark (") and that the SQL escape (name) delimiter is the apostrophe (').
Usage Notes
APOSTSQL and QUOTESQL are mutually exclusive.
Do not explicitly specify QUOTESQL in any language except COBOL.
These options do not affect string delimiters in host language statements.
Specification |
Language |
QUOTESQL |
This is the default for COBOL, if QUOTE is specified. |
APOSTSQL |
This is the default for COBOL, if APOST is specified or defaulted. |
APOSTSQL |
This is the default for PL/I and cannot be changed. |
APOSTSQL |
This is the default for C and cannot be changed. |
CHARSET(charset)
-cs charset
Purpose
Controls the mapping of data, object names and identifier values.
Usage Notes
CHARSET specifies the predefined character set name or character set code to be used at the following times:
Time |
Action Taken |
Precompile |
The CHARSET option tells the precompiler the character set in which the input/output source files, the output listing, and output messages are written. |
Runtime |
The precompiler establishes the character set for communicating with the Teradata Database as the value of the CHARSET option unless overridden by the character set designated by the SET CHARSET request. For information on SET CHARSET, see SQL Data Definition Language (B035‑1144). Subsequent connections to the Teradata Database use the most recently established character set. |
Specify the CHARSET option before the DATABASE or USERID operations if the DATABASE or USERID option values contain any Kanji or other multibyte character set characters.
CHARSET controls the mapping of data, object names and identifier values.
On IBM mainframe client platforms, if the CHARSET option is not specified, PP2 establishes the default character set by order of precedence:
1 Character set specified in the HSHSPB parameter module.
2 Default character set defined on the server specified by the TDPID option when SQLCHECK(FULL) is specified.
3 EBCDIC
On network platforms, if the CHARSET option is not specified, PP2 establishes the default character set by order of precedence:
1 The character set specified in the clispb.dat file
2 ASCII
UTF‑8 and UTF‑16 Support
UTF‑8 (Universal Transformation Format) and UTF‑16 character sets are supported.
See “Table 9: Teradata‑Defined Character Sets for Mainframe Environments” on page 69 and “Table 12: Site‑Defined Character Sets for Network‑Attached Environments” on page 72 for details.
Use the SET CHARSET control statement with these character sets. See SQL Stored Procedures and Embedded SQL (B035‑1148)for details.
When using SET CHARSET for processing UTF‑8 and UTF‑16 data, precompile PP2 applications with one of these PP2 options:
Programming Considerations When Programming with UTF‑8 and UTF‑16 Character Sets
Object Names in Embedded SQL
When setting CHARSET to UTF‑16 on network‑attached systems or when setting CHARSET to UTF‑8 and UTF‑16 on mainframe systems, avoid problems with object names in embedded SQL by coding in the following ways:
These characters always translate to the same internal representation, therefore they appear exactly the same in any session, regardless of the client system or the character set.
Host Variables or Constants and Literals in Embedded SQL
When setting CHARSET to UTF‑16 on network‑attached systems or when setting CHARSET to UTF‑8 and UTF‑16 on mainframe systems:
When deciding the size of a character string, remember that storage for UTF‑8 data is one to four bytes per character. Storage for UTF‑16 data is two bytes per character.
Supported Character Sets
There is support for Chinese and Korean character sets. UTF‑16 support is available on Microsoft Windows, UNIX, and mainframe system environments.
When Teradata‑defined character sets are not appropriate for the site, create site‑defined character sets. See “Site‑Defined Character Sets for Mainframe Environments” on page 70 and “Site‑Defined Character Sets for Network‑Attached Environments” on page 72 for details.
See SQL Fundamentals (B035‑1141) to learn about international character sets, character set restrictions, export rules, and defining your own character sets.
Teradata‑Defined Character Sets for Mainframe Environments
Character Set Name |
Character Set Code Number |
Description |
EBCDIC |
192 |
|
HANGULEBCDIC933_1II |
108 |
|
KATAKANAEBCDIC |
111 |
Note: Not supported for the C preprocessor. |
KANJIEBCDIC5026_0I |
112 |
Note: Not supported with the C preprocessor. |
KANJIEBCDIC5035_0I |
113 |
|
SCHEBCDIC935_21J |
109 |
|
TCHEBCDIC937_3IB |
110 |
|
UTF8 |
191 |
|
UTF16 |
190 |
|
Site‑Defined Character Sets for Mainframe Environments
Character set Name |
Character Set Code Number |
Language |
SDKATAKANAEBCDIC_4IF |
77 |
Japanese |
SDKANJIEBCDIC5026_4IG |
78 |
Japanese |
SDKANJIEBCDIC5035_4IH |
79 |
Japanese |
SDSCHEBCDIC935_6IJ |
75 |
Simplified Chinese |
SDTCHEBDIC937_7IB |
76 |
Traditional Chinese |
SDHANGULEBCDIC933_5II |
74 |
Korean |
Teradata‑Defined Character Sets for Network‑Attached Environments
Character Set Name |
Character Set Code Number |
Description |
ASCII |
255 |
|
JISCII8 |
115 (Intel based platforms) 243 (non‑Intel based platforms) |
|
HANGULKSC5601_2R4 |
120 |
|
KANJISJIS_0S |
119 (Intel‑based platforms) 247 (non‑Intel‑based platforms) |
The SHIFT+JIS character set used by PC clients running DOS/V. It includes: |
KANJIEUC_0U |
118 (Intel‑based platforms) 246 (non‑Intel‑based platforms) |
The Extended UNIX Code multibyte character set combined with the ASCII character set for single byte characters. It includes: |
SCHGB2312_1T0 |
108 |
|
TCHBIG5_1R0 |
122 |
|
UTF8 |
63 |
|
191 |
|
|
UTF16 |
62 |
|
190 |
|
Site‑Defined Character Sets for Network‑Attached Environments
Character set Name |
Character Set Code Number |
Language |
SDKANJIEUC_1U3 |
91 |
Japanese |
SDKANJISJIS_1S3 |
92 |
Japanese |
SDTCHGB2312_2T0 |
94 |
Simplified Chinese |
SDTCHBIG5_3R0 |
95 |
Traditional Chinese |
SDHANGULKSC5601_4R4 |
93 |
Korean |
CURPREFIX(prefix)
-c prefix
Purpose
Specifies the prefix to be used in conjunction with the cursor ID. The prefix and cursor ID identify the cursor that is used in these cursor manipulation statements:
Usage Notes
The abbreviation for CURPREFIX is CP.
CURPREFIX is required for a C program precompilation that contains a cursor type request. CURPREFIX is optional for COBOL and PL/I.
In the absence of this option, PP2 does the following:
Language |
Action Taken by PP2 |
C |
Issues an error as each cursor request is processed. |
COBOL |
Uses as a default value the name found in the PROGRAM-ID COBOL statement. |
PL/I |
Uses as a default value the name found on the first PROC statement. |
For DB2 compatibility in cursor processing, the CURPREFIX option must specify different prefixes for each compile unit of the executable module.
To maintain compatibility with earlier releases of PP2, the CURPREFIX value must be the same for all compile units of an executable module.
The prefix must be no longer than eight characters and must not include any of these characters:
DATABASE(dbname)
-db dbname
Purpose
Specifies a default database for use during preprocessing.
Usage Notes
Unqualified table, view, or macro references are qualified by this database name. In the absence of this option, references are qualified by the default database for the userid that is specified by the USERID option.
The DATABASE option does not affect the qualification of such unqualified references at application execution time. These are determined by one of the following:
If the DATABASE option value contains any Kanji or other multibyte character set characters, specify the CHARSET option before the DATABASE option.
Note: Use the DATABASE PP2 option in a consistent manner. The option does not have to name the same database that will be used at application execution time. However, all unqualified object references in the application program must, at application execution time, resolve to objects that are compatible with the ones to which they resolve at preprocess time.
DATE(D|E|I|J|U)
-d D|E|I|J|U
Purpose
Specifies the format used at PP2 runtime when a date field is returned to a character field in the application from the Teradata Database.
Usage Notes
Format Code |
Description |
D |
Teradata Database format (mm/dd/yy) |
E |
EUR format (dd.mm.yyyy) |
I |
ISO format (yyyy-mm-dd) |
J |
JIS format (yyyy-mm-dd) |
U |
USA format (mm/dd/yyyy) |
DATE(D) is the default. However, because this code returns only the final two dates in the year, always select one of the other codes to ensure that all four digits of the year are returned.
Specifying Date Format
In obtaining DATE information, PP2 returns the data without changing its form. PP2 does not convert DATE data to the form specified for a column. To convert DATE data to a special form, use a specific SELECT statement.
Using the SELECT Statement to Specify Date Format
To obtain date information in the form yyyy/mm/dd, construct the SELECT statement as follows:
SELECT fieldn (FORMAT ’yyyy/mm/dd’) (CHAR(10)) . . . ;
fieldn
is returned as character data through the (CHAR(10))
clause, which causes the DATE option to be ignored.
DYNPREFIX (prefix)
-dp prefix
Purpose
Specifies a prefix that identifies the dynamic statement used by these manipulation statements:
The prefix is used in conjunction with the dynamic statement ID.
Usage Notes
The abbreviation for DYNPREFIX is DP.
The prefix must be no longer than 8 characters and must not include any of these characters:
When the same dynamic statements are prepared in different modules, DYNPREFIX:
FLAG(I|W|E|S)
-f I|W|E|S
Purpose
FLAG specifies the minimum severity diagnostic to be printed. Diagnostics of lower severities are suppressed.
Usage Notes
FLAG(I) is the default.
Diagnostic levels, from lowest to highest severity, are:
1 I—Informational
2 W—Warning (including SQL Flagger Warning)
3 E—Error
4 S—Severe
5 Fatal
Fatal diagnostics are always reported, regardless of the FLAG setting.
FLAG is relevant only if PRINT or TERM is also specified.
INPUT(file spec)
-i filespec
Purpose
Specifies the source file containing embedded SQL statements that PP2 uses as input.
Usage Notes
When INPUT is not specified, the input file defaults to the type of file shown in the table.
Environment |
Type of File |
z/OS |
The file has a ddname name of SYSIN. |
UNIX OS |
Stdin |
Windows |
Stdin |
If a file name is provided with no extension in network‑attached environments, these default extensions are appended:
Language |
Default Extension |
COBOL |
.pb |
C |
.pc |
PL/I |
.pi |
-ld logdata
Purpose
The -ld logdata option is a parameter list that the specified logon mechanism uses to complete the logon process.
Usage Notes
This option is only available for network‑attached systems.
If the logdata parameter list has embedded spaces, delimit the list with quotes (“ ”). For example:
-lm LDAP –ld "authcid=guestldap password=password"
LINECOUNT(integer)
-lc integer
Purpose
Specifies the number of lines to be printed on each page of the PP2 output listing, including heading lines.
Usage Notes
Abbreviation |
Default |
Valid Range |
LC |
LINECOUNT(60) |
10 - 32767, inclusive |
LINECOUNT is ignored if NOPRINT is also specified.
-lm logmech
Purpose
The-lm logmech option specifies the logon mechanism to be used.
Usage Notes
This option is only available for network‑attached systems.
In the next example, LDAP is the specified logon mechanism:
-lm LDAP –ld authcid=guestldap password=password
MARGINS(m,n[,c])
-m m,n[,c]
Purpose
Specifies the margins for the input source code.
Usage Notes
The abbreviation for MARGINS is MAR.
The following table lists codes, and the columns that they specify.
Code |
Column |
m |
Statement‑begin |
n |
Statement‑end |
c |
Carriage control (PL/I only) |
Specified margins must agree with the columns expected by the particular language compiler.
Use MARGINS(1,n) for COBOL in the network‑attached environment to specify to PP2 that the input file is in terminal format.
Refer to the next table for the defaults when using C, COBOL, or PL/I.
Language |
Default |
Notes |
C |
MARGINS(1,72) |
|
COBOL |
MARGINS(8,72) |
Cannot be changed in the IBM mainframe environment. |
PL/I |
MARGINS(2,72,1) |
|
NULLSCAN|NONULLSCAN
-ns | -nns
Purpose
Specifies that PP2 scan for the null character (x‘00') during precompilation.
Usage Notes
Default |
Mutually Exclusive |
NONULLSCAN |
NULLSCAN and NONULLSCAN |
Specify NULLSCAN if using null characters in a COBOL or PL/I program.
NONULLSCAN causes the precompiler to bypass null character scanning.
Notice:
Specify NULLSCAN if the application program contains null characters. If the program has null characters (x'00'), but the NONULLSCAN option is specified or used as the default, PP2 will fail with errors.
Depending on whether the null storage location is interpreted as an op code (S0C1) or a memory address (S0C4), an abend error might be generated during the preprocess step. There may or may not be error messages indicating the cause of the abend.
OPTIONS|NOOPTIONS
-lo | -nlo
Purpose
OPTIONS specifies that PP2 list all options selected by the application.
NOOPTIONS specifies that PP2 does not list the options used by the application.
Usage Notes
Default |
Abbreviation for OPTIONS |
Abbreviation for NOOPTIONS |
Mutually Exclusive |
OPTIONS |
OPTN |
NOOPTN |
OPTIONS and NOOPTIONS |
If NOPRINT is specified, NOOPTIONS is forced.
PRINT[(file spec)]|NOPRINT
-l [filespec] | -nl
Purpose
PRINT specifies that PP2 output the listing to the associated file spec.
NOPRINT specifies that PP2 suppress this listing.
Usage Notes
Default |
Mutually Exclusive |
|
PRINT and NOPRINT |
If PRINT is specified but no file is specified, the print file defaults to different types of files, depending on the environment. The following table lists the file types.
Environment |
Type of File |
z/OS |
File with a ddname of SYSPRINT |
Network‑attached |
Source input file name PP2 generates a file extension of .lis. |
If a file name is specified with no extension when running PP2 in a network‑attached environment, the default file extension is .lis.
NOPRINT implies NOOPTIONS, NOSOURCE and NOXREF.
PUNCH[(file spec)]|NOPUNCH
-o [filespec] | -no
Purpose
PUNCH specifies the file that contains the source code generated by PP2.
NOPUNCH specifies that PP2 suppress source code generation.
Usage Notes
Default |
Abbreviation for PUNCH |
Abbreviation for NOPUNCH |
Mutually Exclusive |
PUNCH |
PU |
NOPU |
PUNCH and NOPUNCH |
If PUNCH is specified but no file is specified, the print file defaults to different types of files, depending on the environment. The following table lists the file types.
Environment |
Type of File |
z/OS |
File with a ddname of SYSPUNCH |
Network‑attached |
An output file with the source input file name and a file extension appropriate to the source language. If a file name is specified without an extension, PP2 uses the defaults explained in the next table. |
If a file name is specified with no extension, the default extensions are:
Language |
Default Extension |
COBOL |
.cob |
C |
.c |
PL/I |
.pli |
SOURCE|NOSOURCE
-ls | -nls
Purpose
SOURCE specifies that source input be included in the PP2 listing.
NOSOURCE specifies that source input be suppressed from the PP2 listing.
Usage Notes
Default |
Abbreviation for SOURCE |
Abbreviation for NOSOURCE |
Mutually Exclusive |
SOURCE |
S |
NOS |
SOURCE and NOSOURCE |
If NOPRINT is specified, NOSOURCE is forced.
SQLCHECK(FULL|NOSYNTAX)
-sc FULL|NOSYNTAX
Purpose
Specifies the level of checking to be performed on embedded SQL statements.
Usage Notes
Option |
Description |
FULL |
Specifies that syntax, object references, and privileges checking are performed on embedded SQL statements. This is the default. Use it whenever ENTRY or INTERMEDIATE for SQLFLAGGER is specified. |
NOSYNTAX |
Specifies that no checking is to be performed on embedded SQL statements; and no syntax, object reference or access rights checking is performed. Specifying the NOSYNTAX option to the SQLCHECK parameter disables the logon to the Teradata Database during the precompile phase. It has no effect on runtime. If both NOSYNTAX and a SQLFLAGGER of ENTRY are specified, PP2 generates an error and uses the default SQLFLAGGER value of NONE. |
SQLFLAGGER (NONE|ENTRY|INTERMEDIATE)
-sf (NONE|ENTRY|INTERMEDIATE)
Purpose
Defines the type of SQL flagging performed on the SQL being preprocessed.
Usage Notes
The abbreviation for SQLFLAGGER is SQLFLAG.
Options for SQLFLAGGER (or -sf) are:
Option |
Level of SQL Flagging Provided |
NONE |
None. This is the default value. |
ENTRY |
Entry level ANSI compliance. Also specify SQLCHECK(FULL) when specifying SQLFLAG(ENTRY). |
INTERMEDIATE |
Intermediate level ANSI‑compliance. |
INTERMEDIATE |
intermediate level ANSI‑compliance. When this option is specified, the default value for TRANSACT becomes ANSI. Also specify SQLCHECK(FULL) when specifying SQLFLAG(INTERMEDIATE). |
When the SQL flagger is enabled, only static embedded SQL statements are flagged during precompilation and only dynamic embedded SQL statements are flagged during program execution (runtime).
TDPID(tdpid|network group name)
-t tdpid|network group name
Purpose
Specifies the Teradata Database identifier used for PP2 connection.
Usage Notes
The abbreviation for TDPID is TDP.
If used, the tdpid|network group name must obey the rules for specifying tdpid|network group name in a logon string.
Specification of this option does not affect, and is not related to, the connection established during application execution.
If SQLCHECK is specified with a value other than NOSYNTAX, a hardware platform for the Teradata Database must be available to PP2.
Refer to the next table for information on mainframe- and network‑attached connections.
Environment |
Action Taken |
Action Taken if the TDPID Option is Not Specified |
IBM mainframe |
The tdpid specifies the tdp to be used for connection. |
The default tdp specified in the HSHSPB control block is used. See Teradata Call-Level Interface Version 2 Reference for Mainframe-Attached Systems (B035‑2417) for details on the HSHSPB control block. |
network‑attached |
The network group name specifies the network group to be used for connection. |
The default network group as specified either in the user‑supplied clispb.dat file or the CLI2SPB control block is used. |
TERM[(file spec)]|NOTERM
-e [filespec] | -ne
Purpose
TERM specifies that PP2 diagnostics are directed to the associated file spec. NOTERM specifies that error output is suppressed.
Usage Notes
Default |
Mutually Exclusive |
NOTERM |
TERM and NOTERM |
For PP2 in the IBM mainframe environment, the error file defaults to the file associated with a ddname or filedef name of SYSTERM.
When running PP2 in a network‑attached environment:
TRANSACT(ANSI|BTET|COMMIT|2PC)
-tr ANSI|BTET|COMMIT
Purpose
TRANSACT specifies the transaction protocol that the application program (compile unit) uses.
Usage Notes
TRANSACT(COMMIT) is the default.
The following table explains the transaction modes.
Mode |
Description |
ANSI |
ANSI transaction semantics are enabled. Selecting this option causes C language strings to be padded with blanks (rather than with nulls) by default. For all languages, truncation of any nonblank and nonzero character produces a warning SQLCODE and SQLSTATE. When this option is specified, the following modes are disabled: |
COMMIT |
Execution of a Teradata SQL request when no transaction (unit of work) is active causes a transaction to be initiated. This is the default. The transaction that is initiated is not terminated until the application terminates or executes one of these statements: If the transaction is active and the application terminates without an explicit COMMIT or LOGOFF statement while executing in COMMIT mode, the Teradata Database rolls back all uncommitted work. This is a distinct difference between DB2 and the Teradata Database. When this option is specified, the following modes are disabled: |
BTET |
Execution of a Teradata SQL request when no transaction is active causes that request to execute as an implicit transaction, even if the request consists of a single Teradata SQL statement. When this option is specified, the following modes are disabled: Initiate and terminate transactions spanning more than one request using BEGIN TRANSACTION and END TRANSACTION. This is a distinct difference between DB2 and the Teradata Database. |
2PC |
The program uses the two phase commit protocol. In 2PC mode, an external resource manager (CICS, IMS, or one written by the user) controls transaction initiation and termination. When this option is specified, the following modes are disabled: Only available for mainframe‑attached clients. An ABORT, BT, CHECKPOINT, COMMIT, DATABASE, ET, ROLLBACK or DDL statement causes an error if 2PC mode is specified. The ABORT, CHECKPOINT, DATABASE, ROLLBACK and DDL statements are valid with BTET or COMMIT transaction protocols, but are disallowed with the 2PC protocol. This is a distinct difference between DB2 and the Teradata Database. |
TRANSACT(2PC) is valid only for mainframe‑attached applications.
PP2 issues a diagnostic if a BEGIN TRANSACTION or END TRANSACTION statement is found in a program precompiled with the TRANSACT(ANSI), TRANSACT(COMMIT) or TRANSACT(2PC) option; or if a COMMIT statement is found in a program precompiled with the TRANSACT(BTET) or TRANSACT(2PC) option.
The transaction protocol for the compile unit where the session is established remains in effect until the session is terminated, regardless of additional compile units with different modes that might be invoked during the session.
USERID(userid[,password[,accountid]])
-u userid[,password[,accountid]]
Purpose
Specifies the userid, password, and account id on the associated server.
See the description of the “TDPID(tdpid|network group name) -t tdpid|network group name” on page 90.
Usage Notes
The abbreviation for USERID is USER.
If supplied, the userid, password, and accountid must obey the usual rules for a logon string.
Specification of this option does not affect, nor is related to, the connection established during application execution.
If SQLCHECK is specified with a value other than NOSYNTAX, a hardware platform for the Teradata Database must be available to PP2.
If the USERID option value contains any Kanji or other multibyte character set characters, specify the CHARSET option before the USERID option.
If the USERID option is not specified or one of the required elements is absent (userid or password) when running PP2 in the IBM mainframe environment, PP2 attempts an implicit connection to the Teradata Database if possible. See Teradata Call-Level Interface Version 2 Reference for Mainframe-Attached Systems (B035‑2417) for details on implicit connection.
Always supply the userid and password when running PP2 in a network‑attached environment: network‑attached environments do not support implicit logon.
Single Sign On (Windows Platforms Only)
If SQL syntax checking is requested, an SSO sign‑on will be triggered by one of the following:
For more information, see “Creating A User for Single Sign-On” and “LOGON Statement” in SQL Data Definition Language (B035‑1144).
VERSION(COBOL|COBOLII|COBOL3)
-v MF1|MF2|LPI
Purpose
Specifies the input and target COBOL compiler code.
Usage Notes
The default value for VERSION is COBOL.
This option is valid only with the COBOL precompiler, PPBMAIN.
PPBMAIN accepts all of the following as valid VERSION COBOL compilers. It flags all other values as errors.
Compiler Name |
Description |
COBOL |
COBOL at the COBOL 74 level, as exemplified by the IBM dialects OS/VS COBOL and OS Full ANSI COBOL Version 3 and 4. The abbreviation for COBOL is COB. |
COBOLII |
IBM dialect VS COBOL II. VS COBOL II contains significant language extensions over OS/VS COBOL and generally supports COBOL at the COBOL 85 level. PP2 output listing will show COBOLII. The abbreviation for COBOLII is COBII. |
COBOL3 |
IBM COBOL for z/OS. PP2 output listing will show COBOL for z/OS. The abbreviation for COBOL3 is COB3. |
MF1 |
Micro Focus COBOL 85 compiler in byte storage mode (compiler option NOIBMCOMP). |
MF2 |
Micro Focus COBOL 85 compiler in word storage mode (compiler option IBMCOMP). |
LPI |
LPI COBOL 85 compiler. |
XREF|NOXREF
-lx | -nlx
Purpose
Specifies that PP2 include a cross reference of symbols used in embedded SQL statements in the PP2 listing.
Usage Notes
Default |
Abbreviation for XREF |
Abbreviation for NOXREF |
Mutually Exclusive |
XREF |
X |
NOX |
XREF and NOXREF |
NOXREF specifies that PP2 suppress a cross reference of symbols used in embedded SQL statements from the listing.