Re: Duplicate VOLSERs at IPL
Just to follow up on this thread: The response was: The developer has decided not to change the message type for this messag e. That's a totally BS answer. Call them back and challenge it. There should at least be a justification for why the developer refused to change it, especially since it can cause data corruption (bad spool pointers, anyone?), AND IS DOCUMENTED TO POSSIBLY DO SO. C'mon, guys, we know you're working on the Next Big Release, but jeez. Some things you shouldn't minimize on. -- db This is being worked on in the background. It seems the issue is not so black and white and possible solution is not so trivial as it may have seemed. Stay tuned... Mike MacIsaac mike...@us.ibm.com (845) 433-7061
Re: Duplicate VOLSERs at IPL
Just closing the loop on this thread... I did open a Sev 3 (should have been Sev 4) PMR for this issue on November 20, 2010, pasting pretty much the same text as posted earler to justify the W-level (Warning) message type on this mesesage. The PMR response was received today, December 27, 2010. The response was: The developer has decided not to change the message type for this messag e. I disagree, since the documentation warns that the wrong volume could be mounted. That incorrect mount could result in a system outage at the customer site to resolve the wrong volumn mount (E.g. mounting a wrong SPOOL volume, or other CP-Owned volume). I can't say for your site, but for us, unscheduled outages are very much frowned upon. OTOH, we don't intentionally duplicate DASD volsers. I automated executi on of a local CKDUPVOL EXEC every hour on VM:Operator, CKDUPVOL will send a text msg/page to z/VM support if a duplicate volser is found (excluding P AV alias volsers). I was simply attempting to protect z/VM newbies who may unknowingly creat e duplicate volsers during z/VM installation, or while building a 2nd level VM system. z/VM has a well-earned reputation for stability. Human error can damage that reputation just as surely as O.S. bugs. Well, I tried. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's.
Re: Duplicate VOLSERs at IPL
Which begs the question, what are the criteria for determining the level of a message? I would think that something that could cause potentially serious system problems, like getting an incorrect CP OWNED volume, would warrant an E. On the other hand, if the duplicated volser is for a volume having only user minidisks, a W might be appropriate as this can be straightened out after the ipl. Even that W is open for debate. If it is something that needs to be fixed before letting the users on the system, an E might be the correct level for the volumes that are merely attached to the system. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Monday, December 27, 2010 8:18 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Duplicate VOLSERs at IPL Just closing the loop on this thread... I did open a Sev 3 (should have = been Sev 4) PMR for this issue on November 20, 2010, pasting pretty much = the same text as posted earler to justify the W-level (Warning) message= type on this mesesage. The PMR response was received today, December 27,= 2010. The response was: The developer has decided not to change the message type for this messag= e.
Re: Duplicate VOLSERs at IPL
I suspect the developer is being somewhat influenced by the z/OS convention which simply warns you. But, at the same time, it halts the IPL and also gives you the option to select the appropriate duplicate. z/VM does not have the select option so if IBM insists on retaining the W class for the message they might also consider adding a select option which would go a long way to making the z/VM IPL much less error prone. Schuh, Richard rsc...@visa.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/27/2010 12:03 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Duplicate VOLSERs at IPL Which begs the question, what are the criteria for determining the level of a message? I would think that something that could cause potentially serious system problems, like getting an incorrect CP OWNED volume, would warrant an E. On the other hand, if the duplicated volser is for a volume having only user minidisks, a W might be appropriate as this can be straightened out after the ipl. Even that W is open for debate. If it is something that needs to be fixed before letting the users on the system, an E might be the correct level for the volumes that are merely attached to the system. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Monday, December 27, 2010 8:18 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Duplicate VOLSERs at IPL Just closing the loop on this thread... I did open a Sev 3 (should have = been Sev 4) PMR for this issue on November 20, 2010, pasting pretty much = the same text as posted earler to justify the W-level (Warning) message= type on this mesesage. The PMR response was received today, December 27,= 2010. The response was: The developer has decided not to change the message type for this messag= e.
Re: Duplicate VOLSERs at IPL
A dupkucate volser is not always an error, it can be, the system doesn't know. So a W is right. Better would indeed be an A, and have the operator decide what to do. 2010/12/27 George Henke/NYLIC george_he...@newyorklife.com I suspect the developer is being somewhat influenced by the z/OS convention which simply warns you. But, at the same time, it halts the IPL and also gives you the option to select the appropriate duplicate. z/VM does not have the select option so if IBM insists on retaining the W class for the message they might also consider adding a select option which would go a long way to making the z/VM IPL much less error prone. *Schuh, Richard rsc...@visa.com* Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/27/2010 12:03 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Duplicate VOLSERs at IPL Which begs the question, what are the criteria for determining the level of a message? I would think that something that could cause potentially serious system problems, like getting an incorrect CP OWNED volume, would warrant an E. On the other hand, if the duplicated volser is for a volume having only user minidisks, a W might be appropriate as this can be straightened out after the ipl. Even that W is open for debate. If it is something that needs to be fixed before letting the users on the system, an E might be the correct level for the volumes that are merely attached to the system. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU IBMVM@LISTSERV.UARK.EDU] On Behalf Of Mike Walter Sent: Monday, December 27, 2010 8:18 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Duplicate VOLSERs at IPL Just closing the loop on this thread... I did open a Sev 3 (should have = been Sev 4) PMR for this issue on November 20, 2010, pasting pretty much = the same text as posted earler to justify the W-level (Warning) message= type on this mesesage. The PMR response was received today, December 27,= 2010. The response was: The developer has decided not to change the message type for this messag= e. -- Kris Buelens, IBM Belgium, VM customer support
Re: Duplicate VOLSERs at IPL
On 12/27/10 11:18 AM, Mike Walter mike.wal...@hewitt.com wrote: The response was: The developer has decided not to change the message type for this messag e. That's a totally BS answer. Call them back and challenge it. There should at least be a justification for why the developer refused to change it, especially since it can cause data corruption (bad spool pointers, anyone?), AND IS DOCUMENTED TO POSSIBLY DO SO. C'mon, guys, we know you're working on the Next Big Release, but jeez. Some things you shouldn't minimize on. -- db
Duplicate VOLSERs at IPL
I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I IPL. the maintenance. How can I be sure the IPL will not pick up these standby disks but WILL pick them up if I need them for fallback? Is just changing the 540RES IPL address enough?
Re: Duplicate VOLSERs at IPL
Here's what I do (I think you remember my FLASH2ND EXEC): 1) Use FLASH2ND to create a 2nd level/backup system a. This will use a new prefixed VOLID of '54B' (replacing the 540). b. Updates the SYSTEM CONFIG reflecting the new VOLID c. Updates a copy of the 1st level directory (USER2 DIRECT) changing the VOLIDs to match the new prefix d. Runs DIRECT against the 2nd level/backup system with the updated directory (USER2 DIRECT). 2) FLASH2ND process creates unique VolSer (VOLID) and is IPLable (w/o changes) Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of George Henke/NYLIC Sent: Wednesday, October 20, 2010 10:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate VOLSERs at IPL I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I IPL. the maintenance. How can I be sure the IPL will not pick up these standby disks but WILL pick them up if I need them for fallback? Is just changing the 540RES IPL address enough? _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
Re: Duplicate VOLSERs at IPL
That's slllick. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Frank M. Ramaekers Sent: Wednesday, October 20, 2010 10:35 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Duplicate VOLSERs at IPL Here's what I do (I think you remember my FLASH2ND EXEC): 1) Use FLASH2ND to create a 2nd level/backup system a. This will use a new prefixed VOLID of '54B' (replacing the 540). b. Updates the SYSTEM CONFIG reflecting the new VOLID c. Updates a copy of the 1st level directory (USER2 DIRECT) changing the VOLIDs to match the new prefix d. Runs DIRECT against the 2nd level/backup system with the updated directory (USER2 DIRECT). 2) FLASH2ND process creates unique VolSer (VOLID) and is IPLable (w/o changes) Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of George Henke/NYLIC Sent: Wednesday, October 20, 2010 10:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate VOLSERs at IPL I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I IPL. the maintenance. How can I be sure the IPL will not pick up these standby disks but WILL pick them up if I need them for fallback? Is just changing the 540RES IPL address enough? _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
Re: Duplicate VOLSERs at IPL
Yes, tyvm, Frank, I remember it well and I guess it is time to use it. I was just hoping I would not have to. But I guess not or you would not have gone to the trouble of creating it. Frank M. Ramaekers framaek...@ailife.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 10/20/2010 11:34 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Duplicate VOLSERs at IPL Here’s what I do (I think you remember my FLASH2ND EXEC): 1) Use FLASH2ND to create a 2nd level/backup system a. This will use a new prefixed VOLID of ‘54B’ (replacing the 540). b. Updates the SYSTEM CONFIG reflecting the new VOLID c. Updates a copy of the 1st level directory (USER2 DIRECT) changing the VOLIDs to match the new prefix d. Runs DIRECT against the 2nd level/backup system with the updated directory (USER2 DIRECT). 2) FLASH2ND process creates unique VolSer (VOLID) and is IPLable (w/o changes) Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of George Henke/NYLIC Sent: Wednesday, October 20, 2010 10:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate VOLSERs at IPL I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I IPL. the maintenance. How can I be sure the IPL will not pick up these standby disks but WILL pick them up if I need them for fallback? Is just changing the 540RES IPL address enough? _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
Re: Duplicate VOLSERs at IPL
Yes, tyvm, Michael. Here is the procedure from Stephen Powell earlier this week to which I believe you allude. If I follow this procedure for falback, then, I should be ok? (1) Open both the Integrated 3270 Console and Operating System Messages windows for the LPAR being IPLed. (2) Double-click on the LOAD icon in the CPC Recovery Menu while the desired LPAR (and only that LPAR) is selected. (3) Enter the device number of the volume which contains the SAPL in the load address field and SYSG in the LOADPARM field. Proceeed with LOAD. (4) The SAPL will initialize on the Integrated 3270 Console window. Give that window the focus. (5) On the SAPL screen, change the module name to ICKSADSF (defaults to CPLOAD, of course) and the load origin to 1000 (if it isn't already). Then tab down to the IPL PARAMETERS field and type CONS=SYSC in the data field, wiping out whatever else may have been there originally. Leave no residual characters. Then press PF10 (F10) to load. (6) Now switch focus to the Operating System Messages window. You should see ICK005E DEFINE INPUT DEVICE, REPLY ',CUU' OR 'CONSOLE' ENTER INPUT/COMMAND: You should know how to handle it from there. In short, SAPL supports SYSG but not SYSC; and ICKDSF supports SYSC but not SYSG! Therefore, both the Integrated 3270 Console window and the Operating System Messages window must be used, each for its own task. There are no real device numbers in SYSTEM CONFIGURATION or DIRECTORY, only VOLSERs and virtual devices. So I guess everything in the IPL after the IPL device address is driven by VOLSER, not device number. So unique VOLSERs are critical at least at IPL time if not at other times. Michael Coffin michaelcof...@mccci.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 10/20/2010 11:41 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Duplicate VOLSERs at IPL Relabel your “standby disks”, maybe put an X in the first character. WRITE DOWN the addresses of your system packs so you have them when you need them. If you come up on your packs with maintenance applied and all is well, you can just recycle those “standby disks” at your convenience. If there is a problem, and you find you need to IPL the standby disks, use IPLSADSF on the PARM disk to relabel packs before IPL’ing (i.e. change your production 540RES to X40RES, and change your X40RES standby disk to 540RES, repeat for all CP OWNED spindles). And since we were just discussing this earlier this week, be advised IPLSADSF only run in line mode on SYSC, it will not run in 3270 mode on SYSG. :) -Mike From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of George Henke/NYLIC Sent: Wednesday, October 20, 2010 11:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate VOLSERs at IPL I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I IPL. the maintenance. How can I be sure the IPL will not pick up these standby disks but WILL pick them up if I need them for fallback? Is just changing the 540RES IPL address enough?
Re: Duplicate VOLSERs at IPL
Where can one pick up that wonderful exec? From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Frank M. Ramaekers Sent: Wednesday, October 20, 2010 10:35 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Duplicate VOLSERs at IPL Here's what I do (I think you remember my FLASH2ND EXEC): 1) Use FLASH2ND to create a 2nd level/backup system a. This will use a new prefixed VOLID of '54B' (replacing the 540). b.Updates the SYSTEM CONFIG reflecting the new VOLID c. Updates a copy of the 1st level directory (USER2 DIRECT) changing the VOLIDs to match the new prefix d.Runs DIRECT against the 2nd level/backup system with the updated directory (USER2 DIRECT). 2) FLASH2ND process creates unique VolSer (VOLID) and is IPLable (w/o changes) Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of George Henke/NYLIC Sent: Wednesday, October 20, 2010 10:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate VOLSERs at IPL I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I IPL. the maintenance. How can I be sure the IPL will not pick up these standby disks but WILL pick them up if I need them for fallback? Is just changing the 540RES IPL address enough? _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com. == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: Duplicate VOLSERs at IPL
How about putting a 2nd config file on the CF1, something like PREMNT CONFIG. The SYSTEM CONFIG has Offline_at_IPL of the backup packs, PREMNT has Offline of the new packs. If the IPL doesn't work, IPL and use fn=PREMNT on the SAPL. If everything works as planned the volumes can be brought online and relabeled. Bob Bates robert.ba...@wellsfargo.commailto:robert.ba...@wellsfargo.com 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 George Henke/NYLIC Sent: Wednesday, October 20, 2010 10:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate VOLSERs at IPL I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I IPL. the maintenance. How can I be sure the IPL will not pick up these standby disks but WILL pick them up if I need them for fallback? Is just changing the 540RES IPL address enough?
Re: Duplicate VOLSERs at IPL
and I thought all you need to do was make sure the duplicates where at a higher address on the string and it would hit the lower ones 1st and advise there was a dupe after reading these posts I wonder Bob Bates robert.ba...@wel lsfargo.com To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System ib...@listserv.u Subject ARK.EDU Re: Duplicate VOLSERs at IPL 10/20/2010 12:38 PM Please respond to The IBM z/VM Operating System ib...@listserv.u ARK.EDU How about putting a 2nd config file on the CF1, something like PREMNT CONFIG. The SYSTEM CONFIG has Offline_at_IPL of the backup packs, PREMNT has Offline of the new packs. If the IPL doesn’t work, IPL and use fn=PREMNT on the SAPL. If everything works as planned the volumes can be brought online and relabeled. Bob Bates robert.ba...@wellsfargo.com 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 George Henke/NYLIC Sent: Wednesday, October 20, 2010 10:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate VOLSERs at IPL I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I IPL. the maintenance. How can I be sure the IPL will not pick up these standby disks but WILL pick them up if I need them for fallback? Is just changing the 540RES IPL address enough?
Re: Duplicate VOLSERs at IPL
We have no issues coming up w/ this q dasd 540res DASD 8000 CP OWNED 540RES 496 DASD 8006 540RES Ready; T=0.01/0.01 11:45:43 Bob Bates robert.ba...@wel lsfargo.com To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System ib...@listserv.u Subject ARK.EDU Re: Duplicate VOLSERs at IPL 10/20/2010 12:38 PM Please respond to The IBM z/VM Operating System ib...@listserv.u ARK.EDU How about putting a 2nd config file on the CF1, something like PREMNT CONFIG. The SYSTEM CONFIG has Offline_at_IPL of the backup packs, PREMNT has Offline of the new packs. If the IPL doesn’t work, IPL and use fn=PREMNT on the SAPL. If everything works as planned the volumes can be brought online and relabeled. Bob Bates robert.ba...@wellsfargo.com 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 George Henke/NYLIC Sent: Wednesday, October 20, 2010 10:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate VOLSERs at IPL I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I IPL. the maintenance. How can I be sure the IPL will not pick up these standby disks but WILL pick them up if I need them for fallback? Is just changing the 540RES IPL address enough?
Re: Duplicate VOLSERs at IPL
Not adequate. What happens if one of the devices at the lower address fails to respond to the IPL roll call? That is a case of having only 1 device, the wrong one, with the volser. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of August Carideo Sent: Wednesday, October 20, 2010 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Duplicate VOLSERs at IPL and I thought all you need to do was make sure the duplicates where at a higher address on the string and it would hit the lower ones 1st and advise there was a dupe after reading these posts I wonder Bob Bates robert.ba...@wel lsfargo.com To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System ib...@listserv.u Subject ARK.EDU Re: Duplicate VOLSERs at IPL 10/20/2010 12:38 PM Please respond to The IBM z/VM Operating System ib...@listserv.u ARK.EDU How about putting a 2nd config file on the CF1, something like PREMNT CONFIG. The SYSTEM CONFIG has Offline_at_IPL of the backup packs, PREMNT has Offline of the new packs. If the IPL doesn't work, IPL and use fn=PREMNT on the SAPL. If everything works as planned the volumes can be brought online and relabeled. Bob Bates robert.ba...@wellsfargo.com 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 George Henke/NYLIC Sent: Wednesday, October 20, 2010 10:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate VOLSERs at IPL I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I IPL. the maintenance. How can I be sure the IPL will not pick up these standby disks but WILL pick them up if I need them for fallback? Is just changing the 540RES IPL address enough?
Re: Duplicate VOLSERs at IPL
Good point Yes from other posts I can see that will most likely at least rename so called fallback and look into that exec thanks Augie Schuh, Richard rsc...@visa.com Sent by: The IBM To z/VM OperatingIBMVM@LISTSERV.UARK.EDU System cc ib...@listserv.u ARK.EDU Subject Re: Duplicate VOLSERs at IPL 10/20/2010 12:52 PM Please respond to The IBM z/VM Operating System ib...@listserv.u ARK.EDU Not adequate. What happens if one of the devices at the lower address fails to respond to the IPL roll call? That is a case of having only 1 device, the wrong one, with the volser. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of August Carideo Sent: Wednesday, October 20, 2010 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Duplicate VOLSERs at IPL and I thought all you need to do was make sure the duplicates where at a higher address on the string and it would hit the lower ones 1st and advise there was a dupe after reading these posts I wonder Bob Bates robert.ba...@wel lsfargo.com To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System ib...@listserv.u Subject ARK.EDU Re: Duplicate VOLSERs at IPL 10/20/2010 12:38 PM Please respond to The IBM z/VM Operating System ib...@listserv.u ARK.EDU How about putting a 2nd config file on the CF1, something like PREMNT CONFIG. The SYSTEM CONFIG has Offline_at_IPL of the backup packs, PREMNT has Offline of the new packs. If the IPL doesn't work, IPL and use fn=PREMNT on the SAPL. If everything works as planned the volumes can be brought online and relabeled. Bob Bates robert.ba...@wellsfargo.com 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 George Henke/NYLIC Sent: Wednesday, October 20, 2010 10:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate VOLSERs at IPL I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I IPL. the maintenance. How can I be sure the IPL will not pick up these standby disks but WILL pick them up if I need them for fallback? Is just changing the 540RES IPL address enough?
Re: Duplicate VOLSERs at IPL
Additionally, he said that he *had* been planning to use the same volser for both systems SPOOL volumes. SAPL's DEVICE NUMBER: field will let you point to a specific device address for the IPL volume, but the first matching SPOOL volser(s) would be found. If that was from the system without the maintenance, the wrong SDFs would be used. Your gun, your foot. Duplicate volsers are simply an invitation to self-imposed disaster. They can be used if you are _both_ experienced ... and LUCKY! But it is _your_ _job_ on the line! Why expose yourself to potential problems when there are other, perfectly reliable, means to avoid problems? Mike Walter Aon Hewitt The opinions expressed herein are mine alone, not my employer's. August Carideo august.cari...@avon.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 10/20/2010 12:01 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Duplicate VOLSERs at IPL Good point Yes from other posts I can see that will most likely at least rename so called fallback and look into that exec thanks Augie Schuh, Richard rsc...@visa.com Sent by: The IBM To z/VM OperatingIBMVM@LISTSERV.UARK.EDU System cc ib...@listserv.u ARK.EDU Subject Re: Duplicate VOLSERs at IPL 10/20/2010 12:52 PM Please respond to The IBM z/VM Operating System ib...@listserv.u ARK.EDU Not adequate. What happens if one of the devices at the lower address fails to respond to the IPL roll call? That is a case of having only 1 device, the wrong one, with the volser. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of August Carideo Sent: Wednesday, October 20, 2010 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Duplicate VOLSERs at IPL and I thought all you need to do was make sure the duplicates where at a higher address on the string and it would hit the lower ones 1st and advise there was a dupe after reading these posts I wonder Bob Bates robert.ba...@wel lsfargo.com To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System ib...@listserv.u Subject ARK.EDU Re: Duplicate VOLSERs at IPL 10/20/2010 12:38 PM Please respond to The IBM z/VM Operating System ib...@listserv.u ARK.EDU How about putting a 2nd config file on the CF1, something like PREMNT CONFIG. The SYSTEM CONFIG has Offline_at_IPL of the backup packs, PREMNT has Offline of the new packs. If the IPL doesn't work, IPL and use fn=PREMNT on the SAPL. If everything works as planned the volumes can be brought online and relabeled. Bob Bates robert.ba...@wellsfargo.com 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 George Henke/NYLIC Sent: Wednesday, October 20, 2010 10:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate VOLSERs at IPL I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I IPL. the maintenance. How can I be sure the IPL will not pick up these standby disks but WILL pick them up if I need them for fallback? Is just changing the 540RES IPL address enough? The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable
Re: Duplicate VOLSERs at IPL
IBM has stated that this is not guaranteed. Frank M. Ramaekers Jr. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of August Carideo Sent: Wednesday, October 20, 2010 11:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Duplicate VOLSERs at IPL and I thought all you need to do was make sure the duplicates where at a higher address on the string and it would hit the lower ones 1st and advise there was a dupe after reading these posts I wonder Bob Bates robert.ba...@wel lsfargo.com To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System ib...@listserv.u Subject ARK.EDU Re: Duplicate VOLSERs at IPL 10/20/2010 12:38 PM Please respond to The IBM z/VM Operating System ib...@listserv.u ARK.EDU How about putting a 2nd config file on the CF1, something like PREMNT CONFIG. The SYSTEM CONFIG has Offline_at_IPL of the backup packs, PREMNT has Offline of the new packs. If the IPL doesn't work, IPL and use fn=PREMNT on the SAPL. If everything works as planned the volumes can be brought online and relabeled. Bob Bates robert.ba...@wellsfargo.com 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 George Henke/NYLIC Sent: Wednesday, October 20, 2010 10:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate VOLSERs at IPL I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I IPL. the maintenance. How can I be sure the IPL will not pick up these standby disks but WILL pick them up if I need them for fallback? Is just changing the 540RES IPL address enough? _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
Re: Duplicate VOLSERs at IPL
On Wednesday, 10/20/2010 at 12:52 EDT, Schuh, Richard rsc...@visa.com wrote: Not adequate. What happens if one of the devices at the lower address fails to respond to the IPL roll call? That is a case of having only 1 device, the wrong one, with the volser. Mantra: Only volumes that you WANT online at IPL should be ALLOWED to come online at IPL. Use OFFLINE/ONLINE_AT_IPL in SYSTEM CONFIG. Have multiple CONFIG files to let you bring various sets of volumes online (incl. one with all devs online). Use the IMBED statement creatively. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: Duplicate VOLSERs at IPL
On Wednesday, October 20, 2010 11:44 AM, August Carideo wrote: and I thought all you need to do was make sure the duplicates where at a higher address on the string and it would hit the lower ones 1st and advise there was a dupe after reading these posts I wonder I have not looked at the code, but if I were to hazzard a guess, I would guess that it processes the volumes in order of increasing subchannel number. Programatically, that is the easiest way to loop through all devices. Start with X'0001' in register 1 and issue STSCH. Increment the number in register 1 by 1 each time through the loop, and quit when STSCH returns condition code 3 or when X'0002' is reached. And that does not necessarily correspond to increasing device number order. What you can do is treat certain devices (by device number, not by volser) as offline at IPL in the system configuration file to avoid duplicate volsers. Then, specify an alternate configuration file at IPL time to backout, if necessary. The alternate configuration file lists a different range of devices as offline at IPL. -- .''`. Stephen Powell : :' : `. `'` `-
Re: Duplicate VOLSERs at IPL
And,l to cite the most recent recitation of that documention: ---snip--- Date: Fri, 27 Aug 2010 14:38:24 -0400 Reply-To: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Sender: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU From: Alan Altmark alan_altm...@us.ibm.com Subject: Re: Duplicate VOLID's Content-Type: text/plain; charset=US-ASCII On Thursday, 08/26/2010 at 09:58 EDT, Tom Huegel tehue...@gmail.com wrote: So I guess there is no way to absolutly protect z/VM from using the wrong pack at IPL.. Maybe a requirement? In SYSTEM CONFIG allow optional rdev on the SLOT deffinations. comments? Rich Corak has explained on previous occasions how volser recognition works. If CP detects a duplicate volser for a device to be attached to SYSTEM at IPL, you will get HCP954I DASD rdev1 VOLID volid IS A DUPLICATE OF DASD rdev2 and you are responsible to ensure that rdev2 is the one you intended to be attached to the system. Out of all the volumes on the system with that volid, the lowest *device number* (address) will win, without regard to who responds first. As has been suggested, this is no guarantee since you can find yourself in trouble if you have a dasd problem or someone dinks with the I/O config and makes a mistake. Being able to place the RDEV on the CP_owned and user_volume_ statements is one way to help mitigate the problem. There is another way to identify devices: by their architected node element descriptor (NED). Or in the lingua franca, universally unique identifiers (UUIDs). When Single System Image hits the streets, you will find UUIDs very much in evidence, though not in the context of IPL or SYSTEM CONFIG. But I could imagine something like this in SYSTEM CONFIG: CP_Owned Slot 1 6X0RES ID 2105.000.IBM.13.3737504EE.0D0A CP_owned Slot 2 6X0TD1 ID 2107.900.IBM.13.29839621A.0D0A CP_owned Slot 3 6X0PG1 ID 2107.900.IBM.13.4924295DC.0D0A, (yes, there are two IDs for slot 3) 2107.900.IBM.13.0358113AA.0D0A (..choose in the order given) so that you wouldn't have to worry about the RDEV. However, there is a Heisenberg-esque trade-off to be made between flexibility and security. Good news - the above syntax ensures you won't have any bogus volumes. Bad news - it won't tolerate any copies or change in DASD, so it's generally hostile to a dynamic DR environment, and you can't get the NED until you IPL. Hmmmorwhen IPL has finished, CP could write the found UUIDs to the warm start area and use those in preference to any other on a subsequent IPL. For PPRC pairs, write both UUIDs and allow either. If a volume with the needed UUID is not available, then (based on configuration) ask which RDEV to use a la z/OS, or just take the lowest-numbered one available. In either case, update the UUID in the warm start area. h. Alan Altmark z/VM Development IBM Endicott ---snip--- Now... for those who were not aware of it, there is an ONLINE ARCHIVE of the IBMVM discussion list. It is amazingly easy to use and does a wonderful job of permitting you to search for previous posts. The post pasted above was found be searching for: DUPLICATE VOLSER with the date qualifier: since 1 JANUARY 2010 Please, please, **PLEASE** copy and paste the following URL into your browser (NOW, before you get side-tracked), and save it as a Favorite. You'll be happy you did so on some weekend or night when you need a quick answer and no one is responding online. http://listserv.uark.edu/archives/ibmvm.html I'd venture a guess that at least sixty percent of the questions posed on this list have answers in previous posts that can be found by using that archive search URL. That's very handy when no one is available to reply right away... Mike Walter Aon Hewitt The opinions expressed herein are mine alone, not my employer's. Frank M. Ramaekers framaek...@ailife.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 10/20/2010 12:44 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Duplicate VOLSERs at IPL IBM has stated that this is not guaranteed. Frank M. Ramaekers Jr. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of August Carideo Sent: Wednesday, October 20, 2010 11:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Duplicate VOLSERs at IPL and I thought all you need to do was make sure the duplicates where at a higher address on the string and it would hit the lower ones 1st and advise there was a dupe after reading these posts I wonder Bob Bates robert.ba...@wel lsfargo.com To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System ib...@listserv.u Subject ARK.EDU
Re: Duplicate VOLSERs at IPL
On Fri, 27 Aug 2010 14:38:24 -0400, Alan Altmark wrote: Rich Corak has explained on previous occasions how volser recognition works. If CP detects a duplicate volser for a device to be attached to SYSTEM at IPL, you will get HCP954I DASD rdev1 VOLID volid IS A DUPLICATE OF DASD rdev2 and you are responsible to ensure that rdev2 is the one you intended to be attached to the system. Out of all the volumes on the system with that volid, the lowest *device number* (address) will win, without regard to who responds first. Looks like my guess was wrong. But you can still wind up with the wrong volser mounted if the right device doesn't respond for some reason, as Alan has said. -- .''`. Stephen Powell : :' : `. `'` `-
Re: Duplicate VOLSERs at IPL
HCP954I DASD rdev1 VOLID volid IS A DUPLICATE OF DASD rdev2 Nonetheless, I believe that the message begs the question: why is that an I-level information message rather than a W-level warning message? The operator response states: Operator Response: Verify that the volume mounted on DASD rdev1 is the one to be used by the system. If it is not, CP may perform incorrect allocation on the volume specified. Shut down the system and remove the incorrectly labeled volume that is a duplicate. This message usually occurs after a system restart when users have mounted volumes with labels identical to those of other user or CP volumes. I believe that CP may perform incorrect allocation on the volume specified. Shut down the system and remove the incorrectly labeled volume that is a duplicate. are pretty outage-intensive warnings. If the situation could be that critical, it should be a Warning-level message. I'll open a PMR for this. Mike Walter Aon Hewitt The opinions expressed herein are mine alone, not my employer's. Stephen Powell zlinux...@wowway.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 10/20/2010 01:27 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Duplicate VOLSERs at IPL On Fri, 27 Aug 2010 14:38:24 -0400, Alan Altmark wrote: Rich Corak has explained on previous occasions how volser recognition works. If CP detects a duplicate volser for a device to be attached to SYSTEM at IPL, you will get HCP954I DASD rdev1 VOLID volid IS A DUPLICATE OF DASD rdev2 and you are responsible to ensure that rdev2 is the one you intended to be attached to the system. Out of all the volumes on the system with that volid, the lowest *device number* (address) will win, without regard to who responds first. Looks like my guess was wrong. But you can still wind up with the wrong volser mounted if the right device doesn't respond for some reason, as Alan has said. -- .''`. Stephen Powell : :' : `. `'` `- The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Duplicate VOLSERs at IPL
Instead of UUID I like the idea of a user supplied (maintained) passcode that would be used by all OS's whenever AVR routines were used. Maybe 20 characters long.. copy programs could ask if you wanted to change it. Put something in there like 'RSU 1002' or 'Joe's test vol'. On Wed, Oct 20, 2010 at 11:27 AM, Stephen Powell zlinux...@wowway.comwrote: On Fri, 27 Aug 2010 14:38:24 -0400, Alan Altmark wrote: Rich Corak has explained on previous occasions how volser recognition works. If CP detects a duplicate volser for a device to be attached to SYSTEM at IPL, you will get HCP954I DASD rdev1 VOLID volid IS A DUPLICATE OF DASD rdev2 and you are responsible to ensure that rdev2 is the one you intended to be attached to the system. Out of all the volumes on the system with that volid, the lowest *device number* (address) will win, without regard to who responds first. Looks like my guess was wrong. But you can still wind up with the wrong volser mounted if the right device doesn't respond for some reason, as Alan has said. -- .''`. Stephen Powell : :' : `. `'` `-
