gtpm2m2yMigration Guide: Program Update Tapes

32-Way Loosely Coupled Pool Support (APAR PJ27686)

The following section discusses the migration considerations for 32-way loosely coupled pool support.

Prerequisite APARs

See the APEDIT for APAR PJ27686 for information about prerequisite APARs.

Functional Overview

The goal of 32-way loosely coupled processor support is to provide the additional capacity you need to support application workload growth. 32-way loosely coupled pool support is one of several steps toward this goal. In this deliverable, all 8-way constraints in the pools area are removed. 32-way loosely coupled pool support provides the following:

Note:
32-way loosely coupled pool support does not remove the constraint of a maximum of 8 loosely coupled processors. Additional functions are required to complete 32-way loosely coupled processor support.

These changes and enhancements are discussed in more detail in the following sections.

Pool Data Structures

The following pool data structures have moved to different storage locations or have been given a new format:

To support the restructuring of the pool data structures, the following additional fixed file record types are provided:

#CY2CPY
During a recoup run or when the ZDDIR command is entered, the pool section keypoint tables (CY2KTs), keypoint 9 (CTK9), and the pool directories are stored in fixed file records. The CY2KTs are stored in the #CY2CPY fixed file record type. The copy of keypoint 9 that corresponds to the #CY2CPY record type is kept in the #IBMM4 fixed file record type, ordinal #KY9CPY1. #CY2CPY is a 4-K processor shared fixed file record type with a minimum of 48 ordinals (1 ordinal for each pool section plus ordinals for pool expansion).

#CY2KT
The pool section keypoint table, or CY2KT record, was previously contained in keypoint 9. While part of CY2KT remains in keypoint 9, most of the record is now in #CY2KT, a 4-K processor shared fixed file record type. A total of 48 ordinals must be allocated for the #CY2KT fixed file record type (1 ordinal for each pool section plus ordinals for pool expansion). Pool sections are assigned ordinals in the same order as their corresponding CY2KT records appear in keypoint 9.

#CY2NEW
During pool generation and reconfiguration, the pool section keypoint tables (CY2KTs) are built in the #CY2NEW fixed file record type. The CY2KTs are later transferred to the #CY2KT fixed file record type. The copy of keypoint 9 that corresponds to the #CY2NEW record type is kept in the #IBMM4 fixed file record type, ordinal #KPT9NEW. #CY2NEW is a 4-K processor shared fixed file record type with a minimum of 48 ordinals (1 ordinal for each pool section plus ordinals for pool expansion).

#STPUR
The short-term processor unique records (control and data records) reside in #STPUR, which is a 4-K, processor unique record type. These records were previously kept in the #STPCR record type. Currently, n ordinals are allocated for the #STCCR fixed file record type, where n is related to the number of short-term directories allocated. For each processor, n #STPUR ordinals must be allocated.

Once migration and conversion to 32-way loosely coupled pool support is completed, and there is no requirement to fall back to pool expansion (PXP) support, you can delete the following record type:

#STPCR
The short-term processor unique records (control and data records) were previously found in the #STPCR record type.

Once the #STPCR fixed file record type is deleted, fallback is no longer possible and the pool data structures cannot be converted back to PXP format. See Migration, Coexistence, and Conversion for more information about migration and conversion considerations.

See Architecture for more information about the pool data structures and fixed record types. Also see TPF System Generation for more information about record types.

ECB-Type User Exits and Pool Data Access

User exits Rearrange_CTK9, Dearrange_CTK9, Get_CY$CR, and File_CY$CR were first introduced with PXP support and provide user access to the pool data structures when they are retrieved or filed by the TPF 4.1 system. These user exits are being reused by 32-way loosely coupled pool support. You must examine your TPF 4.1 system and determine if you must modify your user exits to accommodate 32-way loosely coupled pool support.

The Get_CY$CR and File_CY$CR user exits have been renamed to Find_STCCR and File_STCCR.

The following ECB-type user exits are provided by 32-way loosely coupled pool support:

Rearrange_CTK9
The Rearrange_CTK9 user exit, UPX0, allows you to perform accounting or other activities when the TPF 4.1 system retrieves keypoint 9 through the CYYM interface. This user exit also provides a mechanism for you to provide your own function to convert keypoint 9 from its current format to 32-way loosely coupled pool format or to a compatible user-defined format. The Rearrange_CTK9 user exit is called by the Rearrange_CTK9 function in CYH0.

Dearrange_CTK9
The Dearrange_CTK9 user exit, UPX1, allows you to perform accounting or other activities when the TPF 4.1 system files keypoint 9 through the CYYA interface. This user exit also provides a mechanism for you to provide your own function to convert keypoint 9 from its current format in storage to PXP format or a compatible user-defined format. The Dearrange_CTK9 user exit is called by the Dearrange_CTK9 function in CYH1.

Find_STCCR
The Find_STCCR user exit, UPX2, allows you to perform accounting or other activities when the TPF 4.1 system retrieves a short-term common control record (STCCR). This user exit also provides a mechanism for you to provide your own function to convert the STCCR from its current format to 32-way loosely coupled pool format or a compatible user-defined format. The Find_STCCR user exit is called by the Find_STCCR function in CYH2.

File_STCCR
The File_STCCR user exit, UPX3, allows you to perform accounting or other activities when the TPF 4.1 system files a short-term common control record (STCCR). This user exit also provides a mechanism for you to provide your own function to convert the STCCR from its current format in storage to PXP format or a compatible user-defined format. The File_STCCR user exit is called by the File_STCCR function in CYH3.

