gtps4m1bSystem Generation

System Utilized Record Types

The tables in this section contain lists of the fixed file data record types, including main storage resident records (which have their backup copies on file) that are required by the system programs. In addition to these system records, users will have their own application fixed file data records to include in their database. It should be noted that several of the different system record types are associated with various system packages and components, which are optional. For example, the various records associated with MPIF are only required if MPIF support is defined via the various SIP macros.

Each fixed file record type, including both system and application record types, requires a SIP RAMFIL macro. Inputs to the RAMFIL macro include the FACE record type and the number of records to be allocated. A minimum of 10 % extra records (coded as SPARES in RAMFIL macros) is recommended to allow for expansion. Lists of system utilized data records are provided in Table 16 and Table 18.

Use care when adding or deleting SPARE records. The IPAT and #PROGn area must be synchronized. IBMPAL is the segment used to allocate ECB-controlled programs. It creates both the IPAT and the SAL table. It also assigns program ordinal numbers in #PROGn. Ordinal numbers are assigned in the order that programs are coded. Once a program is assigned an ordinal number, it is important that the assignment never change. If a program ordinal number is changed, that program must be reloaded and all programs that enter it without using the NAME= parameter must be reloaded. For example:

 IBMPAL                                       #PROG1 ordinal
 -------------------------------------------------------------
 SPARE    OLD1                                       0
 COSY,FR,OPTIONS=(KEY0,MONTC,RESTRICT)               1
 BXAX,FR,FUNC=SBFCAP                                 2
 CCKP,FR,OPTIONS=(KEY0,MONTC,RESTRICT)               3
 COHA,FR,OPTIONS=(KEY0,MONTC,RESTRICT)               4
 BWMS,CR,OPTIONS=(KEY0,MONTC,RESTRICT)               5
 BWMU,TV,BWMS,1                                      6

In this example, if CCKP is obsoleted, it should not be deleted. CCKP should be replaced with a SPARE. If it is not replaced with a spare, COHA becomes ordinal 3 and every program allocated after COHA gets assigned a different #PROG1 ordinal number (PROG ordinal shift).

The same problem occurs if a new segment is added instead of replacing a SPARE. All segments below the added segment get a new ordinal number.

In most cases the proper way to add a segment is to find a SPARE and change it. The proper way to delete a segment is to replace it with a SPARE.

The analysis is more complicated when the program being deleted or added contains a FUNC= or an SS= switch.

A similar kind of example could be described for the FUNC parameter that specifies function switches.

#PROGn is initialized when you do a full load. What program goes into a given #PROG ordinal is controlled by the IPAT. The IPAT is created from IBMPAL and any user input decks. To avoid full loads for this reason manage SPAREs carefully.

Many of the data records require initialization before starting up the system. The initialized data records are generated on 1 or more pilot tapes, which are loaded onto the online packs as discussed in System Generation Process.

The records requiring initialization fall into three basic categories:

  1. Records needing complete initialization.
  2. Records needing header and some variable information to be initialized.
  3. Records needing only header information to be initialized. All core resident data records (for example, globals) must have at least a header initialized.

For categories 2 and 3, only 1 skeleton record must be initialized; for example, a standard data/message file (SDMF), and the required number can be generated on a pilot tape via the facilities of the system test compiler (STC).

The contents of the first 4 bytes of a data record (standard header) are:

Bytes 1-2
The record ID, which was coded as any self-defining term, for example:

X'2100'

B'0011000011001100'

C'WW'

2134 (decimal number)

Byte 3
The record code check

Byte 4
The control byte

Table 16 contains a list of the system-required fixed file data record types arranged by system function. Included is the following information:

Also indicated is the offline (MVS) program used to initialize each data record type. TPF provides the following offline programs for system record initialization:


Table 16. System-Required Fixed File Record Types

Record Type Record Macro Name RIAT ID Record Size Initialized By Functional Area MDBF Comments
#ASMSI AS4MF D4C1 L ASL Mapping Paging BSS/SS
#BKDRI BK0RP C2D2 L BRS0 Recoup Descriptor Records BSS/SS
#CANRI MT0MT D4E3 S STC UI Canned Messages BSS/SS
#CCBRU ICCB FF14 4KB Online SNA Comms. BSS See TPF ACF/SNA Network Generation
#CCEPS CC0CC C3C3 L CCSSP 3705 Load /Dump BSS/SS
#CFREC ICFST, ICFSB FC2E 4KB ZIFIL Coupling Facility BSS
  • If you are not using coupling facility support, there is no need to allocate this fixed file record.
  • A record code check (RCC) of X'01' is required for ICFST.
  • A RCC of X'02' is required for ICFSB.

