gtps4m1gSystem Generation

Communications Record Generation

Depending on the line types selected for the communications configuration, as many as 5 different sets of system generation macros or processes may have to be coded or executed in order to generate the required communications network records. In addition, users must code or execute a generation of 3705 EP, 3745 PEP, ACF/NCP or all, if they want any support other than the system console or 3270 local terminals. The 5 sets of macros or processes are as follows:

The remainder of this chapter is devoted to explaining the design considerations for these 5 generation macros and processes. The reader is directed to the previously referenced chapters of this publication for detailed information on how to code the various macros and how to execute the various procedures.

SIP Communication Macros

Table 20 lists the various SIP macros related to communications and the associated records and macros modified and generated by SIP as a result of the user-specified macro parameters. Users should review each macro listed and code the macro parameters that are applicable to their communications network. There are a number of SIP macros and keywords that do not have to be coded if you want to accept the defined default values. Only code these macros for the BSS of MDBF users.

SIP will always generate the code necessary to support SNA communications in the generated TPF system. In order to activate this support, the user must update the SNAKEY macro in the SNA communications keypoint (CTK2) and reassemble and load the keypoint to the TPF system. See TPF ACF/SNA Network Generation for information on this part of SNA network definition.

Table 20. SIP Communications Macros

SIP Macros Macros and Records Modified
BBSAT BSAT, CTKE, SYCON, SYSETK
BSNCT CRSx, JPC0, IBMPAL, SNCT, SYCON, SYSETK
CCPERR LINEQC, SYCON, SYSETK
CCPPOL CTKA
CCPSTA CTKA
CRASTB BSSSET, CTKC, LINEQC, SYSET, SYSTG
LINES BSSSET, CTKA, CTKE, JPC0, IBMPAL, SYCON, SYSET, SYSETK
MSGRT BSSSET, COHx, CTKA, CTKC, JPC0, IBMPAL, SPPGML, SYCON, SYSET, SYSTG
MSGRTA ANTDEF, COHx, CRSx, JPC0, SYCON
NETWK BSSSET, CC0CC, CC1CC, CTKA, CTKB, CTKC, CTKE, JPC0, LINEQ, SYCON, SYSET, SYSETK, SYSTG
SYNCLK BSSSET, CTKA, CTKD, SYCON, JPC0, SYSET

Various communication functions are related to the SIP macro parameters in the following ways:

Error control data (CCPERR macro): This macro controls the error recovery processing done by the communications control program (CCP) for non-SNA communications support. The error counts are threshold values which, when reached, will cause CCP error recovery and line shutdown to begin. The default values supplied by SIP have proven acceptable with past systems and most likely do not require modification. If users want to change these values they should consult the appropriate IBM hardware publication before doing so. A listing of error counts and their supplied defaults can be found in CCPERR.

Line shutdown and restart levels (CCPPOL macro): This macro establishes the input list sizes that stop and start the acceptance and processing of input from the various non-SNA line types. Two levels are supplied for each line type function, as follows:

Note:
For 3270 locals that are not polled, the shutdown and restart levels apply to what action is taken by the host on the receipt of an attention interrupt.

The shutdown and restart levels default to an input list length of 300 for shutting down and an input list length of 150 for restarting.

Users should be aware of the number of times that line polling is shut down and tune their system accordingly. In order to evaluate the efficiency of the levels, refer to the system reduction report produced by the data collection and reduction package. This report will indicate the number of times during samples that lines were shut down and restarted.

All of the levels specified to SIP may be displayed or altered dynamically online via the ZLDCL/ZLACL command.

CTKA communication options (CCPSTA macro): Several communication system options may be set (or defaulted) in the CTKA keypoint record as follows:

SYCON macro communication variables (NETWK macro): Certain miscellaneous values required by SYCON may be set through SIP as follows:

37x5s attached to the TPF system may run in 3 modes depending on the program loaded into the 37x5. The 3 modes are:

37x5 NCP mode: The symbolic device address of the 37x5 is defined with the SIP IODEV macro. Further definition of the NCP and its resources is accomplished with the NCP and RSC input definition statements in OSTG. The 37x5 in NCP mode may not be IPLed by the TPF system. It must be owned and IPLed by the required VTAM CMC.

