gtpa1m0iACF/SNA Network Generation

Coding the OSTG Input Definition Statements

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

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.

Reserved Names

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.

ANT Deck

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:

 TPFc 
The system services control point (SSCP), where c is the processor ID.

 NEFc 
The network extension facility (NEF) application, where c is the processor ID.

 TPFcFMMR 
The SNA functional management message routing (FMMR), where c is the processor ID.

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.

ANTDEF Statement

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:

Figure 4. ANTDEF Statement

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7...
 
symbol   ANTDEF CPUID=c,                                               X
              <SDPSID=(n,...,n)>
 

symbol
The symbol parameter is not required and is ignored if coded.

CPUID
Specifies the 1-character identifier of the TPF processor for which the ANT is being defined, where c is a character from A-Z or 0-9. For a loosely coupled complex, this is the first processor in the complex. The value specified for this parameter must match the value specified in the EXEC PARM data.

SDPSID
Specifies the 1-character identifiers of all the TPF processors in the loosely coupled system, where n is a character from A-Z or 0-9. The maximum number of TPF processors in a loosely coupled system is eight. The value specified for this parameter must match the value specified in the EXEC PARM data.
Note:
If loosely coupled support is not included in the TPF system, you must omit this parameter.

ANTNME Statement

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:

Figure 5. ANTNME Statement

|...+....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>
 

symbol
The symbol parameter is not required and will be ignored if present.

NAME
Specifies the 4-character alphanumeric name of the TPF application. None of the reserved names can be specified. See Reserved Names for more information about the reserved names.

SNA
Specifies the form of terminal addressing accepted by the application. In the TPF system, a terminal can be addressed by line, interchange, and terminal (LIT) address or by the resource identifier (RID) of the terminal (LU). The valid options are:

NO
The application can accept only LIT-type terminal addresses.

YES
The application can accept both LIT- and RID-type terminal addresses.

LU62
The application can communicate as a logical unit (LU) type 6.2 and is precluded from communicating as any other LU type.

APPC
The application is defined as the default TPF/APPC LU.

LOCP
The application is defined as the local TPF/APPN control point (CP) LU.

CPUID
Specifies the 1-character ID of the TPF processor where the application resides. This parameter is required for all applications so that the OSTG program can determine where a TPF application resides.

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 (*).

Note:
Define all applications in the loosely coupled complex as CPUID=*. Defining an application to run only on one specific processor implies that if that processor is not online, the application is not available to the entire network. Processor-unique applications also create difficulties in defining load-balancing algorithms.

RECVRY
Specifies if the application is recoverable. YES indicates that it is, and NO indicates that it is not. The default is NO.
Note:
Message recovery is an optional feature, which is defined in the SNA keypoint (CTK2) using the SNAKEY macro. If the TPF system does not support message recovery, coding YES for this parameter has no effect.

APPL
Specifies if the application can act as both a primary LU (PLU) and a secondary LU (SLU), or only as a PLU. The valid options are:

P
The application can only be a PLU, which is the default.

(S,nnn)
The application can act as both a PLU and an SLU, where nnn indicates the number of concurrent sessions (threads) that this SLU can have with an LU in a remote processor. The maximum number of sessions allowed is 255.

SAWARE
Specifies if session awareness user exit support is available for SLU threads associated with the application. YES indicates that session awareness user exit support is available for SLU threads. NO indicates that session awareness user exit support is not available for SLU threads. The default is NO.

ANTEND Statement

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:

Figure 6. ANTEND Statement

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7...
 
symbol   ANTEND
 

symbol
The symbol parameter is not required and is ignored if coded.

RSC Deck

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:

CDRM
Defines a CDRM resource.

RSCDEF
Begins the definition of resources that have a particular network ID.

RSC
Defines a remote LU resource to the TPF system.

RSCSET
Temporarily overrides the RSC system defaults.

RSCEND
Ends the definition of resources that have a particular network ID.

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.

CDRM Statement

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:

Figure 7. CDRM Statement

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7...
 
cdrmname CDRM  SUBAREA=n,                                              X
              <ELEMENT=n,>                                             X
              <CPUID=c,>                                               X
              <REALNAME=name2>
 

cdrmname
Specifies the name of the CDRM. Specify the CDRM name as follows:

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.