#CF2LR ICFLR, C$CFLR FC2F 4KB ZCFLK INIT Coupling Facility BSS If you are not loosely coupled, there is no need to allocate this fixed file record.
#CIMR1 IDSCDR FC01 - FC0A 4KB ALDR Core Image Restart area for Image 1 BSS/SS
#CMSIT ISIDE FF09 4KB ZNSID SNA Comms. BSS/SS See TPF ACF/SNA Data Communications Reference
#CN1ST CN1ST FC81 S ZMIGR or Restart Subsystem state table. BSS
#CO1RI CO1DR C3F1 L STC Unsolicited Message Processor (UMP) BSS
#CTKX CX0CK 00ED 4KB ALDR Image Pointer Record BSS/SS
#CY2CPY CY2KT FF26 4KB Pool Directory Capture File Pools BSS/SS
#CY2KT CY2KT FF26 4KB Pool Gen File Pools BSS/SS
#CY2NEW CY2KT FF26 4KB Pool Gen File Pools BSS/SS
#DBRRI DB0DB C4C2 4KB Online Database Reorg. BSS/SS
#DSCRU DSEQU C4E2 L or 4KB Online General Data Set and General File Support BSS/SS
#FLOCK
FC2A 4KB Online File System BSS/SS
#GLOBL GLOBx C7D3 L STC Globals BSS/SS See TPF System Installation Support Reference
#HDREC CB8HD 00E2 4KB Online MPIF BSS
#IBMML
Various L
IBM Misc. BSS/SS See the code for the FACE table generator (FCTB) program FTVA03 for information about the number of ordinals to allocate for this fixed file record type.
#IBMMP4
Various 4KB
IBM Misc. BSS/SS See the code for the FACE table generator (FCTB) program FTVA03 for information about the number of ordinals to allocate for this fixed file record type.
#IBMMS
Various S
IBM Misc. BSS/SS See the code for the FACE table generator (FCTB) program FTVA03 for information about the number of ordinals to allocate for this fixed file record type.
#IBMM4
Various 4KB
IBM Misc. BSS/SS See the code for the FACE table generator (FCTB) program FTVA03 for information about the number of ordinals to allocate for this fixed file record type.
#IDOTX IDOTB
4KB
ZIDOT BSS
#IMQCK

4KB Online MQSeries Queue Manager SS MQSeries checkpoint records. The suggested number of #IMQCK records is at least twice the number of allocated SWBs.
#INODE INODE FC2A 4KB Online File System BSS/SS
#IPL1

4KB
IPLA/IPLB for Image 1 BSS
#IPRTE IPRTE FC44 4KB IP Restart TCP/IP Native Stack Support BSS See TPF ACF/SNA Network Generation and the ZTRTE command in TPF Operations
#IZERO
FC2A 4KB Online File System BSS/SS
#KBA IDSKPT C3D2 4KB ACPL Keypoint backup area BSS/SS Keypoint backup area
#KEYPT IDSKPT D2D7 4KB ACPL Keypoint Record BSS/SS
#KSA1 IDSKPT C3D2 4KB ACPL Keypoint staging area for image 1 BSS/SS  
#LKIBR CM8CM C3D4 S 03-CMR SLC BSS/SS
#MAILxx
FC55 4KB
TPF Internet mail server support SS If you are using TPF Internet mail server support, see note (NMAILR). Otherwise, there is no need to allocate this fixed file record.
#MQICD C$MQCD 00F5 4KB Online Message queue interface client support BSS See ZMQID DEFINE in TPF Operations
#NCBRI NC0CB C3C2 S Online SNA Comms. BSS
#OLDx