Find_CY2KT
The Find_CY2KT user exit, UPX6, allows you to perform accounting or other activities when the TPF 4.1 system retrieves a pool section keypoint table (CY2KT). This user exit also provides a mechanism for you to provide your own function to convert CY2KT from its current format to 32-way loosely coupled pool format or a compatible user-defined format. The Find_CY2KT user exit is called by the Find_CY2KT function in CYH6.

File_CY2KT
The File_CY2KT user exit, UPX7, allows you to perform accounting or other activities when the TPF 4.1 system files a pool section keypoint table (CY2KT). This user exit also provides a mechanism for you to provide your own function to convert CY2KT from its existing format to PXP format or a compatible user-defined format. The File_CY2KT user exit is called by the File_CY2KT function in CYH6.

For a user-defined PXP format or 32-way loosely coupled pool format to be compatible with the TPF-supplied default format, the user-defined format must not change any names or properties (data type, length, or word boundary requirements) for any data fields defined in the TPF-supplied DSECT.

To support coexistence of processors running both PXP support and 32-way loosely coupled pool support in the same loosely coupled complex, you must use the pool access functions provided as part of 32-way loosely coupled pool support to access pool data structures in your code. These functions determine the format of the pool data structures on DASD and the format being used by the requesting processor. The appropriate format conversions are performed as the data is retrieved from DASD and presented to the processor or filed back to DASD from the processor. The following pool access functions are provided:

See TPF System Installation Support Reference for more information about user exits and see Pool Access Functions for more information about pool data access.

Migration, Coexistence, and Conversion

The migration strategy for 32-way loosely coupled pool support allows you to move from PXP support to 32-way loosely coupled pool support over time without having to take down your loosely coupled complex. You can install and IPL 32-way loosely coupled pool support on a processor and have that processor coexist with other active processors in the complex that are still running from an image using PXP support.

When all processors in the complex have been migrated to 32-way loosely coupled pool support, you convert the pool data on DASD from PXP format to 32-way loosely coupled pool format by using the ZPMIG command.

As long as the pool data on DASD remains in PXP format, you can IPL any of the processors in the complex with either a 32-way loosely coupled pool image or a PXP image. Once you have converted the pool data structures on DASD to 32-way loosely coupled pool format, all the active processors in the complex must operate from a 32-way loosely coupled pool image.

The pool generation and reallocation procedure can only be used if all processors in the complex are running 32-way loosely coupled pool support and the pool data structures on DASD have been converted to 32-way loosely coupled pool format. See TPF Database Reference for more information about the pool generation and reallocation procedure.

See Migration Scenarios for more information about migrating to 32-way loosely coupled pool support.

ZPMIG--Migrate Pool Structures

This command was initially introduced with PXP support to convert pool data structures from the previous pool format to PXP format. It has been modified for 32-way loosely coupled pool support to do the following:

The ZPMIG command uses the conversion mode indicator in keypoint 9. This indicator has the following settings:

PXP
The pool data structures on DASD are in PXP format.

CONVERTING
The processor complex is in the process of converting the pool data structures on DASD from PXP format to 32-way loosely coupled pool format.

FALLING_BACK
The processor complex is in the process of converting the pool data structures on DASD from 32-way loosely coupled pool format to PXP format.

32LC
The pool data structures on DASD and in storage are in 32-way loosely coupled pool format.

See TPF Operations for more information about the ZPMIG command.

Architecture

In the 32-way loosely-coupled environment, all data structures are changed to support as many as 32 loosely coupled processors. To accommodate 32-way loosely coupled processors, several tables in keypoint 9, the pool section keypoint tables (CY2KTs), and the short-term common control records (STCCRs) are expanded. This expansion causes keypoint 9 to exceed its 4-K size limit, so the CY2KT tables are moved from keypoint 9 to their own fixed file record type. A small part of each CY2KT remains in keypoint 9 to accommodate critical paths such as the get and retrieve file support function (GRFS).

While the format of the short-term processor control records (STPCRs) does not have any 32-way constraints, the layout of the STPCRs in the #STPCR fixed file record type is limited to 8 processors. As a result, the STPCRs and associated data records are moved to a new processor unique fixed file record type.

Changed Record Structures

The following record structures have been changed:

CY0PD
The format of the CY0PD record structure is changed to accommodate the addition of future pool types. The CY0PD DSECT is provided with two expansions: one for PXP format and another for 32-way loosely coupled pool format. The 32-way loosely coupled pool support expansion is the default.

CY1KR
To make more room in keypoint 9, many of the fields from the CY2KT are removed from the CY1KR and placed in their own fixed file record type. The set size fields are moved from the CY1KR into the CY2KT. The CY1KR DSECT is provided with two expansions: one for PXP format and another for 32-way loosely coupled pool format. The 32-way loosely coupled pool support expansion is the default.

CY2KT
Each CY2KT entry in keypoint 9 (currently there are 36, one for each pool section) is moved to the #CY2KT fixed file record type. Each CY2KT is assigned an ordinal in #CY2KT as shown in Table 1064.

The CY2KT DSECT has the following expansions:


Table 1064. CY2KT Table Ordinal Assignments in #CY2KT

Ordinal 0 1 2 3 ... 33 34 35 36 - 47
Pool Section RCC 04 08 0C 10 ... 88 8C 90 94 - C0
Pool Section SLT-A SST-A SDP-A LLT-A ... 4LT-D 4ST-D 4DP-D Future Pool Sections

