If you remember your first years, everyone starts out as an unqualified VM system programmer, then we learn and become qualified! There is a wealth of information to learn about z/VM, but one area where it is lacking is on the upgrade processes and running things 2nd level.
I was trying to make a 2nd level guest this week, and I gave up for the time being. Why? I understand creating it and can get it booted up, but I have duplicate volumes to start. Prior to installing DIRMAINT I did this a number of times and relabeled the disk and updated the user directory as discussed in this thread. But this time I'm stuck on how to tell my 2nd level dirmaint about all my new volume names so it updates the user directory. A cookbook with a few more examples of some of the techniques for running 2nd level guests for maint/upgrades would be better than what appears to be available at this point and time. -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: Wednesday, May 14, 2008 2:06 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: z/VM 5.1 to 5.3 upgrade ( a little handholding requested) In effect, it is too hard to come up with something generic. Why? Because each of our systems can be very, very different. For example, the easiest way to do this, is to have plenty of resources. DUH! 1. If you have plenty of memory, get an LPAR for your test system. And then expose only those disks that you need for that LPAR. However, if you are memory tight, bring up your test system, second level. You will use a lot less memory, and only use that memory when needed. But now you start needing more VM skills. 2. DASD. Copy full volumes, if you have them. If you have a test LPAR, you can keep the same volume labels. You can too, with second level VM, but now you start needing more VM skills. Such as keeping your production VM system, from using your test packs (remember duplicate names), if/when your production system is reipled. Not for people that don't know what they are doing! So relabeling packs is a better way to go, but you also need different VM skills. BTW, when you really know what you are doing, you can bring up a second level VM system, with very little additional disk space (few hundred cylinders). 3. DASD again. Did you keep all your VM related stuff on VM only packs and keep your guest related stuff off of the VM packs? Did you expand your SFS space and put the additional minidisks across other packs that are primarly used for your guests? If so, then you need more VM skills to replicate a test system. Not just copying packs, but copying and moving those minidisks to other packs for your test system. OR do you just wipe out and recreate VMSYSU on your test systems? 4. DASD again. Do you really need xx paging and spool packs for your test system? Answering each one of these questions, will cause the entire cloning process to be different. It's a trade off between the cost of system resources for the VM clone, and the cost of a qualified VM system's programmer. Perhaps the cost of DASD will get to the point, that we will just give a standard 20 volumes to each VM system. Cost of resources vs the cost of accessing qualified people. So, IMHO, writing a Redbook, or something, on this issue, would be good for 5-10% of the shops that don't have a qualified VM systems programmer, and fairly useless for the other 90% of the shops without a qualified VM systems programmer. It would be of mild interest to the shops that do have a VM systems programmer. As a consultant, each place I go to, is entirely different from most other shops that I've been to. Tom Duerbusch THD Consulting Law of Cat Acceleration A cat will accelerate at a constant rate, until he gets good and ready to stop. >>> Stewart Thomas J <[EMAIL PROTECTED]> 5/14/2008 1:32 PM >>> >>> Just wanted to add to this - I'm also a z/OS person turn z/VM person. Yeah these are two different OS'es but the z/OS maintenance/upgrade is so easy sometimes when the OS is just on a few disk volumes and you take the LPAR down, point to the new sysres, and bring it back up. To back off, you do the reverse. All the user data is on non-OS volumes and is retained across. I seriously struggled through my z/VM 5.2 to z/VM 5.3 migration. I just don't have a handle on things like being able to carry my spool volumes with me between releases (I just left all my data behind and started new). And being able to segregate out my own config files and users to carry those through to the new system. It's a major shift from how z/OS does it. And with all of the z/VM shops doing it differently it makes it hard for newbies. Isn't there a single best practice that can be documented for shops running only Linux? Some way to lay out the minidisks and users to make this easier? Yes there are some IBM scripts and utilities that are making strides towards simplification, but it seems we are a long way off from where we could be. My own upgrade process ended up being many steps and it just seems like there should be a simpler way, hopefully someone that found the light can share with others. __________________________________ Tom Stewart Infrastructure Analyst John Deere - z/OS Support Services em: [EMAIL PROTECTED] ph: (309) 765-9405 __________________________________ -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Peter E. Abresch Jr. - at Pepco Sent: Wednesday, May 14, 2008 1:05 PM To: LINUX-390@VM.MARIST.EDU Subject: z/VM 5.1 to 5.3 upgrade ( a little handholding requested) z/VM 5.1 to 5.3 upgrade handholding We are starting our upgrade from z/VM 5.1 to z/VM 5.3. We use z/VM strictly for Linux. We are all old MVSers that originally installed z/VM 5.1. Now we are rethinking our z/VM installation and maintenance methodology. We have talked to various VMers but have become overwhelmed with the many methods of accomplishing this. Here is what we wish to do. We wish to install z/VM 5.3 as a second level guest in our current z/VM 5.1 system. We wish to develop an environment where we can test the hell out of it and once we are happy with it, we wish to implement it into production by simply changing the IPL address for our z/VM LPAR. This methodology will hold true for z/VM maintenance as well. Another words, we will always have a production and a test z/VM. This is not uncommon as we all know. We have chosen to install second level using FTP from the install DVD on a Linux server. We are calling our second level VM VMTESTSV and created the following entry (please provide comments if this entry is not all that it can be). USER VMTESTSV VMTES530 256M 256M BG ACCOUNT SYSTEMS IPL CMS MACH XA OPTION LNKNOPAS CONSOLE 0009 3215 NICDEF 0600 TYPE QDIO LAN SYSTEM VSWTCH00 SPOOL 000C 2540 READER * SPOOL 000D 2540 PUNCH A SPOOL 000E 1403 A LINK MAINT 0190 0190 RR LINK MAINT 019E 019E RR MDISK 0191 3390 371 25 VMUSR0 MR MDISK 2222 3390 241 5 VMUSR0 MR MDISK 22CC 3390 246 5 VMUSR0 MR MDISK 2CF1 3390 251 120 VMUSR0 MR We will install z/VM to the following DASD volsers: Pack Type Prod Test RES 530RES (can we change this volser?) SPOOL VMSPLP VMSPLT PAGE VMPAGP VMPAGT USER1 VMWK01 VMWK01 (shared) USER2 VMWK02 VMWK02 (shared) USER3 VMWK03 VMWK03 (shared) I know, we have to migrate our customization and users over after we install. Let?s say we do all that and completed our testing and are ready for production implementation. We wish to copy the RES volume to another volser and IPL the LPAR from that address. Is this possible and what will be involved? Are we on the right track? Go slow, remember we are old MVSers and very young VMers. Thanks as always. Peter This Email message and any attachment may contain information that is proprietary, legally privileged, confidential and/or subject to copyright belonging to Pepco Holdings, Inc. or its affiliates ("PHI"). This Email is intended solely for the use of the person(s) to which it is addressed. If you are not an intended recipient, or the employee or agent responsible for delivery of this Email to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. If you have received this message in error, please immediately notify the sender and permanently delete this Email and any copies. PHI policies expressly prohibit employees from making defamatory or offensive statements and infringing any copyright or any other legal right by Email communication. PHI will not accept any liability in respect of such communications. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