4KB
E-Type Loader Directory Records BSS/SS See TPF System Installation Support Reference. Required for E-type loaders.
#PDREC CB9PD 00E1 4KB Online MPIF BSS
#PDREU CB9PD 00E1 4KB Online MPIF BSS
#PROG1 IDSPRG 00FF 4KB ACPL E-type program area for Image 1 BSS/SS  
#PRORI PR1OT D6E3 L STC Processor Resource Owner Facility
See TPF Main Supervisor Reference
#PSTXCUR CY7PL FC39 4KB Pool Gen File Pools BSS/SS
#PSTXNEW CY7PL FC3A 4KB Pool Gen File Pools BSS/SS
#PTKST CPTIC D7D2 S SCK GEN Non-SNA Comms. BSS/SS
#PTSCK SCKDS E2D2 L SCK GEN Non-SNA Comms. BSS/SS
#PVR1 IDSPVR FF0E 4KB ACPL PVR for Image 1 BSS/SS PVR1 is required. RCC of X'FF' is required.
#RC8RFS I80I8 FC33 L ZPOOL INIT File Pools or PDU BSS/SS
#RCATU RC0AT D9C3 L SIP Message Router BSS
#RCBRA CI0CO C3D6 L STC Non-SNA Comms. BSS/SS
#RLOG 1-32 ICRCT FC27 4KB Log recovery restart Recovery log support BSS, SS For TPF transaction services, the recovery log fixed file records are always allocated to the BSS. Recovery log records may also be allocated to any user-defined application subsystem. The minimum allocation in the BSS and other subsystems is 60 tracks (see note (N29)).
#RRTRI RR0RT E2F2 4KB OSTG SNA Comms. BSS See TPF ACF/SNA Network Generation
#RV1RU RV1VT E2F6 4KB OSTG SNA Comms. BSS See TPF ACF/SNA Network Generation
#RV2RU RV2VT E2F7 4KB OSTG SNA Comms. BSS See TPF ACF/SNA Network Generation
#SATRU SA0AT E2F1 L OSTG SNA Comms. BSS See TPF ACF/SNA Network Generation
#SC1RU ISCB FF22 4KB Online SNA Comms. BSS See TPF ACF/SNA Network Generation
#SC2RU ISCB FF23 4KB Online SNA Comms. BSS See TPF ACF/SNA Network Generation
#SGFRI SI3GT C7C5 S CNPR Global Synch. BSS/SS See TPF System Installation Support Reference
#SONRI CY3DR C3C4 L Pool Gen File Pools BSS/SS
#SONSKP CY7PL C3C4 L Pool File Pools BSS/SS
#SORID SS0OR E2E2 L CSOR Non-SNA Comms. SS
#SPARI SP0PA E2D7 L/S Online SNA Comms. BSS/SS
#SRTRU SR0RT E2F8 4KB Online SNA Comms. BSS
#STCCR CY$CR FF12 4KB Pool Gen Short Term Pool BSS/SS
#STPKP CY3DR C3C4 L Pool Maint. Short Term Pool BSS/SS
#STPUR ICY$PR FF13 4KB Pool Cycle Up Short-Term Pool BSS/SS
#TDTDR ITDAT 00FB 4KB Restart Tape Support BSS
#TER0 1-10 AS0MP D4E2 L ASL Mapping Paging BSS/SS
#TPLBL TAPEQ E3E9 4KB Restart Tape Support BSS/SS
#UATRI UA1UA E4C1 L STC Non-SNA Comms. BSS/SS
#UQ1UQ UQ1UQ E4D8 S STC Non-SNA Comms. BSS
#UT2RT UT2RT E4E3 S STC Message Switching BSS
#UV1RP UV1RP E4E5 S STC Message Switching BSS
#UX1DQ UX1DQ E4E7 S STC Message Switching BSS
#VFARD VF0AC E5C1 L VFA VFA Support BSS/SS
#WAARI WA0AA C1C1 L STC Non-SNA Comms. BSS/SS
#WGTRU WG0TA C1D6 4KB WGTA Table Terminal Address Subtables BSS Required for the BSS only
#XCPYS UQ1UQ E4D8 S Message Switching Restart WTC BSS/SS
#XD0LS XD0LS E7C4 S STC Message Switching BSS
#XI1LD XI0DS E7C9 S STC Message Switching BSS
#XO1LD XL0DS E7D3 S STC Message Switching BSS
#XPRG1 IDSPRG 00FF 4KB ACPL C Language BSS/SS #XPRG is required.
#XQ1RI XQ1XQ E7D8 S STC Message Switching BSS
#XSQC XY0XY E7E8 L STC Message Switching and RES0 BSS
#XS0RI XS0AA E7E2 S STC Non-SNA Comms. BSS
#XS1AT XB0XB E7C2 S STC Message Switching BSS
#XT0RI XT0CB E7E3 S STC Message Switching BSS
#XV1XV XV1XV E7E5 S STC Message Switching BSS
#XZ1AT XZ1AT E7E9 S STC Message Switching BSS

Notes:

  1. This record is processor shared. In TPF mail configuration file /etc/tpf_mail.conf, define a different #MAILxx record type for each domain in your mail system, where xx is a 2-character alphanumeric string, and allocate 1000 #MAILxx records for each domain that you define. For example, you can associate #MAIL01 with the mail1.site.com domain and #MAIL02 with the mail2.site.com domain.

    See TPF Transmission Control Protocol/Internet Protocol for more information about TPF Internet mail server support.


Miscellaneous record types exist because the file address compute (FACE) program cannot allocate a single record of a specified type. Applications that require a single record should use a record from the appropriate miscellaneous record section. SIP RAMFIL macros for all three record types with a sufficient number of records are required. System required miscellaneous records use record types #IBMMS, #IBMML, #IBMMP4, and #IBMM4. See SYSEQ for more information about the contents of #IBMMS, #IBMML, #IBMMP4, and #IBMM4.

The terms PARS and IPARS, which appear in the Area column stand for the original applications that run under TPF and are called the Passenger Airline Reservation System and the International Passenger Airline Reservation System. A number of the miscellaneous records are only required for users of one or the other of these applications. In addition, World Trade users should refer to the appropriate IPARS version of the referenced documents. The Fare Quote package referred to is the IBM program product that was added to the original PARS application.

Table 17 contains the system record types located in the global area. These records are allocated as fixed file record types of #GLOBL. They are main storage resident with a backup copy on disk. Users should add their global area records to this list. A SIP RAMFIL macro for the #GLOBL record type is required. In addition, 2 or more records must be included in the #GLOBL area for the core allocator record (see TPF System Installation Support Reference for more information about global areas). Table 18 contains all of the records checked by the FACE table generator. Table 19 contains all of the records checked by the SIP Stage I assembly.

Table 17. Global Area Record Types

