At system startup, REP files, consisting of REP records, can be used to correct the SYSIPL, SYSSTART and SLED load objects and the Control System.
REP records permit byte-by-byte correction of the load modules itemized above. “Selectable units” that are not linked to Exec can also be corrected by means of REP records. The corresponding REP file is named SYSREP.<selectable unit>.<ver>. REP records cannot be used to exchange entire modules. Instead, these must be imported into the associated library (OML) with LMS.
In general, REP processing is applied to the last object loaded. Loading of the BS2000 operating system takes place in two steps; each of these is corrected individually.
Class 1 REP records are processed immediately after the resident part of the Control System is loaded. They should be created only for those class 1 modules (resident part) of the Control System that are needed for loading and initializing class 2 modules (non-resident, pageable part) of the Control System. The relocation of correction data in class 1 REP records is limited to class 1 modules and system startup modules; entries can only be relativized at the beginning of the module.
Class 2 REP records are processed immediately after the non-resident part of the Control System is loaded. These records can be used to correct all the remaining modules of the Control System. Relocation of correction data is possible for all modules and entries.
REP processing during system initialization
Except when an error arises, REP processing is executed automatically during FAST and AUTOMATIC startup, i.e. without interaction with the operator. In the case of DIALOG startup, REP processing can be influenced by the operator, except for SYSIPL and SLED.
During FAST and AUTOMATIC startup, the REPs to be processed are expected in the $TSOS.SYSREP.BS2.<ver> and $TSOS.SYSREP.STRT.<ver> files on the home pubset, unless the startup parameter file specifies other REP files for the Control System (REPFILEx parameter). A dialog with the operator will only be initiated if errors arise.
The default names of the REP files are:
for BS2000: SYSREP.BS2.<ver>
for SYSIPL: SYSREP.IPL.<ver> 1 copied to file SYSREP.IPL.DSKnnn
for SYSSTART: SYSREP.STRT.<ver>
for SLED: SYSREP.SLED.<ver> 1 copied to file SYSREP.SLED.DSKnnn
With DIALOG startup, REP files may be on a public disk or private disk or they may be input via the console.
The processing sequence is determined by the operator, who specifies an input device in response to each NSI0050 message. The REPs are processed immediately. Thereafter, the NSI0050 message appears again. This procedure is repeated until the operator enters P.END (or P., if a REP file with a standard name has already been processed) as the response (see next page).
A disk file can be specified four times and the console twice as the input device. A check is made to see whether the specified file has already been processed. These restrictions apply only to BS2000 REP files. They do not apply to any other objects.
Dialog at the console is opened separately for class 1 REP records and class 2 REP records. The entered data is treated exactly as if it had been input via a REP file. It is also written to the save file SYS.NSI.SAVEREP and later to the REPLOG ($SYSAUDIT.SYS.REPLOG.<date>.<sessno>.01) file.
Processing REP files for SYSIPL and SLED
REPs for SYSIPL and SLED are each held in a REP file which is stored in the SVL by SIR. During system initialization or the generation of diagnostic information, the operator has no opportunity to select another REP file.
For the same reason, the type of system initialization has no influence on this part of the REP processing.
If these REP files are modified, they must again be incorporated in the SVL with SIR (CREATE-IPL or MODIFY-IPL function).
1These files are copied by SIR and are then anchored in SVL. They cannot be addressed using file names (see below).
Structure of a REP file
A REP file for system initialization has the following structure:
BS2000_LOADER[_comment] | 1st record (mandatory) |
Class 1 REP records | REP records for selected modules of the resident part of the Control System and system initialization (optional) |
_END[_comment] | End statement for class 1 REP records (mandatory) |
Class 2 REP records | REP records for the entire Control System (optional) |
_END[_comment] | End statement for class 2 REP records |
/[_comment] | End-of-file identifier |
*%comment | The comment record is output to the console (does not apply to comments in SYSREP.IPL.vvv) |
This structure applies equally to SYSIPL, SLED, SYSSTART and BS2000. The distinction between class 1 REP processing and class 2 REP processing is only relevant for BS2000.
Either a second END statement or an end-of-file identifier must exist as the end criterion for class 2 REP records and the REP file.
On disk, the REP records may be 1-256 bytes long, although the characters after the 80th byte are not processed.
The REP file is a SAM file with variable records and standard blocking BUFFER-LENGTH=STD(SIZE=1) or (SIZE=2). The file name can be freely selected. Changes to the REP file on disk should only be made with RMS (see section "RMS: REP delivery and installation").
The REP files are read and processed in the order specified by systems support.
The console can be specified twice as the REP input device. If any faulty disk REPs were read in, these can be corrected again at the end, from the console.
Comment records (with * in column 1) can be inserted anywhere in the REP file after the record “BS2000 LOADER”. They are ignored by startup. Comment records with the % character in column 2 are logged via the console (does not apply to comments in SYSREP.IPL.vvv).
REP records for modules that are not linked into the Control System but whose names are known to the Control System are skipped without an error message. It is thus possible to integrate REP records for all modules of a given BS2000 version in a REP file.
REP records containing invalid module names are logged as faulty. However, if a REP record contains an “S” or “U” in column 69, the error message is suppressed. In this way REP records for modules that are (still) unknown to the Control System (e.g. selectable units, "Function and structure of a REP file") can be included in the REP file.