CY$CR
The CY$CR record structure maps the short-term common control records (STCCRs). The CY2KT that was embedded in CY$CR is removed. New fields are defined in CY$CR to replace the few fields from CY2KT that were also used in CY$CR. The CY$CR DSECT is provided with two expansions: one for PXP format and another for 32-way loosely coupled pool format. 32-way loosely coupled pool support expansion is the default.

ICY$PR
The ICY$PR record structure maps the STPCRs and associated data records. The records are moved to a different fixed file record type. The ICY$STA field, which contains status indicators, is no longer required and is removed from the record.

Pool Access Functions

To support the migration and conversion strategy discussed in Migration, Coexistence, and Conversion, processors that are operating with a TPF image containing 32-way loosely coupled pool support (migrated processors) access the pool data structures through a set of access methods. These access methods read the pool data structures from DASD and convert them to 32-way loosely coupled pool format for use by the migrated processors. When a migrated processor needs to file a pool data structure to DASD, the access method returns the pool data structure to the PXP format before writing the pool data back to DASD.

The following functions are provided to access the pool data structures:

See TPF System Installation Support Reference and the TPF 4.1 system source code for more information about accessing and filing these pool data structures and for detailed information about function interfaces and data record formats.

Operating Environment Requirements and Planning Information

There are no changes.

Interface Changes

The following section summarizes interface changes.

C/C++ Language

The following section summarizes C/C++ language changes. This information is presented in alphabetic order by the type of C/C++ language information. See the TPF C/C++ Language Support User's Guide and TPF Application Programming for more information about the C/C++ language.

Build Scripts

There are no changes.

Dynamic Load Module (DLM) Stubs

There are no changes.

General Use C/C++ Language Header Files

Table 1065 summarizes the general use C/C++ language header file changes. This information is presented in alphabetic order by the name of the general use C/C++ language header file.

General use means these header files are available for your use.

Table 1065. Changes to General Use C/C++ Language Header Files for 32-Way Loosely Coupled Pool Support

C/C++ Language Header File ISO-C New, Changed, or No Longer Supported? Do You Need to Recompile Segments?
c$cy1k.h X Changed Yes
c$fva0.h X Changed No

Implementation-Specific C/C++ Language Header Files (IBM Use Only)

Table 1066 summarizes the general use C/C++ language header file changes that are for IBM use only. This information is presented in alphabetic order by the name of the general use C/C++ language header file.

Table 1066. Changes to Implementation-Specific C/C++ Language Header Files (IBM Use Only) for 32-Way Loosely Coupled Pool Support

C/C++ Language Header File (IBM Use Only) ISO-C New, Changed, or No Longer Supported? Do You Need to Recompile Segments?
i$breq.h X Changed No

Library Interface Scripts

There are no changes.

Library Members (Object Files)

There are no changes.

Link-Edited Modules

Table 1067 summarizes changes to the link-edited modules shipped by IBM, which should go into a data set with attributes DCB=(RECFM=U,LRECL=80,BLKSIZE=1200). This information is presented in alphabetic order by the name of the link-edited module.

Table 1067. Changes to Link-Edited Modules for 32-Way Loosely Coupled Pool Support

Link-Edited Module New, Changed, or No Longer Supported? Description of Change
CPS0 Changed Changed CSECTs CCCTIN and CCDBAF.

Members (Object Files)

There are no changes.

Object Code Only (OCO) Stubs

There are no changes.

Configuration Constant (CONKC) Tags

There are no changes.

Control Program Interface (CINFC) Tags

There are no changes.

Copy Members

Table 1068 summarizes the copy member changes. This information is presented in alphabetic order by the name of the copy member.

Table 1068. Changes to Copy Members for 32-Way Loosely Coupled Pool Support

Copy Member Type CSECT Where Copy Member Is Located DLM Where CSECT Is Located New, Changed, or No Longer Supported? Description of Change
CAAA Control Program CCNUCL Not Applicable Changed Removed comments listing CT55 in control program table of contents.
CTIN Control Program CCCTIN Not Applicable Changed Modified keypoint 9 retrieval and pool storage carve and removed invocation of CT55.
CT01 Control Program CCCTIN Not Applicable Changed Minor changes for keypoint 9 migration support.
CT10 Control Program CCCTIN Not Applicable Changed Modified keypoint 9 retrieval and pool storage carve for 32-way loosely coupled pool support.
CT55 Control Program CCCTIN Not Applicable No Longer Supported Pool storage initialization moved to restart segment CYGR. CCCTIN must be reassembled, and link edit module CPS0 must be relinked.
GRFS40 Control Program CCSONP Not Applicable Changed Changed the reference from CY1NEW to CY2NEW.

Fixed File Records

Table 1069 summarizes fixed file record changes. This information is presented in alphabetic order by the name of the fixed file record.

Table 1069. Changes to Fixed File Records for 32-Way Loosely Coupled Pool Support

Fixed File Record New, Changed, or No Longer Supported? Description of Change
#CY2CPY New Contains the pool section keypoint tables (CY2KTs) during a recoup run or when the ZDDIR command is entered.
#CY2KT New Contains parts of the pool section keypoint table (CY2KT) that were moved from keypoint 9.
#CY2NEW New Contains pool section keypoint tables (CY2KTs) during pool generation and reconfiguration.
#STPCR No Longer Supported No longer required after pool data structures on DASD are converted to 32-way loosely coupled pool support; replaced by #STPUR.
#STPUR New Contains short-term processor unique control records; replaces #STPCR.