Macro Name ID Size Initialized By Area Comments
AR0RT AR L STC Application Recovery  
AS2MT MD L Online Mapping  
XX1ON XX L STC Non-SNA Comm.  
GLOBB GL L STC Global Blocks see INSL-GLBL
GLOBC GL L STC Global Blocks see INSL-GLBL
GLOBD GL L STC Global Blocks see INSL-GLBL
GLOBE GL L STC Global Blocks see INSL-GLBL
GLOBF GL L STC Global Blocks see INSL-GLBL
GLOBG GL L STC Global Blocks see INSL-GLBL
GLOBP GL L STC Global Blocks see INSL-GLBL
GLOBQ GL L STC Global Blocks see INSL-GLBL
XC1CC XC L STC Message Switching  
XK1CT XK L STC Message Switching  
XF1FF XF L STC Message Switching  
XN1XN XN L STC Message Switching  
XJ1LC XJ L STC Message Switching  
XE1SC XE L STC Message Switching  
XW1OC XW L STC Message Switching  
XP1XP XP L STC Message Switching  
XA1DS XA L STC Message Switching  
XU2TQ XU S STC Message Switching  
XR1TR XR L STC Message Switching  

Table 18. Records Checked by the FACE Table Generator (FCTBG)

Recid Size Recno Uniqueness SS Device Required
#APRG1 to #APRG8 4KB See note (N35)

See note (N35A)

Shared All Any No
#BKDRI N/A 36 Shared All Any Yes
#BREATB8 4KB 129 Shared All Any Yes
#BRHIST8 4KB 1290 SSU All Any Yes
#BRIDCOR 4KB 256 Shared All Any Yes
#BRIDDE8 4KB 129 Shared All Any Yes
#BRIDSA8 4KB 129 SSU and processor All Any Yes
#BRIDTB8 4KB 129 SSU and processor All Any Yes
#BRIDTO8 4KB 129 SSU All Any Yes
#BRLOTB8 4KB 129 Shared All Any Yes
#CCBRU N/A N/A Processor BSS Any No
#CIMR1 4KB See note (N20) Shared All Dev A Yes
#CIMR2-8 4KB See note (N20) Shared All Dev A No
#CN1ST Small 64 Shared BSS Any Yes
#CO1RI N/A N/A Shared BSS Any Yes
#CTKX 4KB See note (N21) Shared All Dev A Yes
#CY2CPY 4KB 48 Shared All Any Yes
#CY2KT 4KB 48 Shared All Any Yes
#CY2NEW 4KB 48 Shared All Any Yes
#DBRRI 4KB See note (N1A) SSU All Any Yes
#DSCRU Large See note (N1B) Processor All Any Yes
#FLOCK 4KB See note (N28) Shared All Any Yes
#GLOBL Large N/A SSU All Any Yes
#GR0ZSR Large See note (N33) Shared All Any Yes
#IBMML Large 40 Shared All Any Yes
#IBMMP4 4KB 100 Processor All Any Yes
#IBMMS Small 60 Shared All Any Yes
#IBMM4 4KB 200 Shared All Any Yes
#IDCF1 4KB 128 Shared All Any No
#IDOTX 4KB See note (N2A) Shared BSS Any Yes
#INODE 4KB See note (N28) Shared All Any Yes
#IPL1 4KB See note (N22) Shared BSS Dev A Yes
#IPL2-IPL4 4KB See note (N22) Shared BSS Dev A No
#IPRTE 4KB N/A Processor BSS Any No
#IPSFB 4KB See note (N30) Shared All Any No
#IZERO 4KB See note (N28) Shared All Any Yes
#KBA 4KB See note (N3A) Shared All Any Yes
#KEYPT 4KB See note (N4A) Shared All Dev A Yes
#KFBX0 - 254 4KB See note (N4B) Shared BSS Dev A No
#KSA1 4KB See note (N3A) Shared All Any Yes
#KSA2 to #KSA8 4KB See note (N3A) Shared All Any No
#MPRECP 4KB 8 Shared All Any Yes
#MQICD 4KB 51 N/A BSS Any No
#NCBRI Small N/A Shared BSS Any No
#OLDx 4KB See note (N23) Shared All Any No
#OSIT 4KB See note (N34) Shared BSS Any No
#PROG1 4KB See note (N24) Shared All Any Yes
#PROG2 to #PROG8 4KB See notes (N24) and (N25) Shared All Any No
#PSTXCUR 4KB See note (N37) Shared All Any Yes
#PSTXNEW 4KB See note (N37) Shared All Any Yes
#PVR1 4KB See note (N26) Shared All Any Yes
#PVR2 to #PVR8 4KB See notes (N25) and (N26) Shared All Any No
#RCBRA N/A See note (N5) Shared All Any Yes
#RC8RFS Large 257 Shared All Any Yes
#RGSTAT 4KB 101 Shared All Any Yes
#RLOG1-32 4KB See note (N29) Shared BSS Any Yes
#RRTRI 4KB N/A Shared BSS Any No
#RT1RI 4KB See note (N27) Processor BSS Any No
#RT2RI 4KB See note (N27) Processor BSS Any No
#RV1RU 4KB N/A Processor BSS Any No
#RV2RU 4KB N/A Processor BSS Any No
#SATRU Large N/A Processor BSS Any No
#SC1RU 4KB N/A Processor BSS Any No
#SC2RU 4KB N/A Processor BSS Any No
#SONCP Large See note (N31) Shared All Any Yes
#SONDE Large See note (N31) Shared All Any Yes
#SONRI Large See note (N6) Shared All Any Yes
#SONROLL Large See note (N31) Shared All Any Yes
#SONRPE0-7 Large See notes (N6A) and (N31) Shared All Any Yes
#SONRPM Large See note (N31) Shared All Any Yes
#SONSKP Large 97 Processor All Any Yes
#SONSV Large See note (N31) Shared All Any Yes
#SONUP Large See note (N31) Shared All Any Yes
#SPARI N/A N/A Shared BSS Any No
#SRHH1P 4KB 10 Shared All Any Yes
#SRMP1A 4KB 10 Shared All Any Yes
#SRM31A8 4KB 10 Shared All Any Yes
#SRM41A8 4KB 531 Shared All Any Yes
#SRM51A8 4KB 531 Shared All Any Yes
#SRM61A8 4KB 10 Shared All Any Yes
#SRTRU 4K N/A Processor BSS Any No
#STCCR 4KB See note (N7) Shared All Any Yes
#STPKP Large See note (N31) Shared All Any Yes
#STPUR 4KB See note (N8) Processor All Any Yes
#TPLBL 4KB See note (N10) SSU and processor All Any Yes
#UATRI N/A N/A Shared All Any Yes
#VFARD N/A See note (N11) Shared All Any Yes
#XPRG1 4KB See note (N24A) Shared All Any Yes
#XPRG2 to #XPRG8 4KB See notes (N24A) and (N25) Shared All Any No
#XS0RI N/A N/A Shared BSS Any No

