gtpi1m67System Installation Support Reference

Loading System Components to a New TPF System

The general file loader is used to load all system components to a new TPF system or to selectively update any system component. The general file loader is only necessary at system generation or in an emergency load condition in which no fallback image exists. The general file loader can only be used to load to fixed image 1.

Note:
You must stop the entire online system to use the general file loader. Therefore, if you are loading system components to an existing TPF system, it may be advantageous to use the auxiliary loader. You do not have to stop the system to use the auxiliary loader. See Loading System Components to an Existing TPF System for more information.

After you assemble all system and application programs and generate their data records, do the following to load the system components to a new TPF system:

  1. Initialize the general file.
  2. Format the general file and online modules.
  3. Create a general file load deck.
  4. Load system components to the general file.
  5. IPL the general file.
  6. Load fixed-file records.
  7. IPL the online module.

Initializing the General File

You must initialize and format the general file before you can load system components to it. The system initialization program (SIP) does the initialization. SIP uses the MVS utility program ICKDSF to load IPLA and the volume serial number (VOLID) to the general file.

Formatting the General File and Online Modules

The real-time disk formatter prepares the general file and online modules to receive system components.

Creating a General File Load Deck

This section shows the steps you must take to create a load deck (assuming SIP has been run successfully).

Enter the JCL Cards

The following JCL cards are used to run the general file loader offline segment (ALDR); nn is the release identification and ssid is the subsystem ID.

Figure 13. ALDR Run Load Deck Example

//ALDRGF JOB  (82F91,7323E),'SIP ACP  ',
//   MSGLEVEL=1,CLASS=F,
//   MSGCLASS=A,TIME=15
//LOAD40 EXEC PGM=TPFLDRnn,REGION=9000K,PARM='ALDR,CLMSIZE=4000000'
//STEPLIB  DD DSN=ACP.LINK.RELnn.ssid,DISP=SHR
//         DD DSN=SYS1.EDC.SEDCLINK,DISP=SHR
//         DD DSN=SYS1.PLI.SIBMLINK,DISP=SHR
//SALTB    DD DSN=ACP.SALTBL.RELnn.ssid,DISP=SHR
//GENFIL   DD DSN=GNFLssid,DISP=OLD,
//            UNIT=3380,VOL=(PRIVATE,,,,SER=xxxxxx)
//GENFI2   DD DSN=GNF2BSS,DISP=OLD,
//            UNIT=3380,VOL=(PRIVATE,,,,SER=xxxxxx)
//PRINT    DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//LDRTRACE DD SYSOUT=*
//ALDRCPL  DD DSN=ACP.LINK.RELnn.ssid,DISP=SHR
//LOADMOD  DD DSN=ACP.LINK.RELnn.ssid,DISP=SHR
//OBJDD    DD DSN=ACP.OBJ.RELnn.ssid,DISP=SHR
//INPUT    DD    *
*** INPUT CONTROL CARDS ARE PLACED HERE
/*

Notes:

  1. DD names SALTB, OBJDD, GENFIL, PRINT, INPUT, and LOADMOD are required.

  2. DD name LDRTRACE is required only if you specify TRACE(ON) as a parameter.

  3. Data set concatenation is sequence-dependent.

TPFLDR EXEC Card

The TPFLDR EXEC card identifies the specified version of the TPF offline loader program (TPFLDR).

These are the parameters that can be specified on the EXEC card.

  1. ALDR

    indicates the general file loader (ALDR) is to be executed.

  2. CLMSIZE = x

    where x is greater than or equal to the MVS file size of the largest C load module to be loaded. If a C load module contains a higher than normal ratio of VCONs to executable code, CLMSIZE must be larger. ALDR searches only the OBJDD DSN (not LOADMOD DSN) when CLMSIZE = 0.

  3. TRACE(ON|OFF)

    If you specify TRACE(ON), selective trace data will be written to the LDRTRACE DD name. This trace data can be useful to system programmers to debug problems that occur while running TPFLDR. TRACE(ON) is primarily intended for TPF development personnel for this purpose. TRACE(OFF) is the default. If you specify TRACE(OFF), no trace data is written.

STEPLIB Card

The STEPLIB card identifies the partitioned data sets that contain the offline loader programs.

SALTB Card

The SALTB card identifies partitioned data sets that contain the system allocator table (SALTBL). The SALTBL contains information necessary for the TPF linkage editor to resolve virtual address constants (VCONs). These VCONs can be program addresses, tape names, macro parameters, and others that are put in the SALTBL to allow relocation of resources in the online system. See System Allocator for more information on the SALTBL.

GENFIL Card

The GENFIL card identifies the general file to which offline data is written.

GENFI2 Card

The GENFI2 card identifies the general file DSN for the 4KB region to which offline programs and data are written.

ADATATMP Card

The ADATATMP card specifies a temporary data set used to hold ADATA files before they are written to the output medium.

PRINT Card

The PRINT card causes an output listing that details all system components loaded to the general file to be produced. Errors that do not cause the program to abend are also written in this listing. Abend error messages and informational messages are sent to the operator console. For more information about error messages, see Messages (System Error and Offline) and Messages (Online).

ALDRCPL Card

The ALDRCPL card identifies the partitioned data set that contains the link-edited control program and FACE table. The FACE table and control program are assembled and link-edited using standard MVS facilities. For more information, see TPF System Generation.

LOADMOD Card

The LOADMOD card identifies the partitioned data set (LOADMOD) that contains the link-edited C load modules. When an E-type program is being loaded, the data sets identified by the LOADMOD card are searched before the data sets identified by the OBJDD card are searched. The C load modules are compiled and link-edited using standard MVS facilities. For more information, see TPF System Generation.

OBJDD Card

The OBJDD card identifies object libraries. Object libraries are partitioned data sets of assembled or compiled TARGET(TPF) programs. All programs to be loaded must be in object libraries with the exception of the control program, the FACE table, and C load modules. Library contents are maintained and updated using MVS procedures. For more information see TPF System Generation.

SYSPRINT Card

The SYSPRINT card identifies the device to which output is printed. It should be included in the ALDR load deck or some error messages related to the C load module will be routed to the stdout device. See TPF C/C++ Language Support User's Guide for more information on stdout.

Enter the Input Control Cards

Figure 14 shows a sample ALDR input control load deck. The example explains the order of the cards and states if the cards are required or optional.

Figure 14. ALDR Input Control Load Deck Example

================================================================================
    Initialization part of the load deck - Must be first input control cards
================================================================================
LOADER   CC    40              <-- Required, must be first
LOADER   IMAGE CLEAR           <-- Optional, immediately after CC
LOADER   LOAD  CTKX 40         <-- Optional, (required after IMAGE CLEAR)
GF       CALL  KEYPTCTKAGF     <-- Optional, last initialization statement
GF       CALL  KEYPTCTKVGF
================================================================================
    Main part of the load deck - Must be second input control cards
================================================================================
LOADER   LOAD  CP   40         <-- Required, before file-resident programs
LOADER   LOAD  IPAT 40         <-- Optional, anywhere after LOAD CP
LOADER   LOAD  KEYPT           <-- Optional, anywhere after LOAD CP
LOADER   CALL  KEYPTCTK040     <-- Optional, immediately after LOAD KEYPT
LOADER   CALL  KEYPTCTK140
LOADER   CALL  KEYPTCTK241
LOADER   CALL  KEYPTCTK340
LOADER   CALL  KEYPTCTK440
LOADER   CALL  KEYPTCTK540
LOADER   CALL  KEYPTCTK640
LOADER   CALL  KEYPTCTK940
LOADER   CALL  KEYPTCTKA40
LOADER   CALL  KEYPTCTKB40
LOADER   CALL  KEYPTCTKC40
LOADER   CALL  KEYPTCTKD40
LOADER   CALL  KEYPTCTKE40
LOADER   CALL  KEYPTCTKI40
LOADER   CALL  KEYPTCTKM40
LOADER   CALL  KEYPTCTKV40
LOADER   CALL  KEYPTCTKA40   C
LOADER   PROG-MOD-BASE CLEAR   <-- Opt, after LOAD CP & before LOAD OPL
LOADER   ELDR CLEAR            <-- Optional, anywhere after LOAD CP
LOADER   LOAD  OPL             <-- Optional, anywhere after ELDR CLEAR
 PARS40                        <-- Optional, immediately after LOAD OPL
 PARS4D
 PARSP1
LOADER   LOAD  AP              <-- Optional, anywhere after LOAD CP
LOADER   CALL  PROG COSY40     <-- Optional, immediately after LOAD AP
LOADER   CALL  PROG BXAX40
LOADER   CALL  PROG CCKP40
LOADER   CALL  PROG COHA40
LOADER   CALL  PROG COHB40
LOADER   CALL  PROG UF00P1
 REP  000348 0014700       <- Optional, immediately after CALL PROG ->    UF00P1
LOADER   LOAD  ACPL 40          <-- Optional, anywhere after LOAD CP
LOADER   LOAD  FCTB 40          <-- Optional, anywhere after LOAD CP
LOADER   LOAD  ICDF 40          <-- Optional, anywhere after LOAD CP
LOADER   LOAD  IPLA 40          <-- Optional, anywhere after LOAD CP
LOADER   LOAD  IPLB 40          <-- Optional, anywhere after LOAD CP
LOADER   LOAD  SIGT 40          <-- Optional, anywhere after LOAD CP
LOADER   LOAD  RIAT 40          <-- Optional, anywhere after LOAD CP
LOADER   LOAD  USR1 40          <-- Optional, anywhere after LOAD CP
LOADER   LOAD  USR2 40          <-- Optional, anywhere after LOAD CP
 LDT                            <-- Required, must be last
/*

Figure 15 shows a sample ALDR input control load deck that makes use of the PATH card to load an FCTB in program object format from an HFS path.

Figure 15. ALDR Input Control Load Deck Example Showing FCTB in Program Object Format from HFS

================================================================================
    Initialization part of the load deck - Must be first input control cards
================================================================================
LOADER   CC    40               <-- Required, must be first
================================================================================
    Main part of the load deck - Must be second input control cards
================================================================================
LOADER   PATH  FCTBPATH        This search path can be used to find FCTB
         /u/tpf41/product_components/system/;                                  X
         /u/tpf41/product_components/test/;                                    X
         /u/user1/my_project/tables
LOADER   LOAD  FCTB 40/FCTBPATH <-- FCTBPATH indicates search path to use
 LDT                            <-- Required, must be last
/*

CC Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   CC    uu  vv,vv,vv,vv,vv,vv,vv,vv,vv,vv
 
 
uu = SALTBL version
vv = Version number of operational program (PARS) list

The CC card contains control information for the program. It supplies the version number of the SALTBL to be used for link-editing and the version numbers of any operational program lists to be used to build the directory in main storage. As many as ten lists can be specified. The only card that can precede the CC card is a REP card for the loader. Otherwise the loader will abend.

Image Clear Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   IMAGE CLEAR

The Image Clear card ensures clean image definitions. If it is present, ALDR will set an indicator for ACPL to perform the initialization of various image-related records. Note that with a clear card IPLA, IPLB, CTKX, and all the CIMR components need to be loaded.

Attention: The image clear card will cause all image definitions to be cleared on the online system.

Comment Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
*comments

Comment cards can be placed anywhere in the load deck. Comments are identified by an asterisk (*) in card column 1. As far as control card sequencing is concerned, comment cards are ignored in this section of this publication.

Patching the General File Loader Offline Segment
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
zREP  aaaaaa 001xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx    ALDR
 
z      = Any character except *
aaaaaa = Address of the patch area
xxxx   = Patch data.  The data is entered 2 hex bytes at a
         time, separated by commas or blanks.

The general file loader offline segment first checks for a REP card. The REP card indicates that the offline segment is to be patched before it executes. Any control card other than a REP card will return the program to normal load mode. The REP card must contain ALDR in columns 75-78 or the run will terminate.

Load CTKX Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  CTKX vv
 
vv   = version number

The Load CTKX card causes the image pointer record (CTKX) to be loaded to the general file in a 4KB record. A switch is set in the loader control record to indicate to the general file loader online segment that CTKX was loaded. When a new CTKX is loaded it is compared to the existing version on the GF. If the start ordinal of a CIMR or IPL component is different in the new CTKX, or the allocated size is too small, that component must also be loaded.

Patching

One or more REP cards can follow the Load CTKX card. Each REP card must contain CTKX in card columns 75-78 and the version number in columns 79-80.

Call General File Keypoint Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
GF       CALL  KEYPTnnnnvv
 
nnnn = Keypoint name
vv   = version number

The specified keypoints are written to the general file keypoint area. Only 2 keypoints contain information for the general file that is not the same as the information they carry for the online modules:

 CTKA 
Keypoint A

 CTKV 
Keypoint V

These keypoints have pertinent information about the general file and are used during the general file IPL. They are not used to configure the online system. These keypoints have to be called only if the online versions are called. This is because the Call Online Keypoint card will cause any keypoint not called by the Call General File Keypoint card to be written to the general file keypoint area and the online keypoint area. See Call Online Keypoint Card.

Patching
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
zREP  aaaaaa 001xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx    nnnnvv
 
z      = Any character except *
aaaaaa = Address of the patch area
xxxx   = Patch data.  The data is entered 2 hex bytes at a
         time, separated by commas or blanks.
nnnn   = Associated keypoint name
vv     = version number

A keypoint is patched by placing one or more REP cards after its Call General File Keypoint card. Each REP card must contain the same name and version number in card columns 75-80 as that punched in columns 21-26 of the corresponding Call General File Keypoint card.

Load Control Program Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  CP   vv
 
vv = version number

The offline loader builds a copy of the control program (CP) in main storage from the load module library. The CP is then filed on the general file as a chain of 4KB records (known as core-image records). A version number must be specified in columns 21-22. Switches are set in the loader control record to inform the general file loader online segment that the control program was loaded.

Because of main storage utilization, the CP must be loaded before file-resident programs are loaded to the general file. This restriction includes application program loads via OPL/PARS and LOADER LOAD AP cards. Attempts to load the CP after file-resident programs will cause the loader to abend.

Note:
The Load Control Program Card is only allowed in BSS.

Patching
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
zREP  aaaaaa 001xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx  ccccccvv
 
z      = Any character except *
aaaaaa = Address of the patch area
xxxx   = Patch data.  The data is entered 2 hex bytes at a
         time, separated by commas or blanks.
cccccc = CP CSECT name
vv     = version number

Patch the control program by placing REP cards after the Load Control Program card. Control program patching is accomplished by patching CP CSECTS individually starting at relative address zero. Each REP card must contain the CP CSECT name starting in column 73.

Load IPAT Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  IPAT vv
 
vv = version number

The Load IPAT card causes the program allocation table (PAT) to be loaded to the general file as core-image records. The time stamp in the header of system allocator table (SALTBL) will be used to validate the IPAT. If the time stamp in the header of the IPAT does not match the time stamp of the system allocator table (SALTBL), the load will be aborted.

Patching

One or more REP cards can follow the Load IPAT card. Each REP card must contain the IPAT in card columns 75-78 and the version number in columns 79-80.

Load Keypoint Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  KEYPT
 

The Load Keypoint card tells the offline segment that there are keypoints to be loaded to the working areas of the online modules. (The general file loader loads keypoints directly to the working keypoint area (#KEYPT), not the staging area (#KSAx)). The keypoints are identified by Call Online Keypoint cards that must follow the Load Keypoint card. These cards must come after the Call General File Keypoint card and the Load Control Program card.

Call Online Keypoint Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
GF       CALL  KEYPTnnnnvvON i
 
nnnn = Keypoint name
vv   = version number
ON   = an optional statement
i    = processor ID (optional)

The Call Keypoint cards must be preceded by a Load Keypoint card. These cards specify the names and version numbers of keypoints in columns 21-26. The valid keypoints are:

 CTK0 
Keypoint 0
 CTK1 
Keypoint 1
 CTK2 
Keypoint 2
 CTK3 
Keypoint 3 (Reserved for customer use)
 CTK4 
Keypoint 4 (Reserved for customer use)
 CTK5 
Keypoint 5
 CTK6 
Keypoint 6
 CTK9 
Keypoint 9
 CTKA 
Keypoint A
 CTKB 
Keypoint B
 CTKC 
Keypoint C
 CTKD 
Keypoint D
 CTKE 
Keypoint E
 CTKI 
Keypoint I
 CTKM 
Keypoint M
 CTKV 
Keypoint V

The specified keypoints are written to the general file, in an area that is reserved for online keypoints. ACPL copies the keypoints from the general file to the working keypoint area if the keypoints have not been called by a Call General File Keypoint card.

Each card sets a switch in the loader control record to indicate that the keypoint was loaded. The general file loader online segment uses this information when writing the keypoints to the online modules.

In a loosely coupled environment, when a processor-unique keypoint is being loaded, the processor ID is specified in column 30. If column 30 is blank, the default is the ID of the first processor in the system. When shared keypoints are being loaded, column 30 can be blank or any valid processor ID.

Leaving columns 27 and 28 blank on the Call Keypoint card (as in the example that follows) causes any associated REP card information to patch the Call Keypoint card information before the keypoint is loaded.

LOADER   CALL  KEYPTCTKA40   C    <-- Loads keypoint CTKA
 REP  000348 0014700    <-- Patches the new keypoint before loading -->   CKTA40

Placing ON in columns 27 and 28 of the Call Keypoint card (as in the example that follows) causes the associated REP card information to be written to the online keypoint without loading the keypoint to the general file.

LOADER   CALL  KEYPTCTKA40ON C    <-- No load of keypoint CTKA
 REP  000348 0014700    <-- Patches applied to online keypoint CTKA -->   CKTA40
Note:
At least one REP card must follow the Call Keypoint card when using the ON facility.

Patching
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
zREP  aaaaaa 001xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx    nnnnvv
 
z      = Any character except *
aaaaaa = Address of the patch area
xxxx   = Patch data.  The data is entered 2 hex bytes at a
         time, separated by commas or blanks.
nnnn = Associated keypoint name
vv     = version number

Each REP card must contain the same name and version number in card columns 75-80 as that punched in card columns 21-26 of the corresponding Call Keypoint card.

PROG-MOD-BASE Clear Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   PROG-MOD-BASE CLEAR

The PROG-MOD-BASE Clear card resets the master extra program record so that all extra program records (#XPRG1 fixed file records) are available to be dispensed. If the Clear card is present, ALDR sets an indicator for ACPL to initialize the master extra program record. This occurs on image 1.

The card is optional and can be placed anywhere after the LOAD CP card and before the LOAD OPL and LOAD AP cards. The card must be included to initialize a program base before any C load modules are loaded to that image.

Notes:

  1. All C load modules must be reloaded when the LOADER PROG-MOD-BASE CLEAR card is included.

  2. If the LOADER PROG-MOD-BASE CLEAR card is added while a ZOLDR ACCEPT is in progress for a loadset that contains a C load module, then the ELDR Clear card must also be included in the load deck.

ELDR Clear Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   ELDR CLEAR

The ELDR Clear card ensures clean E-type loader record definitions. If it is present, ALDR will set an indicator for ACPL to clear and reinitialize all E-type loader records for image one. To clear E-type loader records in other images, use the auxiliary loader.

Attention: The ELDR Clear card will cause all E-type programs that were loaded or activated (but not accepted) with the E-type loader to be cleared on the online system.

Load OPL Card and PARS Card
Load OPL Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  OPL            LIST
 
LIST = an optional parameter that causes the general file loader to print
          the name and version number of each program loaded.
 
 
PARS Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
 PARSvv
 
vv = PARS list version

The Load OPL card causes E-type programs to be loaded to the general file. The programs are defined by one or more operational program list (OPL) records. Each of these records contains a series of segment names and version numbers. Each of these records resides on the object module library with the name PARS and a unique 2-character version number. Different lists are indicated by different PARS cards.

If the Load OPL card is not followed by a PARS card then the program uses PARS00 as the list of OPL programs. If one or more PARS cards are supplied, the version numbers specified are used.

The optional operand LIST in card columns 31-34 of the Load OPL card causes the general file loader to print the name and version number of each program loaded.

Patching
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
zREP  aaaaaa 001xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx    nnnnvv
 
z      = Any character except *
aaaaaa = Address of the patch area
xxxx   = Patch data.  The data is entered 2 hex bytes at a
         time, separated by commas or blanks.
nnnn   = Segment name
vv     = version number

One or more REP cards can follow the PARS cards or, if no PARS cards are present, the Load OPL card. Each REP card must contain the segment name and version number in card columns 75-80. Although the offline segment of the general file loader will handle patch cards for different segments in any sequence and freely intermixed, the execution time will be minimized if all REP cards for a segment are in one group. This eliminates needless I/O operations.

Note:
REP cards for C load modules are not supported. If a REP card is specified for a C load module, a warning message is issued and the REP card is ignored.

Load AP Card and Call Program Card
Load AP Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  AP             LIST
 
LIST = an optional parameter that causes the general file loader to print
          the name and version of each program loaded.
 
 
Call Program Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   CALL  PROG nnnnvv
 
 
nnnn = program name
vv   = version number

The Load AP card tells the general file loader offline segment to accept Call Program cards for the selective loading of E-type programs. Any program loaded by this function will overlay any other version of the same program already loaded from an OPL record.

The optional operand LIST in card columns 31-34 of the Load AP card causes the general file loader to print the name and version number of each program loaded.

Note:
If there is a Call Program card syntax error, that program will not load. Also, all cards that follow the incorrect card (with the same Load AP card) will not load.

Patching
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
zREP  aaaaaa 001xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx    nnnnvv
 
 
z      = Any character except *
aaaaaa = Address of the patch area
xxxx   = Patch data.  The data is entered 2 hex bytes at a
         time, separated by commas or blanks.
nnnn   = Segment name
vv     = version number

One or more REP cards can follow a Call Program card. Each REP card must contain the same name and version number in card columns 75-80 as that punched in card columns 21-26 of the corresponding Call Program card.

Note:
REP cards for C load modules are not supported. If a REP card is specified for a C load module, a warning message is issued and the REP card is ignored.

Load ACPL Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  ACPL vv
 
vv = version number

When the program encounters the Load ACPL card, the general file loader online segment is loaded to the general file as core-image records. Its file address on the general file is generated from its ordinal number obtained from CTKX. Switches are set in the loader control record to indicate to the general file loader online segment that the online segment was loaded.

Note:
ACPL can only be loaded for BSS.

Patching
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
zREP  aaaaaa 001xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx    ACPLvv
 
z      = Any character except *
aaaaaa = Address of the patch area
xxxx   = Patch data.  The data is entered 2 hex bytes at a
         time, separated by commas or blanks.
vv     = version number

One or more REP cards can follow the Load ACPL card. Each REP card must contain ACPL in card columns 75-78 and the version number in columns 79-80.

Load ICDF Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  ICDF vv
 
vv   = version number

The Load ICDF card causes the in-core dump formatter (ICDF) to be loaded to the general file as core-image records. Its file address on the general file is generated from its ordinal number obtained from CTKX. A switch is set in the loader control record to indicate to the general file loader online segment that ICDF was loaded.

Note:
ICDF can only be loaded for BSS.

Patching
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
zREP  aaaaaa 001xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx    ICDFvv
 
z      = Any character except *
aaaaaa = Address of the patch area
xxxx   = Patch data.  The data is entered 2 hex bytes at a
         time, separated by commas or blanks.
vv     = version number

One or more REP cards can follow the Load ICDF card. Each REP card must contain ICDF in card columns 75-78 and the version number in columns 79-80.

Load FCTB Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  FCTB vv
 
vv = version number

The Load FCTB card causes the FACE table to be loaded to the general file as core image records. Its file address on the general file is generated from its ordinal number obtained from CTKX. A switch is set in the loader control record to indicate to the general file loader online segment that the FCTB was loaded. If the FCTB is to be loaded in program object format from the hierarchical file system (HFS) under OS/390 UNIX System Services (OS/390 UNIX), specify the name of a search path that was previously initialized in the load deck by a Path card. The format of the Load FCTB card, including the optional path name, follows.

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  FCTB vv/pathname
 
vv = version number
pathname = variable length alphanumeric name assigned by user to search path

Patching
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
zREP  aaaaaa 001xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx    FCTBvv
 
z      = Any character except *
aaaaaa = Address of the patch area
xxxx   = Patch data.  The data is entered 2 hex bytes at a
         time, separated by commas or blanks.
vv     = version number

Only data in the first 16 MB of the FCTB can be patched.

Load SIGT Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  SIGT vv
 
vv = version number

The Load SIGT card causes the global synchronization table (SIGT) to be loaded to the general file as core-image records. Its file address is generated from its ordinal number obtained from CTKX. A switch is set in the loader control record to indicate to the general file loader online segment that SIGT was loaded.

Patching
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
zREP  aaaaaa 001xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx    SIGTvv
 
 
z      = Any character except *
aaaaaa = Address of the patch area
xxxx   = Patch data.  The data is entered 2 hex bytes at a
         time, separated by commas or blanks.
vv     = version number

One or more REP cards can follow the Load SIGT card. Each REP card must contain SIGT in card columns 75-78 and the version number in columns 79-80.

Load USR1 Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  USR1 vv
 
vv = version number

The Load USR1 card causes the first user-defined CIMR area (USR1) to be loaded to the general file as core-image records. Its file address is generated from its ordinal number obtained from CTKX. SIP automatically generates one ordinal number for USR1. A switch is set in the loader control record to indicate to the general file loader online segment that USR1 was loaded. The load USR1 card is required for a full load.

Note:
USR1 can only be loaded for BSS.

Patching

One or more REP cards can follow the Load USR1 card. Each REP card must contain USR1 in card columns 75-78 and the version number in columns 79-80.

Load USR2 Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  USR2 vv
 
vv = version number

The Load USR2 card causes the second user defined CIMR area (USR2) to be loaded to the general file as core-image records. Its file address is generated from its ordinal number obtained from CTKX. SIP automatically generates one ordinal number for USR2. A switch is set in the loader control record to indicate to the general file loader online segment that USR2 was loaded. The load USR2 card is required for a full load.

Patching

One or more REP cards can follow the Load USR2 card. Each REP card must contain USR2 in card columns 75-78 and the version number in columns 79-80.

Load IPLA Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  IPLA vv
 
vv = version number

The Load IPLA card causes program IPLA to be loaded to the general file as core-image records. Its file address is generated from its ordinal number obtained from CTKX. A switch is set in the loader control record to indicate to the general file loader online segment that IPLA was loaded.

Notes:

  1. This is not the IPLA that is used on the general file IPL. The general file IPL uses the IPLA records that were written to the general file by the ICKDSF MVS program.

  2. IPLA can only be loaded for BSS.

Patching
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
zREP  aaaaaa 001xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx    IPLAvv
 
 
z      = Any character except *
aaaaaa = Address of the patch area
xxxx   = Patch data.  The data is entered 2 hex bytes at a
         time, separated by commas or blanks.
vv     = version number

One or more REP cards can follow the Load IPLA card. Each REP card must contain IPLA in card columns 75-78 and the version number in columns 79-80.

Load IPLB Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  IPLB vv
 
vv = version number

The Load IPLB card causes program IPLB to be loaded to the general file as core-image records. Its file address is generated from its ordinal number obtained from CTKX. A switch is set in the loader control record to indicate to the general file loader online segment that IPLB was loaded.

Note:
IPLB can only be loaded for BSS.

Patching
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
zREP  aaaaaa 001xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx    IPLBvv
 
 
z      = Any character except *
aaaaaa = Address of the patch area
xxxx   = Patch data.  The data is entered 2 hex bytes at a
         time, separated by commas or blanks.
vv     = version number

One or more REP cards can follow the Load IPLB card. Each REP card must contain IPLB in card columns 75-78 and the version number in columns 79-80.

Load RIAT Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   LOAD  RIAT vv
 
vv = version number

The Load RIAT card causes the record identifier attribute table (RIAT) to be loaded to the general file as core-image records. Its file address is generated from its ordinal number obtained from CTKX. A switch is set in the loader control record to indicate to the general file loader online segment that RIAT was loaded.

Patching
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
zREP  aaaaaa 001xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx,xxxx    RIATvv
 
 
z      = Any character except *
aaaaaa = Address of the patch area
xxxx   = Patch data.  The data is entered 2 hex bytes at a
         time, separated by commas or blanks.
vv     = version number

One or more REP cards can follow the Load RIAT card. Each REP card must contain RIAT in card columns 75-78 and the version number in columns 79-80.

LDT Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
 LDT

This must always be the last control card for a given run and stops processing. If no LDT card is present, a message is printed, stating that the run cannot be completed.

Path Card
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   PATH  pathname        optional comments
         searchpath
 
pathname = alphanumeric name, up to 16 characters in length, used to reference the search path
searchpath = fully qualified search path occupying up to 14 input cards, as described below

The optional Path card actually consists of two or more cards in the input deck, and is used to initialize a search path that can be referenced on a subsequent Load FCTB card to load an FCTB, in program object format, from the hierarchical file system (HFS) under OS/390 UNIX System Services (OS/390 UNIX). The first card specifies the name that can be used on a subsequent Load FCTB card to reference the search path. After the actual Path card, as many as 14 additional input cards can be included to specify directories in the search path.

One or more absolute directories can be specified starting with the first directory to be searched and ending with the last directory to be searched. If more than one directory is specified, a ; symbol must separate directories. Blanks that follow a ; symbol are ignored. The presence of any character other than a blank in column 80 indicates that the search path continues starting in column 10 on the next card in the load deck. If there is no continuation character in column 80, the path will include all characters starting in column 10 and ending with the last nonblank on the input card. Comments can be included on the Path card starting in column 33. However, comments cannot be included on the subsequent cards that specify the actual search path because all nonblank characters are considered part of the path. An example of a Path card and continuation card that is used to specify a search path for the FCTB follows:

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
 
LOADER   PATH  FCTBPATH         Defining FCTBPATH for later user
         /u/tpf41/produt_components/system/;                                   X
         /u/tpf41/product_components/test/;                                    X
         /u/user1/my_project/tables;                                           X
         /u/tpf41/my_project/phase_one/beta_test_versions/file_address_compute_X
         table/program_object
 

If the Path card shown in the previous example was specified before a Load FCTB card for FCTB40 that specifies FCTBPATH in the load deck, TPFLDR would then attempt to locate the FCTB as a program object file by searching for the following files, in order:

  1. /u/tpf41/product_components/system/FCTB40
  2. /u/tpf41/product_components/test/FCTB40
  3. /u/user1/my_project/tables/FCTB40
  4. /u/tpf41/my_project/phase_one/beta_test_versions/file_address_compute_ table/program_object/FCTB40
Note:
A path name can be defined only once in the load deck. The Path card defining a path name must precede the Load FCTB card that references the path name.

Loading System Components to the General File

Figure 16. General File Load Using the General File Loader Offline Segment (ALDR)




When you create your TPF system for the first time, you must format online modules, initialize and format the general file, and load IPLA and the volume identifier (VOLID) to the general file. See Initializing the General File and Formatting the General File and Online Modules for more information.

The remainder of the general file is loaded by the general file loader offline segment (ALDR). ALDR activates the TPF linkage editor (LEDT/NLDT) to link the E-type programs with input from the system allocator table (SALTBL). ALDR then loads all the records and programs specified in the load deck to the general file.

ALDR also creates a loader control record (LDCRL) on the general file. This control record shows the general file loader online segment (ACPL) the components to load from the general file to the online modules.

Output Listing

An output listing is produced which details all system components loaded to the general file. Errors which do not cause the program to abend are also written in this listing. Abend error messages and informational messages are sent to the operator console. For more information on error messages see Messages (System Error and Offline) and Messages (Online).

IPLing the General File

Figure 17. General File IPL Using the General File Loader Online Segment (ACPL)




When you IPL the general file, the general file loader online segment (ACPL) is placed in main storage. ACPL uses the loader control record (LDCRL) segment to put the contents of the general file onto online modules.

Keypoints are loaded to the prime and duplicate modules. They are copied to the first 256 modules of the same type as the prime module during online execution.

At the completion of the online loading, the operator is notified about all components loaded. If the IPL is unsuccessful, the operator is sent all of the error messages for the run.

Note:
See Messages (System Error and Offline) and Messages (Online) for a complete listing of error and status messages.

If the IPL is successful, the general file loader sends the following message to the operator's terminal:
ACPL0001I SYSTEM LOAD COMPLETE
LOAD DATA AFTER 1052 STATE IF NEEDED
IF NOT IPL PRIME MODULE ccud

This message reminds an operator performing a full load to load data after the system announces it is in 1052 state (see Loading Fixed-File Records).

Loading Fixed-File Records

Figure 18. Loading Fixed-File Records Using the ZSLDR Command




The first time a system has been brought to 1052 state by a general file IPL it should be loaded, using the data loader, with fixed-file records. These records are used by the system and by the application programs.

To load fixed-file records, do the following:

  1. Create a pilot tape (symbolic name = SDF) with the system test compiler (STC) program. See TPF Program Development Support Reference for information on the system test compiler program.
    Note:
    A maximum of 65 535 records can be read or written from a pilot tape.
  2. Mount the pilot tape (SDF). This is the only input to the data loader.
  3. Enter the ZSLDR command to activate the data loader. See TPF Operations for more information about the ZSLDR command.
    Note:
    Once records are loaded to the TPF database, no utility is available to remove the records from the database. If it is necessary to delete previously loaded records from the TPF database, you must create and load a new pilot tape that contains dummy records. If the number of records decreases from one load to the next, the additional records from the first load will not be removed from the database.
  4. Either of 2 actions can now be taken.
    1. If the loaded records are meant for main storage, an online module IPL must be performed to place the records there.
    2. The system can be cycled to NORM state without an online module IPL. An IPL will be required in the future to place the records in main storage.

Notes:

  1. The data loader can be operated only while the TPF system is in 1052 state unless the ID of the pilot tape is N. If the ID of the pilot tape is N, the TPF system can be in any state.

  2. In a loosely coupled facility, the subsystem cannot be above 1052 state in any processor unless the ID of the pilot tape is N. If the ID of the pilot tape is N, the subsystem can be in any state.