Macros

The following section summarizes the macro changes. This information is presented in alphabetic order by the type of macro.

Advanced Program-to-Program Communications (APPC) Macros

There are no changes.

Communication Macros and Statements

There are no changes.

Data Macros

Table 1070 summarizes the data macro changes. This information is presented in alphabetic order by the name of the data macro.

Table 1070. Changes to Data Macros for 32-Way Loosely Coupled Pool Support

Data Macro New, Changed, or No Longer Supported? Do You Need to Reassemble Programs Using This Data Macro? Programs to Reassemble
CFMDC Changed Yes ICDF, additional programs included in Table 1074
CY$CR Changed Yes Programs included in Table 1074
CY0PD Changed Yes DYD2, additional programs included in Table 1074
CY1KR Changed Yes BCPU, BCP1, BDBP, BOFB, BPDH, BRCQ, BRPB, BRTV, BRYA, BRYD, BRYU, B1A5, CYAA, CYD0, CYD1, CYD2, CYD3, CYE2, CYF0, DYDI, DYDK, DYDU, DYD1, DYD2, DYD4, DYD6, DYD8, JCS0, additional programs included in Table 1074
CY2KT Changed Yes BCP1, BDBF, BDBL, BDBP, BOFB, BRPB, BRYU, B1A5, CYD2, CYE2, DYDK, DYDU, DYD4, additional programs included in Table 1074
CY5GT Changed Yes BCPE, BCPU, BCP1, BDBA, BDBF, BDBL, BKC1, BKP5, BOFK, BOF8, BRCQ, BRV3, BRYU, CDCR, CYD0, CYD1, CYD2, CYE2, CYF0, CYF6, DYDE, DYDI, DYDN, JCS0, additional programs included in Table 1074
ICY$PR Changed Yes Programs included in Table 1074
ICYCWB Changed Yes CYA9, additional programs included in Table 1074
ICY7PR Changed No Not Applicable
IFMRBK Changed Yes CYFM, additional programs included in Table 1074
IRECBK Changed Yes Programs included in Table 1074

General Macros

There are no changes.

Selected Equate Macros

Table 1071 summarizes the selected equate macro changes. This information is presented in alphabetic order by the name of the selected equate macro.

Table 1071. Changes to Selected Equate Macros for 32-Way Loosely Coupled Pool Support

Selected Equate Macro New, Changed, or No Longer Supported? Do You Need to Reassemble Programs? Programs to Reassemble
BRPEQ Changed No Not Applicable
CZ1SE Changed No Not Applicable

Structured Programming Macros (SPMs)

There are no changes.

System Initialization Program (SIP) Skeleton and Internal Macros (Inner Macros)

Table 1072 summarizes the system initialization program (SIP) skeleton and internal macro changes. This information is presented in alphabetic order by the name of the SIP skeleton and internal macro. If the SIP skeleton and internal macro (inner macro) is changed, you must reassemble the SIP Stage I deck and run the appropriate job control language (JCL) jobs from the SIP Stage II deck.

Table 1072. Changes to SIP Skeleton and Internal Macros for 32-Way Loosely Coupled Pool Support

SIP Skeleton and Internal Macro New, Changed, or No Longer Supported?
SKCTKB Changed
SPPGML Changed

System Initialization Program (SIP) Stage I Macros and Statements

There are no changes.

System Initialization Program (SIP) Stage II Macros

Table 1073 summarizes system initialization program (SIP) Stage II macro changes. This information is presented in alphabetic order by the name of the SIP Stage II macro. If IBMPAL is changed, you must run the system allocator (SALO) and load the new program allocation table (PAT) to the TPF 4.1 system.

Table 1073. Changes to SIP Stage II Macros for 32-Way Loosely Coupled Pool Support

SIP Stage II Macro New, Changed, or No Longer Supported?
IBMPAL Changed

System Communication Keypoint (SCK) Generation Macros

There are no changes.

System Macros

There are no changes.

System Macros (IBM Use Only)

There are no changes.

Segments

Table 1074 summarizes segment changes. This information is presented in alphabetic order by the name of the segment.

Table 1074. Changes to Segments for 32-Way Loosely Coupled Pool Support