Table 19. Records Checked during SIP Stage I Assembly

All SIP Stage I records go through FCTBG and SIP checking; some attributes are checked by SIP Stage I and some are checked by the FCTBG.
Recid Size Recno Uniqueness SS Device Required or Required with
#ASMSI N/A 36 Shared All Any Mapping Support
#CANRI N/A N/A Shared All Any Reservation Support
#CCEPS N/A N/A Shared All Any 3705 Support
#GR0ZSR N/A N/A Shared All Any TPFDF Support
#GR3MSR N/A N/A Shared All Any TPFDF Support
N/A N/A Shared All Any TPFDF Support
#HDREC 4KB 15 Shared BSS Any MPIF
#IDFCL N/A N/A Shared All Any TPFDF Support
#IDFUL N/A N/A SSU All Any TPFDF Support
#IDFCS N/A N/A Shared All Any TPFDF Support
#IDFC4 N/A N/A Shared All Any TPFDF Support
#IDFUS N/A N/A SSU All Any TPFDF Support
#IDFU4 N/A N/A SSU All Any TPFDF Support
#IRCBDF N/A N/A Shared All Any TPFDF Support
#IRCFDF N/A N/A Shared All Any TPFDF Support
#IRCGDF N/A N/A Shared All Any TPFDF Support
#IRCHDF N/A N/A Shared All Any TPFDF Support
#IRCIDF N/A N/A Shared All Any TPFDF Support
#IRCJDF N/A N/A Shared All Any TPFDF Support
#IRCKDF N/A N/A Shared All Any TPFDF Support
#IRDIDF N/A N/A Shared All Any TPFDF Support
#IR02DF N/A N/A Shared All Any TPFDF Support
#IR03DF N/A N/A Shared All Any TPFDF Support
#LKIBR N/A See note (N12) Shared All Any SLC Support
#NCBN4 4KB N/A Shared BSS Any DLU Support
#NCBN5 4KB N/A Shared BSS Any DLU Support
#PDREC 4KB 4 Shared BSS Any MPIF Support
#PDREU 4KB See note (N12A) Processor BSS Any MPIF Support
#PTKST N/A See note (N13) Shared All Any 2703 EP Support
#PTSCK N/A See note (N14) Shared All Any SCK Symbolic Lines
#RCATU L See note (N15) Processor BSS Any Yes
#SGFRI N/A See note (N16) SSU All Any Yes
#TDTDR 4KB See note (N17) Processor BSS Any Yes
#TER0x N/A N/A Shared All Any Mapping Support
#UQ1UQ N/A N/A Shared BSS Any Non WTC Support
#WAARI N/A See note (N18) Shared All Any Reservation Support
#WGTRU 4KB See note (N19) Processor BSS Any Yes
#XCPYS N/A N/A Shared All Any WTC Support
#XSQC N/A 64 Shared BSS Any Reservation Support or Message Switching Support for non-WTC

These notes apply to both the records checked by the FACE table generator and those checked during Stage I.

