gtps4m0nSystem Generation

Processor Definition

For the purpose of this discussion, the term processor means any system comprised of 1 or more central processing units (CPUs). A CPU is a device capable of executing a program contained in main storage. With the introduction of tightly coupled processor support, two new terms have been introduced. The first is CPC (central processing complex). The second is instruction-stream engine (or simply, I-stream). CPC is synonymous with processor, while an I-stream is a CPU.

TPF may utilize any of the enterprise systems architecture (ESA) processors when a non-loosely coupled system is desired. A loosely coupled TPF system may use any extended architecture processors that have been equipped with the required RPQs. (See TPF Migration Guide: Program Update Tapes for a summary of supported processors and RPQs.)

As many as 32 processors can may be connected together using the loosely coupled (LC) facility of the HPO feature. Each processor runs a separate image of TPF, but all processors share the same database. See Loosely Coupled Complexes for an additional explanation of LC.

Some multiprocessor models are partitionable. Such a processor may be used either as a single integrated processor, or as independent processors.

If you decide to use both processor partitions in the same loosely coupled complex, and clock synchronization is being handled either through the TPF TOD RPQ or the Sysplex Timer (STR) with a TSC then each logical processor requires a unique Time-of-Day (TOD) Synchronization Selection Address (SSA). (See CONFIG for information on how to code SSAs.) Systems using STR without the TOD RPQ or TSC do not use SSAs. A unique SSA is required because each partition is considered to be a separate processor. There is a maximum of 8 SSAs, one for each of the first 8 processors in the LC complex. Additional processors beyond the first 8 should not be assigned an SSA value.

The number and types of channels and control units, and the number and types of I/O devices, are determined during the design of the system. SIP provides the CONFIG and IODEV macros to describe the processor and channel characteristics, respectively.

The following parameters of the SIP CONFIG (processor configuration) macro relate to processor support. (For more information about the CONFIG macro, see CONFIG.)

Notes:

  1. Many of the required initialization parameters in this section are associated with a SIP parameter. SIP parameters are indicated where appropriate, with the SIP parameter given in parentheses preceding or following the macro name. For example:
    SIP Input = (SYSID) CONFIG, or CONFIG (SYSID)
    

    Means:

    SYSID is a parameter used within the SIP macro CONFIG.
    

  2. For users of the LC facility, multiple symbolic processor IDs are specified via the SYSID parameter, one for each of the processors in the LC complex.

In addition to the hardware TOD clock, TPF provides for software clocks which are available to application programs. For users of MDBF in the HPO feature each subsystem is allowed to have its own version of these software clocks. Each subsystem's clock values are calculated using the hardware TOD clock. Non-MDBF users are treated similarly to a BSS in an MDBF system.

These software clocks are located in low memory. Keypoint record A (CTKA) contains the subsystem's local standard time difference from Greenwich Mean Time (GMT). Keypoint record B (CTKB) contains the subsystem's local standard time (LST), the subsystem's GMT, and the subsystem's perpetual minutes clock. There is a copy of these keypoints for each subsystem defined at system generation.

SIP macro parameters that relate to the software system clocks (CLOCKS) are as follows:

GDIF
System clock LST minus GMT.

LST
Precycle above 1052 state LST of system clock in EBCDIC.

DATE
Precycle above 1052 state date of the system clock.

DELTIM
Initial system time difference from the system clock.

Notes:

  1. Precycle above 1052 state means the value to be used by the subsystem prior to cycling the subsystem above 1052 state at which time the system operator can change the value using commands.

  2. The MDBF user will have to code multiple CLOCKS macros, one for each subsystem. The non-MDBF user only codes one CLOCKS macro. This technique of providing different user values by subsystem in a MDBF generation is the standard one used by SIP as is the concept of only coding one version of a given macro in a non-MDBF environment.

Support for the generation of multiple subsystems, each with its own database (DASD devices), is provided by the multiple database function (MDBF) of the HPO feature. There can be a maximum of 64 subsystems, including the basic subsystem (BSS). Generation of an MDBF system is indicated by coding the SSDEF SIP macro. (For more information about the SSDEF macro, see SSDEF.)