OS/390 2.4 guest under z/VM 5.3
Hello all, am trying to run (believe it or not) an OS/390 2.4 guest under z/VM 5.3 (0703) on a CP (z990). The usual CP Directory statements are in place, memory is 1G. I am getting as far as the first reply request, see below: === IEA371I SYS1.PARMLIB ON DEVICE 0847 SELECTED FOR IPL PARAMETERS IEA246I LOAD ID 00 SELECTED IEA519I IODF DSN = SYS1.IODF01 IEA520I CONFIGURATION ID = MVSCP00 . IODF DEVICE NUMBER = 0847 IEA091I NUCLEUS 1 SELECTED IEA370I MASTER CATALOG SELECTED IS SYS1.MCAT.VRESI25 IEA101A SPECIFY SYSTEM PARAMETERS FOR OS/390 02.04.00 JBB6604 === As soon as I reply with r 00,sysp=00,clpa everything dies with a HCPGIR453W CP entered; program interrupt loop message. There is not much on Google about the above configuration, I have tried everything I can think of. I hope this is not an architectural problem.. Anyone any ideas?? Regards, JC John Cassidy (Dipl.-Ingr.) Kapellenstr. 21a D-65193 Wiesbaden EU Mobile: +49 (0) 170 794 3616 http://www.JDCassidy.net http://en.federaleurope.org/ http://sva-zhosting.com/en/index.php
Re: OS/390 2.4 guest under z/VM 5.3
On Mon, Nov 16, 2009 at 12:47 PM, J. Cassidy s...@jdcassidy.net wrote: As soon as I reply with r 00,sysp=00,clpa everything dies with a HCPGIR453W CP entered; program interrupt loop message. That means it gets a program check in the program check handler. You should probably look at the PGMOLD PSW and see where you have been recently... Depending on what made you trip, we may understand whether it can be resolved. Rob
Re: OS/390 2.4 guest under z/VM 5.3
On Monday, 11/16/2009 at 08:17 EST, J. Cassidy s...@jdcassidy.net wrote: am trying to run (believe it or not) an OS/390 2.4 guest under z/VM 5.3 (0703) on a CP (z990). ... As soon as I reply with r 00,sysp=00,clpa everything dies with a HCPGIR453W CP entered; program interrupt loop message. As Rob says, HCP453W indicates that the PROGRAM NEW PSW was corrupted or otherwise not valid when a Program Interrupt (program check) occurred. While it's fairly easy to find out what caused the fatal program interrupt, it won't help to explain why the program new PSW is bad. You can try #CP TRACE PROG RUN CMD D PSW PROG and then re-IPL. You will likely get more than one hit, but the last one will be the fatal one and you will will see from the output that the PNPSW is bogus. Wiping out of the PNPSW isn't usually a surgical strike, but is more often part of the larger mass destruction of low core (that's page 0 for you young whippersnappers out there), usually from picking up an unexpectedly zero pointer. Anyone any ideas?? It's anyone's guess. Unfortunately you are trying to run an unsupported operating system in an unsupported configuration (OS/390 2.4 on a z990), so I can't even suggest that you open a PMR. The z990 had a minimum requirement for OS/390 2.10 (with PTFs). Even the z900 required OS/390 2.8 (with PTFs). But before you give up, make absolutely certain that there is nothing new in the virtual machine configuration. Where was this OS/390 running prior to your attempt to bring it up as a guest of z/VM 5.3 on the z990? Is there anything different about the virtual machine config from it's prior home? And take a look at those TRACE PROG hits. One of them might give you a hint. In case it hasn't been said often or loud enough: Make sure Management knows that z/VM does not hide the hardware from the guest. The guest sees any new chpid types, new disks, new cryptos, and new CPU features (and the loss of old ones, in rare cases). So when the h/w says that some particular level of s/w is required, there's a reason fir it. Sometimes is just the validation and other times it is a technical dependency. If you let the software get *too* old, then you create a void: The newer software won't run on the old box and the older software won't run on the new box. It's a painful, and potentially expensive, chasm to cross. Alan Altmark z/VM Development IBM Endicott
Question on MODIFY COMMAND
If I change SHUTDOWN and FORCE with the following: MODIFY COMMAND SHUTDOWN PRIVCLASS S MODIFY COMMAND FORCEPRIVCLASS S ...and OPER1 does not have class S but does have class A, can OPER1 still successfully issue SHUTDOWN or FORCE? Thank you, Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| : 402.963.8905 || :847.849.7223 || : scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly**
Re: Question on MODIFY COMMAND
No, he won't. But, with CP class A, he can issue SET PRIVCLASS * +S. You your change is only safe to avoid accidental FORCEs or SHUTDOWNs 2009/11/16 Wandschneider, Scott scott.wandschnei...@infocrossing.com If I change SHUTDOWN and FORCE with the following: MODIFY COMMAND SHUTDOWN PRIVCLASS S MODIFY COMMAND FORCEPRIVCLASS S ...and OPER1 does not have class S but does have class A, can OPER1 still successfully issue SHUTDOWN or FORCE? Thank you, Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| : 402.963.8905 || :847.849.7223 || : scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** -- Kris Buelens, IBM Belgium, VM customer support
Re: Question on MODIFY COMMAND
Thank you for verifying my assumption. Thank you, Scott From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Monday, November 16, 2009 12:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Question on MODIFY COMMAND No, he won't. But, with CP class A, he can issue SET PRIVCLASS * +S. You your change is only safe to avoid accidental FORCEs or SHUTDOWNs 2009/11/16 Wandschneider, Scott scott.wandschnei...@infocrossing.com If I change SHUTDOWN and FORCE with the following: MODIFY COMMAND SHUTDOWN PRIVCLASS S MODIFY COMMAND FORCEPRIVCLASS S ...and OPER1 does not have class S but does have class A, can OPER1 still successfully issue SHUTDOWN or FORCE? Thank you, Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || : scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** -- Kris Buelens, IBM Belgium, VM customer support
Re: Question on MODIFY COMMAND
On Monday, 11/16/2009 at 01:03 EST, Kris Buelens kris.buel...@gmail.com wrote: No, he won't. But, with CP class A, he can issue SET PRIVCLASS * +S. Only a class C user can escalate a user's privilege beyond what is in their directory entry. USER OPERATOR ** ABDEFGS COMMAND SET PRIVCLASS -S Then the operator can SET PRIVCLASS +S in order to issue the SHUTDOWN or FORCE command. Needless to say, I am miserly with class C. It should be reserved only to the most trusted of individuals, typically being those who are authorized to update the directory, to diagnose CP problems, or a trusted automation program. Alan Altmark z/VM Development IBM Endicott
Re: OS/390 2.4 guest under z/VM 5.3
On Mon, Nov 16, 2009 at 6:19 PM, Alan Altmark alan_altm...@us.ibm.com wrote: As soon as I reply with r 00,sysp=00,clpa everything dies with a HCPGIR453W CP entered; program interrupt loop message. As Rob says, HCP453W indicates that the PROGRAM NEW PSW was corrupted or otherwise not valid when a Program Interrupt (program check) occurred. While it's fairly easy to find out what caused the fatal program interrupt, it won't help to explain why the program new PSW is bad. You can try #CP TRACE PROG RUN CMD D PSW PROG and then re-IPL. You will likely get more than one hit, but the last one will be the fatal one and you will will see from the output that the PNPSW is bogus. Wiping out of the PNPSW isn't usually a surgical strike, but is more often part of the larger mass destruction of low core (that's page 0 for you young whippersnappers out there), usually from picking up an unexpectedly zero pointer. You're putting different traces in my mouth. It does not have to be a bogus PGM New PSW. It can also be something happening in the program check handler. A popular trick is when the old PSW is massaged in some way before doing a LPSW to continue at a slightly different spot. I expect MVS will do a lot of program checks and most of them being legitimate. What I suggested was to look at the PGM Old PSW to understand where it occurred and what type of program check it was. Rob Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: Question on MODIFY COMMAND
On Mon, Nov 16, 2009 at 8:04 PM, Alan Altmark alan_altm...@us.ibm.com wrote: Only a class C user can escalate a user's privilege beyond what is in their directory entry. USER OPERATOR ** ABDEFGS COMMAND SET PRIVCLASS -S Oooh... I bow deep and admire the cool elegance of this piece of art.
Shared DASD across multiple VM lpars
We have a growing VM/Linux environment with currently about 75 linux gues ts spread across three VM lpars. All DASD is defined as shared. All of the linux guests have been defined as TCPIP Layer 2; so that we can easily mo ve guests between lpars for performance/maintenance reasons. Each guests has unique mini-disks for the linux 191 and DASD swap spaces. Is it advisable to share the full volumes that these mini-disks reside on, across VM lpar s; assuming of course, that a linux guest is completely shutdown and logged off of one lpar before it is restarted on another ? Bob
Re: VM:Account MAINT's 123 disk
Does your VM:Account software a good level to support the z/VM level? Usualy, DIRMAINT 123 and MAINT 123 point to the same physical disk. The VM Resident is not CMS formatted indeed, it contains other stuff than only CMS files. When the disk is formattted (using ICKDSF CPVOL), ICKDSF will write some OS compatible stuff in the first cylinder, that's why ACCESS tells you OS as format. 2009/11/16 Dave Keeton dave.kee...@state.or.us I am attempting to install CA:Account and I have been unable to get it to start properly (it abends) because it isn't reading the object directory. I have defined a read-only link to MAINT's 123 disk (540RES) where the user directory is located, but it appears as OS formatted and not CMS to the VMACCT machine. I've tried linking instead to DirMaint's 123 link and got the same result. I'm not sure I understand why it's appearing that way and how to present it to VMACCT so it can read the user directory. Thanks in advance, Dave -- Kris Buelens, IBM Belgium, VM customer support
Re: VM:Account MAINT's 123 disk
Oops -- I saw CA and then just assumed it was the directory management product you were using.. don't do an MW link for VMACCT! Not sure exactly why it wants to read the object directory... but a readonly should suffice. Sorry! Scott On Mon, Nov 16, 2009 at 2:34 PM, Scott Rohling scott.rohl...@gmail.comwrote: I'm quite sure it will want an MW link to MAINT 123 since it will need to update the directory... Scott On Mon, Nov 16, 2009 at 2:29 PM, Dave Keeton dave.kee...@state.or.uswrote: I am attempting to install CA:Account and I have been unable to get it to start properly (it abends) because it isn't reading the object directory. I have defined a read-only link to MAINT's 123 disk (540RES) where the user directory is located, but it appears as OS formatted and not CMS to the VMACCT machine. I've tried linking instead to DirMaint's 123 link and got the same result. I'm not sure I understand why it's appearing that way and how to present it to VMACCT so it can read the user directory. Thanks in advance, Dave
Re: Shared DASD across multiple VM lpars
I bet you will be happy when z/VM 6.1 is installed and the Single image facility is ready for production. Larry Davis -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Robert J McCarthy Sent: Monday, November 16, 2009 4:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Shared DASD across multiple VM lpars We have a growing VM/Linux environment with currently about 75 linux guests spread across three VM lpars. All DASD is defined as shared. All of the linux guests have been defined as TCPIP Layer 2; so that we can easily move guests between lpars for performance/maintenance reasons. Each guests has unique mini-disks for the linux 191 and DASD swap spaces. Is it advisable to share the full volumes that these mini-disks reside on, across VM lpars; assuming of course, that a linux guest is completely shutdown and logged off of one lpar before it is restarted on another ? Bob
Re: VM:Account MAINT's 123 disk
VM:Account is fine with a RR link. But it wants a link to a full pack minidisk where the active object directory is housed. And you must put a statement in it's VMACCT CONFIG with the virtual address and the real label like: DIRECT 1A0 540RES In the dir: LINK MAINT 123 1A0 RR Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Monday, November 16, 2009 1:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Account MAINT's 123 disk Oops -- I saw CA and then just assumed it was the directory management product you were using.. don't do an MW link for VMACCT! Not sure exactly why it wants to read the object directory... but a readonly should suffice. Sorry! Scott On Mon, Nov 16, 2009 at 2:34 PM, Scott Rohling scott.rohl...@gmail.com wrote: I'm quite sure it will want an MW link to MAINT 123 since it will need to update the directory... Scott On Mon, Nov 16, 2009 at 2:29 PM, Dave Keeton dave.kee...@state.or.us wrote: I am attempting to install CA:Account and I have been unable to get it to start properly (it abends) because it isn't reading the object directory. I have defined a read-only link to MAINT's 123 disk (540RES) where the user directory is located, but it appears as OS formatted and not CMS to the VMACCT machine. I've tried linking instead to DirMaint's 123 link and got the same result. I'm not sure I understand why it's appearing that way and how to present it to VMACCT so it can read the user directory. Thanks in advance, Dave
Re: VM:Account MAINT's 123 disk
Make sure it is a LINK to MAINT’s 123 as 1A0 RR LINK MAINT 123 1A0 RR Verify the name in the VMACCT CONFIG file on VMACCT 191 you should see a statement like this toward the top DIRECT 1A0 540RES If yours does not say 540RES than you need to change it to match the VOLSER of where the ONLINE directory is. Larry Davis From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Monday, November 16, 2009 4:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Account MAINT's 123 disk Oops -- I saw CA and then just assumed it was the directory management product you were using.. don't do an MW link for VMACCT! Not sure exactly why it wants to read the object directory... but a readonly should suffice. Sorry! Scott On Mon, Nov 16, 2009 at 2:34 PM, Scott Rohling scott.rohl...@gmail.commailto:scott.rohl...@gmail.com wrote: I'm quite sure it will want an MW link to MAINT 123 since it will need to update the directory... Scott On Mon, Nov 16, 2009 at 2:29 PM, Dave Keeton dave.kee...@state.or.usmailto:dave.kee...@state.or.us wrote: I am attempting to install CA:Account and I have been unable to get it to start properly (it abends) because it isn't reading the object directory. I have defined a read-only link to MAINT's 123 disk (540RES) where the user directory is located, but it appears as OS formatted and not CMS to the VMACCT machine. I've tried linking instead to DirMaint's 123 link and got the same result. I'm not sure I understand why it's appearing that way and how to present it to VMACCT so it can read the user directory. Thanks in advance, Dave
VM SHUTDOWN RE_IPL
Does a SHUTDOWN REIPL 'reload' the CP Nucleus? I applied a PTF and generated a new nucleus. After renaming the current CPLOAD MODULE to CPOLD MODULE, I copied the one from 493 (K). If I instruct operations to do a SHUTDOWN REIPL, will the new nucleus be loaded? I think it does, but would like to be sure since I am having operations do the SHUTDOWN REIPL and I am remote. The reason I ask is because a SHUTDOWN REIPL does not re-read the SYSTEM CONFIG file correct?Thanks in advance. Thank you, Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| : 402.963.8905 || :847.849.7223 || : scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly**
Re: VM SHUTDOWN RE_IPL
Reloads the nuc AND re-reads the system config. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: Monday, November 16, 2009 2:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] VM SHUTDOWN RE_IPL Does a SHUTDOWN REIPL 'reload' the CP Nucleus? I applied a PTF and generated a new nucleus. After renaming the current CPLOAD MODULE to CPOLD MODULE, I copied the one from 493 (K). If I instruct operations to do a SHUTDOWN REIPL, will the new nucleus be loaded? I think it does, but would like to be sure since I am having operations do the SHUTDOWN REIPL and I am remote. The reason I ask is because a SHUTDOWN REIPL does not re-read the SYSTEM CONFIG file correct?Thanks in advance. Thank you, Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || : scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly**
Re: VM:Account MAINT's 123 disk
No, VM:Account does not need a write link to the object directory. VM:Secure and VM:Director are the only VM:Manager products that need a write link to the object directory. MAINT 123 will show up as OS-formatted when you access it under CMS. That’s normal. Dennis Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their own conscience. -- C.S. Lewis From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Monday, November 16, 2009 13:34 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Account MAINT's 123 disk I'm quite sure it will want an MW link to MAINT 123 since it will need to update the directory... Scott On Mon, Nov 16, 2009 at 2:29 PM, Dave Keeton dave.kee...@state.or.us wrote: I am attempting to install CA:Account and I have been unable to get it to start properly (it abends) because it isn't reading the object directory. I have defined a read-only link to MAINT's 123 disk (540RES) where the user directory is located, but it appears as OS formatted and not CMS to the VMACCT machine. I've tried linking instead to DirMaint's 123 link and got the same result. I'm not sure I understand why it's appearing that way and how to present it to VMACCT so it can read the user directory. Thanks in advance, Dave
Re: Shared DASD across multiple VM lpars
Single System Image is not in z/VM 6.1. It's a Statement of Direction, which means IBM intends to put it in a future release, but isn't promising anything. Dennis Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their own conscience. -- C.S. Lewis -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Davis, Larry (National VM/VSE Capability) Sent: Monday, November 16, 2009 13:21 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Shared DASD across multiple VM lpars I bet you will be happy when z/VM 6.1 is installed and the Single image facility is ready for production. Larry Davis -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Robert J McCarthy Sent: Monday, November 16, 2009 4:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Shared DASD across multiple VM lpars We have a growing VM/Linux environment with currently about 75 linux guests spread across three VM lpars. All DASD is defined as shared. All of the linux guests have been defined as TCPIP Layer 2; so that we can easily move guests between lpars for performance/maintenance reasons. Each guests has unique mini-disks for the linux 191 and DASD swap spaces. Is it advisable to share the full volumes that these mini-disks reside on, across VM lpars; assuming of course, that a linux guest is completely shutdown and logged off of one lpar before it is restarted on another ? Bob
Re: VM:Account MAINT's 123 disk
Have you applied all the zaps from CA to VMACCT? We experienced a VMACCT PRG001 abend and VMACCT looping problem on z/VM 5.3 and z/VM 5.4. It was fixed by a zap from CA. I don’t know the case/issue number as I was not the one applying the zap. Our VMACCT is link to the MAINT 123. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dave Keeton Sent: Monday, November 16, 2009 2:29 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Account MAINT's 123 disk I am attempting to install CA:Account and I have been unable to get it to start properly (it abends) because it isn't reading the object directory. I have defined a read-only link to MAINT's 123 disk (540RES) where the user directory is located, but it appears as OS formatted and not CMS to the VMACCT machine. I've tried linking instead to DirMaint's 123 link and got the same result. I'm not sure I understand why it's appearing that way and how to present it to VMACCT so it can read the user directory. Thanks in advance, Dave
Re: Shared DASD across multiple VM lpars
Not in 6.1, but the future one. Not sure if it has a number or not yet. Many of us will be dancing in the streets when it shows up. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Davis, Larry (National VM/VSE Capability) Sent: Monday, November 16, 2009 1:21 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Shared DASD across multiple VM lpars I bet you will be happy when z/VM 6.1 is installed and the Single image facility is ready for production. Larry Davis
Re: VM SHUTDOWN RE_IPL
My mistake, I have always been under the impression that SHUTDOWN REIPL did not re-read the SYSTEM CONFIG file. Thanks for clarifying that. Thank you, Scott -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes Sent: Monday, November 16, 2009 4:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM SHUTDOWN RE_IPL Reloads the nuc AND re-reads the system config. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: Monday, November 16, 2009 2:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] VM SHUTDOWN RE_IPL Does a SHUTDOWN REIPL 'reload' the CP Nucleus? I applied a PTF and generated a new nucleus. After renaming the current CPLOAD MODULE to CPOLD MODULE, I copied the one from 493 (K). If I instruct operations to do a SHUTDOWN REIPL, will the new nucleus be loaded? I think it does, but would like to be sure since I am having operations do the SHUTDOWN REIPL and I am remote. The reason I ask is because a SHUTDOWN REIPL does not re-read the SYSTEM CONFIG file correct?Thanks in advance. Thank you, Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || : scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Shared DASD across multiple VM lpars
It's the assuming of course part that will bite you :) One false move and wham, all is gone. And how to keep the directory in sync is another bit of the fun. The future promises to solve this for us. In the meantime, you can use CSE. Or wait... Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Robert J McCarthy Sent: Monday, November 16, 2009 1:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Shared DASD across multiple VM lpars We have a growing VM/Linux environment with currently about 75 linux gues= ts spread across three VM lpars. All DASD is defined as shared. All of the = linux guests have been defined as TCPIP Layer 2; so that we can easily mo= ve guests between lpars for performance/maintenance reasons. Each guests has= unique mini-disks for the linux 191 and DASD swap spaces. Is it advisable= to share the full volumes that these mini-disks reside on, across VM lpar= s; assuming of course, that a linux guest is completely shutdown and logged = off of one lpar before it is restarted on another ? Bob
Re: Shared DASD across multiple VM lpars
We share DASD between two z/VM LPAR's, and have guests set up so they can log on to either one. We use the Cross-System Link (XLINK) feature of CSE to make sure that they don't try to run on both LPAR's at once. Dennis Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their own conscience. -- C.S. Lewis -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes Sent: Monday, November 16, 2009 13:34 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Shared DASD across multiple VM lpars It's the assuming of course part that will bite you :) One false move and wham, all is gone. And how to keep the directory in sync is another bit of the fun. The future promises to solve this for us. In the meantime, you can use CSE. Or wait... Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Robert J McCarthy Sent: Monday, November 16, 2009 1:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Shared DASD across multiple VM lpars We have a growing VM/Linux environment with currently about 75 linux gues= ts spread across three VM lpars. All DASD is defined as shared. All of the = linux guests have been defined as TCPIP Layer 2; so that we can easily mo= ve guests between lpars for performance/maintenance reasons. Each guests has= unique mini-disks for the linux 191 and DASD swap spaces. Is it advisable= to share the full volumes that these mini-disks reside on, across VM lpar= s; assuming of course, that a linux guest is completely shutdown and logged = off of one lpar before it is restarted on another ? Bob
Re: Shared DASD across multiple VM lpars
You're not really specifying the requirements.. but reading between the lines - you want to be able to bring up the guest on one LPAR or the other.. so you will have to share the full volumes. You don't necessarily need unique minidisks for the 191 or swap, though... What 'is' the requirement? ;-) You can set things up to actually be live on both systems if you want - Scott On Mon, Nov 16, 2009 at 2:08 PM, Robert J McCarthy bob.mccar...@custserv.com wrote: We have a growing VM/Linux environment with currently about 75 linux guests spread across three VM lpars. All DASD is defined as shared. All of the linux guests have been defined as TCPIP Layer 2; so that we can easily move guests between lpars for performance/maintenance reasons. Each guests has unique mini-disks for the linux 191 and DASD swap spaces. Is it advisable to share the full volumes that these mini-disks reside on, across VM lpars; assuming of course, that a linux guest is completely shutdown and logged off of one lpar before it is restarted on another ? Bob
Re: Shared DASD across multiple VM lpars
We do that across several lpars. We run with a shared directory (DIRMAINT). We have put code in place to verify that the Linux guest is not running on another lpar. Paul Feller AIT Mainframe Technical Support -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Robert J McCarthy Sent: Monday, November 16, 2009 3:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Shared DASD across multiple VM lpars We have a growing VM/Linux environment with currently about 75 linux guests spread across three VM lpars. All DASD is defined as shared. All of the linux guests have been defined as TCPIP Layer 2; so that we can easily move guests between lpars for performance/maintenance reasons. Each guests has unique mini-disks for the linux 191 and DASD swap spaces. Is it advisable to share the full volumes that these mini-disks reside on, across VM lpars; assuming of course, that a linux guest is completely shutdown and logged off of one lpar before it is restarted on another ? Bob
Re: VM SHUTDOWN RE_IPL
It does reread the system config file. Several years ago, we had a problem of it picking up the old module. The way we got around that was to specify the MODULE CPLOAD parameter. If you do that, it will work regardless of whether you have changed the CP. I imagine it probably will work without the parameter; however, I haven't tested it in the years since, so I am only speculating. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: Monday, November 16, 2009 2:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM SHUTDOWN RE_IPL Does a SHUTDOWN REIPL 'reload' the CP Nucleus? I applied a PTF and generated a new nucleus. After renaming the current CPLOAD MODULE to CPOLD MODULE, I copied the one from 493 (K). If I instruct operations to do a SHUTDOWN REIPL, will the new nucleus be loaded? I think it does, but would like to be sure since I am having operations do the SHUTDOWN REIPL and I am remote. The reason I ask is because a SHUTDOWN REIPL does not re-read the SYSTEM CONFIG file correct?Thanks in advance. Thank you, Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || : scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly**
Re: VM:Account MAINT's 123 disk
My mistake - I was linking with the wrong vdev address. VM:Account expected 1A0, not 123. Thanks for the responses. Dave -Original Message- From: Scott Rohling scott.rohl...@gmail.com Reply-to: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Account MAINT's 123 disk Date: Mon, 16 Nov 2009 14:37:18 -0700 Oops -- I saw CA and then just assumed it was the directory management product you were using.. don't do an MW link for VMACCT! Not sure exactly why it wants to read the object directory... but a readonly should suffice. Sorry! Scott On Mon, Nov 16, 2009 at 2:34 PM, Scott Rohling scott.rohl...@gmail.com wrote: I'm quite sure it will want an MW link to MAINT 123 since it will need to update the directory... Scott On Mon, Nov 16, 2009 at 2:29 PM, Dave Keeton dave.kee...@state.or.us wrote: I am attempting to install CA:Account and I have been unable to get it to start properly (it abends) because it isn't reading the object directory. I have defined a read-only link to MAINT's 123 disk (540RES) where the user directory is located, but it appears as OS formatted and not CMS to the VMACCT machine. I've tried linking instead to DirMaint's 123 link and got the same result. I'm not sure I understand why it's appearing that way and how to present it to VMACCT so it can read the user directory. Thanks in advance, Dave
IBM Solutions Edition for Enterprise Linux
Cross posted to linux-390 and ibmvm: I kind of waited to see if anyone from IBM would even mention this here. It came out last week. Prices have come down... a lot... http://www-03.ibm.com/systems/z/solutions/editions/linux.html Those of you thinking of consolidating or even adding more need to go find out more... Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
Re: Shared DASD across multiple VM lpars
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is exactly what CSE is meant for. Yes, we use it. CSE + Dirmaint shared directory + Shared disk == not quite a cluster. (I'm still holding on for cluster level split brain protection, as well as the nifty live migration in the someday SSI) - -- Pat Feller, Paul wrote: We do that across several lpars. We run with a shared directory (DIRMAINT). We have put code in place to verify that the Linux guest is not running on another lpar. Paul Feller AIT Mainframe Technical Support -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Robert J McCarthy Sent: Monday, November 16, 2009 3:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Shared DASD across multiple VM lpars We have a growing VM/Linux environment with currently about 75 linux guests spread across three VM lpars. All DASD is defined as shared. All of the linux guests have been defined as TCPIP Layer 2; so that we can easily move guests between lpars for performance/maintenance reasons. Each guests has unique mini-disks for the linux 191 and DASD swap spaces. Is it advisable to share the full volumes that these mini-disks reside on, across VM lpars; assuming of course, that a linux guest is completely shutdown and logged off of one lpar before it is restarted on another ? Bob -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksCDVMACgkQNObCqA8uBswUKwCgnIji3CF6qc1Wa+CPVF0DluJZ 3FUAn1nOzGRObXt/SAZZ7sG0OXBW4fWW =Em78 -END PGP SIGNATURE-
Re: OS/390 2.4 guest under z/VM 5.3
On Monday, 11/16/2009 at 02:53 EST, Rob van der Heij rvdh...@gmail.com wrote: You're putting different traces in my mouth. It does not have to be a bogus PGM New PSW. It can also be something happening in the program check handler. A popular trick is when the old PSW is massaged in some way before doing a LPSW to continue at a slightly different spot. Sorry. I thought I knew what you meant. :-) A program interrupt loop is detected when there is a program check and the current PSW is the same as the Program New PSW. This indicates that there is something wrong with Program New PSW or there's not a valid instruction at the address pointed to by the PNPSW. Alan Altmark z/VM Development IBM Endicott
Re: VM SHUTDOWN RE_IPL
Wasn't it that you moved MAINT CF1 and that a SHUTDOWN REIPL used the contents of the old CF1. I tried to APAR it, but got a WAD.. 2009/11/16 Schuh, Richard rsc...@visa.com It does reread the system config file. Several years ago, we had a problem of it picking up the old module. The way we got around that was to specify the MODULE CPLOAD parameter. If you do that, it will work regardless of whether you have changed the CP. I imagine it probably will work without the parameter; however, I haven't tested it in the years since, so I am only speculating. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: Monday, November 16, 2009 2:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM SHUTDOWN RE_IPL Does a SHUTDOWN REIPL 'reload' the CP Nucleus? I applied a PTF and generated a new nucleus. After renaming the current CPLOAD MODULE to CPOLD MODULE, I copied the one from 493 (K). If I instruct operations to do a SHUTDOWN REIPL, will the new nucleus be loaded? I think it does, but would like to be sure since I am having operations do the SHUTDOWN REIPL and I am remote. The reason I ask is because a SHUTDOWN REIPL does not re-read the SYSTEM CONFIG file correct?Thanks in advance. Thank you, Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || : scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** -- Kris Buelens, IBM Belgium, VM customer support