37x5 PEP mode: The symbolic device address that is associated with the NCP should be specified with an IODEV macro. See NETWK for definitions necessary for the EP. Any NCP (for example, SNA) resources in the PEP are defined as NCP resources with the NCP and RSC input definition statements of OSTG. EP resources in the PEP are defined to TPF via SIP as if the 37x5 was an EP. A 37x5 running in PEP mode may not be IPLed by TPF. It must be owned and IPLed by the VTAM CMC.

37x5 EP mode: TPF supports the EP mode only for 3705. A 3705 in EP mode may be IPLed by the TPF system. For 3705s in EP mode, enter the following SIP input:

If the system being generated contains 3745 control units in ACF/NCP or PEP mode, additional network definition is required in OSTG and the SNAKEY macro in the SNA communications keypoint (CTK2). (See TPF ACF/SNA Network Generation for the specific definitions required.)

Binary synchronous communications (BSC) inputs: The BSC procedures as described in General Information - Binary Synchronous Communications are supported under TPF. The following SIP macros are required to be coded, as applicable, in order to initialize the BSC communication lines:

The NETWK macro parameters are shown in Table 22, and the LINES macro is shown in Table 21. These macros require separate entries for each line and TCU that utilizes BSC.

SCK/PKST communication keypoint macros (see Communication Keypoint Macros (Non-SNA)) are also required to be coded, as applicable per worksheet entries for both Table 21 and Table 22.

The BBSAT macro must be coded if there are any BSC multipoint lines directly connected to the TPF host processor. It is used to specify the valid sets of polling and selection characters in the BSC multipoint network. Each BBSAT macro relates to a unique BSC line that has also been defined in the SCK and 3745/PEP generations.

The BSNCT macro must also be coded for any BSC multipoint lines. It may also be optionally used for BSC point-to-point lines.

The BSC-associated keywords must also be coded on both the CCPERR and CCPPOL macros to provide for BSC error control and for the BSC restart or shutdown levels.

Synchronous link control (SLC) inputs (SYNCLK macro): If the system being designed contains SLC lines, several variable fields used in SYCON and keypoint D (CTKD) plus the SLC routing table (CTKD) must be defined through SIP. These values are in addition to the SLC lines and pseudo-lines (if any) that must also be described to SIP (LINES macro) and the SCK/PKST macros as shown in Table 16.

The parameters that follow are all those entered in the SIP SYNCLK macro. A brief description accompanies each. A full description of SLC may be found in the TPF Non-SNA Data Communications Reference.

  1. The number of SLC input pool records (NPOOL) must be defined. This number must be a multiple of 8.
  2. The number of SLC links (NLINK) in the system is required if pseudo-lines are being used.
  3. If there are SLC links in the system, indicate the number (N1LNK) with a single AI (ALC) line pair. This number must not exceed the number of SLC links.
  4. The number of slots in the input link control block queue (ILCBQ) must be designated.
  5. The number of slots in the output link control block queue (OLCBQ) must also be specified.
  6. The AI line CXFRC/ENQ LCB-IN level (AILCB) must be established.
  7. The routing of input messages must be established in 2 parameters. The first input (AILST) defines the queue on which the CCP will place input message blocks at initial entry time. The choice is between the ready list (higher priority) and the input list (lower priority). If the input list is chosen no additional coding is required. If the ready list is specified, the routing of the last received or only block of type A messages must be established (AIRTE). The options here are also ready list or input list.
  8. The number of slots in the SLC routing table (NLRT), which will be described later, must be entered. This number must be equal to or greater than the number of table entries.
    Note:
    Leave room for expansion.
  9. Up to 50 entries may be coded as positional parameters to the SYNCLK macro for the SLC routing table. Each entry consists of 6 fields as follows:
    1. The symbolic link number (SKN) for this entry. The SKN is a relative number not an actual symbolic line number. For example, the first table entry should be coded as 1, the second as 2, and so on. The actual symbolic line number will be calculated by SIP based on the numbers of other lines on the system. The number of SKNs must not exceed the number of SLC lines entered in the keyword SLCAI in the SIP macro LINES.
    2. The high-level exit address associated with this pseudo-line number must be entered.
    3. The terminal circuit ID for this entry must be entered.
    4. The pseudo-line number for this entry must be defined. The pseudo-line number is also a relative entry processed in the same manner as the SKN. The number of pseudo-lines must not exceed the number defined by keyword PSLNS in the LINES macro.
    5. The interchange address on the pseudo-line must be entered.
    6. The data transfer code associated with the pseudo-line must be established. This code identifies the form in which data will be transferred as either padded SABRE, padded BAUDOT, International Standards Organization (Standard ISO 7 bit code) extended 7-bit, or extended padded SABRE. In addition, an indication must be made as to whether or not incoming messages should be passed to the input message editor package (UII). (See UI/Reservation Package (PARS).)

