gtps4m1g | System 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.
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:
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:
NCP mode supports only SNA protocols.
EP mode supports only non-SNA protocols.
PEP mode supports both SNA and non-SNA protocols.
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.
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.
The terminals supported in addition to 3270 local CRTs and associated printers are:
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.
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:
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.
The non-SNA communications network is defined for the system by the following set of keypoints:
The SCKs contain the status of each non-SNA communication line attached to the system. They are used at restart time to build the following main storage resident communication tables:
The PKSTs contain the status of each 3705 EP or 3745 PEP on the system.
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)):
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:
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:
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 | ||
* 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:
SIP Input = LINES (line type mnemonic)
SCK Input = SKLNG (LNSY)
SCK Input = SKLNG (PATHx)
Each path requires the following information:
1st character = (L) 3270 local line, 3745 PEP, or 3705 EP 2nd character = (A) automatic switching status (M) manual switching status 3rd character = (P) primary path (A) alternator path Example SCK Input: PATH=(,,LMA)
SCK Input = SKLNG (SL)
SCK Input = SKLNG (BTYPE)
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 | |||||
|
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:
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, 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.
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.