SLED generates a dump file (SLEDFILE) which can be prepared and analyzed by the DAMP dump analysis routine.
Defining the output data
The scope of the output data to be written to SLEDFILE is defined by means of the parameters MODE (as a response to message NSD3001) and TASK (as a response to message NSD3002). The MODE parameter determines the selection of memory pages to be included in the SLEDFILE. The TASK parameter determines the tasks whose address space is to be saved.
The parameters MODE=ALL and TASK=ALL are set automatically, if one of the following conditions is met:
the main memory is less than 128 MB
the system tables for the page selection are corrupt
the product ID or dump testament contains an error.
In the case of a standard SLED (i.e. automatic SLED or the response to NSD1003 is EOT or Y), the MODE and TASK parameters can be specified only by being entered in advance or via the parameter file. If the two parameters are not specified, SLED itself defines the values (implicit EOT response).
You are recommended not to specify the MODE and TASK parameters and instead allow SLED to define these values.
Page selection using the MODE parameter
NSD3001 SPECIFY NOEDIT MODE. REPLY (STD; NSF; REAL; ALL; EOT=STD; - (BACKTRACK))
Depending on the response, the following pages from main memory and the paging area are output:
EOT (no input) | |
The value of this parameter is determined by SLED: | |
| The following pages are output:
*)“resident” in this context means that the page is located in main memory. |
NSF (No System Files) | |
Has the same effect as STD, but without the system files that are also saved if STD is specified, provided that they are accessible. | |
REAL | All main memory pages (the subsequent TASK parameter is ignored); no data in the paging area is saved. |
ALL | In addition to the pages selected by If |
Task selection using the TASK parameter
In addition to the system address space (classes 1 through 4), the address space of the specified tasks can also be saved, depending on the value of the TASK parameter.
NSD3002 SELECT TASKS. REPLY (STD; NONE; ALL; (TSN LIST); EOT=STD/ALL; -(BACKTRACK))
EOT (no input) | |
The value of this parameter is determined by SLED: | |
| The output includes:
|
| All TICs (tasks in control) on a CPU. All tasks |
<tsn1>,<tsn2>,...,<tsn8> | |
In addition to the tasks listed under STD, the tasks specified in this list (maximum 8) are saved in the dump. | |
SLEDFILE contents (MODE = STD/ALL)
STATUS section (CPU status)
MAINMEM section: selected main memory pages
HSA section (only for /390 servers operated in native mode)
VM2HYPVS section (VM2000 Hypervisor on /390 servers, if a SLED has been created in a VM2000 guest system)
IOHIOSDP (bus dump file; only on x86 servers)
FIRMWARE section: firmware code und datea (only on x86 servers)
PAGEPHYS section: selected pages of the paging area
PROTKEYS: memory protection key
The following may also be present if the data is accessible and BS2000, IPL, SYSTART, VM2000 or SLED has been loaded:- TSOSCAT: system catalog
- EQUISAMQ: SPOOL job queue
- SJOBPOOL: job management queue
- REPLOG: if it is not possible to access the REPLOG file then SLED saves the SAVEREP file which contains only the BS2000 repairs.
- CONSLOG: last console logging file of this session
- CONSLOG1: first console logging file of this session
- CONSLOG2: penultimate console logging file of this session
- HELFILE: hardware error logging file - HEL
- SERSLOG: last software error logging file of this session
- SERSLOG1: first software error logging file of this session
- SERSLOG2: penultimate software error logging file of this session
- MSCFTRAC: MSCF trace file
- SJMSFILE: JMS file
- PAGELOG section: table of tasks saved on last system abort
- SLEDMEM section: IPL and SLED coding of the current SLED run
- SLEDLOG section: recording of start of SLED dialog
If REAL is specified then the SLEDFILE contains the items 1, 2, 3, 4, 5, 6, 8, 23 and 24. If NSF is specified then the SLEDFILE contains items 9 to 21.
The operator can initiate a maximum dump by specifying MODE=ALL and TASK=ALL as a response to message NSD3001 or NSD3002.
Output to an emulated tape device
On all BS2000 servers two tape devices are configured which are emulated by the Management Unit (SU /390), the SKP (S servers) or X2000 (SU x86). One of the tape devices operates in real mode on the basis of the integrated CD/DVD drive. The other operates on the basis of a file which is stored in the file system of the MU, SKP or X2000. In addition, further tape devices operating on file basis can be configured.
An emulated tape device operating on file basis must be used for SLED output. Tape devices which operate on the basis of a CD/DVD drive cannot be used for SLED output.
SLED output to an emulated tape device is provided for situations in which a SLED file on disk is not available. SLED output is in particular not convenient in large system configurations in which continuation tapes are required and calls for a certain degree of preparation.
The tape in the tape device must already have been initialized, i.e. assigned standard labels (VOL1, HDR1 and HDR2). Neither the volume serial number (VSN) nor the recording density can be changed. A check is also carried out to determine whether the expiration date entered in label HDR1 has been reached.
In older servers and firmware versions the tape visible in the preconfigured tape device will not yet have been initialized.
If the missing initialization is not to be implemented later (e.g. using the INIT utility routine), subsequent SLED output to the tape will not be possible.
The SLED output file to tape is always named SLEDFILE.
SLED requests two entries via messages NSD3800 and NSD3822: the volume serial number (VSN) and the device identifier (device mnemonic).
Volume serial number (VSN)
The VSN may be specified as a fully or partially qualified entry. The asterisk (
*) is used as a wildcard symbol (only allowed at the end of the entry). If*is entered by itself as the VSN, SLED will accept all tapes, provided they have standard labels.Device identifier
The device mnemonic
mnis specified as the device identifier. SLED checks whether the specified device exists and whether it can be used for output.
If the data specified is invalid, SLED repeats its request for the device identifier.These messages likewise appear if one tape is not sufficient to accommodate the entire output and a continuation tape has to be used. If the VSN was specified as
*this also applies to the subsequent tapes.All continuation tapes must be mounted on the same device.
Because of the emulation, a continuation tape is “mounted” only by means of the following actions:
Backup of the file belonging to the tape emulation, e.g. by downloading it to a PC.
Overwriting the file belonging to the tape emulation with a prepared file which represents an empty tape with a different VSN. This is done, for instance, by uploading from a PC.
The procedure for the two steps is described in the operating instructions of the server concerned.
For reasons of data security, the files written should be overwritten (e.g. by reinitializing the tape) or physically deleted after they have been analyzed.
Output to private disk
In the case of output to private disk, the SLED output file (SLEDFILE) must be contained completely on one disk, i.e. it must not be distributed over several disks. The file must already have been created and must be sufficiently large.
The operator is requested to specify the VSN of the disk. The device address of the disk is then queried via message NSD3410.
An operator wishing to use only the device name can enter * or <EOT> in response to message NSD3400. The parameter file should contain: VSN=*, DEV=<mn>.
Once the output disk has been defined and located, the name of the output file is requested. If output is to private disk, the file is not accessed via the system catalog but exclusively via the F1 labels on the disk. Consequently specification of a catalog ID is irrelevant in this case and is rejected as an error.
If there is already a catalog entry for the file on private disk, it is not updated. After a SLED output file has been created on a private disk, the corresponding catalog entry must be deleted by means of the command EXPORT-FILE FILE-NAME= <filename>.
SLED files must not be created on DRV private disks.
Output to public disks
In the case of output to a public disk, the pubset containing the output file must first be identified. The output files for SLED can also be located outside the home pubset, but only on disks or pubsets which would be suitable as an IPL disk or home pubset, i.e. for example, not on SM pubsets. Output to shared pubsets is also rejected.
The pubset of the SLEDFILE is identified via the first file name to be requested. The following rules apply:
If the file name was specified with catalog ID, this suffices to specify the pubset containing SLEDFILE.
If the file name was specified without with catalog ID (or if the default name was specified implicitly by a null input), an attempt is made to determine the pubset using one of the following two standard rules:
SLED was loaded from a public disk: the pubset to which this disk belongs is the pubset containing SLEDFILE.
SLED was loaded from a private disk but all the public disks that are online belong to a single pubset: this is then the pubset containing SLEDFILE.
If neither of these rules is applicable, this means that SLED was loaded from a private disk and that there are public disks online from various pubsets or no public disks online at all. In this case the operator is requested to specify the catalog ID of the SLED output file.
If the pubset containing SLEDFILE is known, first the associated SYSRES and then all the other disks of the pubset are sought. SLED cannot execute unless all the disks of the SLEDFILE pubset are online. If disks are missing, this is indicated by message NSD1400, SLED must be reloaded once these disks have been attached (SLED repetition!).
Subsequently an attempt is made to locate the specified output file. To this end an accessible catalog with the specified catalog ID must be available.
If the software product HSMS is used on the system involved, systems support must ensure that the file to be output is not automatically migrated and thus made inaccessible if it is not used for a long time.
A pubset for SLED output must not be imported by a running system during SLED operation.
Checking the SLED output file
Once the output file (SLEDFILE) has been identified and located, it must be checked to ensure that it is possible to work with it. This means:
It must not be protected by a password.
ACCESS=WRITE must have been specified.
The expiration date must have been reached.
It must be large enough to accommodate at least the main memory dump, the CONSLOG and SERSLOG files and the hardware data. SLED writes very large main memories as a number of different portions so that DAMP is able to prepare the dump even if the main memory could not be saved in full.
However, excessively small SLED files should be avoided since precisely that data might be missing that is required for error diagnosis.If output to public disks has been requested, the file must not have been created on private disk.
Output to shared pubsets and SM pubsets is prohibited and is rejected by IPL.
If any of these conditions is not satisfied, the appropriate message (NSD32xx) is issued and the name of the SLED output file is requested again.
If the SLED file is not logically empty, it is not used unless the operator makes a positive response to the appropriate query (message NSD3204); otherwise the name of the SLED file is requested again.
Size of SLED output files
If SLED output is to disk, a sufficiently large file must be available on disk. The output file may also be greater than 32 GB (but at most 256 GB) and may reside on the home pubset.
As SLED operates without DMS support, the file cannot be extended dynamically during a SLED run. A sufficiently large value must therefore be specified in the SPACE operand of the CREATE-FILE command when creating a SLED output file.
The scope of the dump, i.e. the size of the SLED output file, is influenced by many factors that are unknown before the dump is taken. At the time the dump is taken, the size of the output file can be controlled via the MODE parameter (pages to be included in the file) and the TASK parameter (tasks whose address space is to be saved). Setting the parameter TASK=ALL to include all tasks' address space has a significant effect not only on the time consumed by the SLED run but also the file size. TASK=ALL can result in a file many times the size of that produced with TASK=STD.
The MODE parameter is decisive if the main memory or system files are large. In such cases, MODE=ALL should only be specified if the file is sufficiently large.
The following factors must be taken into account when calculating the required file size for MODE=STD, TASK=STD (default case):
A: | Size of the system address space used |
B: | Size of the system files TSOSCAT, EQUISAMQ, REPLOG, CONSLOG[x], SJOBPOOL, HEL, SERSLOG[x], SJMSFILE, MSCFTRAC, etc. |
n: | Number of CPUs |
t: | Number of different tasks entered as tasks in control in the TIC table (maximum 64 entries per processor) |
C: | Size of a task's class 5 address space used |
The influence of these factors is calculated using the formula (A + B + n * t * C)
Factors t and C are particularly problematic when calculating the file size. Simply setting the upper limit for these factors results in impractically large values. It is difficult to calculate average values that are generally applicable, since these values vary widely according to the way in which the system is used and the system workload. It may be possible to use the average results of openSM2 measurements in this case.
To summarize, it is difficult to recommend a size for the output file. In most cases, however (except where TASK=ALL is specified), the user will find that double the size of main memory is sufficient.
Rule of thumb for MODE=STD/ALL, TASK=STD
Size of SLEDFILE = 2 * size of main memory.
Example for a SLED run
|