SUBAREA
Specifies the pseudo subarea to be used for PU 5 SNI gateway support. A SAT entry will be created for this subarea. This value is used to group resources in the CDRM domain. It is referred to as the owning subarea (RV1OWNSA). The actual network address of the CDRM is determined dynamically online at ACTCDRM time. This parameter is required.

ELEMENT
Specifies the element address portion of the CDRM network address. The maximum value of n is 32 767. This parameter is ignored for a CDRM accessed through an SNI NCP. (The network address is determined dynamically at ACTCDRM time.)

CPUID
Specifies the processor ID of this CDRM if the CDRM is a TPF processor. This parameter must be omitted if the CDRM is not a TPF processor, but is required for all TPF processors defined in the network.

REALNAME
Specifies the real name of the CDRM. Code this parameter only when the CDRM is accessed through an SNI NCP to a VTAM system that also has APPN connections with the TPF system. In this case, the real name of the CDRM is specified by the REALNAME parameter while an alias name must be specified for cdrmname.

RSCDEF Statement

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:

Figure 8. RSCDEF Statement

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7...
 
symbol   RSCDEF NETID=netid|ANY
 

symbol
The symbol parameter is not required and will be ignored if specified

NETID
Specifies the network identifier for the LU resources defined between this statement and the associated RSCEND statement. The valid options are:

netid
Specifies the network ID.

See SNA Network IDs and Resource Names for information about the characters that you can specify in a network ID.

ANY
Creates an RRT entry with a blank network ID. The actual network ID is determined at session initiation time. For PU 5, the network ID should always be coded NETID=ANY.

RSC Statement

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:

Figure 9. RSC Statement

|...+....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>
 

symbol
Specifies the name of the LU being defined. This parameter is required on the RSC statement. The LU name must be unique for each network ID.

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
Specifies the device or LU type of the resource being defined. The valid options are:

ANY
Unspecified at OSTG definition time. This is the default option.

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.

360X
IBM 360x devices

3614
IBM 3614 Consumer Transaction Facility

3277
IBM 3277 display

3278
IBM 3278 display

3284
IBM 3284 printer

3286
IBM 3286 printer

3287
IBM 3287 printer

3288
IBM 3288 printer

3289
IBM 3289 printer

APPC
LU 6.2 primary LU (PLU)
Note:
This option is treated the same as the L6PLU option. It is still available for migration purposes.

REMCP
Remote APPN control point (CP) LU

APPLU
Primary LU application

APSLU
Secondary LU application

BATCH
IBM 3600 Financial Controller

FMMR
Functional management message router

L6PLU
LU 6.2 primary LU (PLU)

L6SLU
LU 6.2 secondary LU (SLU)

MCHLU
NPSI multichannel link

NEF
The NEF application resident in the 37x5

VCLU
NPSI virtual circuit

AX001
AX25 virtual circuit for single terminal controllers

AX002
AX25 virtual circuit for multiple terminal controllers

XALCI
ALC data formats across GATE/FTPI connections

FTPI
Generic GATE/FTPI resource.

CCTYPE
Specifies the cluster (PU) type to which the resource being defined is connected.

The valid options are:

3601
Finance Communications Controller

3602
Finance Communications Controller

3271
IBM 3271 Controller

3274
IBM 3274 Controller

3276
IBM 3276 Controller.

Note:
The LUTYPE and CCTYPE parameters depend on each other. See Table 2 and Table 3 for information about the valid combinations.

See the TPF Migration Guide: Program Update Tapes for a list of all supported controllers.

LUMOD
Specifies the model of the 3270-type display device being defined. The valid options are:

2
Model 2

3
Model 3

4
Model 4.
Note:
See the TPF Migration Guide: Program Update Tapes for a list of the display devices supported by the TPF system.

SCSBUF
Specifies the buffer size for an IBM 3287 or 3289 printer. The valid options are:

2K
Valid only for 3287 printers.

4K
Valid only for 3287 or 3289 printers.
Note:
This parameter is ignored unless LUTYPE=3287 or LUTYPE=3289 is specified.

RECVRY
Specifies if the resource is eligible for output message recovery. YES specifies that this resource is eligible for output message recovery. NO specifies that this resource is not eligible for output message recovery support. The default is NO.

Notes:

  1. A resource can be eligible for output message recovery only when message recovery is defined for the TPF system. If the TPF system does not support message recovery, coding YES for this parameter has no effect.

  2. The RECVRY parameter and the PSV parameter are mutually exclusive.

  3. The RECVRY parameter and the THREAD parameter are mutually exclusive.