Segment Type Link-Edit Module (Where Offline Segment Is Linked) New, Changed, or No Longer Supported? Description of Change
BCPY Real-Time Assembler Not Applicable Changed Copies CY2KT fixed file records to #CY2CPY.
BCP2 Real-Time Assembler Not Applicable Changed Updated comments.
BRTD Real-Time Assembler Not Applicable Changed Restores CY2KT fixed file records from #CY2CPY.
BRV1 Real-Time Assembler Not Applicable Changed Replaced hardcoded values with equates.
BRV2 Real-Time Assembler Not Applicable Changed Updated indexing into PI1DT for base only systems.
CCDBAF CSECT Not Applicable Changed Removed CY1KR and CY3DR DSECTs.
CDCR Real-Time Assembler CDCP Changed Reassembled to include changes to data macro CY1KR.
CIPZ Real-Time Assembler Not Applicable Changed Changed to support move of pool initialization to pool restart.
CTKO Real-Time Assembler Not Applicable Changed Added support for pool restart.
CTK9 Real-Time Assembler Not Applicable Changed Updated for new format of keypoint 9.
CYAB Real-Time Assembler Not Applicable Changed Removed reference to copy member CT55.
CYAE Real-Time Assembler Not Applicable Changed Updated to correctly determine if system is in restart.
CYAR Real-Time Assembler Not Applicable Changed Set new flags for the interface to CYFM and CYIO.
CYA0 Real-Time Assembler Not Applicable Changed Added Record_Retriever interface to access the CY0PD record.
CYA1 Real-Time Assembler Not Applicable Changed Added Record_Retriever interface and changed to support the new record structures.
CYA2 Real-Time Assembler Not Applicable Changed Added Record_Retriever interface and changed to support the new record structures.
CYA3 Real-Time Assembler Not Applicable Changed Set new flags for the interface to CYFM and CYIO.
CYA4 Real-Time Assembler Not Applicable Changed Added Record_Retriever interface and changed to support the new record structures.
CYA7 Real-Time Assembler Not Applicable Changed Changed to support new format for the CY0PD data structure.
CYB0 Real-Time Assembler Not Applicable Changed Changed to support new format for the CY1KR data structure.
CYC0 Real-Time Assembler Not Applicable Changed Added Record_Retriever interface and changed to support the new record structures.
CYC1 Real-Time Assembler Not Applicable Changed Added Record_Retriever interface and changed to support the new record structures.
CYC2 Real-Time Assembler Not Applicable Changed Added Record_Retriever interface and changed to support the new record structures.
CYC6 Real-Time Assembler Not Applicable Changed Added Record_Retriever interface and changed to support the new record structures.
CYD4 Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
CYE0 Real-Time Assembler Not Applicable Changed Added new error messages.
CYE1 Real-Time Assembler Not Applicable Changed Added new error messages.
CYF1 Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
CYF2 Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
CYF3 Real-Time Assembler Not Applicable Changed Changed to start pool monitor after filing keypoint 9.
CYF4 Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
CYF8 Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
CYF9 Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
CYGM Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
CYGR Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
CYH0 Real-Time Assembler Not Applicable Changed Changed to transform keypoint 9 from PXP support to 32-way loosely coupled pool support.
CYH1 Real-Time Assembler Not Applicable Changed Changed to transform keypoint 9 from 32-way loosely coupled pool support to PXP support.
CYH2 Real-Time Assembler Not Applicable Changed Changed to transform CY$CR from PXP support to 32-way loosely coupled pool support.
CYH3 Real-Time Assembler Not Applicable Changed Changed to transform CY$CR from 32-way loosely coupled pool support to PXP support.
CYH4 Real-Time Assembler Not Applicable Changed Changed to convert all pool structures from PXP support to 32-way loosely coupled pool support and to fall back pool structures from 32-way loosely coupled pool support to PXP support.
CYH5 Real-Time Assembler Not Applicable New Utility routines added for CYH4.
CYH6 Real-Time Assembler Not Applicable New Record_Retriever interfaces for the CY0PD, CY2KT, and short-term processor control record (STPCR) data structures.
CYIO Real-Time Assembler Not Applicable Changed Added interface to support processor unique record types.
CYYM Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
DCR2 Offline Assembler DCRS Changed Added new system errors.
DYDC Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
DYDG Real-Time Assembler Not Applicable Changed Changed to have STPCR and short-term common control record (STCCR) initialized independently.
DYDL Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
DYDQ Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
DYDS Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
DYD3 Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
DYD5 Real-Time Assembler Not Applicable Changed Changed to support new formats for record structures.
FTVA02 Offline C Language FCTBG Changed Changed validation from #STPCR record to #STPUR record.
FTVA03 Offline C Language FCTBG Changed Added validation for new records and removed validation for #STPCR.
JCD4 Real-Time Assembler Not Applicable Changed Added versioning support for Data Collection PB/PE Pools Summary records.
STPP Offline Assembler PPCP Changed Reassembled to include changes to data macro CFMDC.
UPX0 Real-Time Assembler Not Applicable Changed Updated comments.
UPX1 Real-Time Assembler Not Applicable Changed Updated comments.
UPX2 Real-Time Assembler Not Applicable Changed Updated comments.
UPX3 Real-Time Assembler Not Applicable Changed Updated comments.
UPX6 Real-Time Assembler Not Applicable New User exit added for Find_CY2KT.
UPX7 Real-Time Assembler Not Applicable New User exit added for File_CY2KT.

System Equates

There are no changes.

User Exits

Control Program (CP) User Exits and ECB User Exits summarize the control program (CP) and ECB user exit changes. See TPF System Installation Support Reference for a complete description of all user exits.

Control Program (CP) User Exits

There are no changes.

ECB User Exits

This information is presented in alphabetic order by the name of the function.

Table 1075. Changes to ECB User Exits for 32-Way Loosely Coupled Pool Support

Function User Exit Activated In User Exit Program New, Changed, or No Longer Supported? Description of Change
Pool Migration CYH0 UPX0 Changed REARRANGE_CTK9 changed for 32-way loosely coupled pool format.
Pool Migration CYH1 UPX1 Changed DEARRANGE_CTK9 changed for 32-way loosely coupled poolformat.
Pool Migration CYH2 UPX2 Changed Renamed GET_CY$CR to FIND_STCCR and changed for 32-way loosely coupled pool format.
Pool Migration CYH3 UPX3 Changed Renamed FILE_CY$CR to FILE_STCCR and changed for 32-way loosely coupled pool format.
Pool Migration CYH6 UPX6 New FIND_CY2KT added for 32-way loosely coupled pool support.
Pool Migration CYH6 UPX7 New FILE_CY2KT added for 32-way loosely coupled pool support.

Functional and Operational Changes

