IPL FROM CD - SA UTILITIES
Home Rafael Pereira Tercero
   rptv2003@yahoo.com Español   

Presentation
Stand-alone programs
IPL from CD
IBM 1401
SoftCap
TK3-SVC244
zLinux on Hercules
PGP public key
   
 

IPL from CD:
DFSMSdss and ICKDSF STAND-ALONE


Introduction

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.


Advise

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. So, please,

DO NOT THROW AWAY YOUR
SETS OF TAPES AND CARTRIDGES
FOR EMERGENCY SITUATIONS
.


Version

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,
    //            DISP=(,CATLG),BLKSIZE=80,
    //            DSORG=PS,RECFM=F,LRECL=80,SPACE=(CYL,(1,1),RLSE)
    //SYSPRINT DD SYSOUT=*
    //SYSIN    DD *
      BUILDSA  INDD(SAMODS)  -
               OUTDD(CARDDD) -
               IPL(CARD)
    /*                  

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.

PROG.
VERS.
SIZE
HASH
DSS V1.03.0 216,320
SHA-1:  8b:51:01:c6:7a:21:bb:4f:1c:e8:f3:4d:cc:23:f3:f6:76:c6:f7:c6
MD5:     9b:1a:9f:b6:b0:d5:1a:b4:f7:9d:bd:ce:32:73:05:f8
DSS V1.06.0 216,400
SHA-1:  8b:0f:6b:c2:3a:6a:d9:dd:b1:69:86:46:dc:3c:e8:d1:22:fa:ef:d9
MD5:     4f:ff:58:76:c2:98:88:66:40:a1:be:95:a3:3a:53:04
DSS V1.08.0 217,040
SHA-1:  e6:02:a8:0a:8e:d2:76:2a:8c:c5:83:03:f8:ff:b8:ec:4f:a5:e8:ad
MD5:     06:25:e6:63:83:47:89:4f:c6:29:ac:87:62:8d:9d:aa
DSF 16.0P 993,040 SHA-1:  17:3c:dc:c6:d4:21:15:dd:06:20:5f:a0:1e:0f:7a:66:53:8c:53:81
MD5:     53:32:1c:76:c3:12:4c:14:37:a3:ff:b7:57:1f:26:99
DSF
16.0X
1,010,080
SHA-1:  a5:d0:90:2c:11:30:90:47:87:ed:b5:f6:14:16:5c:14:08:94:da:b0
MD5:     f2:b8:83:b5:a8:df:f6:61:68:82:13:6e:72:2d:63:ac
DSF
17.0
1,030,720
SHA-1:  14:63:d0:4e:6d:74:af:b3:5b:df:f3:c9:25:34:7c:1c:9d:2f:b4:c4
MD5:     53:4b:f4:35:98:50:70:02:b5:4c:bb:88:fe:de:99:8d



Basics

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 the .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 .ins 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 registers.

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 sa_program.img, init_reg.img and psw.img. The first one, sa_program.img, contains 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 sa_program.img. This small program can be loaded into any memory address outside of the memory region used to load the STAND-ALONE program. Finally, the psw.img 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 address 4.

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 program 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 .img 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 STAND-ALONE 16.0P:

Content of dsf_160p_ipl.ins file:
dsf_160p_DSF_SA.img 0x00000000 dsf_160p_init_reg.img 0x000FA000 dsf_160p_psw.img 0x00000004

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.

PROGRAM
VERS.
LOAD ENDED
INSTR. ADDR.
HIGHEST
MEM. ADDR.
DOWNLOAD
DSS V1.03.0 x'29C'
x'4F3FF'
dss_130.zip
DSS V1.06.0 x'29C'
x'4F447'
dss_106.zip
DSS V1.08.0 x'29C'
x'4F687'
dss_108.zip
DSF 16.0P x'316'
x'F9D7F'
dsf_160p.zip
DSF
16.0X
x'316'
x'FD96F'
dsf_160x.zip
DSF
17.0
x'31A'
x'1021FF'
dsf_170.zip
 

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 (dsf_160p.zip):
  • dsf_160p/dsf_160p_init_reg.img
    dsf_160p/dsf_160p_ipl.ins
    dsf_160p/dsf_160p_psw.img
    dsf_160p/dsf.conf
  • Put your own copy of ICKDSF STAND-ALONE 16.0P into directory dsf_160p, together with the other files, with name ICKDSF_SA.bin, or, if you prefer to use other directory and/or file name, update the HERCULES configuration file, dsf.conf, accordingly, so that device 000D 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
                                                             (see table)
    HHCPN040I Setting breakpoint at 0000000000000316
    
    ipl d
    
    --> 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 .ins 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 .ins file and proceed with the IPL.
  • To IPL using HERCULES just execute the command: ipl file.ins at the HERCULES console.


02/25/2006

 
   rptv2003@yahoo.com