Statement syntax for configuration statements

Statement syntax is the same in both the configuration data set hlq.PROFILE.TCPIP and the VARY TCPIP,,OBEYFILE command data set.

• Entries in a configuration data set are free format; blanks, comments, and end-of-record are ignored.
• A configuration statement consists of a statement name followed by a required blank, and usually one or more positional arguments. Separate each argument by one or more blanks or end-of-record.
• A semicolon begins a comment. Comments act as blanks, separating words without affecting their meaning.
• An argument followed by a comment must have a blank before the semicolon.
• Statements can be split across multiple lines.
• Sequence numbers are not allowed.
• Lowercase letters are translated to uppercase before the statements are executed, except for those parameters that support mixed case entries. For example, the SNMP community name is case sensitive.
• An END statement terminates a number of statements, such as AUTOLOG. If the END statement is omitted, all subsequent tokens in the data set are interpreted as parameters for that configuration statement.
• If a syntax error is encountered in a list of parameters, such as a HOME list, the rest of the entries in the list are ignored.

  Tip: Because some statements skip the entry in error and continue to process the remaining entries, this does not apply to all statements.

• Profile statements do have some order restrictions. The basic order is any statement that references a name defined in another statement must follow that statement. For example, LINK statements must follow the DEVICE statement that defines the device referenced by the link. Statements referencing links (for example, GATEWAY, HOME, and TRANSLATE) must follow the referenced LINK statement.
• Static system symbols can be used in profile statements.
• For those profile statements where you can modify parameters by respecifying the statement, the only parameter values that are changed when the statement is respecified are those parameters explicitly coded on the respecified statement. The parameter values that are not explicitly coded on the statement are not changed to the default value of the parameter; they retain their last specified value. For example, if you specify: IPCONFIG NODATAGRAMFWD in an initial profile data set, and then specify: IPCONFIG IGNOREREDIRECT in a data set referenced by a VARY TCPIP,,OBEYFILE command, the NODATAGRAMFWD parameter remains in effect and is not changed to the default parameter value of DATAGRAMFWD NOFWDMULTIPATH.
• Rules: User-defined names on configuration statements must adhere to the following rules:
  • Each character must be a non-blank printable character.
  • The following characters are not allowed:
    • Comma (,)
    • Semicolon (;)
    • Equal (=)
    • Asterisk (*)
  • The following characters are considered printable characters:
    • ¢ < ( + | & ! $ ) ¬ \ - / % _ > ? ` : # @ ' " Ý \ { } ¬ ~ (also alphabetic and numeric characters)
  • The first character must be alphanumeric or either $ or @. If it is numeric, the name must not be a hexadecimal number.
• IPv4 IP addresses can be partially defined in a Profile statement where an IP address is expected. If a user enters 100, it is interpreted as 100.0.0.0, and 1.2 is interpreted as 1.2.0.0.
• All characters must be entered in code page IBM-1047.

Guideline: Use the VARY TCPIP,,SYNTAXCHECK command to verify that the configuration statements in the configuration data set are free of syntax errors before starting the TCP/IP stack or activating a new profile using the Vary TCPIP,,OBEYFILE command to activate the profile. To use the syntax checker before starting the stack, you must issue the VARY TCPIP,,SYNTAXCHECK command on a system that has already started TCP/IP. See VARY TCPIP,,SYNTAXCHECK in z/OS Communications Server: IP System Administrator's Commands for more information.