The following section summarizes functional and operational changes. This information is presented in alphabetic order by the functional or operational change.

See Appendix A, "PUT 2-15 Interface Changes by Authorized Program Analysis Report (APAR)" for a summary of functional and operational changes by APAR.

Commands

Table 1076 summarizes command changes. This information is presented in alphabetic order by the name of the command. See TPF Operations for a complete description of all commands.

Attention: Changes to commands can impact any automation programs you are using in your complex.

Table 1076. Changes to Commands for 32-Way Loosely Coupled Pool Support

Command New, Changed, or No Longer Supported? Description of Change
ZPMIG Changed Modified to convert pools from PXP format to 32-way loosely coupled pool format and fall back from 32-way loosely coupled pool format to PXP format.
ZPOOL GENERATION Changed Added restriction that all pool structures must be converted to 32-way loosely coupled pool format before entering this command.
ZRDIR CAPTURE Changed Added pool keypoint tables to capture content for 32-way loosely coupled pool format.
ZRDIR START RESTORE Changed Added pool keypoint tables to restore content for 32-way loosely coupled pool format.

Messages and System Errors

Table 1077 summarizes message (offline and online messages) and system error changes.

The message IDs or system error numbers are listed in numeric order preceded by their alphabetic prefix. Some offline and online messages do not have a standard message ID. For these, the messages are presented in alphabetic order based on the initial message text; or for those messages that begin with variable information, the initial message text that follows that variable information. See Messages (System Error and Offline) and Messages (Online) for a complete description of all messages and system errors.

Attention: Changes to offline messages, online messages, and system errors may impact any automation programs you are using in your complex.

Table 1077. Changes to Messages and System Errors for 32-Way Loosely Coupled Pool Support

Message ID or System Error Number Message Type New, Changed, or No Longer Supported?
00001A System Error Changed
000690 System Error Changed
000691 System Error Changed
000697 System Error Changed
000698 System Error New
000699 System Error New
00069A System Error New
00069B System Error New
00069C System Error New
041014 System Error New
041015 System Error New
BRTD0005E Online New
CTIN0042I Online No Longer Supported
CYA20001I Online New
CYGR0002T Online New
CYGR0099T Online New
DYDG0026E Online New
DYDG0027E Online New
DYD30017E Online No Longer Supported
DYD50013T Online No Longer Supported
DYD50014T Online No Longer Supported
GFSP0054E Online No Longer Supported
GFSP0055E Online No Longer Supported
GFSP0068E Online New
GFSP0069E Online New
GFSP0071E Online New
GFSP0072E Online New
GFSP0073E Online New
GFSP0074E Online New
GFSP0080E Online New
PMIG0001I Online Changed
PMIG0002I Online Changed
PMIG0003T Online Changed
PMIG0004I Online No Longer Supported
PMIG0006W Online Changed
PMIG0009T Online Changed
PMIG0011I Online New
PMIG0012E Online New
PMIG0013E Online New
PMIG0014E Online New
RFPC0003T Online Changed
RFPC0004T Online Changed
RFPC0006T Online No Longer Supported
RFPC0019T Online Changed
RFPC0020T Online No Longer Supported
RFPC0021T Online New
RFPC0022T Online New
RFPC0023T Online New
SISN0006T Online No Longer Supported

Performance or Tuning Changes

There are no changes.

Storage Considerations and Changes

There are no changes.

System Initialization Program (SIP) and System Generation Changes

There are no changes.

Loading Process Changes

There are no changes.

Online System Load Changes

There are no changes.

Publication Changes

Table 1078 summarizes changes to the publications in the TPF library. This information is presented in alphabetic order by the publication title. See the TPF Library Guide for more information about the TPF library.

Table 1078. Changes to TPF Publications for 32-Way Loosely Coupled Pool Support

Publication Title Softcopy File Name Description of Change
TPF Database Reference GTPDBR0C Updated for 32-way loosely coupled pool support with:
  • Restrictions to pool generation and reallocation procedure
  • Addition of the ZPMIG command.
TPF Library Guide GTPDOC0E Updated with definitions for new terminology in the master glossary for 32-way loosely coupled pool support.
Messages (System Error and Offline) and Messages (Online) Not Applicable Updated with new and changed messages and system errors for 32-way loosely coupled pool support.
TPF Migration Guide: Program Update Tapes GTPMG204 Updated with migration considerations for 32-way loosely coupled pool support.
TPF Operations GTPOPR0E Updated with changes to the ZPMIG, ZPOOL, and ZRDIR commands for 32-way loosely coupled pool support.
TPF System Generation GTPSYG0E Updated with information for 32-way loosely coupled pool support.
TPF System Installation Support Reference GTPINR0E Updated with new and changed ECB user exits for 32-way loosely coupled pool support.

Host System Changes

There are no changes.

Application Programming Interface (API) Changes

There are no changes.

Database Changes

There are no changes.

Feature Changes

There are no changes.

Installation Validation

There are no changes.

Migration Scenarios

Before you begin your migration to 32-way loosely coupled pool support, read Functional Overview and Architecture, paying particular attention to Migration, Coexistence, and Conversion.

Migration Terminology

When discussing migration to 32-way loosely coupled pool support from PXP support, the following terms need to be understood:

Fallback
The process of IPLing a processor from an image that does not contain 32-way loosely coupled pool support. Fallback implies that the processor was previously IPLed from an image that did contain 32-way loosely coupled pool support.

Migrate
The process of IPLing a processor from an image containing 32-way loosely coupled pool support.

