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. A CPC is a central processor complex. An instruction-stream engine is simply an I-stream. CPC is synonymous with processor, while an I-stream is a CPU.

z/TPF may utilize any of the z/Architecture® processors when a non-loosely coupled system is desired. A loosely coupled z/TPF system may use any extended architecture processors that have been equipped with the required RPQs. (See z/TPF and z/TPFDF Migration Guide for a summary of supported processors.)

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 z/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.

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.)
  • APRNT–address of the system printer for use during the IPL sequence.
  • VM–whether or not the z/TPF system, normally a test system, is to be run under the control of the VM program product (for example, z/VM®).
  • SYSID–the symbolic z/TPF processor ID(s).
  • PROC1–PROC32: These parameters are coded only when an LC system is required. Each parameter specifies the serial number and the model number for a processor in an LC complex.
Note:
  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, z/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.
Note:
  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.)