Re: IODF Change...
Tom Marchant pisze: On Wed, 14 Oct 2009 09:56:46 -0700, Guy Gardoit wrote: I like to coordinate the last two characters of the IODF data set with the IOCDS I intend to write it to. Example: Create production IODF00 and write it to IOCDS A0. Do you mean that you only use IODF00, IODF01, IODF02 and IODF03? That doesn't allow much flexibility. It isn't very hard to figure out which IODF matches an IOCDS. There is a place in IOCDS load job, where you can put your comment. The comment is then visible on HMC panels. My rule is ABCDnn, where ABCD is username and nn is IODFnn suffix. The other rule is to avoid touching IOCDS used for last IPL and preferrably IOCDS containing last working configuration. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
On Tue, 13 Oct 2009 16:52:58 -0400, Scott Rowe wrote: There is no need to change an IOCDS, it is enough to ACTIVATE the IODF. To clarify, there is no need to create an IOCDS to activate the IODF. It is a good idea to create an IOCDS when you think you have the IODF ready so that the next time you perform a POR the correct hardware definitions will be loaded into the HSA. Of course, if you never need to perform a POR, the IOCDS is not needed at all. However, if there is ever a need to perform a POR, you want an IOCDS that is reasonably close to the IODF that you have been running with. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
I agree completely. Tom Marchant m42tom-ibmm...@yahoo.com 10/14/09 7:42 AM On Tue, 13 Oct 2009 16:52:58 -0400, Scott Rowe wrote: There is no need to change an IOCDS, it is enough to ACTIVATE the IODF. To clarify, there is no need to create an IOCDS to activate the IODF. It is a good idea to create an IOCDS when you think you have the IODF ready so that the next time you perform a POR the correct hardware definitions will be loaded into the HSA. Of course, if you never need to perform a POR, the IOCDS is not needed at all. However, if there is ever a need to perform a POR, you want an IOCDS that is reasonably close to the IODF that you have been running with. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
I disagree completely. To avoid easily obtained out of sync conditions, this process should always be followed for *any* IODF changes: WAS 1. W After the new production IODF is created, use HCD to write it to one of the IOCDS in each machine. I like to coordinate the last two characters of the IODF data set with the IOCDS I intend to write it to. Example: Create production IODF00 and write it to IOCDS A0. 2. ... Activate the IODF in all systems using HCD - I try to avoid activate configuration sysplex wide. I'm not brave enough for that one. Just do one system at a time. 3. S From one LPAR on each machine, use HCD to switch to the new IOCDS - same (ok, almost) as doing a POR Following this process will always avoid any chance of hardware/software being out of sync. Sometimes laziness is a good qulaity in a systems programmer - but not with hardware/software configuration changes. On Wed, Oct 14, 2009 at 4:49 AM, Scott Rowe scott.r...@joann.com wrote: I agree completely. Tom Marchant m42tom-ibmm...@yahoo.com 10/14/09 7:42 AM On Tue, 13 Oct 2009 16:52:58 -0400, Scott Rowe wrote: There is no need to change an IOCDS, it is enough to ACTIVATE the IODF. To clarify, there is no need to create an IOCDS to activate the IODF. It is a good idea to create an IOCDS when you think you have the IODF ready so that the next time you perform a POR the correct hardware definitions will be loaded into the HSA. Of course, if you never need to perform a POR, the IOCDS is not needed at all. However, if there is ever a need to perform a POR, you want an IOCDS that is reasonably close to the IODF that you have been running with. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Guy Gardoit z/OS Systems Programming -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
This article is very confusing - HCD is not that complicated. You'd be wise to ignore it. On Tue, Oct 13, 2009 at 1:27 PM, Jeffrey Deaver jeffrey.dea...@securian.com wrote: I have an IODF which has a mistake in it in regards to some new storage we've attached... Assuming I'm not missing some other configuration issue, I should be able to change the IODF, IPL that LPAR and have the change take effect, right? No POR necessary, right? What am I missing? See, as soon as I send the question, I find what I need. This article seems to explain it quite well... http://www.zjournal.com/index.cfm?section=articleaid=375# ... and points out a few things I'm missing. Jeffrey Deaver, Engineer Systems Engineering jeffrey.dea...@securian.com 651-665-4231(v) IS - Creating competitive advantage with technology. Providing service that excels. OSS - Where Innovation Happens -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Guy Gardoit z/OS Systems Programming -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
Gary, Writing the IOCDS has nothing to do with out of sync conditions. The out of sync conditions are caused when the activation is not done to both hardware and software. They can also be caused by IPLing with the incorrect IODF, which can be easily solved by not hard coding the IODF number in the LOADxx member. Guy Gardoit ggard...@gmail.com 10/14/2009 12:56 PM I disagree completely. To avoid easily obtained out of sync conditions, this process should always be followed for *any* IODF changes: WAS 1. W After the new production IODF is created, use HCD to write it to one of the IOCDS in each machine. I like to coordinate the last two characters of the IODF data set with the IOCDS I intend to write it to. Example: Create production IODF00 and write it to IOCDS A0. 2. ... Activate the IODF in all systems using HCD - I try to avoid activate configuration sysplex wide. I'm not brave enough for that one. Just do one system at a time. 3. S From one LPAR on each machine, use HCD to switch to the new IOCDS - same (ok, almost) as doing a POR Following this process will always avoid any chance of hardware/software being out of sync. Sometimes laziness is a good qulaity in a systems programmer - but not with hardware/software configuration changes. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
Sorry Guy, I realized I typed your name incorrectly only after I had hit send. Guy Gardoit ggard...@gmail.com 10/14/2009 12:56 PM I disagree completely. To avoid easily obtained out of sync conditions, this process should always be followed for *any* IODF changes: WAS 1. W After the new production IODF is created, use HCD to write it to one of the IOCDS in each machine. I like to coordinate the last two characters of the IODF data set with the IOCDS I intend to write it to. Example: Create production IODF00 and write it to IOCDS A0. 2. ... Activate the IODF in all systems using HCD - I try to avoid activate configuration sysplex wide. I'm not brave enough for that one. Just do one system at a time. 3. S From one LPAR on each machine, use HCD to switch to the new IOCDS - same (ok, almost) as doing a POR Following this process will always avoid any chance of hardware/software being out of sync. Sometimes laziness is a good qulaity in a systems programmer - but not with hardware/software configuration changes. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
On Wed, 14 Oct 2009 09:56:46 -0700, Guy Gardoit wrote: I like to coordinate the last two characters of the IODF data set with the IOCDS I intend to write it to. Example: Create production IODF00 and write it to IOCDS A0. Do you mean that you only use IODF00, IODF01, IODF02 and IODF03? That doesn't allow much flexibility. It isn't very hard to figure out which IODF matches an IOCDS. I always like to keep the IODF that was used for the last IPL. Sometimes it is necessary to perform an IODF update in stages. I once did about 8 in a day to remove a channel switch that was connected to printers. When I was finished, each printer was on a dedicated channel that could be reconfigured to any LPAR, and I did it without ever having more than one printer unavailable at a time. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
Omit CUADD. 2009/10/13 Jeffrey Deaver jeffrey.dea...@securian.com I have an IODF which has a mistake in it in regards to some new storage we've attached... CNTLUNIT CUNUMBR=5000,PATH=((CSS(0),B3,B2,82,83,40,41,D0,D1)),* UNITADD=((00,256)),CUADD=0,UNIT=2107 IODEVICE ADDRESS=(5000,228),CUNUMBR=(5000),STADET=Y,UNIT=3390B IODEVICE ADDRESS=(50E4,028),CUNUMBR=(5000),STADET=Y,UNIT=3390A The CUADD statements have the wrong value. They should be CUADD=50 etc instead of CUADD=0 etc. I altered the IODF and IPL'ed my test system, but the change has not taken. In other words, I still can't access the storage From an init job... ICK30713I UNABLE TO ALLOCATE UCB, RC=0008, RSN=0004 FROM IOSODS ICK31024I UNABLE TO OPEN VOLUME. ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12 12:26:0010/13/09 I can't vary the paths online... IEE386I PATH(5001,40) NOT BROUGHT ONLINE IEE763I NAME= IECVIOPM CODE= 0004 IOS552I PATH NOT PHYSICALLY AVAILABLE IEE764I END OF IEE386IRELATED MESSAGES Assuming I'm not missing some other configuration issue, I should be able to change the IODF, IPL that LPAR and have the change take effect, right? No POR necessary, right? What am I missing? Thanks. Jeffrey Deaver, Engineer Systems Engineering jeffrey.dea...@securian.com 651-665-4231(v) IS - Creating competitive advantage with technology. Providing service that excels. OSS - Where Innovation Happens -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
True, but it usually works for me. I do keep a running tab, if you will, of IODF work files. I usually keep at least 30 lying around just in case. I fortunately haven't run into a situation as you describe. There was one exception quite a while agao where I did not follow my usual practice - it was when I dynamically converted all of our substantial DASD farm from ESCON to FICON in stages - 8 ESCON to 2 FICON per CU - one IODF gen per set. On Wed, Oct 14, 2009 at 11:05 AM, Tom Marchant m42tom-ibmm...@yahoo.comwrote: On Wed, 14 Oct 2009 09:56:46 -0700, Guy Gardoit wrote: I like to coordinate the last two characters of the IODF data set with the IOCDS I intend to write it to. Example: Create production IODF00 and write it to IOCDS A0. Do you mean that you only use IODF00, IODF01, IODF02 and IODF03? That doesn't allow much flexibility. It isn't very hard to figure out which IODF matches an IOCDS. I always like to keep the IODF that was used for the last IPL. Sometimes it is necessary to perform an IODF update in stages. I once did about 8 in a day to remove a channel switch that was connected to printers. When I was finished, each printer was on a dedicated channel that could be reconfigured to any LPAR, and I did it without ever having more than one printer unavailable at a time. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Guy Gardoit z/OS Systems Programming -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
But it has a lot to do with any POR that may be necessitated for some other reason - Like MCLs, CPC failure etc. Better safe than sorry - besides I just like to be neat - a Monk complex, if you know who I mean. And, you're right, I did not mention IPLing with the correct IODF - I've found using LOAD** in IPLPARM works best. YMMV On Wed, Oct 14, 2009 at 10:30 AM, Scott Rowe scott.r...@joann.com wrote: Gary, Writing the IOCDS has nothing to do with out of sync conditions. The out of sync conditions are caused when the activation is not done to both hardware and software. They can also be caused by IPLing with the incorrect IODF, which can be easily solved by not hard coding the IODF number in the LOADxx member. Guy Gardoit ggard...@gmail.com 10/14/2009 12:56 PM I disagree completely. To avoid easily obtained out of sync conditions, this process should always be followed for *any* IODF changes: WAS 1. W After the new production IODF is created, use HCD to write it to one of the IOCDS in each machine. I like to coordinate the last two characters of the IODF data set with the IOCDS I intend to write it to. Example: Create production IODF00 and write it to IOCDS A0. 2. ... Activate the IODF in all systems using HCD - I try to avoid activate configuration sysplex wide. I'm not brave enough for that one. Just do one system at a time. 3. S From one LPAR on each machine, use HCD to switch to the new IOCDS - same (ok, almost) as doing a POR Following this process will always avoid any chance of hardware/software being out of sync. Sometimes laziness is a good qulaity in a systems programmer - but not with hardware/software configuration changes. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Guy Gardoit z/OS Systems Programming -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IODF Change...
I have an IODF which has a mistake in it in regards to some new storage we've attached... CNTLUNIT CUNUMBR=5000,PATH=((CSS(0),B3,B2,82,83,40,41,D0,D1)),* UNITADD=((00,256)),CUADD=0,UNIT=2107 IODEVICE ADDRESS=(5000,228),CUNUMBR=(5000),STADET=Y,UNIT=3390B IODEVICE ADDRESS=(50E4,028),CUNUMBR=(5000),STADET=Y,UNIT=3390A The CUADD statements have the wrong value. They should be CUADD=50 etc instead of CUADD=0 etc. I altered the IODF and IPL'ed my test system, but the change has not taken. In other words, I still can't access the storage From an init job... ICK30713I UNABLE TO ALLOCATE UCB, RC=0008, RSN=0004 FROM IOSODS ICK31024I UNABLE TO OPEN VOLUME. ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12 12:26:0010/13/09 I can't vary the paths online... IEE386I PATH(5001,40) NOT BROUGHT ONLINE IEE763I NAME= IECVIOPM CODE= 0004 IOS552I PATH NOT PHYSICALLY AVAILABLE IEE764I END OF IEE386IRELATED MESSAGES Assuming I'm not missing some other configuration issue, I should be able to change the IODF, IPL that LPAR and have the change take effect, right? No POR necessary, right? What am I missing? Thanks. Jeffrey Deaver, Engineer Systems Engineering jeffrey.dea...@securian.com 651-665-4231(v) IS - Creating competitive advantage with technology. Providing service that excels. OSS - Where Innovation Happens -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
There's the IODF and the IOCDS. Perhaps you've changed one but not the other. You should see an 'out of sync' message on the activate panel. Yes, all is doable dynamically these days. Even so, a deactivate and activate sequence for an LPAR is almost the same as a POR. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jeffrey Deaver Sent: Tuesday, October 13, 2009 3:00 PM To: IBM-MAIN@bama.ua.edu Subject: IODF Change... I have an IODF which has a mistake in it in regards to some new storage we've attached... CNTLUNIT CUNUMBR=5000,PATH=((CSS(0),B3,B2,82,83,40,41,D0,D1)),* UNITADD=((00,256)),CUADD=0,UNIT=2107 IODEVICE ADDRESS=(5000,228),CUNUMBR=(5000),STADET=Y,UNIT=3390B IODEVICE ADDRESS=(50E4,028),CUNUMBR=(5000),STADET=Y,UNIT=3390A The CUADD statements have the wrong value. They should be CUADD=50 etc instead of CUADD=0 etc. I altered the IODF and IPL'ed my test system, but the change has not taken. In other words, I still can't access the storage From an init job... ICK30713I UNABLE TO ALLOCATE UCB, RC=0008, RSN=0004 FROM IOSODS ICK31024I UNABLE TO OPEN VOLUME. ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12 12:26:0010/13/09 I can't vary the paths online... IEE386I PATH(5001,40) NOT BROUGHT ONLINE IEE763I NAME= IECVIOPM CODE= 0004 IOS552I PATH NOT PHYSICALLY AVAILABLE IEE764I END OF IEE386IRELATED MESSAGES Assuming I'm not missing some other configuration issue, I should be able to change the IODF, IPL that LPAR and have the change take effect, right? No POR necessary, right? What am I missing? Thanks. Jeffrey Deaver, Engineer Systems Engineering jeffrey.dea...@securian.com 651-665-4231(v) IS - Creating competitive advantage with technology. Providing service that excels. OSS - Where Innovation Happens -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
Hello, When you do the IPL, it is like a software only activate, so the CUADDR part must be a hardware change. You should be able to do a hardware and software activate to correct the situation. Pete Eggebeen Systems Programmer Specialist Enterprise Storage Management FIS Banking Solutions 414.577.9521 Office 414.577.8998 Fax e-mail: pete.eggeb...@metavante.com From: Jeffrey Deaver jeffrey.dea...@securian.com To: IBM-MAIN@bama.ua.edu Date: 10/13/2009 03:00 PM Subject:IODF Change... I have an IODF which has a mistake in it in regards to some new storage we've attached... CNTLUNIT CUNUMBR=5000,PATH=((CSS(0),B3,B2,82,83,40,41,D0,D1)),* UNITADD=((00,256)),CUADD=0,UNIT=2107 IODEVICE ADDRESS=(5000,228),CUNUMBR=(5000),STADET=Y,UNIT=3390B IODEVICE ADDRESS=(50E4,028),CUNUMBR=(5000),STADET=Y,UNIT=3390A The CUADD statements have the wrong value. They should be CUADD=50 etc instead of CUADD=0 etc. I altered the IODF and IPL'ed my test system, but the change has not taken. In other words, I still can't access the storage From an init job... ICK30713I UNABLE TO ALLOCATE UCB, RC=0008, RSN=0004 FROM IOSODS ICK31024I UNABLE TO OPEN VOLUME. ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12 12:26:0010/13/09 I can't vary the paths online... IEE386I PATH(5001,40) NOT BROUGHT ONLINE IEE763I NAME= IECVIOPM CODE= 0004 IOS552I PATH NOT PHYSICALLY AVAILABLE IEE764I END OF IEE386IRELATED MESSAGES Assuming I'm not missing some other configuration issue, I should be able to change the IODF, IPL that LPAR and have the change take effect, right? No POR necessary, right? What am I missing? Thanks. Jeffrey Deaver, Engineer Systems Engineering jeffrey.dea...@securian.com 651-665-4231(v) IS - Creating competitive advantage with technology. Providing service that excels. OSS - Where Innovation Happens -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. - - The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
Do a D IOS,CONFIG command. Are you really running on the modified IODF in the TEST LPAR? When I want a specific IODF I change LOADxx and specify the IODF suffix explicitly (normally run with **). Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jeffrey Deaver Sent: Tuesday, October 13, 2009 15:00 To: IBM-MAIN@bama.ua.edu Subject: IODF Change... I have an IODF which has a mistake in it in regards to some new storage we've attached... CNTLUNIT CUNUMBR=5000,PATH=((CSS(0),B3,B2,82,83,40,41,D0,D1)),* UNITADD=((00,256)),CUADD=0,UNIT=2107 IODEVICE ADDRESS=(5000,228),CUNUMBR=(5000),STADET=Y,UNIT=3390B IODEVICE ADDRESS=(50E4,028),CUNUMBR=(5000),STADET=Y,UNIT=3390A The CUADD statements have the wrong value. They should be CUADD=50 etc instead of CUADD=0 etc. I altered the IODF and IPL'ed my test system, but the change has not taken. In other words, I still can't access the storage From an init job... ICK30713I UNABLE TO ALLOCATE UCB, RC=0008, RSN=0004 FROM IOSODS ICK31024I UNABLE TO OPEN VOLUME. ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12 12:26:0010/13/09 I can't vary the paths online... IEE386I PATH(5001,40) NOT BROUGHT ONLINE IEE763I NAME= IECVIOPM CODE= 0004 IOS552I PATH NOT PHYSICALLY AVAILABLE IEE764I END OF IEE386IRELATED MESSAGES Assuming I'm not missing some other configuration issue, I should be able to change the IODF, IPL that LPAR and have the change take effect, right? No POR necessary, right? What am I missing? Thanks. Jeffrey Deaver, Engineer Systems Engineering jeffrey.dea...@securian.com 651-665-4231(v) IS - Creating competitive advantage with technology. Providing service that excels. OSS - Where Innovation Happens -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
When you IPL'd did you get the message that the hardware and software were out of sync. We just added storage to our machine and the process we used was 1. update the HCD 2. Build a new IODF file 3. Activate the IODF dynamically Activate both the hardware and software 4. Do a software only activation of the new IODF on all other lpars 5. Then use the SE or HMC to configure on the channels. This worked fine for us and we have done it multiple times. Hope this helps Brad Wissink Information Technology Services Iowa State University 515-294-3088 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jeffrey Deaver Sent: Tuesday, October 13, 2009 3:00 PM To: IBM-MAIN@bama.ua.edu Subject: IODF Change... I have an IODF which has a mistake in it in regards to some new storage we've attached... CNTLUNIT CUNUMBR=5000,PATH=((CSS(0),B3,B2,82,83,40,41,D0,D1)),* UNITADD=((00,256)),CUADD=0,UNIT=2107 IODEVICE ADDRESS=(5000,228),CUNUMBR=(5000),STADET=Y,UNIT=3390B IODEVICE ADDRESS=(50E4,028),CUNUMBR=(5000),STADET=Y,UNIT=3390A The CUADD statements have the wrong value. They should be CUADD=50 etc instead of CUADD=0 etc. I altered the IODF and IPL'ed my test system, but the change has not taken. In other words, I still can't access the storage From an init job... ICK30713I UNABLE TO ALLOCATE UCB, RC=0008, RSN=0004 FROM IOSODS ICK31024I UNABLE TO OPEN VOLUME. ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12 12:26:0010/13/09 I can't vary the paths online... IEE386I PATH(5001,40) NOT BROUGHT ONLINE IEE763I NAME= IECVIOPM CODE= 0004 IOS552I PATH NOT PHYSICALLY AVAILABLE IEE764I END OF IEE386IRELATED MESSAGES Assuming I'm not missing some other configuration issue, I should be able to change the IODF, IPL that LPAR and have the change take effect, right? No POR necessary, right? What am I missing? Thanks. Jeffrey Deaver, Engineer Systems Engineering jeffrey.dea...@securian.com 651-665-4231(v) IS - Creating competitive advantage with technology. Providing service that excels. OSS - Where Innovation Happens -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
I have an IODF which has a mistake in it in regards to some new storage we've attached... Assuming I'm not missing some other configuration issue, I should be able to change the IODF, IPL that LPAR and have the change take effect, right? No POR necessary, right? What am I missing? See, as soon as I send the question, I find what I need. This article seems to explain it quite well... http://www.zjournal.com/index.cfm?section=articleaid=375# ... and points out a few things I'm missing. Jeffrey Deaver, Engineer Systems Engineering jeffrey.dea...@securian.com 651-665-4231(v) IS - Creating competitive advantage with technology. Providing service that excels. OSS - Where Innovation Happens -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
Did you do the hardware activate? CUADD is a hardware parameter, which changes only with a POR or activate hardware changes from the HCD panels. - Original Message - From: Jeffrey Deaver jeffrey.dea...@securian.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, October 13, 2009 2:59:52 PM GMT -06:00 US/Canada Central Subject: IODF Change... I have an IODF which has a mistake in it in regards to some new storage we've attached... CNTLUNIT CUNUMBR=5000,PATH=((CSS(0),B3,B2,82,83,40,41,D0,D1)),* UNITADD=((00,256)),CUADD=0,UNIT=2107 IODEVICE ADDRESS=(5000,228),CUNUMBR=(5000),STADET=Y,UNIT=3390B IODEVICE ADDRESS=(50E4,028),CUNUMBR=(5000),STADET=Y,UNIT=3390A The CUADD statements have the wrong value. They should be CUADD=50 etc instead of CUADD=0 etc. I altered the IODF and IPL'ed my test system, but the change has not taken. In other words, I still can't access the storage From an init job... ICK30713I UNABLE TO ALLOCATE UCB, RC=0008, RSN=0004 FROM IOSODS ICK31024I UNABLE TO OPEN VOLUME. ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12 12:26:00 10/13/09 I can't vary the paths online... IEE386I PATH(5001,40) NOT BROUGHT ONLINE IEE763I NAME= IECVIOPM CODE= 0004 IOS552I PATH NOT PHYSICALLY AVAILABLE IEE764I END OF IEE386I RELATED MESSAGES Assuming I'm not missing some other configuration issue, I should be able to change the IODF, IPL that LPAR and have the change take effect, right? No POR necessary, right? What am I missing? Thanks. Jeffrey Deaver, Engineer Systems Engineering jeffrey.dea...@securian.com 651-665-4231(v) IS - Creating competitive advantage with technology. Providing service that excels. OSS - Where Innovation Happens -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
Did you do an ACTIVATE from the new IODF? Jeffrey Deaver jeffrey.dea...@securian.com 10/13/2009 3:59 PM I have an IODF which has a mistake in it in regards to some new storage we've attached... CNTLUNIT CUNUMBR=5000,PATH=((CSS(0),B3,B2,82,83,40,41,D0,D1)),* UNITADD=((00,256)),CUADD=0,UNIT=2107 IODEVICE ADDRESS=(5000,228),CUNUMBR=(5000),STADET=Y,UNIT=3390B IODEVICE ADDRESS=(50E4,028),CUNUMBR=(5000),STADET=Y,UNIT=3390A The CUADD statements have the wrong value. They should be CUADD=50 etc instead of CUADD=0 etc. I altered the IODF and IPL'ed my test system, but the change has not taken. In other words, I still can't access the storage From an init job... ICK30713I UNABLE TO ALLOCATE UCB, RC=0008, RSN=0004 FROM IOSODS ICK31024I UNABLE TO OPEN VOLUME. ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12 12:26:0010/13/09 I can't vary the paths online... IEE386I PATH(5001,40) NOT BROUGHT ONLINE IEE763I NAME= IECVIOPM CODE= 0004 IOS552I PATH NOT PHYSICALLY AVAILABLE IEE764I END OF IEE386IRELATED MESSAGES Assuming I'm not missing some other configuration issue, I should be able to change the IODF, IPL that LPAR and have the change take effect, right? No POR necessary, right? What am I missing? Thanks. Jeffrey Deaver, Engineer Systems Engineering jeffrey.dea...@securian.com 651-665-4231(v) IS - Creating competitive advantage with technology. Providing service that excels. OSS - Where Innovation Happens -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
There is no need to change an IOCDS, it is enough to ACTIVATE the IODF. Hal Merritt hmerr...@jackhenry.com 10/13/2009 4:17 PM There's the IODF and the IOCDS. Perhaps you've changed one but not the other. You should see an 'out of sync' message on the activate panel. Yes, all is doable dynamically these days. Even so, a deactivate and activate sequence for an LPAR is almost the same as a POR. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jeffrey Deaver Sent: Tuesday, October 13, 2009 3:00 PM To: IBM-MAIN@bama.ua.edu Subject: IODF Change... I have an IODF which has a mistake in it in regards to some new storage we've attached... CNTLUNIT CUNUMBR=5000,PATH=((CSS(0),B3,B2,82,83,40,41,D0,D1)),* UNITADD=((00,256)),CUADD=0,UNIT=2107 IODEVICE ADDRESS=(5000,228),CUNUMBR=(5000),STADET=Y,UNIT=3390B IODEVICE ADDRESS=(50E4,028),CUNUMBR=(5000),STADET=Y,UNIT=3390A The CUADD statements have the wrong value. They should be CUADD=50 etc instead of CUADD=0 etc. I altered the IODF and IPL'ed my test system, but the change has not taken. In other words, I still can't access the storage From an init job... ICK30713I UNABLE TO ALLOCATE UCB, RC=0008, RSN=0004 FROM IOSODS ICK31024I UNABLE TO OPEN VOLUME. ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12 12:26:0010/13/09 I can't vary the paths online... IEE386I PATH(5001,40) NOT BROUGHT ONLINE IEE763I NAME= IECVIOPM CODE= 0004 IOS552I PATH NOT PHYSICALLY AVAILABLE IEE764I END OF IEE386IRELATED MESSAGES Assuming I'm not missing some other configuration issue, I should be able to change the IODF, IPL that LPAR and have the change take effect, right? No POR necessary, right? What am I missing? Thanks. Jeffrey Deaver, Engineer Systems Engineering jeffrey.dea...@securian.com 651-665-4231(v) IS - Creating competitive advantage with technology. Providing service that excels. OSS - Where Innovation Happens -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
Don't you need to update the IOCDS also (and I guess a POR to activate it)? Is the controller correctly configured to respond as address 50? Are the CHPIDs correct (and not the PCHID number)? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jeffrey Deaver Sent: Tuesday, October 13, 2009 1:00 PM To: IBM-MAIN@bama.ua.edu Subject: IODF Change... I have an IODF which has a mistake in it in regards to some new storage we've attached... CNTLUNIT CUNUMBR=5000,PATH=((CSS(0),B3,B2,82,83,40,41,D0,D1)),* UNITADD=((00,256)),CUADD=0,UNIT=2107 IODEVICE ADDRESS=(5000,228),CUNUMBR=(5000),STADET=Y,UNIT=3390B IODEVICE ADDRESS=(50E4,028),CUNUMBR=(5000),STADET=Y,UNIT=3390A The CUADD statements have the wrong value. They should be CUADD=50 etc instead of CUADD=0 etc. I altered the IODF and IPL'ed my test system, but the change has not taken. In other words, I still can't access the storage From an init job... ICK30713I UNABLE TO ALLOCATE UCB, RC=0008, RSN=0004 FROM IOSODS ICK31024I UNABLE TO OPEN VOLUME. ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12 12:26:0010/13/09 I can't vary the paths online... IEE386I PATH(5001,40) NOT BROUGHT ONLINE IEE763I NAME= IECVIOPM CODE= 0004 IOS552I PATH NOT PHYSICALLY AVAILABLE IEE764I END OF IEE386IRELATED MESSAGES Assuming I'm not missing some other configuration issue, I should be able to change the IODF, IPL that LPAR and have the change take effect, right? No POR necessary, right? What am I missing? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF Change...
Jeffrey, There are errors in that article, though you could say I'm being pedantic, I think they are important: You do not create an IOCDS and then create an IODF, you create an IODF and then potentially create an IOCDS from it, the process as written in the article makes no sense. The IOCDS serves no purpose other than to be loaded at POR. There is no need to create an IOCDS before one ACTIVATEs an IODF. Many (including myself) prefer to ACTIVATE an IODF (in hardware and software) to test that it works properly before writing to the IOCDS. P.S. I hope this email gets to the listserver sometime today, I can't believe how long some of my emails take to get forwarded, the last one was over 15 minutes. I suspect the problem is on this end, our email servers seem to run pretty slow ;-) Jeffrey Deaver jeffrey.dea...@securian.com 10/13/2009 4:27 PM I have an IODF which has a mistake in it in regards to some new storage we've attached... Assuming I'm not missing some other configuration issue, I should be able to change the IODF, IPL that LPAR and have the change take effect, right? No POR necessary, right? What am I missing? See, as soon as I send the question, I find what I need. This article seems to explain it quite well... http://www.zjournal.com/index.cfm?section=articleaid=375# ... and points out a few things I'm missing. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
Hello list, I had the following question in July of this year. I just want add to the archive the resolution of this problem. Snip from July 2008 Our system is a 2096 U03 with three LPARs but no sysplex. Two LPARs are production, one at z/OS 1.4 and a small one at z/OS 1.7. The current IODF is a version 5 level. This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. end of snip The problem was I had two control unit # 2 on the same path because I did not requested EMC to verify my IODF. HCD did not object because it had to do with the DMX1000 internal mapping of CHIPIDs. This obviously caused the DMX1000 to do some sort of diagnostics. My IODF error was partially due to the fact that our maintenance contract had expired with EMC and we had not completed negotiations with a third party to support the DMX1000. Regards, Listen. Think. Solve. Steve Wolf Rockwell Automation 414-382-4308 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
On Mon, 21 Jul 2008 07:06:23 +0200, Barbara Nitz [EMAIL PROTECTED] wrote: *Obviously* you don't work here :-) Here I am fast with system dump cleanup to keep the DASD pool empty. If anyone wants a dump longer than it takes me to take a look at it, they should rename it to a 'keep' qualifier. I was really hard pressed when IBM asked me a while back to find a dump from before a huge IODF change for comparison. Why not migrate them directly to ML2 with HSM? That is what we do. They are only on DASD for a short time. I'm not sure how long we keep them on ML2 without checking, but it is probably between 2 and 4 weeks (this was all set up about 10 years ago when I implemented dynamic SVC dumps while consulting here). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
.. I just can't resist... The data collection for IPLDATA STATUS was just a little thing I hacked together in OS/390 1.3 to help me find a starting point of where to look when I got asked to help diagnose why did that IPL take so long? problems. Another Jim-Mulder-Special :-) It seems to me that the only new stuff going into IPCS is stuff Jim wrote at one point or another. Everything else IBM appears to keep as in-house tool because if made public, then it must be supported, and customers don't look at dumps, anyway. Right? From an internal code point of view, IPL ends when NIP starts. This always reminds me of my first meeting with Ken Trowell: He was soundly thrashing anyone who called the whole thing IPL and said that IPL is an architected instruction, which isn't very long. At that time, I had about 18 months of MVS experience and still no clue what he was talking about :-( To this day I confuse my colleagues when I say 'IPL is done' or 'NIP is done' by looking at the nip console output. Shane, Else go find a convenient dump - I would usually be hard pressed to *not* find a system dump from IPL to IPL. *Obviously* you don't work here :-) Here I am fast with system dump cleanup to keep the DASD pool empty. If anyone wants a dump longer than it takes me to take a look at it, they should rename it to a 'keep' qualifier. I was really hard pressed when IBM asked me a while back to find a dump from before a huge IODF change for comparison. Regards, Barbara -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
Here's one customer's perspective of 'IPL stages'. It's what I see without knowing anything significant about the underlying code. 0. Click 'go for it' on the LOAD ACTIVATE confirmation box. 1. Get back 'OK' from LOAD ACTIVATE . 2. Get the first output line on a console that can display NIP messages for the system being IPLed. Might be HMC; might be channel attached 3270; whatever. 3. Get the first output line on a shared console in the same sysplex if any. 4. Get message 'IEE389I MVS COMMAND PROCESSING AVAILABLE' . 5. Logon to a VTAM SMCS session from a 'remote' location, which might be located right next to the HMC or around the world. If anything goes wrong along the way, our options depend on which milestone we've reached so far. For example, if #1 fails, we start asking around about IOS changes people might have made that they forgot to mention. If #5 fails, we head straight for the network guy. Experience leads us in one direction or another depending on where we fail and what symptoms if any there are to consider. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Jim Mulder [EMAIL PROTECTED] OMTo Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: IODF change causes next IPL to hang 07/17/2008 10:45 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/17/2008 09:00:16 AM: A colleague asks, When are the 'official' start and end times (events) that comprise 'IPL'? From the IPLDATA STATUS output it appears that 'official start' occurs after the IPLTEXT has been loaded and control transferred to it, and 'official end' occurs when *MASTER* has completed initialization. Is that pretty close? The data collection for IPLDATA STATUS was just a little thing I hacked together in OS/390 1.3 to help me find a starting point of where to look when I got asked to help diagnose why did that IPL take so long? problems. It presents things in four phases IPL-NIP-IEEVIPL-IEEMB860 because that happens to be how the system initialization code is structured. But I was not trying to create any 'official' terminolgy. From an internal code point of view, IPL ends when NIP starts. From a customer point of view, IPL more likely is considered to have ended when the system is ready to run applications - after the network is up, the database is up, and the applications are up. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
On Fri, 18 Jul 2008 01:45:58 -0400, Jim Mulder [EMAIL PROTECTED] wrote: ... The data collection for IPLDATA STATUS was just a little thing I hacked together in OS/390 1.3 to help me find a starting point of where to look when I got asked to help diagnose why did that IPL take so long? problems. This is not the first time, and I'm sure won't be the last time that a little thing ... hacked together by a tester has proved to be a life saver. None of our MVS system programmers knew about this command. We don't know when our intermittant IPL problem will strike again, but you can bet this command will be issued afterwrds. ... It presents things in four phases IPL-NIP-IEEVIPL-IEEMB860 because that happens to be how the system initialization code is structured. But I was not trying to create any 'official' terminolgy. ... Too late. You labled them - it's officail now. :-) Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
On Fri, 2008-07-18 at 15:01 -0500, Patrick O'Keefe wrote: None of our MVS system programmers knew about this command. We don't know when our intermittant IPL problem will strike again, but you can bet this command will be issued afterwrds. There are lots of things to see in a dump - I used to keep an eye on the Jerry Ng presentations at Share for anything new (to me). If the system that had the problem is still up, just use IPCS on 'active' and run the IPLDATA anytime before the next IPL. Else go find a convenient dump - I would usually be hard pressed to *not* find a system dump from IPL to IPL. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Jim Mulder IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/16/2008 04:35:28 PM: Pat, in your situation try running the IPCS VERBEXIT BLSAIPST. The documented way of invoking that function is IPLDATA STATUS Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY A colleague asks, When are the 'official' start and end times (events) that comprise 'IPL'? From the IPLDATA STATUS output it appears that 'official start' occurs after the IPLTEXT has been loaded and control transferred to it, and 'official end' occurs when *MASTER* has completed initialization. Is that pretty close? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/17/2008 09:00:16 AM: A colleague asks, When are the 'official' start and end times (events) that comprise 'IPL'? From the IPLDATA STATUS output it appears that 'official start' occurs after the IPLTEXT has been loaded and control transferred to it, and 'official end' occurs when *MASTER* has completed initialization. Is that pretty close? The data collection for IPLDATA STATUS was just a little thing I hacked together in OS/390 1.3 to help me find a starting point of where to look when I got asked to help diagnose why did that IPL take so long? problems. It presents things in four phases IPL-NIP-IEEVIPL-IEEMB860 because that happens to be how the system initialization code is structured. But I was not trying to create any 'official' terminolgy. From an internal code point of view, IPL ends when NIP starts. From a customer point of view, IPL more likely is considered to have ended when the system is ready to run applications - after the network is up, the database is up, and the applications are up. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IODF change causes next IPL to hang
Hello List, Are system is a 2096 U03 with three LPARs but no sysplex. Two LPARs are production, one at z/OS 1.4 and a small one at z/OS 1.7. The current IODF is a version 5 level. This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. The 1.7 system complained about the new UCBs when I did the activate but it kept running. We have done a IODF change before but at that time only the 1.4 LPAR was active. DO I need to do a software IODF change on the 1.7 LPAR before I do the IODF on the 1.4 system. Regards, Steve Wolf Rockwell Automation 414-382-4308 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
On Wed, 16 Jul 2008 14:33:44 -0500, Stephen Wolf [EMAIL PROTECTED] wrote: ... This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. ... How long did you wait? Do you know it was not going to wake up? We have had some very long hangs in NIP lately, but it eventually would wake up. It felt like an eternity but I suspect it was 5-10 minutes of no obvious activity. Then the IPL process would take off and act like nothing had happened. No problems were noted afterwords. I don't think they were associated with IODF changes, did not effect all members of the PLex, and did not effect all LPARs on a single processor. In other words, we were never able to associate the hang with anything. We are on 1.8 and have both basic and parallel Sysplexes so our environments are quite different from yours (but I don't know how being part of a Sysplex could matter so early in the IPL.) Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
On Wed, 16 Jul 2008 14:33:44 -0500, Stephen Wolf [EMAIL PROTECTED] wrote: Hello List, Are system is a 2096 U03 with three LPARs but no sysplex. Two LPARs are production, one at z/OS 1.4 and a small one at z/OS 1.7. The current IODF is a version 5 level. This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. The 1.7 system complained about the new UCBs when I did the activate but it kept running. We have done a IODF change before but at that time only the 1.4 LPAR was active. DO I need to do a software IODF change on the 1.7 LPAR before I do the IODF on the 1.4 system. Do you have the compatibility PTF on z/OS 1.4 that will allow you to use the version 5 level IODF? The required maintenance is documented in the z/OS 1.7 Planning for Migration manual. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
Pat, in your situation try running the IPCS VERBEXIT BLSAIPST. It shows the various phases of NIP and the timing. Maybe you can pinpoint where the delay has occurred. I've seen long delays when there are problems when the DASD goes into some sort of error recovery and retries each device for minutes before abandoning it and going to the next one. Alan ... This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. ... How long did you wait? Do you know it was not going to wake up? We have had some very long hangs in NIP lately, but it eventually would wake up. It felt like an eternity but I suspect it was 5-10 minutes of no obvious activity. Then the IPL process would take off and act like nothing had happened. No problems were noted afterwords. I don't think they were associated with IODF changes, did not effect all members of the PLex, and did not effect all LPARs on a single processor. In other words, we were never able to associate the hang with anything. We are on 1.8 and have both basic and parallel Sysplexes so our environments are quite different from yours (but I don't know how being part of a Sysplex could matter so early in the IPL.) Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
It's been a while since I've seen it because our current IODF maestro is on top of it, but our most common cause in the past of a long pause during NIP is failure to find an IODF that matches the hardware/HSA version. IOS (or whoever does the search) has a complicated and s-l-o-w procedure to search for an appropriate MVS linear cluster. If this is the problem, NIP will eventually settle on a usable IODF or it will wait state. It may take a while to reach either conclusion. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Stephen Wolf [EMAIL PROTECTED] LL.COMTo Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU IODF change causes next IPL to hang 07/16/2008 12:33 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU Hello List, Are system is a 2096 U03 with three LPARs but no sysplex. Two LPARs are production, one at z/OS 1.4 and a small one at z/OS 1.7. The current IODF is a version 5 level. This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. The 1.7 system complained about the new UCBs when I did the activate but it kept running. We have done a IODF change before but at that time only the 1.4 LPAR was active. DO I need to do a software IODF change on the 1.7 LPAR before I do the IODF on the 1.4 system. Regards, Steve Wolf -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/16/2008 04:35:28 PM: Pat, in your situation try running the IPCS VERBEXIT BLSAIPST. It shows the various phases of NIP and the timing. Maybe you can pinpoint where the delay has occurred. The documented way of invoking that function is IPLDATA STATUS Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
I've heard about a couple of things that can really slow an IPL down. One is an ESCON channel connected to nothing or a inop device. NIP (or somebody) will wait a very long time to see if it will come active. If there has been hardware microcode updates, the chp does not actually load the new microcode until a live LPAR tries to touch it. That can take a very long time. Worse if the chp is not connected to a live device. Try identifying dead or chp's and deactivate via the SE. Also expect long delays the first time a chp is used, even to an existing device. That scar is still fresh :-) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Wolf Sent: Wednesday, July 16, 2008 2:34 PM To: IBM-MAIN@BAMA.UA.EDU Subject: IODF change causes next IPL to hang Hello List, Are system is a 2096 U03 with three LPARs but no sysplex. Two LPARs are production, one at z/OS 1.4 and a small one at z/OS 1.7. The current IODF is a version 5 level. This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. The 1.7 system complained about the new UCBs when I did the activate but it kept running. We have done a IODF change before but at that time only the 1.4 LPAR was active. DO I need to do a software IODF change on the 1.7 LPAR before I do the IODF on the 1.4 system. Regards, Steve Wolf Rockwell Automation 414-382-4308 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
On Wed, 16 Jul 2008 15:24:56 -0500, Mark Zelden [EMAIL PROTECTED] wrote: On Wed, 16 Jul 2008 14:33:44 -0500, Stephen Wolf [EMAIL PROTECTED] wrote: Hello List, Are system is a 2096 U03 with three LPARs but no sysplex. Two LPARs are production, one at z/OS 1.4 and a small one at z/OS 1.7. The current IODF is a version 5 level. This weekend I activated a new IODF on the 1.4 system using the HCD dialogs which completed successfully. I did not do an activate on the 1.7 We then IPLed the 1.4 system and it just waited. The NIP console was not activated and there was not a hard wait. I brought up my rescue system and changed the IODF back to the old one and the 1.4 system IPLed ok. The 1.7 system complained about the new UCBs when I did the activate but it kept running. We have done a IODF change before but at that time only the 1.4 LPAR was active. DO I need to do a software IODF change on the 1.7 LPAR before I do the IODF on the 1.4 system. Do you have the compatibility PTF on z/OS 1.4 that will allow you to use the version 5 level IODF? The required maintenance is documented in the z/OS 1.7 Planning for Migration manual. Mark I just re-read what you wrote. Disregard what I wrote since you already had activated the V5 IODF on your 1.4 system. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to hang
This is a very cool technique for debugging mysterious IPL slowdowns. You don't even need a dump - if you run this IPCS command on a running system, the IPLDATA STATUS command will tell you how long each module in the IPL process took to perform its function when that system was IPLed - even days later. Brian On Wed, 16 Jul 2008 16:54:29 -0400, Jim Mulder wrote: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/16/2008 04:35:28 PM: Pat, in your situation try running the IPCS VERBEXIT BLSAIPST. It shows the various phases of NIP and the timing. Maybe you can pinpoint where the delay has occurred. The documented way of invoking that function is IPLDATA STATUS Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
