Regardless of the type of server to be controlled by the operator, it is important to answer the following questions in advance in order to make sure that the loading procedure is executed correctly:
How are the required files and devices identified?
What points must be observed regarding unique disk configuration?
How is the home pubset determined and checked for completeness and consistency?
How does the system react to assigned pubsets or detached devices?
What can cause devices to be unavailable during system initialization?
What points must be observed regarding multiprocessors?
What is the function of the parameter file in system initialization?
How is the loading procedure logged?
What must be taken into account with regard to Unicode capability?
Identification of the required files and devices
The volumes required for HW-IPL must be addressed as follows:
For SUs /390, the IPL device is identified by the device number. For devices with a four-digit MN, the device number is the same as the MN. For devices with a two-digit MN, there is a unique assignment between device number and MN, which is described in the "System Installation" manual [55].
For SUs x86, the IPL device is identified by the mnemonic device name (MN).
Only disks of the home pubset should be used as IPL disks. Disks with a physical block size of 4KB are not supported as IPL disks.
All other devices subsequently required for the loading procedure are identified by the mnemonic device name MN.
If files which are stored on private disks are used for system initialization, not only the file name but also the corresponding VSN must be specified. Private disks may be used only if they are included in the disk configuration for system initialization.
Unique disk configuration
After SYSBOOT, SYSIPL determines the available disk configuration (via an online scan). At this point, the BS2000 device tables, i.e. the generated hardware configuration, are not yet available.
Multiple online scan sessions are prevented by creating a separate table for all disks identified that are not added to the system initialization device table. If one of these disks is used later on, then it is added to the system initialization device table without performing another online scan.
Private disks are only accepted into the disk configuration for system initialization if the IPL disk itself is a private disk, if private disks are required for a SLED dump, or if the operator explicitly requests this (by selecting the ALLDISK option in the DIALOG initialization mode).
System initialization is problem-free only if each accessible disk has a unique VSN. If more disks with the same VSN can be accessed, this will normally be recognized.
Exception: the current IOCF of the SU /390 is not correct.
If disks having the same VSN are detected and at least one of these is not a DRV disk, then the system proceeds as follows: When the disks belong to the same pubset as the IPL disk, then the disk with the same time stamp as the IPL disk is selected. If none of the disks has the same time stamp as the IPL disk or the disks belong to a different pubset than the IPL disk, then a check is made to see if one of the disks was already selected by responding to message NSI2208. If this is true, then this disk is selected again. This applies not only to pubset disks but also to private disks.
In the exceptional case stated above, any discrepancy between the real and generated configurations goes undetected. If system initialization is then continued, this may result in unpredictable I/O errors and the destruction of disk contents!
During system initialization, all attached devices are normally checked to determine the disk configuration. This process can be time-consuming and prone to error, especially if a large number of peripherals are being used (e.g. devices that are not required and therefore not operational are addressed). To circumvent this process, the following option is offered: The disk configuration actually required for system initialization (i.e. all disks of the home and paging pubsets and any private disks used) can be saved in SYSDAT.IPL-CONF.DSKnnn, a file reserved for this purpose on the IPL disk (nnn = number of the IPL disk in the pubset).
Dynamic partitioning of the IPL-CONF file
The IPL-CONF file (SYSDAT.IPL-CONF.DSKnnn) is partitioned dynamically. This enables multiple startup configurations to be stored in this file. Each configuration in the configuration file is identified by the IPL-CPU-ID, home PVS-ID and IORSF date. During startup, if a matching configuration is found, it will be used and no online scan will be performed unless explicitly requested. When no matching configuration exists, online scan will be initiated and a new configuration will be written to the file.
When a pubset is used as the home pubset on various servers, the entries for the startup configuration in the IPL-CONF file are not lost, but each is stored in a separate partition. When the server is switched, the corresponding startup configuration is used without an online scan necessarily being required.
A new startup configuration does not overwrite an existing one, but is entered as a new startup configuration after the last existing one. When an existing startup configuration is modified, the original one is “discarded” and the modified startup configuration is entered like a new one after the last existing one.
However, the IPL-CONF file is not enlarged: When there is a lack of space, the startup configurations declared invalid are first of all deleted one after the other. If the free space in the file is still not sufficient after this, the startup configuration which has remained unused for the longest time is removed. This action is performed without consulting the operator and is repeated until enough space is available for the new or modified startup configuration.
The IPL-CONF file can contain, for example, 12 startup configurations each with 255 disks. When there are fewer disks, the number of configurations increases: Consequently, 30 configurations each with 100 disks or 57 configurations each with 50 disks are possible, for instance.
Saving a startup configuration in the IPL-CONF file is initiated as follows:
in DIALOG mode:
If the operator responds to the messageNSI1110with the IPL-CONF option SAVE, the startup configuration is saved as a new partition.In all startup modes:
The startup configuration is saved when:the IPL disk is one of the disks of the home pubset
and the IPL-CONF option IGNORE has not been explicitly specified
and online scan has been performed.
The online scan is always performed automatically when the home pubset or one or more paging pubsets has/have been extended or a new paging pubset has been specified using BS2000 parameters (in the SYSPAR.BS2.nnn file or via the console).
The file is then used automatically for all subsequent system initializations, provided that the VSN of the saved pubsets, the mnemonic device name MN, the disk type and the number of disks belonging to the pubsets remain unchanged.
To support modifications to existing, startup configurations in the SYSDAT.IPL-CONF.DSKnnn file (e.g. if an extended or different pubset is used), in DIALOG mode the message NSI1110 offers the operator the following functions if the IPL-CONF option is specified:
IGNORE function:
The existing valid startup configuration in the SYSDAT.IPL-CONF.DSKnnn file is ignored. An online scan is executed.RESET function:
The current valid startup configuration in the SYSDAT.IPL-CONF.DSKnnn file is still used for the current system initialization and is then declared invalid.SAVE function:
The disk configuration required for startup is saved in the SYSDAT.IPL-CONF.DSKnnn file as a new partition.
All combinations except SAVE and RESET are valid.
Determining the home pubset and checking for completeness and consistency
If the IPL-CONF function is not used for system initialization, the home pubset can be determined as follows according to the type of system initialization, and once the available disk configurations have been determined:
in FAST or AUTOMATIC mode:
The home pubset selected is the one to which the IPL disk belongs.in DIALOG mode:
If the IPL disk belongs to a pubset, the home pubset selected is the one to which the IPL disk belongs.
If the IPL disk is a private disk or the IPL option ALLDISK was specified and the disk configuration consists of more than one pubset, the ID (PVSID) of the home pubset is queried via messageNSI1135.
Disks with a physical block size of 4KB cannot belong to a home pubset. SM pubsets and shared pubsets are likewise not supported as home pubsets.
The home pubset should have a high degree of availability, i.e. through the hardware, the data for a virtual disk is recorded on several physical disks. This redundancy ensures that there is no loss of data if a physical disk crashes.
All the disks available in the startup configuration and disks belonging to the home pubset according to VSN syntax are compared with the volume list on Pubres. In DIALOG mode or in error situations the disks belonging to the home pubset are logged with the last time stamp and their mnemonic device name MN (with message NSI1143 or NSI1145).
The following error situations are displayed:
System ID (SYSID) of the home pubset not defined (message
NSI1280)
System initialization proceeds with the default value.Invalid SYSID of the home pubset (message
NSI1285)
System initialization proceeds with the default value.Missing disk in the home pubset (message
NSI3215)
System initialization cannot proceed.Time stamp of a disk not the same as the time stamp of Pubres (message
NSI1148)
Whether or not system initialization can proceed depends on the response to messageNSI1148.DMS attributes of a disk different to the DMS attribute of the home pubset (
NSI3220)
The relevant DMS attribute s are indicated by messageNSI3221.
System initialization is aborted since such an inconsistent pubset cannot be imported by the IMCAT command.Unknown disk in the home pubset (message
NSI1145)
Disks that do not belong to the home pubset are indicated by the wordsIS NEWin messageNSI1145.
Support for DRV disks
DRV pubsets are also permitted as home pubsets. DRV private disks are still not supported, and neither are DRV disks outside of the home pubset at startup paging initialization.
Because the DRV function is not yet available in the early phase of system initialization, the accesses to the DRV disks must be implemented by the IPL EXEC itself.
The following restrictions apply during system initialization:
Data is only ever read from or written to one disk of a DRV disk pair. The disk to be used is selected either automatically or in DIALOG startup by the operator specifying the DRV-SELECT option.
A disk can be selected from a disk pair with the same VSN only if both disks are in the DRV-DUAL state and the time stamp is identical on both of them. If this is not the case, selection of the disk is subject to restrictions (see also the “DRV” manual [17]).
If the IPL disk belongs to a DRV pair, the system initialization can continue with a different disk after the online scan or after the IPL-CONF file has been evaluated. This means that changes to the data are not written to the disk selected at the start of IPL, but are written instead to a different disk of the DRV pair.
Input/output errors on one DRV disk during system initialization do not cause the second disk of the pair to be accessed. As with individual disks, the discovery of irrecoverable I/O errors leads to abortion.
The home pubset is started up in the DRV-MONO state; reconstruction must be initialized with the START-DRV command.
If the home pubset was in the DRV-DUAL state on shutdown, reconstruction is initiated by DRV. This process reconstructs the files which have been modified since system initialization.
START/STOP mode for multiprocessors
In multiprocessor systems, the START/STOP mode controls selection of the CPUs when the SVP-START/STOP function is used. The SVP-START/STOP function is not needed in BS2000 operation. Nevertheless the START/STOP mode must be set correctly so that when the SVP-START/STOP or address stop function is used there are no undesirable side effects.
The following conditions apply for the settings of the START/STOP mode:
If all CPUs are to be used, the START/STOP mode must be set to ALL CPU so that in the case of STOP all CPUs are stopped and in the case of START all CPUs are started. This setting should be used as the presetting.
If only one CPU is to be used or if the SVP-START/STOP or address stop function is required for system initialization or for the dump function, the START/STOP mode must be set to TARGET CPU (CPU currently in use). This prevents the SVP-START function from starting CPUs that can no longer or not yet be controlled by the software.
If more than one CPU but not all the CPUs are to be used, correct functioning of the SVP-START/STOP function cannot be guaranteed.
Releasing assigned pubsets
If the home and/or paging pubsets required for system initialization were not exported correctly during the last system session (by means of SHUTDOWN), or if they are being used by another system, the operator will be requested to release them (message NSI424A).
The operator is informed of the precise nature of this use in a message preceding the request.
It is absolutely essential to assign unique SYSIDs if multiple home pubsets are operated in parallel.
Release is only possible if these pubsets are not currently being used by another system. If pubsets are released without a careful preliminary check, then the pubset data may be destroyed as a result of unrestricted access by two systems.
Parameter service
A startup parameter file is essential if system initialization is to be performed correctly. The parameter service supplies the software components with data.
For a detailed description of the parameter service including the structure and contents of the parameter files, see chapter "Parameter service".
Logging the startup dialog on the IPL console
All messages, including those not output at the console in FAST and AUTOMATIC mode, and all responses are logged in main memory and transferred to the logging file ($SYSAUDIT.SYS.CONSLOG.date.session-no.ser-no) as soon as the CONSLOG function is available.
For information on the CONSLOG logging file structure and contents, please refer to the “Diagnostics Handbook” [14].
If system initialization is concluded before the CONSLOG function is made available, the console dialog can be found in a subsequent dump.