gtpd1m0tDatabase Reference

Management Functions

File pool management functions are supported by the following facilities designed to enhance file pool processing:

These facilities are described in the following sections.

Get File Storage (GFS)

Application programs issue the get file storage macros to obtain large or small file pool records respectively. The following sections describe the functions available in the processing of these macros.

Basic Pool Selection

Selection of a pool section is normally based on the get file storage macro expansions. Pool fallback and ratio dispensing fallback can modify normal pool selection as described in the following sections. See TPF General Macros for more information about the file storage macros.

Pool Fallback

When a depleted pool section is selected for address dispensing, an alternate compatible pool section is used if possible. The appropriate GFS program is started for processing the alternate pool section.

Selection of alternate pool sections for fallback processing is done based on either a specified or predefined schedule. Systems with pools have predefined schedules for short-term pool section fallback. These predefined schedules refer to duplicate pool sections only. Therefore, a system with pool sections has no predefined short-term to short-term pool fallback. However, optional, primary pool fallback schedules can be defined for systems with pool sections. If specified, these optional schedules can provide short-term to short-term, short-term to long-term, or long-term to long-term fallback capability for depleted pool sections.

The optional fallback can be specified in the SYCON macro or by a ZGFSP command. See TPF Operations for more information about the ZGFSP command.

Ratio Dispensing

This facility is used to dispense addresses for any basic pool type using several sections of the pool (for example, 3390 SSTA pool sections). When a pool section is selected, its ratio factor (that is, number of addresses) is used to determine how many addresses to dispense from that section before selecting another pool section from the schedule. Therefore, ratio dispensing allows any specific record ID (pool record) to be spread across several device types.

Bit Scanning

The GFS programs process each bit in a directory as an entity although groups of bits are selected for ease of processing.

Dispensing Algorithms

Dispensing of file pool addresses is based on the pattern of available bits (records) in the directory records. With all bits in available status, the following describes the GFS algorithm.

Pool addresses are dispensed across all pertinent modules by increasing the ordinal by 1 because each ordinal is a continuous number.

Directory Replenishing

Multiple directory records are generated for each pool section. Directory replenishing (or reordering) for short-term pool sections generally consists of scheduling retrieval of a new directory set before the in-use directory set is depleted of available addresses. This is done when the remaining number of available addresses in the in-use directory set reaches a predefined critical level called the reorder level. At this point, a control transfer is used to schedule an ECB and the retrieval of a directory reorder program to perform this function.

The short-term pool sections are designed to be recycled. Therefore, when the last directory set of such a pool section is depleted, the first directory of the pool section set is again set up for dispensing pool records with all bits in available status.

For long-term pool sections, two sets are maintained in main storage. These sets are referred to as the active and the standby sets. When the active set is depleted, the standby set becomes active and a control transfer is used to schedule a reorder of the depleted set.

Implied Wait Processing

When a depleted directory is referred to in order to satisfy a get file storage macro request, the requesting program is placed in a CPU Loop queue to delay processing of the request. The get file storage macro is processed again when the program is again given control by the CPU Loop program.

This implied wait procedure is linked to pool sections that require directory reorder support. The procedure is enforced to allow retrieval of a new directory to replace an empty in-use directory.

GFS Keypointing

Each pool section is assigned a counter to determine when a file update of critical keypoint information should be done. After an address is dispensed from a pool section, the keypoint update counter of that pool section is checked. If a keypoint update is necessary, a keypoint procedure is started. The respective keypoint update counters are also reset.

Module Down Processing

GFS does not dispense pool addresses referring to disk modules in down or offline status. One of the following techniques is used to recognize the condition and allow dispensing to continue until a pool address is found that can be dispensed:

Release File Storage (RFS)

Application programs issue the release file storage macro to release file pool records. The processing done by RFS is based on whether the record is long-term or short-term.

Processing Long-Term Released File Pool Addresses

Long-term releases are blocked into CYSRB tape records. These tape records are written to the real-time tape (RTA).

Processing Short-Term Released File Pool Addresses

Released short-term addresses are returned directly to the respective directory if it is part of a set in main storage and being used by GFS for address dispensing.

RFS Keypointing

RFS performs keypointing procedures similarly to GFS for released short-term pool addresses only. Each short-term address that is returned to its respective directory causes the relevant keypoint update counter to be checked as described previously for GFS keypointing.

Initialize File Pools

Initialization for pool management is done during CP initialization, restart processing, and cycle-up. During CP initialization, the main storage ICY7PRs are carved out of the permanent main storage area for each pool section existing in the system. Pointers to these areas are initialized. Following restart processing, the system is in 1052 state with pool management still inactive though partially initialized. Pool management is inactive in 1052 and UTIL state. During cycle-up to CRAS state or higher, the pool management facilities are initialized. At this point in time, all pool management facilities are available for use by application programs.

Shutdown of File Pools

All pool management facilities are shut down (that is, inactivated) during and as the last step of cycle-down. The file copies of each in-use directory are updated, the last CYSRB records are written to tape, and all keypoints are updated to reflect a planned shutdown of the pool complex. A system re-IPL or cycle-up must follow a cycle-down to again reactivate pool management.

Pool Function Switches

A switch is assigned to each major pool function to indicate if a function is active. This is important because:

The file pool maintenance and initialization scheduler sets all but the recoup switch, which is set by recoup as needed. The PFSWC macro is used by the individual functions (that is, programs supporting the function) to reset a switch. This macro also defines the switches that are located in field CY5PFS of the pool management global table (CY5GT). You can use a CINFC CMPFSW macro to obtain the address of the switches.

Pool Management Commands

Some pool management functions are controlled with commands. All file pool commands are transferred to the file pool maintenance and initialization scheduler for initial processing. When started in 1052 or UTIL state, this scheduler will normally force a pool management cycle-up and cycle-down sequence to perform initialization generally required for these functions even when pool management is not active. Bypass options are provided to avoid this special initialization procedure for reconciling pool counts and, optionally, for recoup functions.

The following list shows the pool management commands with a brief description of each. See TPF Operations for more information about these commands.

ZDFPC
Allows you to display the count of all available file pool addresses. You can display the counts for a specified device or pool type. In addition, you can display pool counts on a time-initiated basis.

ZGFSP
Allows you to do the following miscellaneous file pool functions:

The monitoring function is a GFS function that allows you to monitor long-term pool activities. Start monitoring by entering ZGFSP OPT with the MON parameter.

The pool monitor starts in all NORM state processors in a loosely coupled environment. If the monitor is active when a processor cycles to NORM state, the function automatically starts in this processor. The monitor in each processor analyzes pool usage for its processor only. At 1-minute intervals, the pool monitor checks the pool usage for each long-term pool section in the subsystem and displays the appropriate message as follows:

See Messages (System Error and Offline) and Messages (Online) for more information.

ZGAFA
Allows you to get a file pool address.

ZGAFI
Allows you to get a file pool address by record ID.

ZPMIG
Allows you to do the following 32-way loosely coupled pool support functions:

You can enter this command only from a processor where 32-way loosely coupled pool support is installed and active, and only when the processor is in 1052 state or higher.

See TPF Migration Guide: Program Update Tapes for more information about migrating to 32-way loosely coupled pool support and converting pool data structures to 32-way loosely coupled pool support format.