Computer room agent set (CRAS) table (CRASTB macro): The CRAS table is established via this macro in order to allow communication between the TPF online system and system operators after an IPL has taken place.

  1. The CRASTB macro provides for the definition of a prime CRAS device (the system console), a receive-only (RO) hardcopy terminal (system RO CRAS), and for both alternate consoles and alternate CRAS devices (alternate CRAS). The alternate consoles and alternative CRAS devices are used by the fallback routines if there is a hardware failure of one of the system consoles.
  2. For LC users of the HPO feature, a prime and RO CRAS device must be defined for each processor in the complex.
  3. In addition, input to the CRASTB macro also defines the physical type of console device to be supported by the system. Two generic types of devices are supported:
    1. TPF supports the native system console, which is normally a 3270-like device (for example, a 3036, or a 3278 model 2A). This is referred to as native console support (NCS). In this case the RO CRAS device is a 3270 local printer and the alternate console devices would also be 3270 local terminals (both CRTs and printers).
    2. TPF also supports the use of a 1052/3215 printer/keyboard which is attached to the system via an RPQed 7412 control unit. In this case the RO CRAS device may be a 1053 printer which is also attached via the RPQed 7412 CU. An alternate 1052/3215 console may also be specified which is used in case of hardware failure of the prime 1052/3215 console.
  4. An additional function of the CRAS table is to allow the user to specify additional (99) alternate CRAS devices. These may either be 3270 local devices or terminals located out in the communications network. These are specified dynamically via the ZACRS command.

    The terminals supported in addition to 3270 local CRTs and associated printers are:

  5. CRASTB macros are coded as follows:
  6. For NCS and local 3270 CRAS devices, the user must specify the amount of time (MORE) that messages are held on the CRT screen before being cleared and the next message displayed.
Note:
During online operation the initial CRAS configuration may be displayed or modified dynamically via the ZDCRS and ZACRS commands.

The number and type of non-SNA communication line/protocols (LINES macro) is used to define which and how many lines are attached to the host TPF system.

Additional non-SNA communications support (NETWK macro)--In addition to the previous SIP macros/keyword parameters, the NETWK macro contains additional keyword parameters which are of interest to the non-SNA communications designer.

  1. The NETWK macro also contains the following keyword parameters:
    1. The total number (N2703) of 3705 controllers plus the number of 3745 control units running PEP.
    2. The maximum (M3270) size of an input/output message, including control characters, from/for any 3270 terminal.
    3. The number (NUAT) of unique, including expansion, LNIATAs requiring an entry in the AAA/RCB initialization table (UAT). This includes pseudo LITs.
    4. The time interval (WGTIME) for controlling the frequency of keypointing the WGTA table which contains the UAT entries allocated above.

    Additional non-SNA communications support (CONFIG macro)--in addition to the normal communications macros specified above, the CONFIG macro contains several keyword parameters which are also of interest to the non-SNA communications designer. Note, MDBF users of the HPO facility should only code these parameters on the CONFIG macro which is associated with the BSS.

    The CONFIG parameters are:

    1. Whether or not (MAPSP) support will be provided for the 3270 mapping support package. This is an application type support package which is further discussed in TPF Mapping Support. Support is provided for all versions of TPF's 3270 support including 3270/SDLC, 3270 local.
    2. Whether or not (MSGSW) support will be provided for the message switching package (MESW). This is another application type support package which is further discussed in Message Switching Packages. It is also influenced by the CONFIG USER keyword (see below).
    3. Whether or not the TPF system is to be generated to run under the control of the VM product (VM=YES|NO) has communications impacts. The option should only be YES if the system being generated is a test system.
    4. Whether or not the system being generated is for either a domestic or a World Trade user (USER) governs the type of MESW support provided (see MSGSW above), plus unique support within several of the communications protocols. For MDBF users, one subsystem can be for domestic use and another for World Trade use.
    5. Whether or not the old PARS reservation function is included in the system is governed by the RES parameter (see UI/Reservation Package (PARS)). For MDBF users, one or more subsystems can have this unique application and others not have it.

    SNA requirements--When defining an SNA communications network, including one with only NEF support, see the TPF ACF/SNA Data Communications Reference.

    A TPF SNA network requires an additional network definition step, which is done outside of SIP. Refer to TPF ACF/SNA Network Generation. for information on doing these steps.

    In addition, there is also a requirement to do a separate generation of ACF/NCP. If 3600/4700 support is required, there are additional generation requirements to be able to load/dump these communication devices.

