Sorry for my delay in responding. I have been under the weather. I finally found the documentation regarding a DDR IPL using an HMC with no 3270 console or integrated console available. I used this on VM 3.1 but I can't see why it would not work with VM 2.4.
You will need to IPL the standalone DDR tape and add the following 8 character value AUTODDDA to the PARM field. DDDA is the address of the disk drive to receive the output from the DDR restore. This IPL provides no messages and will load the DDR program and restore tape data to disk drive DDDA. Upon successful completion a disable PSW state will be loaded "PSW 000A0000 00000000". You can now IPL address DDDA and follow the normal IPL procedures using the HMC. This emergency system at address DDDA automatically brings up TCPIP and provides 3270 access. Log onto a userid and start restores or one better build this system as your DR system. You can automate it so you can just autolog userids to perform you automatic DR restore procedures. Naturally you have tested them out many times before running this DR emergency system as a second level system with small mini-disk representing your floor system. You just can't beat VM for making life at work easy. Hans Rempel -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: November 23, 2006 11:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IPL Help for old 9672 with VM/ESA 2.4 > I therefore created a mini VM system with TCPIP started so that I could > restore it using this method and have an VM system that I could IPL. > > I did that a few years back. I'd can't remember off hand how that was > done. > Does anyone else remember? This is a good thing to do. (in fact, I'll be giving a session at WAVV and probably the next zExpo on it -- another good reason to support WAVV...8-)) You need your CP nucleus and parm area, your IODF (if you use it instead of the much superior CP dynamic detection of devices...), your MAINT 190, most of TCPMAINT, and TCPIP itself. You also need a minimal OPERATOR, and I create one USERxxxx userid for each real tape drive you have (to allow parallel DDRs to occur on all your real drives). Configure USERxxxx to IPL 190 rather than CMS, so you don't need NSSes or spool space, and the USERxxxx ids don't even need a writable 191 -- you're not going to put anything on them anyway. FTPSERVE would be handy, but is not critical. On our 1-pack system, the PROFILE EXEC on the USERxxxx R/O 191 gets the userid, parses the xxxx and attaches the device at address xxxx as 181. The shared 191 also contains a DDR control file that restores from 181 to whatever is attached at 200 and some other assorted helpful tools (like TRACK, so you can be nosy and look at how each of the IDs is going. You don't need much (if any) page space, no dump space (unless you intend to use the 1 pack system for diagnostics too, for which you need spool and/or dump space); this system is supposed to be small and temporary -- just enough to get your real system restored as fast as possible. All those ids fit easily on one mod 3 sized volume (with a little bit of juggling and size management to remove some extra whitespace. One major caution: be sure the volume you're doing this on is in the Offline_at_IPL in your production SYSTEM CONFIG; you don't want this directory "accidentally" coming online if something happens to the production volume that contains your normal CP directory. I'm still working on the handouts for the talk; I'll post a draft when I get them finished. -- db