Notes:

  1. Number of record types + 3

  2. For Large record size, calculate as follows:
    Number_of_general_data_sets/8
    with a minumum of 2 × number_of_processors

    For 4KB record size, calculate as follows:
    Number_of_general_data_sets/31
    with a minumum of 2 × number_of_processors

    The maximum number of records is 255 for each processor.

  3. 24 × number of processors

  4. Calculated as follows:
    ((number_of_processor-unique_keypoints × number_of_processors) +
    number_of_processor-shared_keypoints + 1)

  5. This is a vertical record. Multiple extents (RAMFIL macro with PRIOR parameter value not equal to 0) are allowed.
    (((number_of_processor-unique_keypoints × number_of_processors)
    + number_of_processor-shared_keypoints) ×
    (NFBACK_parameter_on_RAM_macro + 1)) + 1

  6. This is a vertical record that must be defined if the value of the NFBACK parameter on the RAM macro is not 0. The number of definitions must match the value of the NFBACK parameter and must start with #KFBX0 and continue sequentially.
    (1 + (7 × number_of_processors) +9)

  7. 2 × number of processors

  8. Add up for each pool RAMFIL (RECNO + 7999)/8000.

  9. Define #SONRPEx records for each processor up to the first eight. If there is one processor, only define #SONRPE0. For additional processors, define #SONRPE1 for processor 2 up to SONRPE7 for processor 8. Do not define additional SONRPEx records for processors beyond the eighth.

  10. 12 + the sum of all ((short-term pool directories + 499) / 500)

  11. This is a processor unique record.
    The number of records for each processor =
    12 + (((number of short-term directories for SST-A + 499)/500)
    + ((number of short-term directories for LST-A + 499)/500)
    + ((number of short-term directories for 4ST-A + 499)/500)
    + ...
    + ((number of short-term directories for 4ST-D + 499)/500))

    Notes:

    1. Drop the fractional portion of each short-term directory result, for example: (7 + 499)/500 = 1.

    2. All 12 pool short-term directory types (SST-A to 4ST-D) must be included in the calculation.

  12. This is an SSU/processor unique record. (18 ordinals for each RAMFIL statement.).

  13. Number of processors

  14. Number of pool records per link × number of SLC links

  15. Calculated as follows:
    number of paths defined for the TPF system/
    ((4096 - record header length)/PDR item length)

  16. Number of 2703 lines

  17. Number of symbolic lines

  18. Number of RCAT records

  19. Number of fields defined for the user in GLSYNC. One more than this is required for the first SSU.

  20. This is a processor unique record. (Number of tape control units + 1 ordinals) for each RAMFIL statement.

  21. Number of unique LNIATAs

  22. Calculated as follows:
    ((((number of UATs × WGTA entry size +
    (calculated usable space of a 4K block - 1))/
    (calculated usable space of a 4K block)) +
    (((number of UATs × hash table entry size +
    (calculated usable space of a 4K block - 1))/
    (calculated usable space of a 4K block)))

  23. This is a vertical record. The RECNO parameter on the RAMFIL macro that is coded for this record type reflects the records that are reserved on a single module only. The total number of records, which is the RECNO times the number of prime modules, must be enough to contain all the CIMR components. All RECNO must be coded with a single RAMFIL. #CIMRx cannot be spanned.

  24. This is a vertical record. The RECNO parameter on the RAMFIL macro that is coded for this record type reflects the records that are reserved on a single module only. The total number of records that are coded for this record type must equal the number of images to be generated. If only 1 image is being generated, RECNO=2 must be coded. #CTKX cannot be spanned.

  25. This is a vertical record. The RECNO parameter on the RAMFIL macro that is coded for this record type reflects the records that are reserved on a single module only. The total number of records coded for this record type must be large enough to contain IPL1, IPL2, IPLA, and IPLB. #IPLx cannot be spanned.

  26. RECNO must be greater than (maximum number of loadsets online × average number of programs in each loadset) × 1.1

    For the BSS subsystem, #OLDx records are required; the minimum number allowable is defined by the following equation. For other subsystems, users can choose not to allocate any #OLDx records if they do not plan to use the E-type loader on that subsystem.

    Minimum number of #OLDx records required =
     
          35       +   (#CPUs genned × 200)    +
      (reserved)       (recommended number of
                        available records)
     
     
      (32    ×    [MAX_NUM_ACTIVE_LOADSETS / ECR_NUM_ENTRIES)]
     (Max.          (IBM default = 1000)       (Defined in
      CPUs)                                   C$IDSECR = 203)
     
                   Round up the figure in square brackets to
                   a whole number.
    

    You may need to define additional #OLDx records because C load modules use a minimum of 2 #OLDx records each and can be larger than 4 KB. Use the following formula to estimate the number of additional #OLDx records that you need. The formula can be used in either of the following ways:

    • On a per C load module basis and then summed up for a total.
    • Use the total size of all C load modules for the total number of #OLDx records needed.

    This needs to be calculated only for the maximum number of C load modules that will exist in loadsets at a given time. The size of the C load module (size_of_module) is the offline size produced by the linkage editor. Each directory record can hold approximately 500 entries.

    The following formula is an approximation; it is not intended to give an exact number. It can be used on from 1 to n number of C load modules.

    Number of #OLDx records for one or more C load modules =
         ((sum_of_C load module_sizes/4000) + (3 * number_of_C load modules))
    

    Some examples help to explain this formula.

    • A C load module that is 1 MB in size:
          Number of #OLDx records = ((1000000/4000) + (3 * 1))
                                  =      250        +    3
                                  =      253
      
    • A C load module that is 1.624 KB in size:
          Number of #OLDx records = ((1624/4000) + (3 * 1))
       
                                  =     0.406    +    3
                                  =     3.4
                                  =     4
      
    • A loadset that contains 50 C load modules, 15 of which contain multiple OBJs, and 35 that contain only one OBJ each, for a total of 289.352 KB in size:
          Number of #OLDx records = ((289352/4000) + (3 * 50))
                                  =     72.338   +     150
                                  =     222.338
                                  =     223
      

    You will need to allocate additional #OLDx records if you plan to use the E-type loader to load programs with ADATA files for use by the TPF Assembler Debugger for VisualAge Client. To estimate the number of additional #OLDx records that need to be allocated, do the following:

    1. Estimate the maximum number of basic assembler language (BAL) programs that will be loaded with ADATA files in loadsets simultaneously.
    2. Calculate the number of records required to hold ADATA files by using one of the following:
      Number of #OLDx records for BAL ADATA files = (number of BAL programs)
       + ((sum of sizes of object modules) / 80)
       
      Number of #OLDx records for BAL ADATA files = (number of BAL programs)
       + ((sum of sizes of source files) / 1200)
       
      Number of #OLDx records for BAL ADATA files =  (number of BAL programs)
       * 40
      
    3. Modify the number of #OLDx records for BAL ADATA files by using one of the following:
      • If the number of BAL programs is less than 10, multiply the number of #OLDx records by 1.5.
      • If the number of BAL programs is greater than 10 but less than 25, multiply the number of #OLDx records by 1.3.
      • If the number of BAL programs is greater than 25 but less than 50, multiply the number of #OLDx records by 1.1.
    4. Estimate the maximum number of assembler programs that are members of load modules that will be loaded with ADATA files in loadsets simultaneously.
    5. Calculate the number of records required to hold ADATA files by using one of the the following:
      Number of #OLDx records for load module ADATA files = (2 *
      (number of load modules containing members with ADATA files)) +
      ((sum of sizes of object modules) / 80)
       
      Number of #OLDx records for load module ADATA files = (2 *
      (number of load modules containing members with ADATA files)) +
      ((sum of sizes of source files) / 1200)
      
    6. Modify the number of #OLDx records by using one of the following:
      • If the number of load module members is less than 10, multiply the number of #OLDx records by 1.5.
      • If the number of load module members is greater than 10 but less than 25, multiply the number of #OLDx records by 1.3.
      • If the number of load module members is greater than 25 but less than 50, multiply the number of #OLDx records by 1.1.
    7. Add the number of #OLDx records for BAL ADATA files (calculated in the previous steps) to the number of #OLDx records for load module ADATA files (calculated in the previous steps) to calculate the total number of additional #OLDx records required to hold ADATA files.
      Note:
      These guidelines provide only a rough estimate, so increase or decrease the allocations based on available space and the importance of having enough records available for loadsets.

  27. RECNO must be greater than or equal to the total number of programs, transfer vectors, and spares to be loaded.

  28. The formula for determining the number of #XPRGns can be used in either of the following ways:
    • On a per C load module basis and then summed up for a total.
    • Use the total size of all C load modules for the total number of #XPRGn records needed.

    The size of the C load module is needed as input to the formula. It is the offline size produced by the linkage editor.

    The following formula is an approximation; it is not intended to give an exact number. It can be used on from 1 to n number of C load modules.

    Number of #XPRGn records for one or more C load modules =
         ((sum_of_C load module_sizes/4000) + (2 * number_of_C load modules))
    

    Some examples help to explain this formula.

    1. A C load module that contains multiple OBJs and is 85.296 KB in size:
          Number of #XPRGn records = ((85296/4000) + (2 * 1))
                                   =      21.324    +    2
                                   =      23.324
                                   =      24
      
    2. A C load module that is 1.624 KB in size:
          Number of #XPRGn records = ((1624/4000) + (2 * 1))
                                   =     0.406    +    2
                                   =     2.406
                                   =     3
      
    3. Fifty (50) C load modules, 15 of which contain multiple OBJs, and 35 that contain only one OBJ each, for a total of 289.352 KB in size:
          Number of #XPRGn records = ((289352/4000) + (2 * 50))
                                   =     72.338   +     100
                                   =     172.338
                                   =     173
      

  29. For any additional program base, you must have a corresponding set of #PROGn, #PVRn, and #XPRGn records. For example, #PROG2 must have corresponding #PVR2 and #XPRG2 records. You cannot have 1 of these record types without both of the other 2 record types.

  30. The formula for estimating the number of #PVR records for 1 program base is:
    Number of #PVRn records = (number of #PROGn records) / PVRMAXE
      for a program base
    

    Note that PVRMAXE is defined in IDSPVR; the current value of PVRMAXE is 127.

  31. This is a processor unique record. See TPF ACF/SNA Network Generation for information about how many #RT1RI and #RT2RI records to define.

  32. You must have equal numbers of #INODE and #FLOCK fixed file records. The number of #INODE and #FLOCK fixed file records must be allocated in fixed ratios: up to 1001 #INODE/#FLOCK records must have 1 #IZERO fixed file record, up to 2001 #INODE/#FLOCK records must have 2 #IZERO fixed file records, up to 3001 #INODE/#FLOCK records must have 3 #IZERO fixed file records, and so on.

  33. This is a vertical record. The RECNO parameter on the RAMFIL macro that is coded for this record type reflects the records that are reserved on a single module only.
    Note:
    For TPF transaction services, the recovery log fixed file records are normally allocated to the BSS. If you do not want to allocate to the BSS, you may allocate recovery log records to any user-defined application subsystem. You must always allocate recovery log records on the BSS even when they have been allocated on the user-defined application subsystem. BSS recovery log records are necessary if the system is IPLed without the user-defined application subsystem. The TPF system must always have access to recovery log records.

    To calculate the required number of records, use the following formula:

    (300 ECBs per second * the average size of the commit scope for each ECB
    (100 KB) * TPF queue manager checkpoint interval(5 seconds)) +
    (1000 MQPUT/MQGET requests per second * the average size of a message
    (4 KB) * TPF queue manager checkpoint interval(5 seconds)) * 1.5
    (factor for padding)
    

    For example, (300 * 100 KB * 5 = 150 000 KB) + (1000 * 4 KB * 5 = 20 000 KB) * 1.5 = 255 MB.

  34. #IPSFB fixed file records (RIAT ID X'FC40') are used in a circular fashion. Ordinal record 0 is used to control the use of the remaining records. Ordinal records 1 through the number of records that were defined will have an entry added to them for each program that is activated, deactivated, accepted, or changed (using the ZAPAT, ZAPGM, or ZRTDM commands). The size of the database is dynamically allocated based on the number of #IPSFB records that are defined. The CUPT program logs the entries. For example, if you activate a loadset with 50 programs, positive feedback support makes 50 entries to the fixed file record starting at the 51st entry in the current 4-KB record. When ordinal record 1 is filled, positive feedback support makes entries in ordinal record 2. Positive feedback support fills each record until the last record that was defined. After making an entry in the last slot in the last record, positive feedback support makes its next entry in the first slot of the first record, ordinal 1. Therefore, the number of #IPSFB fixed file records that are defined, as well as the amount of loggable activity, determines how much information can be stored before the log wraps.

    When the TPF system is cycled to NORM state, the CUPH program copies the contents of the #IPSFB fixed file records to a POSIX file called tpfva.fil, which is found in directory /tpf.va. This file is a duplicate of the fixed file records. It can be transferred to another system by using the TPF-supported Trivial File Transfer Protocol (TFTP) or File Transfer Protocol (FTP). When the file has been transferred, it can be used by any user program.

    To turn off positive feedback support, remove the #IPSFB records.

  35. Greater of (the number of ordinals allocated for SONRI) or the sum of each pool RAMFIL (RECNO + 7999)/8000

  36. 30 × number of processors

  37. Minimum of 4 × number of processors. Define #OSIT records only if Open Systems Adapter (OSA)-Express Support is defined (the MAXOSA parameter is not zero).

  38. #APRGx records are needed for any program base on which you plan to load ADATA files with base versions of programs. To estimate the number of additional #APRGx records that need to be allocated, do the following:
    1. Estimate the maximum number of BAL programs that will be loaded with ADATA files in loadsets simultaneously.
    2. Calculate the number of records required to hold ADATA files by using one of the following:
      Number of #APRGx records for BAL ADATA files = (number of BAL programs)
       + ((sum of sizes of object modules) / 80)
       
      Number of #APRGx records for BAL ADATA files = (number of BAL programs)
       + ((sum of sizes of source files) / 1600)
       
      Number of #APRGx records for BAL ADATA files =  (number of BAL programs)
       * 40
      
    3. Modify the number of #APRGx records for BAL ADATA files by using one of the following:
      • If the number of BAL programs is less than 10, multiply the number of #APRGx records by 1.5.
      • If the number of BAL programs is greater than 10 but less than 25, multiply the number of #APRGx records by 1.3.
      • If the number of BAL programs is greater than 25 but less than 50, multiply the number of #APRGx records by 1.1.
    4. Estimate the maximum number of assembler programs that are members of load modules that will be loaded with ADATA files in loadsets simultaneously.
    5. Calculate the number of records required to hold ADATA files by using one of the following:
      Number of #APRGx records for load module ADATA files = (2 *
       (number of load modules containing members with ADATA files)) +
      ((sum of sizes of object modules) / 80)
       
      Number of #APRGx records for load module ADATA files = (2 *
       (number of load modules containing members with ADATA files)) +
      ((sum of sizes of source files) / 1200)
      
    6. Modify the number of #APRGx records by using one of the following:
      • If the number of load module members is less than 10, multiply the number of #APRGx records by 1.5.
      • If the number of load module members is greater than 10 but less than 25, multiply the number of #APRGx records by 1.3.
      • If the number of load module members is greater than 25 but less than 50, multiply the number of #APRGx records by 1.1.
    7. Add the number of #APRGx records for BAL ADATA files (calculated in the previous steps) to the number of #APRGx records for load module ADATA files (calculated in the previous steps) to calculate the total number of additional #APRGx records required to hold ADATA files.
      Note:
      These guidelines provide only a rough estimate, so increase or decrease the allocations based on available space and the importance of having enough records available for ADATA files.

  39. To use expression enhancements for the TPF debuggers, you must double your APRGx record allocation. Symbol tables are created by the TPFSYM offline program and contain information for all symbols defined in a program. The TPFSYM offline program is loaded to the TPF system through the TPFLDR offline loader. The increased size of each ADATA file depends on the number of symbols defined in the program and the number of symbols defined in the common symbol table (UCST). Doubling your APRGx record allocation provides enough room to hold the new ADATA file.

  40. Minimum of 10 ordinals. If more than 710 pool RAMFIL statements exist then the number of ordinals is the (number of pool RAMFIL statements + 70)/71.