gtpd2m0j | Data Communications Services Reference |
The following devices are eligible for use as CRAS devices:
The terms console and system console generically refer to the device designated as Prime CRAS at system generation time. Similarly, the terms system RO, system printer, RO console, and system RO console refer to the device designated as RO CRAS at system generation time. Hence, console support pertains to the TPF functions which support the use and continued operation of the system consoles. The system consoles, as they are defined via the system generation process (SIP), are assigned symbolic line numbers 00 and/or 01. In a system generated with 1052 console support, both the system console and the RO console are assigned symbolic line number 01. In a system generated with 3270 native console support, the system console is assigned symbolic line number 01 and the system RO is assigned symbolic line number 00. Although the system console devices may be replaced (ZACRS REP) with alternate CRAS terminals during online operation, the replacement devices will not be assigned the system console symbolic line numbers of 00 and 01; they will retain the symbolic line numbers they were assigned at generation time.
There are two mutually exclusive versions of console support: 1052/3215 console support and 3270 native console support. These are the only device types currently supported as system consoles (that is, on symbolic lines 00 and 01). The type of console support is specified by the user at system generation time via the SIP CRASTB macro. See TPF System Generation for additional information about CRASTB.
When the system is generated with 1052 console support, a 1052/3215 printer keyboard or equivalent serves as the system console.
With this support, the prime CRAS and RO are most often defined as the same physical device, with symbolic LNIATA 010000 assigned to the PRC and symbolic LNIATA 010002 assigned to the RO. Defining the PRC and the RO as the same physical device means that one hardware subchannel address is used to access the device. This allows the use of a single symbolic line number (01) for both the PRC and RO. Alternatively, the RO can be defined as a separate device. See TPF System Generation for detailed information about the SIP CRASTB macro.
The user also has the option of defining an alternate 1052 to be used for fallback purposes.
Refer to the following table for a description of various fallback scenarios:
When the system is generated with native console support, locally attached 3270 devices (including the native console, if one exists) serve as system consoles. With this support, the PRC and RO are never the same physical device; the PRC has symbolic LNIATA 010000 and the RO has symbolic LNIATA 000000. Since the PRC and RO are different physical devices, they are accessed via different hardware subchannel addresses, and therefore require different symbolic line numbers. Up to seven alternate system consoles and seven alternate RO consoles may be defined. See SIP CRASTB macro in TPF System Generation. Both the PRC and RO are supported as model 2 devices (1920 byte buffer), regardless of actual device characteristics, as are all 3270 local devices logged to SMP.
Since the system console is not a hardcopy device, all messages destined for it are duplicated on the system RO, providing the RO is valid. If at any time, the RO becomes invalid and there is no useable fallback RO device, message duplication is bypassed. Messages destined for the RO are not duplicated on the PRC.
The TPF system can survive below 1052 state without an RO. If there is no RO available during restart, the TPF system will not attempt to send any messages to it. Below 1052 state, if an RO is not available, any message destined for the RO will be sent to the PRC instead. However, once 1052 state is reached, all messages destined for the invalid RO will result in CTL-86 system error dumps (invalid line number). At this time, the RO should be replaced with another valid device. See the ZACRS command in TPF Operations.
The 3270 system console screen is formatted in a manner similar (but not identical) to that of CMS running under VM. In particular;
However,
When the IPL program finds it necessary to communicate with the system console, it will first use the SIP defined subchannel addresses. See SIP CRASTB macro in TPF System Generation. The subchannel address of the first device that IPL can successfully talk to is selected as the system console. If none of these devices is operational, IPL will enter an enabled wait state. An attention interrupt generated from any other configured device will cause IPL to select that device as the system console. All communications tables will be built to reflect the selected device as the system console. If the attention interrupt method of console selection is used, the type of device which generates the interrupt must be compatible with the type of console support that is generated in the system. For 3270 native console support, this device must also be on the console control unit. See 3270 Native Console Support. Violation of this constraint will confuse the IPL program, and the IPL will not be successful. For example, on a system generated with 1052 console support, generation of an attention interrupt from a 3270 device in response to IPL's enabled wait state will cause the IPL to be terminated.
During IPL, the 3270 system console screen is formatted as follows:
After IPL successfully selects a system console, it will attempt to duplicate the message sent to it on the system RO. In selecting the system RO, IPL will first use the SIP defined subchannel addresses (reference SIP CRASTB macro). The subchannel address of the first printer that IPL can successfully talk to is selected as the system RO. If none of these devices is operational, the IPL program will send a message to the system console indicating this fact, and the IPL will continue. Message duplication to the RO will therein be bypassed.
Two types of console fallback are supported: automatic fallback and operator initiated fallback.
In the event of a hardware failure detected by the control program on either the system console or the RO console, automatic fallback will be initiated. Fallback is first attempted to the devices specified as alternate consoles at system generation time. These devices are reserved for fallback purposes and can not otherwise be used (unless reconfigured onto different subchannels). If fallback to one of these devices is successful, notification will be sent to the new device; if unsuccessful, the CRAS table (CR0AT) will be searched for an eligible fallback device (see 03-CVKM). For a system generated with 1052 console support, an alternate CRAS CRT is eligible for fallback of the system console only if it has an associated printer. If no fallback device is found, the system is not operational and a system switchover must be performed.
Alternatively, the operator may wish to initiate fallback (for example, to take a console device offline for scheduled maintenance). The ZACRS command provides this capability. For 1052 console support, the alternate console must first be validated (via ZACRS) before it is eligible for fallback. See TPF Operations for information about the ZACRS command.
The system RO provides a hardcopy log of system activity. However, as system activity increases, the RO can become overloaded with the increased message traffic. Also, with the increased message volume, this system log becomes increasingly more difficult to analyze. Functional support consoles (FSCs) were designed to alleviate these problems. They are typically hardcopy alternate CRAS devices which serve as hardcopy logs of a functional area of system activity, and as such may be viewed as a logical extension of the system RO console. Instead of one hardcopy log of system activity, hardcopy FSCs provide the conceptual equivalent of multiple system ROs, each RO collecting output messages for a separate functional area of the system. 3270 local CRTs can also be defined as FSCs; however, with this definition, no hardcopy logs are available for this FSC type.
All commands are associated (via the command editor tables in 03-CSMP) with one or more functional areas. Each functional area corresponds to an FSC. When a command is input to the system, in addition to sending the response to the originator, copies of the input message and the response are sent to the corresponding FSC(s). Unsolicited messages (those not associated with a command) are also sent to the FSC selected by the message sender. Assignment and deletion of FSCs is operator initiated (ZACRS) and may be modified dynamically as dictated by varying levels of system activity. The system RO is the default for all messages destined for an FSC which is not currently assigned. Duplicate messages will never be sent to a single device.
Sixteen FSCs are supported. Each FSC can be referenced by number
(1-16) and/or name (reference macro RTCEQ). Seven FSCs are
currently named as follows:
Number | Name | Description |
---|---|---|
1 | RO | System RO printer |
2 | PRC | System console |
3 | TAPE | Tape console |
4 | DASD | DASD console |
5 | COMM | Communications console |
6 | AUDT | Audit trail console |
7 | RDB | Relational database (TPFAR) messages |
The procedure for the addition of a new name to this list is outlined in Addition Of A New FSC Name.
An IBM Extended Operations Console Facility/2 (EOCF/2) configuration has an automation gateway that connects the TPF system with a token-ring local area network (LAN). The automation gateway consists of a communications gateway or bridge that emulates a 3215 console. The attached LAN consists of primary system console, alternate, and various FSC sessions implemented with automation capabilities on workstations. See Figure 2 for an overview.
Figure 2. TPF System Configuration with IBM Extended Operations Console Facility/2
Except for the Prime and RO CRASs, these LAN CRASs are not defined in the CRAS table. LAN functional consoles receive specific messages because of the functional support console (FSC) routing indicators in an output header that prefixes messages sent to the automation gateway.
The automation gateway attaches a multiple console support header in front of each message coming from the LAN to TPF, and processes the header for each output message going from the TPF system to the LAN. For multiple console support, individual workstations or windows are identified by a console ID in the multiple console support header in the input and output messages. Each multiple console support header begins with the escape character (, MCSESC in LINEQ) followed by the console ID which is 2 EBCDIC hex digits. The console ID ranges from 00 and 0 through mm, 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.) Internally in the TPF system, the console ID is stored in hexadecimal, rather than EBCDIC hex digits, in the TA portion of the LNIATA.
You must ensure that all possible LNIATAs on line X'01' are in the
WGTA table. See TPF System Generation for
detailed information about generating additional UAT entries and the creation
of the WGTA table. Table 1 contains additional information on the console ID. Figure 3 and Figure 4 contain examples of
multiple console support headers.
Table 1. Console ID Information
FSC Type | Console ID (TA) | Comments |
---|---|---|
PRC (Prime CRAS) | 00 (X'00') | If sent to or from the TPF system, this is used to identify the Prime CRAS logical terminal. |
Reserved for future IBM use. | 01 (X'01') | |
RO (Receive Only CRAS) | 02 (X'02') |
|
Other CRAS Workstations | 03-mm (X'03'-X'mm'), where mm is the maximum terminal address specified in your IBM Extended Operations Console Facility/2 configuration. | General Use |
Reserved for future IBM use. | F0-FF (X'F0'-X'FF') |
Notes:
Figure 3 illustrates the format of the input message from an automation gateway to the TPF system. For more information about the maximum terminal address, see the IBM Extended Operations Console Facility/2 System Administrator's Guide.
Figure 3. Example of an Input Message from an Automation Gateway to the TPF System
Where:
Figure 4 illustrates the format of the output message from the TPF system to an automation gateway. For more information about the maximum terminal address, see the IBM Extended Operations Console Facility/2 System Administrator's Guide.
Figure 4. Example of an Output Message from the TPF System to an Automation Gateway
Where:
Possible FSC indicators (as defined in RTCEQ) are identified in the
following table.
Table 2. Possible FSC Indicators as Defined in RTCEQ
FSC Type | FSC Indicator |
---|---|
RO CRAS (Receive Only CRAS) | 8000 |
PRC (Prime CRAS) | 4000 |
Tape | 2000 |
DASD | 1000 |
Communications | 0800 |
AUDT (Audit Trail) | 0400 |
10 additional user-defined functional support consoles | 0200-0001 |
This support allows the operator to control the terminals that are allowed to input critical commands. Commands deemed appropriate for this type of control are defined in different ways and are indicated in the command editor tables (03-CSMP). Modification of these tables is via source update or command. For detailed information, see Modifying the Command Editor Tables. These types of restrictions can be defined for commands:
The remainder of the discussion details the restricted type of authorization. With this support, a CRAS terminal must first be granted authorization before it is allowed to input any message classified as restricted. The system operator may grant or rescind authorization to a specific CRAS terminal dynamically during online operation via the ZACRS command. At system generation time, the system console is authorized to input all restricted messages; authorization is not granted to any other CRAS terminal at this time.
Although message restriction is by message, authorization is by function. The functional classification is equivalent to that of the functional support consoles. Sixteen functional classifications are supported, and once again, these functions may be referred to by number (1-16) and/or by name. The following example may be helpful.
Assume that mounting a tape is a function which is deemed critical to system operation, over which the operator wishes to exercise control. In this example, the ZTMNT command would be defined as restricted in the command editor tables. On the initial IPL of the system, the ZTMNT message would be accepted only from the system console; any attempt to input this message from another CRAS terminal would be rejected. As system activity increases, suppose the system operator becomes very busy and cannot keep up with all the tape requests. At that time, the operator could use the ZACRS message to authorize one or more alternate CRAS terminals to input TAPE messages. After so doing, the authorized CRAS terminals would be permitted to input the ZTMNT message as well as any other restricted message which is classified as a TAPE message. At any time, if the operator again wishes to obtain exclusive control of tape mounts, he can remove the TAPE authorization from any and all alternate CRAS sets which currently have such authorization.
The current CRAS configuration is maintained in the CRAS status table (CR0AT) which resides in keypoint record C (CK8KE). CTKC is a core resident keypoint which is shared by all loosely coupled processors in a TPF-generated with the High Performance Option (HPO) feature. The CRAS table may be displayed or altered during online operation via commands. Successful alteration of the CRAS table will be reflected in the DASD copy of CTKC. Notification of this alteration is sent to every processor in the loosely coupled complex. Upon receipt of this notification, each processor refreshes its core resident copy of CTKC with the latest data.
The current CRAS configuration may be displayed at any time using the ZDCRS command. Displays vary depending on the options chosen on the input message. For more information about the ZDCRS command, see TPF Operations. Unoccupied slots are never displayed. FSCs which are not assigned default to the RO and are only displayed if they have been previously assigned and then deleted.
The ZDCRS command provides the following major functions:
The current CRAS configuration may be altered at any time using the ZACRS command. For more information about the ZACRS command, see TPF Operations. ZACRS provides the following major functions:
Care should be taken when modifying the CRAS table; it is assumed that the user will not request a change to the CRAS configuration that will adversely affect the running of the system. The following restrictions and considerations should be well noted:
Long Message Transmission (LMT) services hardcopy devices, such as 3270 printers and ALC terminals (1977, 1980, and so on), which have hardcopy capability. These ALC terminals may be attached via the Network Extension Facility (NEF). LMT timeout, as it is currently implemented, maintains a counter of the number of timeout intervals (currently defined as 9) which have passed since the last message was sent to a device. This number is the amount of time between activations of the LMT timeout program, XLJJ. When the number of timeout intervals (user specified in bits 4-7 of field XS0OTM in the XS0AA record) has occurred, a timeout is declared and the message is resent. When four consecutive timeouts have occurred without a corresponding answerback received by LMT, a transmission failure is declared, the device is set to an invalid state, and the operator is informed of the failure. If the device is an FSC, the operator will receive the following notification: LMT FAILURE TO FSC ON xxxxxx-QUEUE HELD
To illustrate the situation, consider an example. A 3270 local printer (3284) is being used as the communications (COMM) console, and some hardware error occurs at the device (for example, the plug is pulled out). Suppose a command to start the network is input from an alternate CRAS CRT. In response to this request, many messages will be sent to the originating CRT screen, perhaps faster than the operator can read all of them. The COMM console (which by definition is a hardcopy device) is therefore examined in order to read all the messages. Because it is not operable, no messages appear. If the XS0OTM value has been coded at 10, LMT will wait 90 (9x10) seconds before declaring a timeout and 4 timeouts (360 seconds or 6 minutes) before issuing the message that a failure has occurred. This time could be crucial if any unusual conditions have occurred which require operator notification.
From the above, it can be seen that the values set in the example may be unacceptable to some users with large networks and high message volumes. However, there are considerations to be taken into account when setting these values. The time interval used by LMT timeout multiplied by the number of intervals (XS0OTM) should be greater than the time it will take to print the longest message this device is expected to receive. For example, if the 3284 described above can receive 4K buffer of data and prints at the rate of 60 characters per second, 4096/60 or about 70 seconds are necessary to print all the data and generate an answerback. Any value of XS0OTM which declares a timeout before this physical print time has elapsed, would result in this message being timed out.
It is suggested that the user set the time interval for devices which will be used as functional consoles according to the individual needs of the installation. The information listed above is intended as an aid to assist the user in understanding the process and helping him/her set the values appropriately. If the user changes any of the values described above, he must be aware that the values in XLJJ for timeout intervals and the number of retries is hard coded and used for EVERY terminal LMT supports. Changing a value may seem appropriate for a 3270 local functional console, but may be totally inappropriate for a remote NEF report printer.