IPL from CD:
DFSMSdss and ICKDSF STAND-ALONE
Every MVS installation has STAND-ALONE utilities for emergency situations.
The basic utilities are DFSMSdss STAND-ALONE and ICKDSF STAND-ALONE, both
from IBM, and, recently, it is not rare to include de STAND-ALONE editor
ZZSA, from Jan Jaeger (http://www.cbttape.org/~jjaeger)
in the catalog of utilities.
And the usual scheme consists in having a set of these utilities in every
media type suitable for IPL available at the installation: 3420 tape units,
3480, 3490 and 3590 cartridge units, DASDs, etc.
In the case of the ZZSA editor, we also have a CD image, provided by Jan
Jaeger himself, so that we can load it from the CD reader of the HMC.
My purpose is to collaborate in the specification of a methodology to
obtain CD versions for DFSMSdss STAND-ALONE and ICKDSF STAND-ALONE as well.
In this document, I describe the memory images I have prepared to IPL
DFSMSdss STAND-ALONE and ICKDSF STAND-ALONE from CD.
The described method to IPL STAND-ALONE utilities from CD is the
result of a pastime and has been obtained just as an entertainment. I make
it available to everyone who wants to use it in the hope that it can be useful,
interesting or, simply, amusing. But in no way do I intend it to replace
the well-established and officially IBM-supported methods to IPL these utilities.
DO NOT THROW AWAY YOUR
SETS OF TAPES AND CARTRIDGES
FOR EMERGENCY SITUATIONS.
The necessary files to IPL from the CD the way it is described in this
page, depend critically on the exact version of the STAND-ALONE program.
Whoever follows the steps described below for a program version different
from that for which they were designed will end up, most probably, with
a useless set of files.
The ICKDSF STAND-ALONE card image is directly available in SYS1.SAMPLIB(ICKSADSF).
However, the DFSMSdss STAND-ALONE card image must be generated using the
BUILDSA command, as in this example:
//BUILDSA EXEC PGM=ADRDSSU,PARM='UTILMSG=YES'
//SAMODS DD DISP=SHR,DSN=SYS1.SADRYLIB
//CARDDD DD DSN=dsname,
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
BUILDSA INDD(SAMODS) -
For version identification, I propose up to three checks. Firstly, the
version number displayed at the console by the program itself as it starts
execution. In the following DFSMSdss STAND-ALONE example, it is version 1.03.0:
5694-A01 DFSMSDSS STAND-ALONE V1.03.0
and, in the next ICKDSF STAND-ALONE example, it is version 16.0X:
ICKDSF - SA/XA/ESA DEVICE SUPPORT FACILITIES 16.0X
TIME: hh:mm:ss mm/dd/yy PAGE 1
Secondly, we could check the card image size.
Lastly, we could calculate a hashing function (SHA-1, MD5, etc.)
from the card image. In this page I consider two alternatives: SHA-1 and
MD5. I hope these three checks are enough to convice us we are talking of the
same card image :-) It should be noted, though, that, for DFSMSdss, the resulting
hashing values will differ depending on the BUILDSA options used. I usually
let them take the default values, as in the sample JCL showed above.
The identifying data for the versions of the programs I have prepared CD
images for are the following.
The IPL from CD consists of a reset-clear of the LPAR, followed by
the loading into memory of the memory images stored on the CD files, followed
by the loading into the PSW of the contents of the first eight memory bytes.
From that point on, the machine starts executing instructions normally. We can select any of the files stored on the CD that have
.ins extension to launch the IPL. The
.ins file is an ASCII file
which specifies 1 to n files, each containing a memory image, along with the
memory address each image must be loaded into.
Initially, what we have is a card image of the program. Normally, we have
it stored on tape, cartridge or DASD. When we IPL from the device containing
the card image, a CCW chain loads into memory a small loader program. Once
in memory, the loader program starts execution and loads into memory the
rest of the cards, thus loading the STAND-ALONE program. Next, the execution
of the latter starts.
The IPL from CD is different from the IPL from other device types like
card readers, tape units, cartridge units or DASDs, in that what we must
store on the CD is not a card image of the program, but a memory image of
it, which will be loaded into memory from the address specified in the
file on. So, we can't simply copy the card image into the CD. What we have
to do is to obtain a memory image that, once loaded into memory, behaves
as the original program would.
This imposes two important restrictions. Firstly, and obviously, we have
no longer available the device to read the card image. So, the memory image
to be used must be obtained right after the loader program has done its job
and that device is no longer necessary.
And, secondly, our memory image must provide the mechanisms to drive the
CPU towards the state it was in when we obtained the memory image, including
the PSW, the values of the general registers and the values of the control
The scheme I follow for all the programs is the following. I use three
files with memory images, with
.img extension. Let's say the
name of these three files are
psw.img. The first one,
the memory image of the STAND-ALONE program once it has been loaded into
memory. The second file,
init_reg.img, contains the memory image
of a small program whose function is to restore the values of the registers
and of the PSW to those they had when we got the memory image
This small program can be loaded into any memory address outside of the memory
region used to load the STAND-ALONE program. Finally, the
file contains the address into which we have loaded the program whose memory
image is in
init_reg.img, and it must be loaded into memory
All together, the three memory images have the following effect. From
address 0 on, we have the memory image of the STAND-ALONE program. This memory
image is intact, except for the word at address 4 which, instead of containing
its original value, contains the address into which we have loaded our small
init_reg. So, when, at the end of the IPL from the CD
the machine loads into the PSW the first eight memory bytes and starts executing
instructions, our program is the first one to receive control. As we have
mentioned above, this program makes the registers and the PSW to take the
same values they had when we obtained the memory image of the STAND-ALONE
program, thus completing the restoration of the CPU to the state in which
it was in that moment. From this point on, the behaviour of the STAND-ALONE
program should be indistinguishable from that showed by the program when
we run it using the traditional card image.
How to generate the files for IPL
To perform the IPL from CD of each STAND-ALONE program, I use four
files. Three of them, the ones with
.img extension, contain
memory images. The fourth one, with
.ins extension, is an ASCII
file which specifies the memory addresses at which the images in the
files must be loaded. The
.ins file is the one we select to launch the IPL.
As an example, this is the
.ins file corresponding to ICKDSF
Content of dsf_160p_ipl.ins file:
I provide three out of these four files. They can be freely downloaded
from this page. The fourth file, the one containing the memory image of the
STAND-ALONE program itself, must be generated by the user using his or her
own card image. Later on, I'll show through an example how to generate that
image using HERCULES (http://www.hercules-390.org/).
To generate the memory image of the STAND-ALONE program we need to know:
- The address of the instruction reached by the loader program
right after it has finished loading into memory the whole card image.
- The highest memory address occupied by the STAND-ALONE program.
The following are the data for the versions of the programs I have studied,
and the files to download.
As an example, these are the steps to follow in order to obtain the memory
image of DSF 16.0P using HERCULES. For the other versions of DSF or for DSS,
the steps to follow would be similar.
- Unzip the downloaded file (
Put your own copy of ICKDSF STAND-ALONE 16.0P into directory
dsf_160p, together with the other files, with name
or, if you prefer to use other directory and/or file name, update the HERCULES
dsf.conf, accordingly, so that device
points to the right file.
- IPL the card image and get the memory image with the following commands:
hercules -f dsf.conf
b 316 <-- 316 is the Load Ended Instruction Address
HHCPN040I Setting breakpoint at 0000000000000316
--> gets STOPPED with PSW=000C0000 00000316
savecore dsf_160p_DSF_SA.img 0 f9d7f <-- f9d7f is the Highest Memory
Address (see table)
HHCPN104I Saving locations 00000000-000F9D7F to dsf_160p_DSF_SA.img
How to IPL from the HMC or using HERCULES
- To IPL from the HMC you must place the
file and the three
.img files on the CD. Next, start a "Single
Object Operations" session and choose the "Load from CD or Server" task from
the "CPC Recovery" task list. At the showed window, select the
file and proceed with the IPL.