gtpd2m0jData Communications Services Reference

General Description

Device Support

The following devices are eligible for use as CRAS devices:

1052/3215
Printer Keyboard

1053/1980
Printer (Output Only)

PS/2
Installed with the IBM Extended Operations Console Facility/2 (EOCF/2)

1977
Typewriter Terminal

4505/2915
CRT Terminal

3270
CRT Terminal (Local, BSC, and SDLC)

3284/3286
Printer (Output Only) (Local, BSC, and SDLC)

3278
CRT Terminal (Local, SDLC).
Note:
To use this terminal as a local device, define it as a 3277.

3287/3289
3287/3289 Printers (SDLC)
Note:
For detailed information on EOCF/2, see the IBM Extended Operations Console Facility/2 System Administrator's Guide.

System Console Support

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.

1052/3215 Console Support

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:

3270 Native Console Support

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,

Selection of the System Console During IPL

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:

Selection of the System RO During IPL

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.

Console Fallback

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.

Functional Support Consoles

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
Note:
Although the capability exists for remote 3270 CRTs to be defined as FSCs, the TPF system does not support this environment because of long message processing (scrolling package) requirements.

The procedure for the addition of a new name to this list is outlined in Addition Of A New FSC Name.

IBM Extended Operations Console Facility/2

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.

Multiple Console Support

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')
  • This console ID is considered to be the RO CRAS for this TPF system. This console ID should never be sent by the automation gateway, but, if it is, the TPF system processes it as though it was any other console ID.
  • The automation gateway considers that the RO CRAS is also the soft copy log. In other words, there is no actual screen or printer designated as RO CRAS.

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:

  1. If there is no multiple console support input header on a message from LN 01, the message is routed to the Prime CRAS.

  2. Except for the Prime and RO CRASs, the LAN CRASs on line number 01 are not defined in the CRAS table.

  3. For additional information on the maximum terminal address, see the IBM Extended Operations Console Facility/2 System Administrator's Guide.

Multiple Console Support Header Examples

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:

xx
EBCDIC hexadecimal digits ranging from 00 and 02 through the maximum terminal address specified in your IBM Extended Operations Console Facility/2 configuration.

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:

xx
TA converted to EBCDIC hexadecimal digits ranging from 00 and 02 through the maximum terminal address specified in your IBM Extended Operations Console Facility/2 configuration.

bbbb
EBCDIC hexadecimal digits representing functional support console (FSC) indicators used to route messages to specialized consoles. Multiple FSC indicators can be set.

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

Input Message Restrictions

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.

Note:
The ZACRS command is critical to this control, and should be defined as restricted. Authorization to input this message should be restricted to the system console (PRC).

Alteration/Display Of Current CRAS Configuration

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.

Displaying the CRAS Table

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:

Altering the CRAS Table

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:

Operational Restrictions/Considerations

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: