gtps4m13 | System Generation |
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 |
|
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.