gtps4m13System Generation

Keypoint Records

The control program keypoints are a specific set of critical system records located at fixed locations in the online file storage fixed file area. The keypoints use a 4K record size. A copy of each keypoint record is kept on each of the online modules. Keypoint records are updated on file by a system program in the online management of resources and error recovery. These records represent the current status of the system and are fundamental to system generation, system restart and the online operation of the system. Many of the tables contained in the various keypoint records are loaded into the main storage control program records and table area by the initializer program. For additional information on system keypoints and the updating of keypoints, see TPF Concepts and Structures.

SIP creates if necessary, and assembles all the control program keypoint records. Many of the SIP macro parameters provide input to the various keypoints.

The system keypoints are located in the fixed file area defined by the FACE record type #KEYPT, and space for these records is allocated via the RAMFIL statement. #KEYPT is a fixed file record and can be placed on DEVA. Another record type related to #KEYPT is #CTKX. CTKX contains the ordinal numbers of every system keypoint within #KEYPT. This table of keypoint addresses is critical for error recovery and system restart. The user is free to choose which DASD address is used for its location on DEVA. It is ignored if placed on other devices. #KEYPT and #CTKX must have the same duplication as the device duplication.

One keypoint staging area corresponds to each TPF image. The keypoint staging areas are defined by the FACE record type #KSAx, where x is the image number. Keypoints are loaded to an image by writing them to the staging area, where they can then be moved to the physical keypoints (#KEYPT) by issuing the ZIMAG MOVE command. Moving keypoints causes the system keypoints currently in the working keypoint area to be moved into the keypoint backup area. There is 1 keypoint backup area; it is maintained in fixed record area #KBA. Keypoints can be selectively fallen back from this area by entering the ZIMAG KEYPT RESTORE command.

The HPO feature may affect the number of copies which are maintained for a particular keypoint. LC defines keypoints as shared or processor unique. This allows each processor in an LC complex to view a resource, as defined by a keypoint, as either its own or as shared with the other processors in the complex. For example, all information about the status of the shared DASD is located in a shared keypoint.

MDBF defines keypoints as shared or subsystem unique. This allows each subsystem to view a resource defined by a keypoint as its own or as shared with the other subsystems. The MDBF shared keypoints are located in the basic subsystem (BSS). For example, all of the keypoints concerning communications are shared.

It should also be noted that in a loosely coupled complex each processor performs the keypoint copy function independently and it takes into account processor-unique keypoints and shared keypoints described above.

The keypoint copy function is also activated for each subsystem of a MDBF user sequentially and it takes into account subsystem-unique keypoints and shared keypoints. The restart area and the keypoints are applicable for each subsystem and as a result there is an area for each subsystem located on its independent database. A subsystem, other than the BSS, may not be IPLed until the BSS is IPLed since certain records only exist within the core image area of the data base of the BSS. In addition, an MDBF user has the option at generation time to provide the ability to also keypoint the fallback area on the prime module, if desired.

A complete list of the control program keypoint records follows. This summary includes a brief description of the contents of these records. Note that the title of the keypoint (for example, CTKA) is not the same as the data macro corresponding to the keypoint (CK1KE). Data macros declare the names of the fields within the keypoints. They reside in the released control program macro library indicated. Whether keypoints are unique for loosely coupled or MDBF systems is also indicated.

Table 5. Control Program Keypoints

Keypoint Macro Name Function Processor SS Initialized By Residency Demand Keypointable
Record A (CTKA) CK1KE Contains information required for system loading and for the initializer program. Unique Unique SIP File No
Record B (CTKB) CK9KC Miscellaneous initialization and restart values, for example, clock status, VFA status, and DASD error thresholds. Unique Unique SIP Main storage Yes
Record C (CTKC) CK8KE Status of Computer Room Agent Set (CRAS) attached terminals, initial Routing Control Application Table (RCAT) and Terminal Address Table (WGTA) control information. Shared Shared SIP Main storage No
Record D (CTKD) CK7KE Status used by the synchronous link programs. Unique Shared SIP Main storage Yes
Record E (CTKE) CK6KE Describes the non-SNA communications network. Unique Shared SIP File No
Record I (CTKI) IC0CK Describes the status of all processors in a loosely coupled complex of the HPO feature. Shared Shared SIP File No
Record M (CTKM) MK0CK Describes the status of each subsystem and each subsystem user. Shared Shared SIP Main storage No
Record V (CTKV) IDSCKV Contains volume serial number ranges for the online modules, the copy module, and the loader general file. Shared Unique SIP File No
Record 0 (CTK0) CK0KE Contains legal disk hardware addresses. Shared Shared SIP File No
Record 1 (CTK1) CK2KC Contains the Tape Status Table (TSTB). Unique Shared N/A Main storage Yes
Record 2 (CTK2) CK2SN Contains all the information in the system about the SNA configuration and the TCP/IP device parameters. Unique Shared Source, contains no SIP provided inputs Main storage No
Record 3 (CTK3) None This keypoint is available for customer use. Unique Shared Customer File No
Record 4 (CTK4) VK4CK This keypoint is available for customer use. Shared Unique Customer File No
Record 5 (CTK5) None This keypoint is reserved for IBM use. Shared Shared N/A File No
Record 6 (CTK6) CJ6KP Contains the DASD module status indicators. Shared Unique SIP File and main storage (see note 1) No
Record 9 (CTK9) CY1KR Contains the status of the DASD pools. Shared Unique Source, contains no SIP provided inputs Main storage No
Note:
  1. The entire keypoint is file-resident; the first section of the keypoint is also main-storage-resident.
  2. Processor shared means that there is one copy of the keypoint for all processors in a loosely coupled environment.
  3. Processor unique means that there is one copy of the keypoint per processor in a loosely coupled environment.
  4. Subsystem (SS) shared means that there is one copy of the keypoint residing in the BSS in an MDBF environment.
  5. Subsystem (SS) unique means that there is one copy of the keypoint per subsystem in an MDBF environment.

Use the following method to determine the number of #KEYPT records needed by each device type in your configuration. This method shows you how to automate the calculation using SIP.

SIP calculates the number of records required for each device type.

  1. Code all of your SIP stage I.
  2. Code #KEYPT with any number of records.
  3. Run the FACE table generator.
  4. If the number of #KEYPT records is too small, the FACE table generator produces an error message that tells how many records are needed.