Message router support (MSGRT and MSGRTA macros)--Communications support requires the use the TPF message router and log processor packages. The SIP requirements for this support are discussed later in Message Router Support and in Log Processor.

Communication Keypoint Macros (Non-SNA)

The non-SNA communications network is defined for the system by the following set of keypoints:

The SCK and PKST generation package (see Non-SNA Communications) provides a set of macros and an offline process which can be used to define the user's non-SNA network configuration and produce STC input to create a communications pilot tape which contains an SCK for each non-SNA line and a PKST for each non-SNA communications control unit. Note, communication keypoint records are not required for a network supported only by the Network Extension Facility (NEF) and SNA.

Refer to Table 21 and Table 22 to assist in setting up SIP and SCK/PKST inputs. Information entered in SIP macros is passed to the SCK/PKST macros via the SYGLBK and SYSETK members which are created during SIP Stage II execution. This insures basic integrity between the two processes, SIP and SCK generation. SIP Stage II must be successfully completed prior to SCK/PKST generation.

The SCK macro sets must be coded in symbolic line number (SLN) sequence and the line numbers must start at two. SLN number one is reserved for use of prime and RO CRAS. The SCK input for these unique entries is described in Communication Pilot Record Generation. This is to ensure that all the SCKs are initialized. If the macros are not coded in line number sequence, the user must ensure that an SCK has been created for every line in the system. PKSTG macro calls must follow the last SCK macro set. All control unit numbers must be in sequence order and the control unit number must start at zero. If PKSTG macros are not coded in control unit number sequence, the user must ensure that a PKST has been created for every control unit in the system. A SENDG END macro statement must follow the last PKSTG macro call; this will cause final validation checks.

During phase I of the SCK process the user coded SCK/PKST macro statements are analyzed for errors. Some errors will prevent SCK/PKST record generation from continuing but in most cases errors will be flagged and processing will continue, using default values wherever possible, to produce an assembly listing and STC input for phase II. If errors occur in phase I, they must be resolved before proceeding to phase II.

Phase II is a straightforward STC execution of the output of phase I. Before executing STC, the unit test disk, DISK01, should be loaded with an SDMF and a DRIL file containing at least the following macros (see note (SDMFN3)):

SCKDS
Data record description for SCK.

CPTIC
Data record description for PKST.

Output from phase I can then be used as input (CARDIN; see note (CARDN1)) to STC to produce a communications pilot tape (TAPE1; see note (TAPEN2)). This tape is then used as input for the online system loader to initialize the communications keypoint records on file.

Notes:

  1. CARDIN is the DDNAME given to the DCB describing the input file of STC executing under MVS control.

  2. TAPE1 is the DDNAME given to the DCB defining the output tape file from STC.

  3. Loading of the SDMF and DRIL disk can be accomplished at the time the SCK pilot is created by coding the parameter 'LOAD=YES' of the SENDG macro. The user must also insure that the DD statement for the SDMF and DRIL tape is included in the STC execution JCL.

Two worksheets are provided to aid in the definition of the non-SNA communication network. The entries for the transmission control unit worksheet (Table 21) and the lines definition worksheet (Table 22) are described below. An individual entry is made for each terminal control unit and each line in the non-SNA network. No entries need be made for the NEF supported network.

On the transmission control unit (TCU) definition worksheet (Table 21) the user must describe the physical layout and characteristics of all TCUs on the system being generated. SIP and PKST macros both require inputs. Information entered in SIP macros is passed to the SCK/PKST generation package which insures basic integrity between the two system generation processes. Outlined below is a brief description of each column in the figure and the related SIP and PKST entries required:

  1. Indicate the symbolic control unit number in column one.
  2. Enter the control unit type in column two.
  3. Indicate the initial status of the TCU as either online or offline in column three.
  4. For 3705 EPs and 3745 PEPs, indicate the native subchannel address of each TCU along with their associated channel adapter type in column four.
  5. Indicate the range of subchannel addresses associated with each TCU in columns five and six.

Finally, the total number of 3705 EPs and 3745 PEPs defined in the TCU worksheet is required as input to SIP.

The first entry has been entered as an example for the user.

Table 21. Non-SNA Transmission Control Unit (TCU) Worksheet

Symbolic CU Number CU Type TCU Status Online=ON Offline=OFF 3705 Native Subchannel Address * Lowest Subchannel Address Highest Subchannel Address
        60 6F
02 3705 ON 1A-1    
           
           
           
           
           
           
           
           
           
           
           
Note:
Total number of 3705 EPs and 3745 PEPs = ______

* Column 4 is not needed for 3745/PEP.

All non-SNA lines on the system being generated must be declared in SIP and defined with SCK macros. As with TCUs, data received in SIP is passed to the SCK/PKST generation package through SYGLBK/SYSETK. Lines declared in SIP must be defined in SCK/PKST so that an SCK data record is created for each line.

The worksheet in Table 22 is provided to serve as a guide and format for designing line definitions. All columns correlate to the narrative below in the same manner as the TCU worksheet above. Inputs to the worksheet are as follows:

  1. Indicate the line type (SLC, LC, or BSC) for each line in column 1.

    SIP Input = LINES (line type mnemonic)

  2. Indicate the symbolic line number in hex for each line in column 2. The SLNs are created in direct relation to the line type and number of lines in the line status table (LSTB). At the completion of the SIP run, the SIP report lists the line types and their associated SLNs under the heading labeled "Lines."

    SCK Input = SKLNG (LNSY)

  3. Indicate the paths (from 1-4) by which a line may be connected to the TPF host in columns 3-7. The maximum number of paths described for any line must not be greater than the value entered in the SIP NPATH parameter of the NETWK macro.

    SCK Input = SKLNG (PATHx)

    Each path requires the following information:

  4. Enter in column 7 the count of the number of BSC messages that will be sent before line turn around occurs and messages will be received.

    SCK Input = SKLNG (SL)

  5. Indicate for BSC lines the line type; either multipoint (MP) or point-to-point (PP) and whether or not the line has blocking (Y or N) in column 8.

    SCK Input = SKLNG (BTYPE)

  6. Indicate for BSC lines the type of code used as follows in column 9.

     E/U 
    = EBCDIC or UASCII code

     Y/N 
    = Data transparency, yes or no

     Y/N 
    = RCPLs required, yes or no

     SCK Input 
    = SKLNG (BCODE)
  7. Indicate for BSC multipoint lines the time-out value (0-255) in column 10.

    SCK Input = SKLNG (BSTOV)

For pseudo lines, only 1 path is required. They should be defined in the SKLNG macro as PATH1 = (ppp,nn.LMP) where ppp equals the physical line number, nn equals the actual symbolic control unit number through which the line passes, and LMP indicates the following:

L = 3705EP

M = manually switchable

P = primary path.

For 3270 local lines, only 1 path is allowed. It should be defined in the SKLNG macro as PATH1 = (ppp,,LMP) where ppp equals the physical line number and LMP = local 3270, manually switchable and primary (only) path.

Finally, all non-SNA terminals or terminal control units must be defined with SCK generation macros. The following are the terminal parameters required for BSC:


Table 22. Non-SNA Communication Lines Worksheet

1 2 3 4 5 6 7 8 9 10 Description
Line Type SLN Line Paths (1-4) BSC
PLN SCU CUT LNS SL TYP COD TIM
- 00                 RO CRAS
- 01                 Prime CRAS
BSC 43 032 03 3705 LMP 101 PP-B ETY 50  
LC 50 094 06 Local LMP          
Legend:

SLN
Symbolic line number

PLN
Physical line number

SCU
Symbolic control unit number

CUT
Control unit type (3705 EP, 3745 PEP, or 3270 local)

LNS
Line status

SL
Line turnaround count

TYP
BSC line type

COD
BSC line code

TIM
BSC multipoint timeout value.

Communication Pilot Record Generation

The system test compiler (STC) is a multipurpose tape file generator that is used to create pilot tapes. See TPF Program Development Support Reference for additional information about this package. STC is used to create a pilot tape containing the following non-SNA communication records in addition to its use in SCK generation phase II, described previously.

