gtpa1m0i | ACF/SNA Network Generation |
All of the input definition statements are patterned after the assembler language macro syntax.
Any record beginning with an asterisk (*) in column 1 is considered by the OSTG program to be a comment record. The record will be printed as it is found on the input list report and the text will not be examined by the OSTG program.
The general format of input definition statements is:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7... symbol OPCODE PARAMETER=value1, commentary X <PARAMETER=value2>
The symbol parameter is used on some statements and ignored if specified on others. Symbols must start in column 1 of the input definition statement and can be a maximum of 8 alphanumeric characters. The first character must be A-Z. Alphabetic characters must be in uppercase. There must be at least 1 blank character after a symbol.
The OPCODE is the name of the input definitions statement and must be coded as shown in this publication. The OPCODE must be preceded and followed by 1 or more blank characters
The parameter must be coded as shown in this publication. Optional parameters are denoted by brackets (< >). All allowable values are also defined in this publication for each permissible parameter. The last parameter value must be followed by 1 or more blanks.
Allowable parameter values are separated by the vertical bar (|) in this publication. This notation is used to show that you must select one of the specified values.
Each statement can be continued to subsequent records by ending the parameter value with a comma, placing one or more blanks after the comma, and placing a nonblank character in the continuation column (column 72). Any text following the comma and blanks is treated as commentary. Commentary is printed in the input list report but is not examined. The continued record must begin with the parameter in column 16. Columns 1-15 inclusive must contain blanks. If an input definition statement has no parameters, but commentary is desired, code a comma in place of the parameter and one or more blanks before any commentary text.
Comment records (* in column 1) are not allowed in a continued statement. They can only precede or follow completed input definition statements.
SNA network IDs and resource names can contain from 1-8 characters. They must begin with an uppercase letter (A-Z), @, #, or $. The remaining characters can be uppercase letters (A-Z), numbers (0-9), @, #, or $.
Be aware that some of the older terminals may not support special characters. Therefore, if you include the @, #, or $ in an SNA network ID or resource name, you will not be able to type that network ID or resource name on those terminals. Also, these characters may not display in output messages on some of the older terminals. However, you can use the UCCWTOP user exit to change these special characters to printable characters. For more information about the UCCWTOP user exit, see TPF System Installation Support Reference. For more information about output message restrictions, see TPF Programming Standards.
It is necessary to restrict the use of certain names in the OSTG input definition statements. These reserved names are:
Each definition statement explains which, if any, of the reserved names are allowed.
ALSNODES is a reserved name that is used to activate or deactivate all of the PU 2.1 links for a given processor.
CTCNODES is a reserved name that indicates priming is performed for all inactive CTC links. The priming process starts XID processing over CTC links with an active partner.
The ANT deck consists of the following input definition statements:
This deck is produced as a PDS member by the SIP process from information provided by the MSGRTA macros.
The ANT deck consists of a series of input definition statements used to describe the TPF applications that are available to the TPF system being generated. Input this deck to the OSTG program exactly as it is produced by SIP.
Changes to this deck after it is produced by SIP can cause results that cannot be predicted in the TPF system. The OSTG program assumes that the sequence in which the applications are defined in this deck is the same as the sequence in which they were defined in SIP, and in the application name table (ANT). Therefore, additions, deletions, and other changes can cause the application index field to be calculated incorrectly.
The name of the ANT deck is automatically generated by SIP. SIP uses the first processor ID coded in the SYSID parameter of the CONFIG macro and appends it to the characters ANT. For example, if the first processor ID coded is A, the name of the ANT deck is ANTA. If the first processor ID coded is B, the ANT deck is named ANTB.
See Sample ANT Deck for an example of the ANT deck.
Resource resolution table (RRT) entries are created only for local processor IDs in the loosely coupled complex. RRT entries are not generated for remote applications. Code RSC statements for these remote applications in order to generate RRT entries.
The following RRTs are created for each processor in the TPF system:
These RRTs are required for every TPF processor that is being generated, and for the remaining processors in the loosely coupled complex. These RRTs are always generated automatically when the processor is first found.
For remote TPF processors, the SSCP, SNA FMMR, and SMP application must be explicitly coded in RSC statements to generate RRT entries.
The ANTDEF input definition statement is always the first statement in the ANT deck and begins the definition of the applications in the TPF system. Only one ANTDEF input definition statement is allowed in the ANT deck.
See Sample ANT Deck for an example of the ANTDEF statement.
The format of the ANTDEF statement is:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7... symbol ANTDEF CPUID=c, X <SDPSID=(n,...,n)>
The ANTNME statements follow the ANTDEF statement. There must be one ANTNME statement for each application defined using the MSGRTA macro in SIP, and an ANTNME statement for any special applications required by the TPF system, such as SMP. MSGRTA macros must be specified for all applications residing in the TPF processor being generated. There can be a maximum of 256 ANTNME statements.
See Sample ANT Deck for an example of the ANTNME statement.
The format of the ANTNME statement is:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7... symbol ANTNME NAME=application_name, X SNA=YES|NO|LU62|APPC|LOCP, X CPUID=c, X <RECVRY=YES|NO,> X <APPL=P|(S,nnn),> X <SAWARE=YES|NO>
If the application resides on only one processor, c is a character from A-Z or 0-9. If the application resides on all processors in the loosely coupled complex, c is an asterisk (*).
The ANTEND input definition statement is used to delimit the ANT deck. It is the last statement in the ANT deck and it has no parameters.
See Sample ANT Deck for an example of the ANTEND statement.
The format of the ANTEND statement is:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7... symbol ANTEND
The RSC deck must follow the ANT deck. It contains a series of input definition statements that describe the cross-domain resource manager (CDRM) resources and remote logical units (LUs) that can communicate with the TPF system being generated.
You can also use the ZNDYN ADD command to define CDRM resources and dynamic LU support to define remote LU resources. See TPF Operations for more information about the ZNDYN ADD command. See TPF ACF/SNA Data Communications Reference for more information about dynamic LU support and defining resources to the TPF system.
The RSC deck contains the following input definition statements:
The CDRM statements can be specified only if the TPF system supports a network control program (NCP) that is running in a PU 5 environment.
The network definitions follow the optional CDRM statements. Each network ID is defined by an RSCDEF statement, which is followed by all of the RSC statements for that network ID and ended with an RSCEND statement. One or more RSCSET statements can exist anywhere between the RSCDEF and RSCEND statements. You can define any number of network IDs by coding one or more sets of RSCDEF, RSC, and RSCEND statements.
See Sample RSC Deck for an example of the RSC deck.
The CDRM definition statement describes a cross-domain resource manager (CDRM) that is allowed to communicate with the TPF CDRM as a PU 5 node. Therefore, this statement is valid only if PU 5 support was included in the TPF system. (That is, the SUBAREA parameter was specified in the EXEC PARM field of the JCL deck.) A CDRM is the portion of an SSCP that controls the cross-domain resource connections.
A CDRM definition statement is also required for each processor in a TPF loosely coupled complex when PU 5 support is included in the TPF system. The CDRM statements for the loosely coupled processors are used to define the unique SNA subarea values for each processor.
You can also use the ZNDYN ADD command to define CDRM resources. See TPF Operations for more information about the ZNDYN ADD command. See TPF ACF/SNA Data Communications Reference for more information about defining resources to the TPF system.
See Sample RSC Deck for an example of the CDRM statement.
The format of the CDRM statement is:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7... cdrmname CDRM SUBAREA=n, X <ELEMENT=n,> X <CPUID=c,> X <REALNAME=name2>
See SNA Network IDs and Resource Names for information about the characters that you can specify in a CDRM name.
If the CDRM is accessed through an SNI NCP to a VTAM system that also has APPN connections with the TPF system, you must use an alias CDRM name because the VTAM SSCP name and CP name are identical. In this case, cdrmname must be an alias name for the CDRM, and the real name of the CDRM must be specified by the REALNAME parameter. See TPF ACF/SNA Data Communications Reference for more information about TPF/APPN and SNI considerations.
The RSCDEF statement identifies the beginning of the remote LU descriptions. It is used to delimit a network ID. A network ID can be thought of in the same way that a domain was thought of in previous TPF releases. The network ID is used to qualify network names in order to resolve any duplication of names among different networks.
See Sample RSC Deck for an example of the RSCDEF statement.
The format of the RSCDEF statement is:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7... symbol RSCDEF NETID=netid|ANY
See SNA Network IDs and Resource Names for information about the characters that you can specify in a network ID.
The RSC definition statement is used to describe each remote LU resource. You can also use dynamic LU support to define remote LU resources. See TPF ACF/SNA Data Communications Reference for more information about dynamic LU support and defining resources to the TPF system.
See Sample RSC Deck for an example of the RSC statement. Also see Valid Combinations for the CCTYPE and LUTYPE Parameters for more information about the valid combinations for the following parameters.
The format of the RSC statement is:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7... symbol RSC <LUTYPE=ANY|3277|3278|3284| X |3286|3287|3288|3289|360X|3614|APPC|REMCP| X APPLU|APSLU|AX001|AX002|BATCH|FMMR| X L6PLU|L6SLU|MCHLU|NEF|VCLU|XALCI|FTPI,> X <CCTYPE = 3601|3602|3274|3276|3271,> X <LUMOD=2|3|4|,> X <SCSBUF=2K|4K,> X <RECVRY=YES|NO,> X <IATA=xxxx,> X <THREAD=SINGLE|MULTI,> X <UMODE=xx,> X <MODE=NETVIEW,> X <PSV=name,> X <LEID=xx|yyyy|zzzzzz,> X <AWARE=YES|NO,> X <PRSHR=YES|NO,> X CHAIN=YES|NO>
See SNA Network IDs and Resource Names for information about the characters that you can specify in an LU name.
The following are valid reserved names:
See Reserved Names for more information about the reserved names.
LUTYPE=ANY creates an RRT entry that simply predefines the LU node name. If LUTYPE=ANY is specified, omit all of the other parameters with the exception of the IATA and UMODE parameters. The information for the other parameters is determined and the RVT is updated at session initiation time. See TPF ACF/SNA Data Communications Reference for more information.
The valid options are:
See the TPF Migration Guide: Program Update Tapes for a list of all supported controllers.
Notes:
Notes:
The logical end-point identifier (LEID) is a hexadecimal value, which can be specified in the following formats:
Notes:
The RSCSET input definition statement allows you to temporarily override the system defaults of the corresponding parameters in the RSC statement. This statement can exist in the RSC deck anywhere between the RSCDEF statement and the RSCEND statement.
The values specified for the RSCSET parameters replace the system default values for all of the following RSC statements until the values are changed by another RSCSET statement or the RSCEND statement is reached.
If a value you specify for one of the RSCSET parameters is not valid, the value is flagged with an error message and the default for that parameter remains unchanged.
No RRT entry is created by this statement.
See Sample RSC Deck for an example of the RSCSET statement.
The format of the RSCSET statement is:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7... symbol RSCSET <LUTYPE=ANY|3277|3278|3284| X |3286|3287|3288|3289|360X|3614|APPC|REMCP| X APPLU|APSLU|AX001|AX002|BATCH|FMMR| X L6PLU|L6SLU|MCHLU|NEF|VCLU|XALCI|FTPI,> X <CCTYPE = 3601|3602|3274|3276|3271,> X <LUMOD=2|3|4|,> X <SCSBUF=2K|4K,> X <RECVRY=YES|NO,> X <THREAD=SINGLE|MULTI,> X <UMODE=xx,> X <PSV=name,> X <AWARE=YES|NO,> X <PRSHR=YES|NO,> X CHAIN=YES|NO>
See RSC Statement for more a description of the parameters.
Code the RSCEND input definition statement to mark the end of the RSC deck. This statement is used by the OSTG logic as a delimiter to complete the remote LU definitions for a set of resources residing in a network ID.
This statement also resets all of the default values that may have been overridden with RSCSET statements back to the system default values.
See Sample RSC Deck for an example of the RSCEND statement.
The format of the RSCEND statement is:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7... symbol RSCEND
The ALS deck must follow the RSC deck. It defines the NCP, CTC, and ALS resources that are channel-attached to the TPF system.
You can also use the ZNDYN ADD command to define NCP and CTC resources. If the TPF system is running in Advanced Peer-to-Peer Networking (TPF/APPN) mode, you can use the ZNDYN ADD command and dynamic LU support to define ALS resources as well. See TPF Operations for more information about the ZNDYN ADD command. See TPF ACF/SNA Data Communications Reference for more information about TPF/APPN support, dynamic LU support, and defining resources to the TPF system.
The following input definition statements are included in the ALS deck:
The ALS, NCP, and CTC input definition statements can exist in the ALS deck in any order.
See Sample ALS Deck for an example of the ALS deck.
The ALS statement defines both the 37x5 and non-37x5 devices that can connect to the TPF system as a PU 2.1 link station.
If the TPF system is running in Advanced Peer-to-Peer Networking (TPF/APPN) mode, you can also use the ZNDYN ADD command and dynamic LU support to define ALS resources. See TPF Operations for more information about the ZNDYN ADD command. See TPF ACF/SNA Data Communications Reference for more information about TPF/APPN support, dynamic LU support, and defining resources to the TPF system.
See Sample ALS Deck for an example of the ALS statement.
The format of the ALS statement is:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7... alsname ALS <CLU=cluname,> X <QN|ALSQN=xx>
For 37x5 connections, this name is used by the TPF system and VTAM to refer to the 37x5 channel adapter. The name must match the name coded on the PU statement in the NCP generation deck.
For non-37x5 devices such as a 3174 APPN controller or RISC System/6000 system, code the ALS name using the following format:
TPFxnnnn
Where:
If the TPF system is running in APPN mode, do not code this parameter. If the TPF system is running in LEN mode, the CLU parameter on the ALS statement is required when defining the primary ALS. The CLU parameter is not required when the ALS statement is used for the backup section of an NCP used in a 37x5 multiple central control unit (CCU).
When specifying a CLU name, follow the rules for defining a symbol, which are located in Coding the OSTG Input Definition Statements.
None of the reserved names can be specified. See Reserved Names for more information about the reserved names.
This name is used by the TPF system and VTAM when establishing the CLU-CLU session with the Logon Manager (LM).
It is recommended that the name you use matches the corresponding LU name in the NCP generation deck for this ALS. The TPF system uses this method to give you a way to correlate the CLU name with the ALS and to ensure that the correct number of CLUs are defined. When defining the ALS for a backup CCU of a multi-engine 37x5, the CLU name is not required because the LU name from the primary ALS is used. See Figure 23 and Figure 24 for an example of the NCP channel adapter definition for the PU 2.1 environment for the 3745-410 fallback mode support.
This parameter represents the unique qualifier number (QN) for each ALS defined. This value is specified as 2 hexadecimal digits. This qualifier is appended to the application name and processor ID defining TPF applications as independent LUs in the NCP. These TPF alias names are used by the VTAM Logon Manager for load balancing sessions across multiple links to the TPF system. See ALS and CTC Qualifiers for more information on this parameter.
The NCP statement defines each 37x5 that can be channel attached to a local TPF processor as a PU 4 node.
You can also use the ZNDYN ADD command to define NCP resources. See TPF Operations for more information about the ZNDYN ADD command. See TPF ACF/SNA Data Communications Reference for more information about defining resources to the TPF system.
The following information is specified on the NCP input definition statement:
The NCP statement is valid only if PU 5 support has been included in the TPF system.
See Sample ALS Deck for an example of the NCP statement.
The format of the NCP statement is:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7... ncpname NCP SUBAREA=n,WINSIZE=n,<VRTO=n,><VRILTO=n>
See SNA Network IDs and Resource Names for information about the characters that you can specify in an NCP name.
None of the reserved names can be specified. See Reserved Names for more information about the reserved names.
You can specify a value in the range 1-255. The recommended value is 42. This value will be the minimum and maximum window size used on the virtual route.
Setting the number too low can result in unnecessary overhead (a virtual route pacing response [VRPRS] is required once every window) and delay in response time (the TPF system will queue messages if a VRPRS is outstanding). Setting the number too high can cause NCP buffer depletion because an NCP reserves three times the minimum number of buffers for the virtual route.
When the virtual route (VR) is blocked for the specified time, the link attempts to issue 1 more PIU with the VR pacing request indicator on. The TPF system may have lost the VR pacing response, or the NCP may have lost the VR pacing request. If the link times out again, the link is discontacted.
The default for this parameter is 0, which indicates that no timeout processing occurs on this link. The maximum value is 65 535 (about 54 minutes).
There are two considerations for setting this value:
When the virtual route (VR) is blocked for the specified time and the input list is shut down, the link attempts to issue the equivalent of 1 VR pacing window of PIUs (WINSIZE value) each time the timer goes to 0. Because the TPF system is in input list shutdown, the pacing response is not yet received because both of the read buffers are on the input list that is shut down.
An attempt is made to send out the PIUs in these blocks to the NCP in order to relieve the input list shutdown condition. To prevent the NCP from being flooded, set this value equal to the value it normally takes for the NCP to process 1 window of PIUs.
The default value for this parameter is 0, which indicates that no timeout processing occurs on this link. The maximum value is 255 (about 12 seconds).
The CTC statement defines each CTC link station that can be attached to the local TPF processor as a PU 5 node.
You can also use the ZNDYN ADD command to define CTC resources. See TPF Operations for more information about the ZNDYN ADD command. See TPF ACF/SNA Data Communications Reference for more information about defining resources to the TPF system.
You can specify the following information on the CTC definition statement:
See Sample ALS Deck for an example of the CTC statement.
The format of the CTC statement is:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7... ctcname CTC SUBAREA=n,WINSIZE=n, X <CLU=cluname|CLU=(cluname1, cluname2,...,cluname8),> X <QN=xx,> X <TG2SDA>,<VRTO=n,><VRILTO=n>,<REMOTE=yes|no>
See SNA Network IDs and Resource Names for information about the characters that you can specify in a CTC name.
This parameter is required only for CTC connections to VTAM when APPC sessions are active and the TPF system is running in LEN mode. Do not code this parameter when the TPF system is running in APPN mode.
If this is a loosely coupled complex, multiple CLU names must be specified. There must be a CLU name for each TPF processor in the complex in order for each TPF processor to have its own CLU-Logon Manager session. The CLU names must be defined to VTAM as a CDRSC.
To create an alias name for a TPF application, the qualifier number is appended to the application name and processor ID. The TPF CLU uses this alias name to inform the Logon Manager of the availability of a TPF application across the link. Therefore, define TPF application alias names as a CDRSC to VTAM. See ALS and CTC Qualifiers for more information about this parameter.
When the virtual route (VR) is blocked for the specified time, the link attempts to issue 1 more PIU with the VR pacing request indicator on. The TPF system may have lost the VR pacing response, or the CTC may have lost the VR pacing request. If the link times out again, the link is discontacted.
The default value for this parameter is 0, which indicates that no timeout processing occurs on this link. The maximum value is 65 535 (about 54 minutes).
There are two considerations for setting this value:
When the virtual route (VR) is blocked for the specified time and the input list is shut down, the link attempts to issue the equivalent of 1 VR pacing window of PIUs (WINSIZE value) each time the timer goes to 0. Because the TPF system is in input list shutdown, the pacing response is not yet received because both of the read buffers are on the input list that is shut down.
An attempt is made to send out the PIUs in these blocks to the CTC in order to relieve the input list shutdown condition. To prevent the CTC from being flooded, set this value equal to the value it normally takes for the CTC to process a window of PIUs.
The default value for this parameter is 0, which indicates that no timeout processing occurs on this link. The maximum value is 255 (about 12 seconds).