IATA
Specifies the pseudo interchange address/terminal address (IATA) to be used by this resource to communicate with the old type applications that require a line number/interchange address/terminal address (LNIATA). Each IATA specified must be unique. Duplicate IATAs are not allowed by the OSTG program.

THREAD
Specifies if the resource being defined supports single (SINGLE) or multiple (MULTI) thread operations.
Note:
The THREAD parameter and the RECVRY parameter are mutually exclusive.

UMODE
Specifies a 1-byte hexadecimal indicator that is stored in RVT mode byte 3. The contents and use of this user mode byte are left solely to your discretion. This information is accessible to user applications using the INQRC macro. See TPF General Macros for more information about the INQRC macro.

MODE
NETVIEW specifies that this resource is a NetView Terminal Access Facility (TAF) LU type 1 printer. It is valid only when CCTYPE=3274 or CCTYPE=3276 and LUTYPE=3287 or LUTYPE=3289 are specified. As a result, this causes the SNANETV bit in RV1MOD2 to be set. This parameter is ignored for all other values of the CCTYPE and LUTYPE parameters.

PSV
Specifies the 1- to 6-character alphanumeric process selection vector (PSV) name. Reserved PSV names for IBM use start with the letter I.

Notes:

  1. A maximum of 96 user-specified PSV names is allowed in the RSC statement.

  2. A maximum of 32 IBM-reserved PSV names is allowed in the RSC statement.

  3. If this parameter is omitted, an exit routine will not be called for this LU.

  4. The PSV parameter and the RECVRY parameter are mutually exclusive.

LEID
Assigns the resource a pseudo line, interchange, and terminal address.

The logical end-point identifier (LEID) is a hexadecimal value, which can be specified in the following formats:

xx
The first byte (LN) of the LEID associated with this LU. All inbound data messages contain the remaining 2 bytes of LEID information (IATA).

yyyy
The first 2 bytes (LN and IA) of the LEID associated with this LU. All inbound data messages contain the remaining byte of LEID information (TA).

zzzzzz
The 3-byte LEID associated with this LU. This full 3-byte LEID value can be used for 3270 devices, thereby replacing the IATA parameter.

Note:
All 3270 devices must have a corresponding WGTA entry. All other RSC statements with the LEID parameter must have a WGTA entry unless they have a PSV routine.

AWARE
Specifies if the session awareness user exits are to be driven for this LU. YES specifies that the session awareness user exists are to be driven for this LU. NO specifies that the session awareness user exits are not to be driven for this LU. NO is the default value.
Note:
This parameter is valid for all resource types except LU 6.2.

PRSHR
Specifies if this is a printer that can be shared. YES specifies that this is a printer that can be shared. NO specifies that this is a printer that cannot be shared. This parameter is valid only for resources that are printers. This parameter is not valid for resources that are defined as LUTYPE=ANY.

CHAIN
Specifies if large messages are transmitted in multiple segments for NPSI devices. YES specifies that large messages are transmitted in multiple segments for NPSI devices. NO specifies that large messages are not transmitted in multiple segments for NPSI devices. NO is the default value.

Notes:

  1. YES is supported only on X.25 virtual circuits and X.25 multichannel links.

  2. NO is supported only for AX.25, FTPI, and XALCI NPSI devices.

RSCSET Statement

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:

Figure 10. RSCSET Statement

|...+....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>
 

symbol
The symbol parameter is not required and is ignored if coded.

See RSC Statement for more a description of the parameters.

RSCEND Statement

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:

Figure 11. RSCEND Statement

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7...
 
symbol   RSCEND
 

symbol
The symbol parameter is not required and is ignored if coded.

ALS Deck

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:

ALS
Defines the 37x5 and non-37x5 ALS resources that can attach to the TPF system as PU 2.1 link stations.

NCP
Defines the 37x5 NCP resources that can attach to the TPF system as PU 4 nodes.

CTC
Defines the channel-to-channel stations.

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.

ALS Statement

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:

Figure 12. ALS Statement

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7...
 
alsname  ALS   <CLU=cluname,>                                          X
               <QN|ALSQN=xx>
 

alsname
This parameter is required and specifies the link station name of the ALS. See SNA Network IDs and Resource Names for information about the characters that you can specify in an ALS name.

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:

x
The 1-character ID of the TPF processor.

