How to Read the Option Syntax - Preprocessor2 for Embedded SQL

Teradata Preprocessor2 for Embedded SQL Programmer Guide

Product
Preprocessor2 for Embedded SQL
Release Number
15.00
Language
English (United States)
Last Update
2018-09-27
dita:id
B035-2446
lifecycle
previous
Product Category
Teradata Tools and Utilities

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


1
An en dash (–) means unavailable or not applicable.

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:

  • CHARSET(EBCDIC) on mainframe systems
  • -cs ASCII on network‑attached systems
  • 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:

  • Use only digits (0-9) and simple, single‑byte Latin letters (A to Z, a to z).
  • 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.

  • Do not use the hexadecimal representation to represent a character name.
  • 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:

  • Use host variables in the embedded SQL to supply UTF‑8 and UTF‑16 input values to, or receive UTF‑8 and UTF‑16 output values from, the Teradata Database. Use host variables in the embedded SQL statements instead of UTF‑8 and UTF‑16 string constants.
  • Use only digits and simple, single byte Latin letters (A to Z, a to z) as constants in EXEC SQL statements. The constants must be in the same charset encoding as the SQL keywords.
  • 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

     

    Table 9: Teradata‑Defined Character Sets for Mainframe Environments  

    Character Set Name

    Character Set Code Number

    Description

    EBCDIC

    192

  • Uppercase and lowercase English characters
  • Special characters
  • HANGULEBCDIC933_1II

    108

  • Korean characters
  • Uppercase and lowercase English characters
  • Multibyte characters
  • Special characters
  • KATAKANAEBCDIC

    111

  • Uppercase English characters
  • katakana characters
  • Special characters
  • Note: Not supported for the C preprocessor.

    KANJIEBCDIC5026_0I

    112

  • Uppercase and lowercase English characters
  • katakana characters
  • Multibyte characters
  • Special characters
  • Note: Not supported with the C preprocessor.

    KANJIEBCDIC5035_0I

    113

  • Uppercase and lowercase English characters
  • katakana characters
  • Multibyte characters
  • Special characters
  • SCHEBCDIC935_21J

    109

  • Simplified Chinese characters
  • Uppercase and lowercase English characters
  • Multibyte characters
  • Special characters
  • TCHEBCDIC937_3IB

    110

  • Traditional Chinese characters
  • Uppercase and lowercase English characters
  • Multibyte characters
  • Special characters
  • UTF8

    191

  • Compressed UNICODE (1‑3 byte on Teradata)
  • UTF16

    190

  • 2 byte UTF‑16
  • Site‑Defined Character Sets for Mainframe Environments

     

    Table 10: 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

     

    Table 11: Teradata‑Defined Character Sets for Network‑Attached Environments  

    Character Set Name

    Character Set Code Number

    Description

    ASCII

    255

  • Uppercase and lowercase English characters
  • Special characters
  • JISCII8

    115 (Intel based platforms)

    243 (non‑Intel based platforms)

  • Uppercase and lowercase English characters
  • katakana characters
  • Multibyte characters
  • Special characters
  • HANGULKSC5601_2R4

    120

  • Uppercase and lowercase English characters
  • Multibyte characters
  • Special characters
  • 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:

  • Uppercase and lowercase English characters
  • katakana characters multibyte characters
  • Special characters
  • 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:

  • Uppercase and lowercase English characters
  • katakana characters
  • Multibyte characters
  • Special characters
  • SCHGB2312_1T0

    108

  • Simplified Chinese characters
  • Uppercase and lowercase English characters
  • Multibyte characters
  • Special characters
  • TCHBIG5_1R0

    122

  • Traditional Chinese characters
  • Uppercase and lowercase English characters
  • Multibyte characters
  • Special characters
  • UTF8

    63

  • Intel‑based platforms
  • 191

  • non‑Intel‑based platforms
  • UTF16

    62

  • Intel‑based platforms
  • 190

  • non‑Intel‑based platforms
  • Site‑Defined Character Sets for Network‑Attached Environments

     

    Table 12: 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:

  • CLOSE
  • DECLARE
  • FETCH
  • OPEN
  • POSITION
  • 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:

  • Apostrophe
  • Quote
  • Space
  • 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:

  • SQL DATABASE statements (if any)
  • The default database for the userid specified by a SQL LOGON or CONNECT statement
  • Userid under which the program implicitly connected to the server
  • 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)) .  .  .  ;
  • The date column fieldn in this example is of type DATE, but fieldn is returned as character data through the (CHAR(10)) clause, which causes the DATE option to be ignored.
  • The DATE option applies only to DATE data being returned to character variables.
  • The host variable that receives this field must be of character type, with a length of at least 10.
  • The format specified in the SELECT statement overrides the DATE option only for the statement and the field (or fields) which are specified. Use this method to obtain a format other than one available through the DATE option.
  • DYNPREFIX (prefix)
    -dp prefix

    Purpose  

    Specifies a prefix that identifies the dynamic statement used by these manipulation statements:

  • DECLARE
  • PREPARE
  • DESCRIBE
  • EXECUTE
  • OPEN
  • 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:

  • Apostrophe
  • Quote
  • Space
  • When the same dynamic statements are prepared in different modules, DYNPREFIX:

  • Is required for C, COBOL and PL/I programs.
  • Should specify unique prefixes for each compilation unit of the executable module.
  • 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

    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:

  • If TERM is specified, but a file is not specified, the error file defaults to the file associated with STDERR.
  • If a file name is specified with no extension, the default file extension is .err.
  • 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:

  • BTET
  • COMMIT
  • 2PC
  • 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:

  • ABORT
  • COMMIT
  • LOGOFF
  • ROLLBACK
  • 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:

  • ANSI
  • BTET
  • 2PC
  • 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:

  • ANSI
  • COMMIT
  • 2PC
  • 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:

  • ANSI
  • BTET
  • COMMIT
  • 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:

  • Omission of the USERID (-u ) PP2 option
  • Specification of the userid option with only the accounting data supplied
  • 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.