Migrated Processor
A processor that has been IPLed from an image containing 32-way loosely coupled pool support.

Unmigrated Processor
A processor that has been IPLed from an image that does not contain 32-way loosely coupled pool support.

Pool Conversion
The process of converting all pool data structures from PXP format to 32-way loosely coupled pool format. For pool conversion to take place, all processors in the complex must be migrated. After pool conversion is completed, only migrated processors can join the complex.

Pool Conversion Fallback
The process of converting all pool data structures from 32-way loosely coupled pool format to PXP format. For pool conversion fallback to take place, all processors in the complex must be migrated. After pool conversion fallback is completed, unmigrated processors can join the complex or migrated processors can be re-IPLed with an unmigrated image.

Migration and Conversion Process

The migration, coexistence, and conversion process for 32-way loosely coupled pool support is similar to that used for PXP support in PUT 2. SeePool Expansion (PXP) Support (APAR PJ17912) for more information about migration to PXP support.

Migrating processors to a TPF image containing 32-way loosely coupled pool support and converting the pool data structures on DASD from PXP format to 32-way loosely coupled pool format is a two-stage process. This process is shown in Figure 9 where the boxes labeled B and C are processors in the complex and the DASD icon represents the pool data structures on DASD.

The letter O or N inside a processor box indicates the level of pool support contained in the image from which the processor was IPLed. O represents PXP support and N represents 32-way loosely coupled pool support. The small box in the larger processor box represents the pool data structures in the processor's main storage. The pool data structures are always in the format of the pool support of the image that was IPLed. For the DASD icon, O indicates that the pool data structures on DASD are in PXP format, and N indicates that the pool data structures on DASD are in 32-way loosely coupled pool format.

Old Base ((1)) in Figure 9 represents a TPF complex before beginning Stage 1 migration. Migration ((2) and (3)) represent a TPF complex during Stage 1 migration. New Base ((4)) represents the complex at the completion of Stage 2 conversion where the pool data structures in main storage of all processors and on DASD are in 32-way loosely coupled pool format. Stage 2 conversion of pool data structures on DASD from PXP format to 32-way loosely coupled pool format is represented by the transition between (3) and (4) where the ZPMIG command is used to convert the pool data structures.

Stage 1 - Migration

Stage 1 is performed on a processor-by-processor basis. In this stage you will migrate each processor from PXP support to 32-way loosely coupled pool support. At any point during stage 1, a processor that has been IPLed from an image with 32-way loosely coupled pool support can be re-IPLed from an image containing PXP support. Pool data structures on DASD remain in PXP format. This Stage 1 complex configuration is represented by (2) in Figure 9.

During stage 1, processors with 32-way loosely coupled pool support (migrated) and processors with PXP support (unmigrated) are able to coexist indefinitely provided that no more than eight processors are defined in the TPF complex. The code of unmigrated processors is not changed to support the coexistence of migrated and unmigrated processors in the same complex. Migrated processors access the pool data structures on DASD by using a set of access functions that translate between the PXP format on DASD and 32-way loosely coupled pool format in the processor's main storage. These access routines are represented by the Xlator layer on the migrated processor in Figure 9.

When all processors in the complex are IPLed from an image with 32-way loosely coupled pool support, as represented by (3), you have completed Stage 1 of the migration process and may proceed to Stage 2.

Figure 9. Migration and Conversion from Pool Expansion Support to 32-Way Loosely Coupled Pool Support


Stage 2 - Conversion

Stage 2 is performed complex-wide after Stage 1 is completed and all active processors have been migrated to 32-way loosely coupled pool support as shown by (3).

During Stage 2, the pool data structures on DASD are converted to 32-way loosely coupled pool format using the ZPMIG command described in ZPMIG--Migrate Pool Structures. The command must be entered for each subsystem. This process is represented by the double arrow labelled ZPMIG between (3) and (4). The completion of Stage 2 is represented by New Base ((4)).

You may still return to PXP support by using the ZPMIG command to do pool conversion fallback on pool data structures on DASD and re-IPLing processors with an unmigrated image.

Note:
As noted in Pool Data Structures, once the #STPCR record type is deleted, fallback to PXP support is no longer possible.

Migrating to 32-Way Loosely Coupled Pool Support

There are two migration scenarios to consider when migrating your complex to 32-way loosely coupled pool support:

New TPF 4.1 System

If you are installing the TPF 4.1 system for the first time, install the system using the system installation information provided in TPF System Generation, TPF System Installation Support Reference, and the program directories. 32-way loosely coupled pool support is installed as part of the normal installation procedure.

Existing TPF 4.1 System

If you have the TPF 4.1 system installed in your complex and want to add 32-way loosely coupled pool support, use the following migration scenario.

