The BS2000 system initialization procedure consists of “bootstrapping”, i.e. more and more powerful functional units are loaded and started step by step until BS2000 is operational.
Execution of the various routines is initiated on a hardware-dependent basis via the service processor (SVP) on SU /390 or X2000 on SU x86, or via restart processing in the case of automatic restart. This initial program loading (IPL) starts system initialization. Here both the IPL disk and the type of system initialization are defined. The setting for the load options for BS2000 defines whether the system startup is to take place in a convenient or flexible way.
In FAST and AUTOMATIC mode, system initialization is convenient and to a large extent automatic. In DIALOG mode, system initialization is flexible and interactive (see section "Types of system initialization").
For a VM2000 guest system, system initialization is started by means of the SE Manager (see the “Operation and Administration” manual [57]) or using the VM2000 command START-VM (see the “VM2000” manual [60]). On SUs x86 the VM2000 guest system can also be started using the SVP functions on the KVP console which is assigned to the virtual machine.
The most important steps in the system initialization procedure, from the point at which the hardware is made available through to the end of the startup procedure, “System ready”, are:
Figure 2: Flow chart of functions for BS2000 system initialization
System initialization for BS2000 can begin when the required hardware units (MU, Server Units, peripheral devices) have been activated and are operational. The relevant operation guides for the SE servers involved describe in detail how to perform these steps, i.e. how to activate the power supply, load the firmware, etc.
Internally, system initialization for BS2000 begins with the loading of the initial program loader (SYSBOOT). This is actually performed by the HW-IPL routine (step (1) in figure 2).
SYSBOOT is the first program in system initialization. It performs elementary checks and initiates other load routines (step (2) in figure 2).
The routine loaded and started by SYSBOOT is SYSIPL, which queries the options in DIALOG mode and determines the current disk and CPU configuration (step (3) in figure 2). The time base for the system time is defined. The disk configuration is checked to ensure that it is complete and unique. With DRV disks in the home pubset, the associated disk pairs are established. In addition, this routine loads and corrects SYSSTART or SLED.
The two programs SYSBOOT and SYSIPL and the IPL REP file reside in fixed locations on a specific disk known as the IPL disk. The IPL disk may be a public disk (a disk belonging to a pubset) or a private disk. For FAST and AUTOMATIC startup, this must be one of the disks of the home pubset.
Private disks may only be used for initial program loading in a DIALOG startup. At a later stage in the system initialization procedure, the operator must specify which pubset is to be the home pubset for the session.
When initial program loading takes place from a public disk, the pubset to which the disk belongs is automatically selected as the home pubset. Only in the case of dialog startup with the ALLDISK option can the operator still change the pubset.
If the IPL disk does not belong to the later home pubset, particular care must be taken to ensure that the versions and correction statuses on the two are the same.
A disk configuration may include more than one IPL disk. Setting up IPL disks is a systems support task performed using the SIR utility routine, described in detail in the “Utility Routines” manual [5].
An IPL disk can be used either for SUs /390 or for SUs x86.
When loading SYSBOOT and SYSIPL/SLED the BS2000 file management functions are not yet available. The necessary files can therefore only be found if they are “anchored” beforehand on the lPL disk. This is done with the CREATE-IPL-VOLUME statement of the SIR utility and consists of the following steps:
The files needed to load SYSBOOT and SYSIPL/SLED are copied to the IPL disk.
The backup files used by SYSBOOT and SLED are created on the IPL disk.
A direct reference to each of these files is entered in the SVL of the IPL disk:
Original file
File created by SIR
---
SYSDAT.IPL-CONF.DSKnnn
---
SYSPRG.BOOT.DSKnnn.SAVE
SYSPRG.IPL.<ver>
SYSPRG.IPL.DSKnnn
---
SYSPRG.SLED.DSKnnn.SAVE
SYSREP.IPL.<ver>
SYSREP.IPL.DSKnnn
SYSREP.SLED.<ver>
SYSREP.SLED.DSKnnn
“nnn” stands for the number of the IPL disk within the pubset. If the IPL disk is a private disk, then the VSN of the private disk is used instead of the DSKnnn name section.
If not yet present on a different disk belonging to the pubset, the backup file for system patches, SYS.NSI.SAVEREP, is created (but not for private disks).
The original files are not needed anymore to initialize the system and can safely be changed while the system is running to, for example, to accept a new correction status. However, all changes only affect the initialization of the system after new copies have been created and anchored with SIR.
The anchored files may not be changed or deleted during operation because that will generally destroy the disk's IPL capability. They are protected by SIR with BACKUP-CLASS=E and MIGRATE=INHIBITED so that they cannot be moved or preempted.
All the other routines required for system initialization reside as “normal files” on either a pubset or a private disk.
The configuration tables are generated dynamically.
SYSSTART (step (4) in figure 2) is a program that prepares and carries out system initialization proper for BS2000. The preparation stage mainly involves reading in the parameters for BS2000, determining the object code corrections for the class 1 Executive and checking the SYSSTART and BS2000 versions for consistency. During execution, the individual BS2000 initialization functions are called via tables. These initialization functions also include the virtual memory management data structures and the initialization of the paging areas used by SYSSTART to prepare the transition to BS2000 virtual addressing mode.
Finally, SYSSTART calls the BS2000 load system (step (5) in figure 2), which consists of the two parts “class 1 Executive” (resident) and “class 2 Executive” (pageable).
At this stage of system initialization, a device management application is made for access rights to system initialization devices (disks of the home pubset and paging pubsets). Once this phase of system initialization is complete, the BS2000 load system has been loaded, patched and parameterized.
BS2000 is said to be loaded once this part of it is contained in its entirety in main memory. The portions of BS2000/OSD which are resident in main memory (class 1 Executive) are loaded first. The remaining portions are pageable. SYSINIT copies these routines to the paging memory via main memory.
Patched means that modules of these portions have been modified by SYSSTART during system initialization by means of REP records. REP records can be read in from a maximum of four cataloged disk files in any order. The console can also be defined as the input device, but not for REPs for SYSIPL. During system initialization, all REP records processed from disk and console are written to backup file SYS.NSI.SAVEREP and later logged in the file $SYSAUDIT.SYS.REPLOG.<date>.<sessno>.01.
Parameterized means that a set of parameter records containing statements for the BS2000 initialization routines has been read in. The entire parameter input consists of a series of sections - identified by specific keywords - that affect specific functional units and are evaluated by these functional units (see chapter chapter "Parameter service").
By presetting a value on system start, the operator can specify that loading, patching and parameterization are to be almost fully automatic and noninteractive (in this case, files with default names are used) or that these procedures are to be more flexible, controlled by means of a dialog with the operator.
The final phase of BS2000 system initialization is started using E2START (step (6) in figure 2). This routine is already executing under BS2000 and first determines the name of the command file (CMDFILE) to be started automatically after “System ready”.
To make BS2000 operational, this phase includes the execution of initialization routines for:
activating the task scheduler
opening the system files (user catalog, SYSEAM, etc.)
making file catalog management available
activating the dynamic binder loader (DBL)
activating the PLAM library access method
starting the functions for monitoring disk and tape devices
activating the SERSLOG function
starting DSSM (Dynamic SubSystem Management) 1)
Once the memory occupied by system initialization has been released and the job scheduler started, “System ready” has been reached and processing of the commands stored in the command file CMDFILE is initiated. Although it is not mandatory to use a command file - the name of which may be freely selected - it is highly advisable because of the demand for automation of the operations.
Command files can be used for the automatic activation of the system components and settings that make a specific system operable:
starting up the optional subsystems
starting the BS2000 data communication system 2)
loading the SPOOL system 3)
specific load regulation
activating special programs by means of ENTER files
Notes
1) | DSSM: When a subsystem is started, DSSM uses IMON-GPN to determine the path names of all the files of the subsystem from the current SCI. If IMON-GPN is not available (already loaded when DSSM is started) or if there is no file under the specified path name, DSSM uses the standard names entered in the subsystem catalog. If a standard name is used, message |
2) | Data communication system (DCM): If that is not the case, the data communication system has to be activated separately after each system initialization. This is done by means of the DCSTART command, which is stored in the CMDFILE for reasons of convenience. The DCSTART command automatically initiates opening of the following internal privileged applications of the system:
If the first DCSTART command is issued later than 10 min. after the “System Ready” or if the DCM is terminated while BS2000 is running (BCEND command) and restarted, the $DIALOG application must be started manually by the operator using the START-DIALOG-APPLICATION command. Another option would be to include /START-DIALOG-APPLICATION in BCAM’s SOF (Start Option File). A prerequisite for this is that a console access has been configured for BCAM with the authorization for START-DIALOG-APPLICATION (see the “BCAM” manual [4]). In the operating mode with operator logon, the operator must first enter SET-LOGON-PARAMETERS and REQUEST-OPERATOR-ROLE commands after “System ready” before being able to enter further commands. Consequently, it is advisable to also remove the prerequisites for the first two commands from the CMDFILE. The prerequisites are as follows:
Since the operator ID has to be unlocked under the TSOS ID but an operator role can only be set up and assigned to an operator ID under SYSPRIV, it is advisable to invoke from the CMDFILE an ENTER job which issues the UNLOCK-USER command and calls a further procedure for setting up and assigning the operator roles under the SYSPRIV ID. The whole process could look something like this: Call from the CMDFILE:
Contents of the E.OPR-LOGON.TSOS file /SET-LOGON-PARAMETERS / UNLOCK-USER SYSPRIV / SET-JOB-STEP / UNLOCK-USER SYSOPR / SET-JOB-STEP / ENTER-JOB FROM-FILE=$TSOS.E.OPR-LOGON.SYSPRIV,- / PROC-ADMISS=*PAR(USER-ID=SYSPRIV,- / ACC=SYSACC,- / PASS=*NONE) /EXIT-JOB Contents of the E.OPR-LOGON.SYSPRIV file /SET-LOGON-PARAMETERS / CREATE-OPERATOR-ROLE OPERATOR-ROLE=SYSADM,ROUT-CODES=*ALL / SET-JOB-STEP / MODIFY-OPERATOR-ATTR USER-ID=SYSOPR,ADD-OP-ROLE=SYSADM / SET-JOB-STEP / INFORM-OPERATOR,- / MSG='*** OPERATOR-ROLE SYSADM CREATED AND ADDED ***' / INFORM-OPERATOR,- / MSG='+------------------------------------------------------+' / INFORM-OPERATOR,- / MSG='! THE FIRST OPERATOR COMMANDS AFTER SYSTEM READY !' / INFORM-OPERATOR,- / MSG='! (BEFORE /DCSTART ... ) MUST BE: !' / INFORM-OPERATOR,- / MSG='! /SET-LOGON-PARAMETERS SYSOPR,SYSACC !' / INFORM-OPERATOR,- / MSG='! /REQUEST-OPERATOR-ROLE OP-ROLE=SYSADM !' / INFORM-OPERATOR,- / MSG='+------------------------------------------------------+' /EXIT-JOB Only then is BS2000 capable of communication. |
3) | SPOOL: |
To summarize, system initialization consists of the following internal steps:
HW-IPL: | - Loading the 1st block of SYSBOOT |
SYSBOOT: | - Loading the 2nd block of SYSBOOT - Loading SYSREP.IPL.<version> |
SYSIPL: | - Self correction - Loading, correcting and starting SYSSTART |
SYSSTART: | - Reading in the parameters - Loading and correcting the memory-resident portions of BS2000 (class 1 exec) |
Class 1 | - Initialization of the resident portion of BS2000Automatic attachment of the disk devices which were generated asDETACHED and on which are mounted the necessary public disks 1 - Loading the pageable portion of BS2000 (class 2 exec) |
Class 2 | - Initialization of the pageable portions |
SYSINIT | - Determining the command file and calling initialization functions for BS2000 functional units (DSSM, PLAM, etc.) - Release of occupied memory and start of the job scheduler |
„System Ready“ | |
1 During the startup phase, all public disks of the home pubset and all pubsets which contain paging disks and which were specified in the parameter service are automatically attached to the system, even if they were explicitly generated as DETACHED. The devices of the home pubset remain ATTACHED during the entire session.
The SHOW-SYSTEM-INFORMATION command can be used to obtain information on the system configuration, the VM2000 version used, the monitor system and the time setting parameters.