On Thu, 30 Nov 2006 16:40:05 -0500, Horein, Steve (HAR-ORL) wrote: >Well <expletive deleted>! >So basically I'm not in a very good position, and back to square one. It >seems to me that to accomplish what I want, and maintain Production >integrity, I need to create an uncataloged copy of <MyHLQ>.IODFxx (which >is found in HSA) on a new volume. I then create SYSx.IPLPARM on this new >IODF volume, utilizing LPARNAME filtering, PARMLIB concatenation, all >the 'new' bells and whistles, etc, in LOADxx (or more likely LOADxy). I >change my LOAD parms to point to new IODF vol and LOAD member, IPL and >off I go! >
It's probably not so bad. I understand your need to prove to management that it all works, and you need to provide adequate fallback to what you have today. For your fallback, I would suggest a full volume copy of your IODF volume. That copy would be your fallback IODF volume. You could give it a different VOLSER or not. If not, I think (perhaps others can verify) that whichever one you use for the IOFDF at IPL time will come up online and the other will come up offline. If I'm mistaken about this, though, you'll have to respond correctly to the message that tells you that there are two volumes with the same VOLSER. Next, look at your LOADxx members on the two systems. Are they uniquely named? If so, you can build a new SYSn.IPLPARM on your IODF volume and copy all of the members into it. If not, copy them with different names. Maybe keep the LOADxx members as is for your production system and change the names of the members for your test system. IPL your test system to verify that it works ok. Now you can create a new LOADxx for your test system and start playing.... When you think you've got things the way you want them, you may have to create some PARMLIBs for your production system that matches what you built for your test system and you're ready to go. Don't worry about the name of the LOADxx member that you are building for your testing. Once you have everything weorking as you like, you can always copy it to the name that you want. Also understand that your SYSn.IPLPARM does not need to be in your ARMLIB concatenation. It is only needed at IPL time and you can freely compress it, or delete and reallocate it if necessary. As to your PARMLIB concatenation, I recommend that you do as Mark (I think) mentioned and concatenate your parmlib ahead of the one that is maintained by SMP/E. If you have need of a different PARMLIB for your two systems, you could consider (I hope I'm saying this right... ) SYS1.&SYSNAME..PARMLIB. Another that I have found useful at times is SYS1.&SYSR1..PARMLIB. Remember that you can always change your PARMLIB concatenation when you discover new needs. You really don't need to put more in there than you need now. For your installation PARMLIB, I would recommend, though that you not include any member that is using all defaults. It is better, IMO to take the defaults from the SMP/E maintained PARMLIB. Good luck! -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