AAA/RCB initialization table (UAT): This table contains an item for every terminal (including NEF-supported terminals) and every binary synchronous line in the system. Each item contains the necessary data to initialize the agent assembly area (AAA) and the routing control block (RCB) for the terminal or line it references. The UAT table is used to initialize the AAA and RCB records. For MDBF users, a set of UAT records must be built for each subsystem. The set loaded to the basic subsystem includes all terminals. The set that must be loaded to a subsystem is a subset of the basic subsystem's UAT records. This subset will contain only entries for terminals that will have access to that subsystem. This subset will be used for the record initialization described previously and for the initialization of the subsystem ordinal table records (SSOR). See Operator/Terminal Control for an explanation of SSOR use.

The UATs are also used at restart time to build the WGTA table where there is one entry for each UAT. The SIP input for the NUAT keyword of the NETWK macro specifies the total number, including expansion, of UAT entries that are now being created. The WGTIME keyword is also associated with the WGTA table created from the UATs.

If an automation gateway is connected to a processor for multiple console support, you must specify additional UATs for that processor. Besides the Prime CRAS and RO CRAS UAT entries, you must generate UAT entries for each possible LNIATA made up of LN/IA 0100 and the TA in the multiple console support header received from the automation gateway; that is, UATs for LNIATAs 010003 through 0100mm, where mm is the maximum terminal address specified in your IBM Extended Operations Console Facility/2 (EOCF/2) configuration. (For additional information about the maximum terminal address, see the IBM Extended Operations Console Facility/2 System Administrator's Guide.) Unlike those for the prime CRAS and RO CRAS, the additional UATs should be generated as not permanently logged to ensure that the other consoles can log on or off from applications other than SMP.

XLMT assembly area (XLMA)--These areas are 381-byte records located in fixed locations on file and used by the LMT package. (See Long Message Transmitter Package.) An XLMA record is reserved for each hardcopy terminal (for example, IBM 1052, 3215, 1980-21, 1980-24, 1977, 3284, or 3286) whose address is referred to by symbolic line number, interchange address, and terminal address (LNIATA). An automation gateway is an exception; LNIATAs 010003 through 0100mm do not require an XLMA record, where mm is the maximum terminal address specified in your IBM Extended Operations Console Facility/2 configuration.

These XLMA records are used to queue and control transmission of messages to these terminals.

On a WTC system using IPARS message switching, a record must be assigned for each CRT device defined as a message switching input terminal.

Entries must be made in the XLMT assembly area for all hardcopy terminals supported by the network extension facility (NEF). The NEF pseudo LN/IA, along with the real TA, should be used.

Line number/interchange address/terminal address index (XLAD): The XLAD table is maintained in the unprotected application global area and is used to convert the high-speed line number, interchange address, and terminal address (LNIATA) into an ordinal number. The long message transmitter program (LMT) uses this number to access the XLMT assembly area (XLMA) assigned to each:

  1. LNIATA hardcopy terminal.
  2. CRT devices defined as message switching input terminals. This applies only to World Trade systems using the IPARS messages switching package.
  3. NEF-supported hardcopy terminals require an entry using the NEF pseudo LN/IA and the real TA.

Agent assembly area--Each AAA is a record permanently assigned to a specific terminal in the system. Pseudo AAAs not associated with a terminal are also temporarily created for internal use (for example, TTY or file record processing). AAAs are required for the PARS (RES0) and IPARS applications. If an automation gateway is used and the local area network (LAN) terminals are logging into airline reservation applications, AAAs must be allocated for all terminals with LNIATAs in the range of 010003-0100mm, where mm is the maximum terminal address specified in your IBM Extended Operations Console Facility/2 configuration. When MDBF is installed, AAA records only have to be allocated in the subsystems that have an airline reservation type of application.

If an automation gateway is used, all the possible terminal appearances on the LAN require an RCB; that is, LNIATA 010000 and LNIATA in the 010002 to range 0100mm, where mm is the maximum terminal address specified in your IBM EOCF/2 configuration. (For additional information on the maximum terminal address, see the IBM Extended Operations Console Facility/2 System Administrator's Guide.)

System communication keypoints: These keypoints are normally generated using the SCK/PKST generation package (see Communication Keypoint Macros (Non-SNA)). However, systems supporting only SDLC communication lines still require 2 SCK records for the prime and RO CRAS terminals that must be generated via STC. The following is the required STC input:

*
*  SCK RECORDS FOR PRIME AND RO CRAS
*
SCKDS    GSTAR 1.
BSTA06   ENT   (#PKSCK)0.
SCKBID   ENT   SK.
SCKIND   ENT   X'80'.
SCKDIS   ENT   X'003E'.
         GEND
SCKDS    GSTAR 1.
BSTA06   ENT   (#PTSCK)1.
SCKBID   ENT   SK.
SCKIND   ENT   X'80'.
SCKDIS   ENT   X'003E'.
           GEND

The following are the fields that must be initialized for the previous record types:

Record Macro Name Mandatory Fields to be Initialized Title And Notes
XS0AA
XS0AVA  XS0BCH  XS0CAP  XS0CCT
XS0COP  XS0FCH  XS0LNR  XS0LOP
XS0MIA  XS0MSG  XS0MTL  XS0OLN
XS0OME  XS0OTC  XS0OTL  XS0OTM
XS0RMC  XS0RSC  XS0SOP  XS0SP1
XS0SP2  XS0SSP  XS0TCC  XS0TQC
XS0TSI  XS0TTA  XS0TTP
XLMT Assembly Area
XX1ON
XX1ELN  XX1IN1  XX1LNR  XX1TLN
XX1TON
LNIATA Index
UA1UA
UALIND  UA1ADD  UA1APN  UA1CID
UA1CIT  UA1ISP  UA1TTP  UA1TYS
UA1XRF
AAA/RCB Initialization Table--One item for each high-speed terminal including NEF supported terminals.
CI0CO
CI0IAS  CI0LNB  CI0MOD  CI0TAS
CI0TTP  CI0TYS
Routing Control Block--One record per terminal.
WA0AA
WA0CIT  WA0GFC  WA0HFC  WA0IAS
WA0IOT  WA0ITC  WA0LNB  WA0LST
WA0NAB  WA0NMC  WA0RFC  WA0RKC
WA0SIN  WA0SIO  WA0SIS  WA0TAS
WA0TKC  WA0TLC  WA0TNC  WA0TYS
WA0TY1
Agent Assembly Area--One completely initialized AAA for a prime and RO CRAS set must be program (UAA1). Required only if created by the AAA initialization RES=YES.

SNA Table Generation

SNA table generation, or SNA network definition, is performed by the offline SNA table generation (OSTG) program and by the SNAKEY macro in the SNA communications keypoint (CTK2). See TPF ACF/SNA Network Generation for detailed specifications about performing these two tasks.

SIP provides input to the SNA table generation program in the form of a data set name that contains the application name table (ANT) definitions, and is derived from the MSGRTA macros of SIP as coded by the user. (See Message Router Support.) The SIP GENSIP macro provides the ANTPDS parameter, which is used to specify the actual name of the data set that will contain the ANT entries for the SNA table generation program.

Online, SNA restart initializes the main storage resident resource vector table (RVT) from the resource resolution table (RRT). The main storage resident copy of the subarea address table (SAT) is built from the SAT file created offline by OSTG.

3600/4700 SNA Generation Requirements

When you use either the 3600 or 4700 Finance Communication systems, both PUs need to be loaded and dumped, and this must be done by another system. The component that does this function is known as subsystem support services (SSS). You must generate the system so that these devices are owned by the TPF-required VTAM CMC and, as a result, all loading or dumping is taken care of by that system. The encrypt/decrypt module desired should be added to the TPF-released object library for any system supporting 3614s.

The SIP CONFIG macro provides the CIPHR parameter, which is used to specify which of the following encryption techniques are desired (both, one, or the other, or none):

Additional information regarding SSS can be found in 3600 Finance Communication System 3614 Programmer's Guide and Reference.

Application programs that use TPF SNA support as their communications medium must conform to those SNA disciplines implemented in TPF unless it is the NEF support. The TPF ACF/SNA Data Communications Reference describes host application programming and SNA message protocols that may be implemented. The IBM 3600 Finance Communication System Instructions and Macro Reference, and the IBM 3600 Finance Communication System Programmer's Guide and Component Descriptions, should be helpful to the application developer. Resources defined in a particular network mode must be examined carefully for dependencies that must be defined in other interfacing nodes. For example, input buffers must be defined so that they are compatible with ACF/NCP-defined output message lengths.