To Migrate Your Complex to 32-Way Loosely Coupled Pool Support
Before You Begin

  • If you are a TPF 4.1 user who has not installed or has not completed migrating to PXP support, you must complete the migration and conversion to PXP support before installing 32-way loosely coupled pool support and then continue with step 1 of this procedure. See Pool Expansion (PXP) Support (APAR PJ17912) for more information about PXP support.
  • If during the installation and migration to 32-way loosely coupled pool support you need to fall back to PXP support, follow the procedure in Falling Back to Pool Expansion (PXP) Support.
  • If you have any code that refers to pool data structures you must determine if the format or location of the data structures have changed. Use the appropriate pool data structure access method to access changed data structures. See Pool Access Functions for more information about pool access methods.
  • You must also examine your TPF system to determine if you must modify your user exits to accommodate 32-way loosely coupled pool support. See ECB-Type User Exits and Pool Data Access for more information about user exits.

  1. Ensure that no deactivation or reallocation processing is running on the TPF 4.1 system in which you are installing program update tape (PUT) 14.
  2. Install PUT 14, which contains APAR PJ27686 for 32-way loosely coupled pool support, on your TPF 4.1 system.
  3. Verify that the conversion indicators in keypoint 9 (CY1MD32 and CY1PLC) are set to zeros. If they are not set to zeros, change them to zeros (X'00').
  4. Update the SIP RAMFIL macro input statements to the FACE table generator (FCTBG):
    1. Add RAMFIL statements specifying the following new record types in the RECID parameter:
      • #CY2KT
      • #CY2CPY
      • #CY2NEW
      • #STPUR.

      Make sure that the required number of ordinals is specified. See Pool Data Structures and TPF System Generation for more information about these fixed record types.

    2. Ensure that the subsystem users (SSUs), processors, and I-streams correspond correctly with the fixed file record types in the USER parameter. See Table 1069 for the fixed file record types.

    See TPF System Generation for more information about the RAMFIL macro.

  5. Run the FCTBG to create a new FACE table.
  6. Assemble the SIP stage I deck to create a SIP stage II deck.
  7. Run the system allocator program (SALO) using the IBMPAL and SPPGML additions for the newly created segments to create an updated program allocation table (IPAT) and a system allocator table (SAL).
  8. Run SIP stage II.
  9. Complete Stage 1 (see Stage 1 - Migration) by migrating each processor in the loosely coupled complex to 32-way loosely coupled pool support as follows:
    1. Deactivate the processor and IPL it from an image containing 32-way loosely coupled pool support.
    2. Once all processors in the complex have been migrated and are operating with 32-way loosely coupled pool support, Stage 1 is completed.
    Note:
    During coexistence mode when migrated and unmigrated processors are active in the same complex, unmigrated processors operate unchanged. They do not check any new bits or call any new functions.

    Migrated processors read pool data structures from DASD using the record retriever routines. The record retriever routines convert the pool data structures on DASD from PXP format to 32-way loosely coupled pool format. When migrated processors file pool data structures, the record retriever routines convert the pool data structures back to PXP format before being filed to DASD. In this way, all pool data structures on DASD remain in a format that is understood by the unmigrated processors.

    Coexistence mode creates restrictions on the use of the ZRDIR CAPTURE and ZRDIR START RESTORE commands. See TPF Operations for more information about these commands.

    You can return any processor to PXP support by performing migration fallback, see Falling Back to Pool Expansion (PXP) Support. Any unmigrated processors must be returned to their migrated state before continuing with 10.

  10. Complete Stage 2 (see Stage 2 - Conversion) by converting each subsystem in the complex to 32-way loosely coupled pool support format on DASD as follows:
    1. Ensure that the pool status for the current pool structure in storage is set for each processor by entering the ZDFPC command on each processor.
    2. Ensure that all processors in the complex are running with an image containing 32-way loosely coupled pool support by entering the ZPMIG command with the STATUS parameter specified on an active processor. The PMIG0011I message displays the status of each processor. If this message is not received, the processor on which ZPMIG command was entered was not IPLed from an image containing 32-way loosely coupled pool support. Re-IPL the processor with the correct image.
    3. Enter the ZPMIG command with the CONVERT parameter specified for each subsystem from one of the processors in the complex. This command sets the conversion mode indicator in keypoint 9 to CONVERTING. It then converts keypoint 9, the pool section keypoint tables (CY2KTs), the pool descriptor record (CY0PD), and the short-term common control records (STCCRs) on DASD from PXP format to 32-way loosely coupled pool support format. The CY2KTs, short-term processor control (STPCRs), and associated data records are moved to new fixed file records on DASD.

      The conversion mode indicator in keypoint 9 will then be set to 32LC and 32-way loosely coupled pool support conversion is completed. Once the conversion mode indicator is set to 32LC, all the intermediate conversion functions are no longer used for the subsystem for which the command was entered and all pool data structures on DASD and in storage are in 32-way loosely coupled pool support format.

    4. When you enter ZPMIG CONVERT and there are inactive processors that have never been IPLed from an image containing 32-way loosely coupled pool support, those processors may not have current pool carve values set in keypoint B. When the inactive processors are brought into the loosely coupled complex, pool restart validates the amount of storage carved for pools, if necessary resetting the pool carve values in keypoint B and requesting an IPL. Because this validation is performed for a single subsystem at a time, a complex with multiple subsystems defined could see multiple requests for IPLs when bringing up the inactive processors.

      You can avoid these IPLs by entering the ZGFSP SET command on each subsystem for each inactive processor. This sets the pool carve values in keypoint B.

    Note:
    Once the complex has been converted to 32-way loosely coupled pool support format on DASD, any processor joining the complex must be IPLed from an image containing 32-way loosely coupled pool support.

    The complex may be returned to PXP format if there are eight or fewer processors in the complex and the #STPCR record type has not been deleted. To return the complex to PXP format, see Falling Back to Pool Expansion (PXP) Support. If there is no requirement to return to PXP format, the #STPCR record type may be deleted.

    See TPF Operations for more information about the ZDFPC and ZPMIG commnds.

Falling Back to Pool Expansion (PXP) Support

If a migrated processor must be IPLed from an image that does not contain 32-way loosely coupled pool support, two scenarios are possible: