gtpi1m5xSystem Installation Support Reference

System Environment Considerations

This section contains global area information that is specific for multiple database function and tightly coupled environments.

Multiple Database Function Environment

Multiple Database Function (MDBF) is a licensed feature that supports multiple, discrete applications on the same processor. It consists of 2 distinct yet related concepts: subsystems and subsystem users. Figure 5 shows such a system.

Figure 5. Global Storage Allocation for a Single I-Stream with 2 Subsystems and 5 SSUs


Subsystems Under the Multiple Database Function

A subsystem (SS) can be thought of as an independent application system that shares certain resources with other subsystems. Each subsystem can use all the control program services and can contain a complete base of application programs. For ease of control, one subsystem, called the basic subsystem (BSS), contains all the system-related software such as the control program and file-resident support programs. The BSS is the only subsystem that can be hardware IPLed.

The subsystem user (SSU) support allows 2 or more users to use the facilities of the same subsystem. Each SSU can maintain a unique global area, or it can share portions of a common global area with other SSUs.

Globals are among the system resources that are subsystem unique. That is, each subsystem can have its own globals, different from those of any other subsystem. In subsystems, global records can be declared to be common or unique among the SSUs making up the subsystem. Since this is such an important function, special attention is given here to declaring and using SSU common globals.

Example

Given the following assumptions:

the following sequence of events occurs:

  1. The records defined for the first SSU of this subsystem are physically stored in the GL3 area, and directory entries are generated during the execution of GOGO. (GOGO is the primary loading segment for globals.)
  2. When the GOA entry for a record for another SSU is processed, instead of physically loading a GL0BP record, GOGO generates only a directory entry that points to the record loaded for the first SSU.
  3. When the application programs of these SSUs need to access the global field @COMMN, the GLOBZ macro with the REGC parameter must be used. This loads the designated register with the GL3 area of the first SSU in the subsystem, thus providing addressability to the common field.

For the reasons just given, SSU-common fields must be defined in GL3 only. SSU-unique fields can be defined in either GL1 or GL3, but, if they are defined in GL3, they must be defined and loaded before any SSU-common blocks. Better yet, define them in GL1 only, leaving GL3 for the SSU-common fields.

Note:
SSU-common or SSU-unique global records can reside in GL1 or GL3.

Design Considerations for Subsystems and SSUs

The following considerations apply:

Tightly Coupled Environment

The tightly coupled (TC) environment supports multiple I-streams in each central processing complex (CPC). One of the I-streams in each CPC serves as the main I-stream, while all other I-streams in the CPC are known as application I-streams. The main I-stream services I/O requests, interrupts, and some control program (CP) services. The application I-streams execute applications and some CP services.

All I-streams in the CPC have the same MDBF configuration. To put it simply, all subsystems (SSs) and subsystem users (SSUs) that exist for one I-stream also exist for the other I-streams.

I-Stream Unique/Shared Globals

The implementation of globals for tightly coupled systems allows great flexibility in the allocation of the global area. Since each I-stream has its own global area, each I-stream can maintain a set of I-stream-unique (ISU) global records that are unique to that I-stream and not addressable from other I-streams. ISU records can be accessed only by the owning I-stream.

I-stream shared (ISS) global records that are shared by all I-streams in a CPC can also be defined. Only global records can be I-stream shared, not global fields. I-stream sharing is allowed in the SSU operating mode for SSU unique records, or in the SS operating mode for SSU shared records. ISS records can be read by any I-stream.

Note:
The application MUST provide its own serialization method for updating ISS records.

See Loading Globals for information on loading ISU and ISS records.

Figure 6 represents the layout of the global areas for a tightly coupled system with 3 I-streams and 2 subsystem users. Unique page and segment tables provide each I-stream with its own view of the global areas.

The main I-stream's view of storage is identical to real memory. Real storage below the 16MB boundary is reserved for an area to contain the I-stream shared global records and for one copy of the I-stream unique globals and global directories. Real storage in high memory is reserved for (n-1) copies of the I-stream unique globals and global directories, where n is the number of I-streams.

Each application I-stream sees its I-stream-unique globals in the unique area below 16MB, even though these globals actually reside in high real memory. Thus, applications dispatched on any I-stream are able to access all of the shared and unique globals they need using 24-bit addresses.

The layout of the extended global areas is unchanged from previous releases of the TPF system. Extended globals are allocated subsystem user in I-stream within global area.

Figure 6. Global Storage Allocation for 3 I-Streams with 1 Subsystem (the BSS) and 2 SSUs


Extended Globals

Extended globals contain global records. They do not contain global directories or global blocks. The extended global area resides above the 16M line and is divided into 3 sections: GL1, GL2, and GL3. There are further sub-divisions in each of these sections. For example, the GL1 area contains a section for each I-stream in the processor, and each of these sections contain a section for each SSU in the complex. There is no separation between I-stream unique and I-stream shared globals. They are both in the same section. The actual definition of the global record (I-stream unique or I-stream shared) is implemented with the pointers to these records which reside below the 16M line inside of the global directories (GL0BA and GL0BY).

Note:
Unlike primary globals below the 16M boundary, each I-stream has the ability to access extended globals of other I-streams.

Notes:

  1. The virtual address of the beginning of the I-stream-shared and I-stream-unique areas is the same on all I-streams. The overall size of an I-stream unique area is the same for all I-streams.

  2. The I-stream-unique primary globals in high memory are all visible on the main I-stream. To ensure that certain system functions, such as critical record filing and ZDCOR/ZACOR, can still access all of main storage.

  3. The global directories reside in the I-stream unique areas. Addresses in the global directories can be used only on the I-stream to which the directories correspond.
    Note:
    The addresses in the directories in high memory for I-streams 2-n have no meaning on the main I-stream.

  4. It follows that application utility programs should not attempt to access an I-stream-unique global on another I-stream without first switching control to the other I-stream (via the SWISC macro). Also, application programs should not pass the address of a global on one I-stream to a program on another I-stream, since the receiving program may have a totally different view of global storage.

Synchronizing Globals in the Tightly Coupled Environment

Sometimes the same global can be loaded into the global area of each I-stream, for example, data residing in a field that can't be I-stream shared, giving it the appearance of an ISU global. Some of these ISU globals that get updated by an application on one I-stream may need to have their updates transmitted to the other I-streams in the CPC. This process is called global synchronization.