nnnn
The 4-character SDA number of the ALS channel adapter.

CLU
This parameter is optional and should be coded only when the resource being defined by this ALS statement is a 37x5 NCP. It specifies the 1- to 8-character control LU (CLU) name coded in the NCP generation deck. See SNA Network IDs and Resource Names for information about the characters that you can specify in a CLU name.

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.

QN|ALSQN
This parameter is required only when defining a 37x5 NCP and the TPF system is running in LEN mode. If the TPF system is running in APPN mode or you are defining a non-37x5 device, do not code this parameter.

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.

Note:
The ALS name is not network qualified. Therefore, all ALS and CLU names must be unique. (You cannot define the same ALS or CLU name for more than one network ID.)

NCP Statement

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:

Figure 13. NCP Statement

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7...
 
ncpname  NCP   SUBAREA=n,WINSIZE=n,<VRTO=n,><VRILTO=n>
 

ncpname
This parameter is required and specifies the name of the network control program (NCP). This name is used by the TPF system to verify that the 37x5 contains the correct NCP load image.

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.

SUBAREA
This parameter is required and specifies the subarea address of the NCP being defined.

WINSIZE
This parameter is required and specifies the virtual route pacing window size to be set by the TPF system when activating the virtual route between the TPF system and the NCP. The TPF system uses XID format 2 to connect the NCP and uses FID4 PIUs to communicate with the NCP.

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.

VRTO
This optional parameter specifies the virtual route timeout value when the virtual route of the link is blocked. Specify the number of SNA polling intervals for the virtual route timeout value. The SNA polling interval is defined by the SNAPOLL 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 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:

VRILTO
This optional parameter specifies the virtual route input list timeout value when the virtual route of this link is blocked and the TPF system is in input list shutdown. Specify the number of SNA polling intervals for the virtual route input list timeout value. The SNA polling interval is defined by the SNAPOLL parameter.

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).

CTC Statement

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:

Figure 14. CTC Statement

|...+....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>
 

ctcname
This parameter is required and specifies the name of channel-to-channel (CTC) link station. The CTC name is not network qualified. Therefore, all CTC and ALS names must be unique. Duplicate CTC names are not allowed. See the description of duplicate node names in Duplicate Node Name List Report for more information.

See SNA Network IDs and Resource Names for information about the characters that you can specify in a CTC name.

SUBAREA
This parameter is required and specifies the remote subarea address accessed by the CTC link station that is being defined. Values range from 1-255. You must define a CDRM with the same subarea. You can define no more than 2 CTC link stations with the same subarea.

WINSIZE
This parameter is optional and specifies the virtual route pacing window size to be set by the TPF system when activating the virtual route through the CTC. The value can range from 1-255. The default (and recommended) value is 100. The TPF system requires that the virtual route use pacing windows with equal minimum and maximum values.

TG2SDA
This parameter is no longer supported. If you code this parameter it is ignored.

CLU
This parameter specifies the 1- to 8-character name of the control LU (CLU) for this CTC. See SNA Network IDs and Resource Names for information about the characters that you can specify in a CLU 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.

Note:
If 2 CTC connections are defined between a TPF processor and VTAM, at least 1 CTC connection must have a CLU defined. Both connections should have CLUs defined for load balancing and backup.

QN
This parameter is required for CTC connections to VTAM when the TPF system is running in LEN mode. When the TPF system is running in APPN mode, do not code this parameter. The qualifier number (QN) is 2 hexadecimal characters that uniquely represent each CTC link to a VTAM host.

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.

VRTO
This optional parameter specifies the virtual route timeout value when the virtual route of this link is blocked. Specify the number of SNA polling intervals for the virtual route timeout value. The SNA polling interval is defined by the SNAPOLL 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:

VRILTO
This optional parameter specifies the virtual route input list timeout value when the virtual route of this link is blocked and the TPF system is in input list shutdown. Specify the number of SNA polling intervals for the virtual route input list timeout value. The SNA polling interval is defined by the SNAPOLL parameter.

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).

REMOTE
This optional parameter specifies the type of hardware used to provide the CTC link. A remote CTC controller connects 2 systems through a telecommunications link. The IBM 3737 is an example of a remote CTC device. If REMOTE=YES is specified, the TPF system will send a DISCONTACT to the remote system following a hard initial program load (IPL). Otherwise, a clear subchannel (CSCH) instruction will be executed to end a previously active link.