Re: Early IPL problems
In 4fbe7bb5.3060...@valley.net, on 05/24/2012 at 02:19 PM, Gerhard Postpischil gerh...@valley.net said: You used the PASSWORD facility to protect critical data sets. In order to update them, it was necessary to respond to a WTOR with the password. Don't forget my local mods to OPEN, which checked CVTUSER and bypassed the WTOR if authorized. That was inconvenient enough so that I wrote SETPASS [2]. As I recall, you wrote it after my OPEN mods were in place. The ABEND table was fun eg. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
In 4fbadd3e.5050...@valley.net, on 05/21/2012 at 08:26 PM, Gerhard Postpischil gerh...@valley.net said: You also used this to reply to password requests for system data sets having all hex-zero passwords. I don't recall[1] having done so. If you can explain How I forgot, I'd like to try the same technique on some other, equally undesirable, memories. [1] But I believe it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
On 5/23/2012 10:17 AM, Shmuel Metz (Seymour J.) wrote: You also used this to reply to password requests for system data sets having all hex-zero passwords. I don't recall[1] having done so. If you can explain How I forgot, I'd like to try the same technique on some other, equally undesirable, memories. You used the PASSWORD facility to protect critical data sets. In order to update them, it was necessary to respond to a WTOR with the password. The password was all hex zeroes, and could not be entered from a conventional console. You switched to the 00C/00E alternate console, and feed in a Reply nn card with the hex zeroes multi-punched [1]. That was inconvenient enough so that I wrote SETPASS [2]. [1] These days the method may be less safe, with some tn3270 clients offering keyboard customization including hex values. [2] That was a great learning experience. I had hard-coded the number of block per track in the PASSWORD data set, and at some point (OS/360 15/16, or 18?), IBM decided to change the device related constants and the PASSWORD data set wound up with one block less per track. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
John, Boy that's a blast from the past, I worked man moons ago a s/370-158..3215 m worked another place on 4381s using a 3287 as a CICS log Scott ford www.identityforge.com On May 20, 2012, at 1:07 PM, McKown, John john.mck...@healthmarkets.com wrote: I agree totally. Personally, I really __liked__ the 3215 keyboard/printer on the s/370 145 that I started on. I wonder if it would be possible to use an OSA-ICC to have a 3284 definition which would be connected to by a Linux box running pr3287 and then generate that as a 3287 non-SNA printer for hardcopy during IPL. I vaguely remember having a 1403 as a console for NIP messages long ago. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of R.S. Sent: Saturday, May 19, 2012 3:01 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems I prefer to have system solution, which would allow me to view/manage TEXT FILE. It's far more convenient than using video camera. And in fact I miss the facility. BTW: I haven't investigated it: I have some 3270 emulator which allow to view few previous screens - sometimes usable for ISPF activities. However this facility does not work for NIP text stream. -- Radoslaw Skorupka Lodz, Poland W dniu 2012-05-18 21:11, McKown, John pisze: I use the HMC and the Operating System Messages ICON. I don't have any NIPCONS, so I IPL and monitor from the HMC until I can get an SMCS console going. If you do have a 3270 type console, why not record the console on your cell phone camera? It is a bit small. So, get a tablet. Might take two people. One to do the IPL, the other to keep the console in focus. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Friday, May 18, 2012 1:52 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems On 5/18/2012 11:22 AM, Mark Zelden wrote: No, the complaint is that on emulated consoles attached via Tn3270 (2074, OSA-ICC and I assume Visira which I've never worked with) any messages that come out on the console along with the wait disappear immediately due to the RESET that happens along with the wait. Sounds like z/OS sysprogs need to ask their employers to pay for Evelyn Wood speed-reading classes. ;-) Seriously, I remember OS/2 had a similar issue. Before you could write down the information about a catastrophic trap, it would restart and blow away the screen. There was a special CONFIG.SYS parameter you had to code to prevent it from automatically restarting itself. Oh what fun... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN . -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste
Re: Early IPL problems
On Fri, 18 May 2012 01:43:56 -0400, Jim Mulder wrote: When the 2074 control unit came along, it responded to the reset by clearing the screens of its terminals/consoles and displaying some kind of link message. This makes me wonder, why does the 2074 clear the screens? Can that behavior be fixed? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
In a6b9336cdb62bb46b9f8708e686a7ea00e924b4...@nrhmms8p02.uicnrh.dom, on 05/20/2012 at 12:07 PM, McKown, John john.mck...@healthmarkets.com said: I vaguely remember having a 1403 as a console for NIP messages long ago. While it was popssible to use a card reader and printer as a console, and to use a printer as a hardcopy console, that was not something that I did except under duress, e.g., for diagnosing JES2 parameter errors. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
On 5/21/2012 8:13 AM, Shmuel Metz (Seymour J.) wrote: While it was popssible to use a card reader and printer as a console, and to use a printer as a hardcopy console, that was not something that I did except under duress, e.g., for diagnosing JES2 parameter errors. You also used this to reply to password requests for system data sets having all hex-zero passwords. If that was duress, it was self-inflicted G Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
I agree totally. Personally, I really __liked__ the 3215 keyboard/printer on the s/370 145 that I started on. I wonder if it would be possible to use an OSA-ICC to have a 3284 definition which would be connected to by a Linux box running pr3287 and then generate that as a 3287 non-SNA printer for hardcopy during IPL. I vaguely remember having a 1403 as a console for NIP messages long ago. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of R.S. Sent: Saturday, May 19, 2012 3:01 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems I prefer to have system solution, which would allow me to view/manage TEXT FILE. It's far more convenient than using video camera. And in fact I miss the facility. BTW: I haven't investigated it: I have some 3270 emulator which allow to view few previous screens - sometimes usable for ISPF activities. However this facility does not work for NIP text stream. -- Radoslaw Skorupka Lodz, Poland W dniu 2012-05-18 21:11, McKown, John pisze: I use the HMC and the Operating System Messages ICON. I don't have any NIPCONS, so I IPL and monitor from the HMC until I can get an SMCS console going. If you do have a 3270 type console, why not record the console on your cell phone camera? It is a bit small. So, get a tablet. Might take two people. One to do the IPL, the other to keep the console in focus. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Friday, May 18, 2012 1:52 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems On 5/18/2012 11:22 AM, Mark Zelden wrote: No, the complaint is that on emulated consoles attached via Tn3270 (2074, OSA-ICC and I assume Visira which I've never worked with) any messages that come out on the console along with the wait disappear immediately due to the RESET that happens along with the wait. Sounds like z/OS sysprogs need to ask their employers to pay for Evelyn Wood speed-reading classes. ;-) Seriously, I remember OS/2 had a similar issue. Before you could write down the information about a catastrophic trap, it would restart and blow away the screen. There was a special CONFIG.SYS parameter you had to code to prevent it from automatically restarting itself. Oh what fun... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN . -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe
Re: Early IPL problems
I prefer to have system solution, which would allow me to view/manage TEXT FILE. It's far more convenient than using video camera. And in fact I miss the facility. BTW: I haven't investigated it: I have some 3270 emulator which allow to view few previous screens - sometimes usable for ISPF activities. However this facility does not work for NIP text stream. -- Radoslaw Skorupka Lodz, Poland W dniu 2012-05-18 21:11, McKown, John pisze: I use the HMC and the Operating System Messages ICON. I don't have any NIPCONS, so I IPL and monitor from the HMC until I can get an SMCS console going. If you do have a 3270 type console, why not record the console on your cell phone camera? It is a bit small. So, get a tablet. Might take two people. One to do the IPL, the other to keep the console in focus. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Friday, May 18, 2012 1:52 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems On 5/18/2012 11:22 AM, Mark Zelden wrote: No, the complaint is that on emulated consoles attached via Tn3270 (2074, OSA-ICC and I assume Visira which I've never worked with) any messages that come out on the console along with the wait disappear immediately due to the RESET that happens along with the wait. Sounds like z/OS sysprogs need to ask their employers to pay for Evelyn Wood speed-reading classes. ;-) Seriously, I remember OS/2 had a similar issue. Before you could write down the information about a catastrophic trap, it would restart and blow away the screen. There was a special CONFIG.SYS parameter you had to code to prevent it from automatically restarting itself. Oh what fun... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN . -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists
Re: Early IPL problems
In D39079588512418AAAFA4139AA527226@MAINWS, on 05/18/2012 at 12:54 PM, Doug Fuerst d...@bkassociates.net said: Are we saying that we cannot look at the current PSW, get the WSC, and look it up? No, she's saying that she can't get to the associated messages. I've been looking at WSC's since System 360 days. Those are not the issue. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
In 4fb69a54.7050...@phoenixsoftware.com, on 05/18/2012 at 11:52 AM, Edward Jaffe edja...@phoenixsoftware.com said: Seriously, I remember OS/2 had a similar issue. Before you could write down the information about a catastrophic trap, it would restart and blow away the screen. There was a special CONFIG.SYS parameter you had to code to prevent it from automatically restarting itself. Oh what fun... Other way around: you have to add REIPL=ON if you want an automatic reboot. I suspect that you had an installation standard to always add it as part of installing OS/2. Note that you could use TRAPDUMP to get a dump prior to the reboot. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
For the cases where z/OS is loading a disabled wait state, and one of these consoles is the SYNCHDEST console or the NIP console, this behavior is unfortunate (to say it politely. When it happens to me, I say it using more colorful language). But there isn't anything z/OS can do about this. We really do want the system reset done to release the DASD reserves. I figured that you would know the actual technical background for losing the data on the console screen. The problem is that many in IBM development and service/support do not appear to know this and judge from their own testing under VM. And the customer more or less gets ridiculed as being unable to read. For this reason (among others), I recommend using the System Console (aka Operating System Messages on the HMC) as the SYNCHDEST and NIP console. I'd love to. Unfortunately there's no way my colleague will be allowed to generate the HMC as NIP console. This installation is firmly in the era of 'each system it's own green screen' (and it's own NIP console) and is unlikely to change. And the HMC *is* set as synchdest console (I had seen to that). Doesn't help when the wait state message doesn't explain why the wait state was loaded. *That* message was a 'normal' message earlier that went to the green screen (which got released). Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
Are we saying that we cannot look at the current PSW, get the WSC, and look it up? I've been looking at WSC's since System 360 days. Never found it too difficult. Doug -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Friday, May 18, 2012 3:02 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems For the cases where z/OS is loading a disabled wait state, and one of these consoles is the SYNCHDEST console or the NIP console, this behavior is unfortunate (to say it politely. When it happens to me, I say it using more colorful language). But there isn't anything z/OS can do about this. We really do want the system reset done to release the DASD reserves. I figured that you would know the actual technical background for losing the data on the console screen. The problem is that many in IBM development and service/support do not appear to know this and judge from their own testing under VM. And the customer more or less gets ridiculed as being unable to read. For this reason (among others), I recommend using the System Console (aka Operating System Messages on the HMC) as the SYNCHDEST and NIP console. I'd love to. Unfortunately there's no way my colleague will be allowed to generate the HMC as NIP console. This installation is firmly in the era of 'each system it's own green screen' (and it's own NIP console) and is unlikely to change. And the HMC *is* set as synchdest console (I had seen to that). Doesn't help when the wait state message doesn't explain why the wait state was loaded. *That* message was a 'normal' message earlier that went to the green screen (which got released). Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
On Fri, 18 May 2012 12:54:28 -0400, Doug Fuerst d...@bkassociates.net wrote: Are we saying that we cannot look at the current PSW, get the WSC, and look it up? I've been looking at WSC's since System 360 days. Never found it too difficult. No, the complaint is that on emulated consoles attached via Tn3270 (2074, OSA-ICC and I assume Visira which I've never worked with) any messages that come out on the console along with the wait disappear immediately due to the RESET that happens along with the wait. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
On 5/18/2012 11:22 AM, Mark Zelden wrote: No, the complaint is that on emulated consoles attached via Tn3270 (2074, OSA-ICC and I assume Visira which I've never worked with) any messages that come out on the console along with the wait disappear immediately due to the RESET that happens along with the wait. Sounds like z/OS sysprogs need to ask their employers to pay for Evelyn Wood speed-reading classes. ;-) Seriously, I remember OS/2 had a similar issue. Before you could write down the information about a catastrophic trap, it would restart and blow away the screen. There was a special CONFIG.SYS parameter you had to code to prevent it from automatically restarting itself. Oh what fun... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
I use the HMC and the Operating System Messages ICON. I don't have any NIPCONS, so I IPL and monitor from the HMC until I can get an SMCS console going. If you do have a 3270 type console, why not record the console on your cell phone camera? It is a bit small. So, get a tablet. Might take two people. One to do the IPL, the other to keep the console in focus. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Friday, May 18, 2012 1:52 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems On 5/18/2012 11:22 AM, Mark Zelden wrote: No, the complaint is that on emulated consoles attached via Tn3270 (2074, OSA-ICC and I assume Visira which I've never worked with) any messages that come out on the console along with the wait disappear immediately due to the RESET that happens along with the wait. Sounds like z/OS sysprogs need to ask their employers to pay for Evelyn Wood speed-reading classes. ;-) Seriously, I remember OS/2 had a similar issue. Before you could write down the information about a catastrophic trap, it would restart and blow away the screen. There was a special CONFIG.SYS parameter you had to code to prevent it from automatically restarting itself. Oh what fun... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
On Fri, 18 May 2012 14:11:14 -0500, McKown, John john.mck...@healthmarkets.com wrote: If you do have a 3270 type console, why not record the console on your cell phone camera? It is a bit small. So, get a tablet. Might take two people. One to do the IPL, the other to keep the console in focus. I've used the Shift and Print Screen keys a few times in the past... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
On 18 May 2012 15:11, McKown, John john.mck...@healthmarkets.com wrote: I use the HMC and the Operating System Messages ICON. I don't have any NIPCONS, so I IPL and monitor from the HMC until I can get an SMCS console going. If you do have a 3270 type console, why not record the console on your cell phone camera? It is a bit small. So, get a tablet. Might take two people. One to do the IPL, the other to keep the console in focus. I did just that last year with a Windows BSOD that was followed so quickly by an automagic reboot that the error code couldn't be read. I didn't try to click a still picture - just videoed the 30 seconds or so that mattered, then scrolled through it slowly. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
My colleagues were unable to determine *what* caused the wait state, for the simple reason that the accompanying message wasn't visible anymore. In this, I also blame IBM who apparently do all their testing under VM (where the NIP messages stay on the console) and have no clue about the real world that actually uses 'real' consoles NOT under VM for a NIP console. A 'real' console is these days attached somehow to an IP network. The second the wait state hits, that console is released to the network. Which means that the 'IP network' puts its welcome message back onto that console, effectively wiping out any messages that might have been visible there. And believe me, that is so fast that you have no chance of seeing any preceding message, much less comprehend it. IBM should really test their systems on real consoles (not VM, and not on the HMC, either), because IBM doesn't even understand how hard it is to see NIP messages preceding a problem. In addition, *EVERY* NIP message explaining a wait state should be *in the wait state message*, not some preceding 'for your info' thing. Especially when the component loading the wait state wasn't the culprit. While most unit testing and component testing is done under VM, plenty of testing (System Test, Integration Test, Performance Test, Consolidated Service Test, Engineering System Test, to name a few) is done not under VM, using real consoles.We are certainly well aware of the issue you are describing. In the old days, MVS loaded a disabled wait state by simply loading the wait state PSW on all CPs. Any DASD reserves held at the time the wait state was loaded continued to be held, blocking any sharing systems from accessing the reserved devices, until the operator did something to initiate a system reset. This problem was exacerbated by the increased use of shared DASD when Sysplex came along. So, about 20 years ago, APAR OY36587 implemented a different method for loading a disabled wait state. Instead of doing a LPSW in the last CP, we issue a DIAGNOSE instruction, passing the desired wait state PSW as a parameter. The machine initiates a system reset to cause the reserves to be released, and loads the wait state PSW. The system reset drives a reset to each channel path (which is what causes a DASD control unit to release the reserves). The terminal/console control units of that era (3174) did not change the current display of its terminals in response to the reset. When the 2074 control unit came along, it responded to the reset by clearing the screens of its terminals/consoles and displaying some kind of link message. For the cases where z/OS is loading a disabled wait state, and one of these consoles is the SYNCHDEST console or the NIP console, this behavior is unfortunate (to say it politely. When it happens to me, I say it using more colorful language). But there isn't anything z/OS can do about this. We really do want the system reset done to release the DASD reserves. For this reason (among others), I recommend using the System Console (aka Operating System Messages on the HMC) as the SYNCHDEST and NIP console. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
I second these options. Not having to go find the wait states book, but having a help link on the HMC would be nice. We also keep a copy of ZZSA around, but have not had to use it (Murphy's Law maybe?). I also agree about the real console problem. If there was a way to have every message generated from the start of the IPL to the failure go to the operating systems messages on the HMC, or some other place it would be great. And I do appreciate you asking about this. Having worked closely with IBM development years ago during the IMS Datasharing days, I understand that even IBM does not have one person who understands the entire process soup to nuts. Everyone complains that IBM never listens, but when IBM asks, you get beaten up for not already knowing the answer. Some people can never be pleased. My $.02. Steve On Mon, 14 May 2012 18:52:21 +, Gibney, Dave gib...@wsu.edu wrote: I have heard two good suggestions. 1. Add an aid to the HMC to access the Wait State code documentation. 2. ZZSA equivalent easily invoked via HMC (or SE) as fix of last resort :) Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
Will you pay (Euros only) for this knowledge? I am afraid nothing is free nowadays. = Thanks for all of the feedback thus far, both on and off the list, it has = been useful. = = So far, there seems to be general agreement that the frequency of problems = is low (at least in production LPARs), that some way of displaying what = the Wait State Code (WSC) means would be useful and that recovery from = these sort of problems is accomplished by using another running z/OS = system. = = To help focus the feedback somewhat I would be interested to know: = - What are the typical steps taken to identify/recover from a WSC ? For = example, =Step 1: Find the meaning of the WSC =Step 2: SADUMP =Step 3: Correct the source of the problem =Step 4: Re-IPL =Step 5: Open a PMR =etc., etc. =Steps 1 seems fairly certain, beyond that the remaining steps (both = content and sequence) seem to be much less so. = - Are the existing messages useful/sufficient for identifying the = underlying cause and how to correct the WSC ? = - Are there circumstances (e.g. console setup, etc.) that prevent the = existing messages from being seen ? = - Are additional/better/different messages needed to identify and/or = correct the cause of the WSC ? = - Is there any need to diagnose and/or correct problems without resorting = to another running z/OS system ? = - To what extent, if any, is it desirable to avoid the WSC by providing = some means of error recovery ? = = Thanks. = = John McDowell - IBM = = = = = -- = For IBM-MAIN subscribe / signoff / archive access instructions, = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = John Cassidy (Dipl.-Ingr.) Kapellenstr. 21a D-65193 Wiesbaden EU Mobile: +49 (0) 170 794 3616 http://www.JDCassidy.net http://en.federaleurope.org/ http://sva-zhosting.com/en/index.php -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
Our typical steps: Step 1 - detect that there is a WSC and find it - this seems to be an operational challenge. It typically ends up with an early morning call stating the IPL didn't work or some reference to whatever the last message on the console was before the IPL was attempted. Now that we have remote access to the HMC it has gotten easier as we're no longer dependent on the operator's interpretation of what's going on. Step 2 - Correct the source of the problem Step 3 - re-IPL (repeat) I can't remember the last time we actually took and used a SADUMP and most WSC issues are configuration issues and do not result in a PMR. Some sort of indication on the NIP console to alert the operators to the WSC would be nice, assuming it got far enough to be able to use a console. Thanks, Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John McDowell Sent: Monday, May 14, 2012 12:56 PM To: IBM-MAIN@bama.ua.edu Subject: Early IPL problems Thanks for all of the feedback thus far, both on and off the list, it has been useful. So far, there seems to be general agreement that the frequency of problems is low (at least in production LPARs), that some way of displaying what the Wait State Code (WSC) means would be useful and that recovery from these sort of problems is accomplished by using another running z/OS system. To help focus the feedback somewhat I would be interested to know: - What are the typical steps taken to identify/recover from a WSC ? For example, Step 1: Find the meaning of the WSC Step 2: SADUMP Step 3: Correct the source of the problem Step 4: Re-IPL Step 5: Open a PMR etc., etc. Steps 1 seems fairly certain, beyond that the remaining steps (both content and sequence) seem to be much less so. - Are the existing messages useful/sufficient for identifying the underlying cause and how to correct the WSC ? - Are there circumstances (e.g. console setup, etc.) that prevent the existing messages from being seen ? - Are additional/better/different messages needed to identify and/or correct the cause of the WSC ? - Is there any need to diagnose and/or correct problems without resorting to another running z/OS system ? - To what extent, if any, is it desirable to avoid the WSC by providing some means of error recovery ? Thanks. John McDowell - IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
I find it odd that IBM is asking this question. I have been fixing wait states for 40 years. Some are easy, some are hard. Having another system to fix things is always a great idea. IBM has tons of people supposedly who know this stuff. Doug -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John McDowell Sent: Monday, May 14, 2012 12:56 PM To: IBM-MAIN@bama.ua.edu Subject: Early IPL problems Thanks for all of the feedback thus far, both on and off the list, it has been useful. So far, there seems to be general agreement that the frequency of problems is low (at least in production LPARs), that some way of displaying what the Wait State Code (WSC) means would be useful and that recovery from these sort of problems is accomplished by using another running z/OS system. To help focus the feedback somewhat I would be interested to know: - What are the typical steps taken to identify/recover from a WSC ? For example, Step 1: Find the meaning of the WSC Step 2: SADUMP Step 3: Correct the source of the problem Step 4: Re-IPL Step 5: Open a PMR etc., etc. Steps 1 seems fairly certain, beyond that the remaining steps (both content and sequence) seem to be much less so. - Are the existing messages useful/sufficient for identifying the underlying cause and how to correct the WSC ? - Are there circumstances (e.g. console setup, etc.) that prevent the existing messages from being seen ? - Are additional/better/different messages needed to identify and/or correct the cause of the WSC ? - Is there any need to diagnose and/or correct problems without resorting to another running z/OS system ? - To what extent, if any, is it desirable to avoid the WSC by providing some means of error recovery ? Thanks. John McDowell - IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of J. Cassidy Sent: Monday, May 14, 2012 12:01 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems Will you pay (Euros only) for this knowledge? I am afraid nothing is free nowadays. nothing is and always has been free grin. GNU software, and other FOSS software, is gratis and libre both. And so is often considered free. Of course, it really isn't because it is costing the authors their time and effort. Also they pay for their own hardware, electricity, and internet connection. But for the rest of us, it is a gift. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
I think Doug Fuerst had a point though. With their vast knowledgebase and thousand of man(woman)years of experience, a set of questions like that from IBM is rather odd. = -Original Message- = From: IBM Mainframe Discussion List = [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of J. Cassidy = Sent: Monday, May 14, 2012 12:01 PM = To: IBM-MAIN@bama.ua.edu = Subject: Re: Early IPL problems = = Will you pay (Euros only) for this knowledge? = = I am afraid nothing is free nowadays. = = nothing is and always has been free grin. = = GNU software, and other FOSS software, is gratis and libre both. And so is = often considered free. Of course, it really isn't because it is costing = the authors their time and effort. Also they pay for their own hardware, = electricity, and internet connection. But for the rest of us, it is a = gift. = = -- = John McKown = Systems Engineer IV = IT = = Administrative Services Group = = HealthMarkets(r) = = 9151 Boulevard 26 * N. Richland Hills * TX 76010 = (817) 255-3225 phone * = john.mck...@healthmarkets.com * www.HealthMarkets.com = = Confidentiality Notice: This e-mail message may contain confidential or = proprietary information. If you are not the intended recipient, please = contact the sender by reply e-mail and destroy all copies of the original = message. HealthMarkets(r) is the brand name for products underwritten and = issued by the insurance subsidiaries of HealthMarkets, Inc. -The = Chesapeake Life Insurance Company(r), Mid-West National Life Insurance = Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM = = -- = For IBM-MAIN subscribe / signoff / archive access instructions, = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = John Cassidy (Dipl.-Ingr.) Kapellenstr. 21a D-65193 Wiesbaden EU Mobile: +49 (0) 170 794 3616 http://www.JDCassidy.net http://en.federaleurope.org/ http://sva-zhosting.com/en/index.php -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
John, I have always found that the Wait States that I encounter are of my own doing. I have never done an SADUMP. The one occurrence that was problematic was after a POR and no LP would IPL. Had to make changes to SYS1.PARMLIB but had no system. We were saved by the Jan Jeager's OS/390 System Utilities. Building that capability into the HMC would be a great addition. Thanks, .Larry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John McDowell Sent: Monday, May 14, 2012 12:56 PM To: IBM-MAIN@bama.ua.edu Subject: Early IPL problems Thanks for all of the feedback thus far, both on and off the list, it has been useful. So far, there seems to be general agreement that the frequency of problems is low (at least in production LPARs), that some way of displaying what the Wait State Code (WSC) means would be useful and that recovery from these sort of problems is accomplished by using another running z/OS system. To help focus the feedback somewhat I would be interested to know: - What are the typical steps taken to identify/recover from a WSC ? For example, Step 1: Find the meaning of the WSC Step 2: SADUMP Step 3: Correct the source of the problem Step 4: Re-IPL Step 5: Open a PMR etc., etc. Steps 1 seems fairly certain, beyond that the remaining steps (both content and sequence) seem to be much less so. - Are the existing messages useful/sufficient for identifying the underlying cause and how to correct the WSC ? - Are there circumstances (e.g. console setup, etc.) that prevent the existing messages from being seen ? - Are additional/better/different messages needed to identify and/or correct the cause of the WSC ? - Is there any need to diagnose and/or correct problems without resorting to another running z/OS system ? - To what extent, if any, is it desirable to avoid the WSC by providing some means of error recovery ? Thanks. John McDowell - IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This E-mail and any of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information or Protected Health Information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited by federal law and may expose you to civil and/or criminal penalties. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
You're assuming that every employee of IBM is well versed in every aspect of all of IBM's products. Are all of your team members equally versed in the OS that you are running? I rather doubt it. Thank You, Dave O'Brien NIH Contractor From: J. Cassidy [s...@jdcassidy.net] Sent: Monday, May 14, 2012 1:49 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems I think Doug Fuerst had a point though. With their vast knowledgebase and thousand of man(woman)years of experience, a set of questions like that from IBM is rather odd. = -Original Message- = From: IBM Mainframe Discussion List = [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of J. Cassidy = Sent: Monday, May 14, 2012 12:01 PM = To: IBM-MAIN@bama.ua.edu = Subject: Re: Early IPL problems = = Will you pay (Euros only) for this knowledge? = = I am afraid nothing is free nowadays. = = nothing is and always has been free grin. = = GNU software, and other FOSS software, is gratis and libre both. And so is = often considered free. Of course, it really isn't because it is costing = the authors their time and effort. Also they pay for their own hardware, = electricity, and internet connection. But for the rest of us, it is a = gift. = = -- = John McKown = Systems Engineer IV = IT = = Administrative Services Group = = HealthMarkets(r) = = 9151 Boulevard 26 * N. Richland Hills * TX 76010 = (817) 255-3225 phone * = john.mck...@healthmarkets.com * www.HealthMarkets.com = = Confidentiality Notice: This e-mail message may contain confidential or = proprietary information. If you are not the intended recipient, please = contact the sender by reply e-mail and destroy all copies of the original = message. HealthMarkets(r) is the brand name for products underwritten and = issued by the insurance subsidiaries of HealthMarkets, Inc. -The = Chesapeake Life Insurance Company(r), Mid-West National Life Insurance = Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM = = -- = For IBM-MAIN subscribe / signoff / archive access instructions, = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = John Cassidy (Dipl.-Ingr.) Kapellenstr. 21a D-65193 Wiesbaden EU Mobile: +49 (0) 170 794 3616 http://www.JDCassidy.net http://en.federaleurope.org/ http://sva-zhosting.com/en/index.php -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
The IBM Mainframe people were implied in my previous post. Coffee time perhaps? = You're assuming that every employee of IBM is well versed in every aspect = of all of IBM's products. = Are all of your team members equally versed in the OS that you are = running? I rather doubt it. = = Thank You, = Dave O'Brien = NIH Contractor = = From: J. Cassidy [s...@jdcassidy.net] = Sent: Monday, May 14, 2012 1:49 PM = To: IBM-MAIN@bama.ua.edu = Subject: Re: Early IPL problems = = I think Doug Fuerst had a point though. = = With their vast knowledgebase and thousand of man(woman)years of = experience, a set of questions like that from IBM = is rather odd. = = = = -Original Message- = = From: IBM Mainframe Discussion List = = [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of J. Cassidy = = Sent: Monday, May 14, 2012 12:01 PM = = To: IBM-MAIN@bama.ua.edu = = Subject: Re: Early IPL problems = = = = Will you pay (Euros only) for this knowledge? = = = = I am afraid nothing is free nowadays. = = = = nothing is and always has been free grin. = = = = GNU software, and other FOSS software, is gratis and libre both. And so = is = = often considered free. Of course, it really isn't because it is = costing = = the authors their time and effort. Also they pay for their own = hardware, = = electricity, and internet connection. But for the rest of us, it is a = = gift. = = = = -- = = John McKown = = Systems Engineer IV = = IT = = = = Administrative Services Group = = = = HealthMarkets(r) = = = = 9151 Boulevard 26 * N. Richland Hills * TX 76010 = = (817) 255-3225 phone * = = john.mck...@healthmarkets.com * www.HealthMarkets.com = = = = Confidentiality Notice: This e-mail message may contain confidential or = = proprietary information. If you are not the intended recipient, please = = contact the sender by reply e-mail and destroy all copies of the = original = = message. HealthMarkets(r) is the brand name for products underwritten = and = = issued by the insurance subsidiaries of HealthMarkets, Inc. -The = = Chesapeake Life Insurance Company(r), Mid-West National Life Insurance = = Company of TennesseeSM and The MEGA Life and Health Insurance = Company.SM = = = = -- = = For IBM-MAIN subscribe / signoff / archive access instructions, = = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = = = = = John Cassidy (Dipl.-Ingr.) = = Kapellenstr. 21a = = D-65193 Wiesbaden = = EU = = = = Mobile: +49 (0) 170 794 3616 = = = http://www.JDCassidy.net = = http://en.federaleurope.org/ = = http://sva-zhosting.com/en/index.php = = -- = For IBM-MAIN subscribe / signoff / archive access instructions, = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = = -- = For IBM-MAIN subscribe / signoff / archive access instructions, = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = John Cassidy (Dipl.-Ingr.) Kapellenstr. 21a D-65193 Wiesbaden EU Mobile: +49 (0) 170 794 3616 http://www.JDCassidy.net http://en.federaleurope.org/ http://sva-zhosting.com/en/index.php -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
So you are suggesting that all mainframe IBMers are equally knowledgeable. That statement would be a fallacy. Thank You, Dave O'Brien From: J. Cassidy [s...@jdcassidy.net] Sent: Monday, May 14, 2012 2:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems The IBM Mainframe people were implied in my previous post. Coffee time perhaps? = You're assuming that every employee of IBM is well versed in every aspect = of all of IBM's products. = Are all of your team members equally versed in the OS that you are = running? I rather doubt it. = = Thank You, = Dave O'Brien = NIH Contractor = = From: J. Cassidy [s...@jdcassidy.net] = Sent: Monday, May 14, 2012 1:49 PM = To: IBM-MAIN@bama.ua.edu = Subject: Re: Early IPL problems = = I think Doug Fuerst had a point though. = = With their vast knowledgebase and thousand of man(woman)years of = experience, a set of questions like that from IBM = is rather odd. = = = = -Original Message- = = From: IBM Mainframe Discussion List = = [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of J. Cassidy = = Sent: Monday, May 14, 2012 12:01 PM = = To: IBM-MAIN@bama.ua.edu = = Subject: Re: Early IPL problems = = = = Will you pay (Euros only) for this knowledge? = = = = I am afraid nothing is free nowadays. = = = = nothing is and always has been free grin. = = = = GNU software, and other FOSS software, is gratis and libre both. And so = is = = often considered free. Of course, it really isn't because it is = costing = = the authors their time and effort. Also they pay for their own = hardware, = = electricity, and internet connection. But for the rest of us, it is a = = gift. = = = = -- = = John McKown = = Systems Engineer IV = = IT = = = = Administrative Services Group = = = = HealthMarkets(r) = = = = 9151 Boulevard 26 * N. Richland Hills * TX 76010 = = (817) 255-3225 phone * = = john.mck...@healthmarkets.com * www.HealthMarkets.com = = = = Confidentiality Notice: This e-mail message may contain confidential or = = proprietary information. If you are not the intended recipient, please = = contact the sender by reply e-mail and destroy all copies of the = original = = message. HealthMarkets(r) is the brand name for products underwritten = and = = issued by the insurance subsidiaries of HealthMarkets, Inc. -The = = Chesapeake Life Insurance Company(r), Mid-West National Life Insurance = = Company of TennesseeSM and The MEGA Life and Health Insurance = Company.SM = = = = -- = = For IBM-MAIN subscribe / signoff / archive access instructions, = = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = = = = = John Cassidy (Dipl.-Ingr.) = = Kapellenstr. 21a = = D-65193 Wiesbaden = = EU = = = = Mobile: +49 (0) 170 794 3616 = = = http://www.JDCassidy.net = = http://en.federaleurope.org/ = = http://sva-zhosting.com/en/index.php = = -- = For IBM-MAIN subscribe / signoff / archive access instructions, = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = = -- = For IBM-MAIN subscribe / signoff / archive access instructions, = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = John Cassidy (Dipl.-Ingr.) Kapellenstr. 21a D-65193 Wiesbaden EU Mobile: +49 (0) 170 794 3616 http://www.JDCassidy.net http://en.federaleurope.org/ http://sva-zhosting.com/en/index.php -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
I am finished here. Don't be so bloody pedantic. = So you are suggesting that all mainframe IBMers are equally knowledgeable. = That statement would be a fallacy. = = Thank You, = Dave O'Brien = = = From: J. Cassidy [s...@jdcassidy.net] = Sent: Monday, May 14, 2012 2:06 PM = To: IBM-MAIN@bama.ua.edu = Subject: Re: Early IPL problems = = The IBM Mainframe people were implied in my previous post. = = Coffee time perhaps? = = = You're assuming that every employee of IBM is well versed in every = aspect = = of all of IBM's products. = = Are all of your team members equally versed in the OS that you are = = running? I rather doubt it. = = = = Thank You, = = Dave O'Brien = = NIH Contractor = = = = From: J. Cassidy [s...@jdcassidy.net] = = Sent: Monday, May 14, 2012 1:49 PM = = To: IBM-MAIN@bama.ua.edu = = Subject: Re: Early IPL problems = = = = I think Doug Fuerst had a point though. = = = = With their vast knowledgebase and thousand of man(woman)years of = = experience, a set of questions like that from IBM = = is rather odd. = = = = = = = -Original Message- = = = From: IBM Mainframe Discussion List = = = [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of J. Cassidy = = = Sent: Monday, May 14, 2012 12:01 PM = = = To: IBM-MAIN@bama.ua.edu = = = Subject: Re: Early IPL problems = = = = = = Will you pay (Euros only) for this knowledge? = = = = = = I am afraid nothing is free nowadays. = = = = = = nothing is and always has been free grin. = = = = = = GNU software, and other FOSS software, is gratis and libre both. And = so = = is = = = often considered free. Of course, it really isn't because it is = = costing = = = the authors their time and effort. Also they pay for their own = = hardware, = = = electricity, and internet connection. But for the rest of us, it is = a = = = gift. = = = = = = -- = = = John McKown = = = Systems Engineer IV = = = IT = = = = = = Administrative Services Group = = = = = = HealthMarkets(r) = = = = = = 9151 Boulevard 26 * N. Richland Hills * TX 76010 = = = (817) 255-3225 phone * = = = john.mck...@healthmarkets.com * www.HealthMarkets.com = = = = = = Confidentiality Notice: This e-mail message may contain confidential = or = = = proprietary information. If you are not the intended recipient, = please = = = contact the sender by reply e-mail and destroy all copies of the = = original = = = message. HealthMarkets(r) is the brand name for products = underwritten = = and = = = issued by the insurance subsidiaries of HealthMarkets, Inc. -The = = = Chesapeake Life Insurance Company(r), Mid-West National Life = Insurance = = = Company of TennesseeSM and The MEGA Life and Health Insurance = = Company.SM = = = = = = = -- = = = For IBM-MAIN subscribe / signoff / archive access instructions, = = = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = = = = = = = = = John Cassidy (Dipl.-Ingr.) = = = = Kapellenstr. 21a = = = = D-65193 Wiesbaden = = = = EU = = = = = = = = Mobile: +49 (0) 170 794 3616 = = = = = = http://www.JDCassidy.net = = = = http://en.federaleurope.org/ = = = = http://sva-zhosting.com/en/index.php = = = = -- = = For IBM-MAIN subscribe / signoff / archive access instructions, = = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = = = = -- = = For IBM-MAIN subscribe / signoff / archive access instructions, = = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = = = = = John Cassidy (Dipl.-Ingr.) = = Kapellenstr. 21a = = D-65193 Wiesbaden = = EU = = = = Mobile: +49 (0) 170 794 3616 = = = http://www.JDCassidy.net = = http://en.federaleurope.org/ = = http://sva-zhosting.com/en/index.php = = -- = For IBM-MAIN subscribe / signoff / archive access instructions, = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = = -- = For IBM-MAIN subscribe / signoff / archive access instructions, = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = John Cassidy (Dipl.-Ingr.) Kapellenstr. 21a D-65193 Wiesbaden EU Mobile: +49 (0) 170 794 3616 http://www.JDCassidy.net http://en.federaleurope.org/ http://sva-zhosting.com/en/index.php -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
I have heard two good suggestions. 1. Add an aid to the HMC to access the Wait State code documentation. 2. ZZSA equivalent easily invoked via HMC (or SE) as fix of last resort :) Once, after final recabling of a DASD move, we had one mistake in LOADxx. It did take opening an incident with IBM to fully diagnose. We were about to recable back, when I remembered the CD Sam K. gave out at SHARE. Flipped the equivalent of 2 bits in one character and there was dancing in the machine room. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John McDowell Sent: Monday, May 14, 2012 11:44 AM To: IBM-MAIN@bama.ua.edu Subject: Early IPL problems Just to be clear. My intent is to get a sampling of customer experience in the titled area, specifically to gauge real world experiences. If you see no need for any changes in the z/OS system behavior in this area that is fine, on the other hand if you would like to see some different behavior I am interested in hearing what that might be. John McDowell - IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
And credible system programmer should be able to diagnose a simple wait state. It really is not terribly difficult. And if you can't, perhaps Windows is more your style. Sorry. Doug -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Monday, May 14, 2012 2:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems So you are suggesting that all mainframe IBMers are equally knowledgeable. That statement would be a fallacy. Thank You, Dave O'Brien From: J. Cassidy [s...@jdcassidy.net] Sent: Monday, May 14, 2012 2:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems The IBM Mainframe people were implied in my previous post. Coffee time perhaps? = You're assuming that every employee of IBM is well versed in every aspect = of all of IBM's products. = Are all of your team members equally versed in the OS that you are = running? I rather doubt it. = = Thank You, = Dave O'Brien = NIH Contractor = = From: J. Cassidy [s...@jdcassidy.net] = Sent: Monday, May 14, 2012 1:49 PM = To: IBM-MAIN@bama.ua.edu = Subject: Re: Early IPL problems = = I think Doug Fuerst had a point though. = = With their vast knowledgebase and thousand of man(woman)years of = experience, a set of questions like that from IBM = is rather odd. = = = = -Original Message- = = From: IBM Mainframe Discussion List = = [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of J. Cassidy = = Sent: Monday, May 14, 2012 12:01 PM = = To: IBM-MAIN@bama.ua.edu = = Subject: Re: Early IPL problems = = = = Will you pay (Euros only) for this knowledge? = = = = I am afraid nothing is free nowadays. = = = = nothing is and always has been free grin. = = = = GNU software, and other FOSS software, is gratis and libre both. And so = is = = often considered free. Of course, it really isn't because it is = costing = = the authors their time and effort. Also they pay for their own = hardware, = = electricity, and internet connection. But for the rest of us, it is a = = gift. = = = = -- = = John McKown = = Systems Engineer IV = = IT = = = = Administrative Services Group = = = = HealthMarkets(r) = = = = 9151 Boulevard 26 * N. Richland Hills * TX 76010 = = (817) 255-3225 phone * = = john.mck...@healthmarkets.com * www.HealthMarkets.com = = = = Confidentiality Notice: This e-mail message may contain confidential or = = proprietary information. If you are not the intended recipient, please = = contact the sender by reply e-mail and destroy all copies of the = original = = message. HealthMarkets(r) is the brand name for products underwritten = and = = issued by the insurance subsidiaries of HealthMarkets, Inc. -The = = Chesapeake Life Insurance Company(r), Mid-West National Life Insurance = = Company of TennesseeSM and The MEGA Life and Health Insurance = Company.SM = = = = -- = = For IBM-MAIN subscribe / signoff / archive access instructions, = = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = = = = = John Cassidy (Dipl.-Ingr.) = = Kapellenstr. 21a = = D-65193 Wiesbaden = = EU = = = = Mobile: +49 (0) 170 794 3616 = = = http://www.JDCassidy.net = = http://en.federaleurope.org/ = = http://sva-zhosting.com/en/index.php = = -- = For IBM-MAIN subscribe / signoff / archive access instructions, = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = = -- = For IBM-MAIN subscribe / signoff / archive access instructions, = send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN = John Cassidy (Dipl.-Ingr.) Kapellenstr. 21a D-65193 Wiesbaden EU Mobile: +49 (0) 170 794 3616 http://www.JDCassidy.net http://en.federaleurope.org/ http://sva-zhosting.com/en/index.php -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
I always found that your activity the day after you have a wait state and you have no other system to fix it is to create a small one or two pack system to save your butt next time it happens. Or create another LPAR and have the space system running all the time. You generally only have this happen once. Doug -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Martin, Larry D Sent: Monday, May 14, 2012 1:51 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems John, I have always found that the Wait States that I encounter are of my own doing. I have never done an SADUMP. The one occurrence that was problematic was after a POR and no LP would IPL. Had to make changes to SYS1.PARMLIB but had no system. We were saved by the Jan Jeager's OS/390 System Utilities. Building that capability into the HMC would be a great addition. Thanks, .Larry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John McDowell Sent: Monday, May 14, 2012 12:56 PM To: IBM-MAIN@bama.ua.edu Subject: Early IPL problems Thanks for all of the feedback thus far, both on and off the list, it has been useful. So far, there seems to be general agreement that the frequency of problems is low (at least in production LPARs), that some way of displaying what the Wait State Code (WSC) means would be useful and that recovery from these sort of problems is accomplished by using another running z/OS system. To help focus the feedback somewhat I would be interested to know: - What are the typical steps taken to identify/recover from a WSC ? For example, Step 1: Find the meaning of the WSC Step 2: SADUMP Step 3: Correct the source of the problem Step 4: Re-IPL Step 5: Open a PMR etc., etc. Steps 1 seems fairly certain, beyond that the remaining steps (both content and sequence) seem to be much less so. - Are the existing messages useful/sufficient for identifying the underlying cause and how to correct the WSC ? - Are there circumstances (e.g. console setup, etc.) that prevent the existing messages from being seen ? - Are additional/better/different messages needed to identify and/or correct the cause of the WSC ? - Is there any need to diagnose and/or correct problems without resorting to another running z/OS system ? - To what extent, if any, is it desirable to avoid the WSC by providing some means of error recovery ? Thanks. John McDowell - IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This E-mail and any of its attachments may contain Prince George's County Government or Prince George's County 7th Judicial Circuit Court proprietary information or Protected Health Information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited by federal law and may expose you to civil and/or criminal penalties. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
Umm, maybe their data base got corrupted? HONE used to have all this stuff by machine type, FRU and time to repair. In a message dated 5/14/2012 12:49:48 P.M. Central Daylight Time, s...@jdcassidy.net writes: experience, a set of questions like that from IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
I maintain a CD with ZZSA on it on top of each HMC - (Now you remind me to have my hardware folks go and look to make sure they are still taped there). Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Gibney, Dave Sent: Monday, May 14, 2012 11:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems I have heard two good suggestions. 1. Add an aid to the HMC to access the Wait State code documentation. 2. ZZSA equivalent easily invoked via HMC (or SE) as fix of last resort :) Once, after final recabling of a DASD move, we had one mistake in LOADxx. It did take opening an incident with IBM to fully diagnose. We were about to recable back, when I remembered the CD Sam K. gave out at SHARE. Flipped the equivalent of 2 bits in one character and there was dancing in the machine room. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John McDowell Sent: Monday, May 14, 2012 11:44 AM To: IBM-MAIN@bama.ua.edu Subject: Early IPL problems Just to be clear. My intent is to get a sampling of customer experience in the titled area, specifically to gauge real world experiences. If you see no need for any changes in the z/OS system behavior in this area that is fine, on the other hand if you would like to see some different behavior I am interested in hearing what that might be. John McDowell - IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
At some point, and at some place, I had a standalone dataset editor. You IPL'd it, and you could edit a dataset. Can't remember who made it. Old age, you know Doug -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of ITURIEL DO NASCIMENTO NETO Sent: Monday, May 14, 2012 4:03 PM To: IBM-MAIN@bama.ua.edu Subject: RES: Early IPL problems Or you can download an amazing SOS IPL text... Available at http://www.cbttape.org/~jjaeger/zzsa.html Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto BANCO BRADESCO S.A. 4254 / DPCD Engenharia de Software Sistemas Operacionais Mainframes Tel: +55 11 3684-2177 R: 42177 3-1402 Fax: +55 11 4197-2814 -Mensagem original- De: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] Em nome de Doug Fuerst Enviada em: segunda-feira, 14 de maio de 2012 16:56 Para: IBM-MAIN@bama.ua.edu Assunto: Re: Early IPL problems I always found that your activity the day after you have a wait state and you have no other system to fix it is to create a small one or two pack system to save your butt next time it happens. Or create another LPAR and have the space system running all the time. You generally only have this happen once. Doug -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Martin, Larry D Sent: Monday, May 14, 2012 1:51 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems John, I have always found that the Wait States that I encounter are of my own doing. I have never done an SADUMP. The one occurrence that was problematic was after a POR and no LP would IPL. Had to make changes to SYS1.PARMLIB but had no system. We were saved by the Jan Jeager's OS/390 System Utilities. Building that capability into the HMC would be a great addition. Thanks, .Larry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John McDowell Sent: Monday, May 14, 2012 12:56 PM To: IBM-MAIN@bama.ua.edu Subject: Early IPL problems Thanks for all of the feedback thus far, both on and off the list, it has been useful. So far, there seems to be general agreement that the frequency of problems is low (at least in production LPARs), that some way of displaying what the Wait State Code (WSC) means would be useful and that recovery from these sort of problems is accomplished by using another running z/OS system. To help focus the feedback somewhat I would be interested to know: - What are the typical steps taken to identify/recover from a WSC ? For example, Step 1: Find the meaning of the WSC Step 2: SADUMP Step 3: Correct the source of the problem Step 4: Re-IPL Step 5: Open a PMR etc., etc. Steps 1 seems fairly certain, beyond that the remaining steps (both content and sequence) seem to be much less so. - Are the existing messages useful/sufficient for identifying the underlying cause and how to correct the WSC ? - Are there circumstances (e.g. console setup, etc.) that prevent the existing messages from being seen ? - Are additional/better/different messages needed to identify and/or correct the cause of the WSC ? - Is there any need to diagnose and/or correct problems without resorting to another running z/OS system ? - To what extent, if any, is it desirable to avoid the WSC by providing some means of error recovery ? Thanks. John McDowell - IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This E-mail and any of its attachments may contain Prince George's County Government or Prince George's County 7th Judicial Circuit Court proprietary information or Protected Health Information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited by federal law and may expose you to civil and/or criminal penalties. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN AVISO LEGAL br...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou
Re: Early IPL problems
NewEra Software markets SAE. They also have a DASD erase program. We use it at DR to scrub all our data. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bill Fairchild Sent: Monday, May 14, 2012 3:51 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems SAE - StandAlone Editor, from a vendor whose name escapes me now, in Winnipeg, Canada, I believe. Bill Fairchild Programmer Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
Calgary, not Winnipeg. SAE is Stand-Alone Environment (not editor). NewEra is right. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, May 14, 2012 3:56 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems NewEra Software markets SAE. They also have a DASD erase program. We use it at DR to scrub all our data. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bill Fairchild Sent: Monday, May 14, 2012 3:51 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems SAE - StandAlone Editor, from a vendor whose name escapes me now, in Winnipeg, Canada, I believe. Bill Fairchild Programmer Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
- What are the typical steps taken to identify/recover from a WSC ? For example, The one occurance we had recently that resulted in a wait state (during hardware migration - hot swap to a new CPU) was entirely due to IBM changing the rules that applied forever without notice, in other words that I consider a bug. (IBM differs on that opinion). The wait state code was ridiculous (GRS saying it couldn't get to the ISGLOCK structure), especially in light that this was the *second* system in that sysplex to get IPL'd, and the first was happily running along on the same box using that structure. Besides, GRS wasn't the culprit in this, even though they loaded the wait state. My colleagues were unable to determine *what* caused the wait state, for the simple reason that the accompanying message wasn't visible anymore. In this, I also blame IBM who apparently do all their testing under VM (where the NIP messages stay on the console) and have no clue about the real world that actually uses 'real' consoles NOT under VM for a NIP console. A 'real' console is these days attached somehow to an IP network. The second the wait state hits, that console is released to the network. Which means that the 'IP network' puts its welcome message back onto that console, effectively wiping out any messages that might have been visible there. And believe me, that is so fast that you have no chance of seeing any preceding message, much less comprehend it. Admittedly at this point, an sadump *should* have been taken, just to get at the NIP messages. Unfortunately I am the resident dump reader, and I wasn't there that night (besides, I would have known immediately how to fix this and wouldn't have needed the sadump). So it took three of my colleagues about 4 hours of trial and error to find a bypass, until they inadvertently hit the right thing to do. (Don't tell me that we should have opened an ETR with IBM - that wouldn't have given faster results, either, since we are NOT a US customer). IBM should really test their systems on real consoles (not VM, and not on the HMC, either), because IBM doesn't even understand how hard it is to see NIP messages preceding a problem. In addition, *EVERY* NIP message explaining a wait state should be *in the wait state message*, not some preceding 'for your info' thing. Especially when the component loading the wait state wasn't the culprit. - Are the existing messages useful/sufficient for identifying the underlying cause and how to correct the WSC ? No. - Are there circumstances (e.g. console setup, etc.) that prevent the existing messages from being seen ? Use real consoles for testing, not the HMC and not VM consoles. And don't only test new designs by only using what IBM thinks a customer should do and by only testing the upper limits of any parameter. I have the impression that lower limits are never tested, even if they are allowed. And IBMs test scenarios lack real world experience, it seems to be an ivory tower outlook. - Are additional/better/different messages needed to identify and/or correct the cause of the WSC ? Yes. Those that don't disappear when the system hits the wait state. - Is there any need to diagnose and/or correct problems without resorting to another running z/OS system ? Yes, if it is the first system to get IPL'd on new hardware and the wait state code implies some sort of setup problem that will need to get fixed by changing parms. Others have commented on this. If you have to take an sadump to find out why you got the wait state, you will always need a system up and running to even debug. Or to send the dump to IBM. - To what extent, if any, is it desirable to avoid the WSC by providing some means of error recovery ? It is desirable not to change the rules, especially in sensitive areas of IPL, way before the customer hits a wait state code with a well-known and previously working setup just because design changes weren't thoroughly tested with real-world scenarios and lower limits. Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
Yup, that's it. Good product, good vendor. SAE used to be called NOTSO. They have another product, Image Focus that will let you run a virtual IPL with all of your changes before going live. Really nice in a small shop with no real sandbox. Linda - Original Message - From: Bill Fairchild bfairch...@rocketsoftware.com To: IBM-MAIN@bama.ua.edu Sent: Monday, May 14, 2012 1:58:02 PM Subject: Re: Early IPL problems Calgary, not Winnipeg. SAE is Stand-Alone Environment (not editor). NewEra is right. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, May 14, 2012 3:56 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems NewEra Software markets SAE. They also have a DASD erase program. We use it at DR to scrub all our data. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bill Fairchild Sent: Monday, May 14, 2012 3:51 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems SAE - StandAlone Editor, from a vendor whose name escapes me now, in Winnipeg, Canada, I believe. Bill Fairchild Programmer Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
Agreed with Skip Mark and RS - Rare to have problems in IPL of prod systems. Using another member of the Sysplex to fix is the normal course. Dup volumes has bitten us more than any other error I'd guess. HMC providing easily readable translation of the wait state would be awesome Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Zelden Sent: Sunday, April 29, 2012 8:33 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Early IPL problems On Sat, 28 Apr 2012 09:47:29 +0200, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2012-04-27 23:03, John McDowell pisze: I'm trying to get a feel for problems that occur in the early stages of z/OS system start up (e.g. IPL/NIP). Generally problems in these stages result in a non-restartable wait state, for example wait state x'0B1' (e.g. LOADxx or IODF problem). Questions: 1. FREQUENCY: How often do they occur ? 2. DURATION: How long does it take to resolve them (e.g. minutes, hours, etc.) ? 3. IMPACT: What are the consequences (e.g. missed SLAs, etc.) ? 4. CAUSE: What are the underlying sources (e.g. hardware, software, etc.) ? 5. RECOVERY: How do you recover from them ? 1. Rarely. IPL is performed rarely. In my case I haven't noticed such problem *on production systems* for years. Such problems do happen during tests, like new system, PTFs applied (and IPLTEXT not refreshed), new CPC, new LPAR, DR test, etc. BTW: I *hate* looking at last 3 digits, then previous digits... ;-) Since the numbers are available on HMC, it would be nice to have button Explain which could (under the covers) open the book and perform the analysis for me. 2. The time depends on two-three elements: a) time to open the book. It can be few seconds when I'm on my PC (HMC accessed remotely), it can be minutes when I do it on real HMC and I have to use another PC for documentation access. b) time to write down the digits, extract wait state code and reason code. c) (optional) sometimes I need to check whether description is accurate or maybe fix something (like LOAD member). I usually logon to TSO on another system and view/modify the things. It could take 5 min. 3. Lost time, some stress. From business point of view it doesn't affect my SLA. 4. IODF in multiple extents, OS config with bad offline/online device set (i.e. IODF device is described as OFFLINE YES), mistakes in LOADxx, not refreshed IPLTEXT (after PTF APPLY), typo in LOAD window on HMC. 5. See 2. I think R.S.'s response is typical for most of us. Although I can't remember the last time I had a wait due to nucleus or IODF in multiple extents, occasionally I have typo'd a loadparm when IPLing one of my sandbox LPARs. Loadparms never change in production except for a brief period when migrating to a new OS release and the sysprog will do that initial IPL/change and the HMC remembers it of course. Load addresses change often, but no one ever seems to type those in wrong. I really like the idea of the HMC being able to quickly open a reference to the correct wait state code. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
On Fri, 27 Apr 2012 16:03:21 -0500 John McDowell john...@us.ibm.com wrote: :I'm trying to get a feel for problems that occur in the early stages of z/OS system start up (e.g. IPL/NIP). Generally problems in these stages result in a non-restartable wait state, for example wait state x'0B1' (e.g. LOADxx or IODF problem). : :Questions: :1. FREQUENCY: How often do they occur ? When I stick in early IPL code - not that frequent. :2. DURATION: How long does it take to resolve them (e.g. minutes, hours, etc.) ? Usually not long. :3. IMPACT: What are the consequences (e.g. missed SLAs, etc.) ? None, it is a test system. :4. CAUSE: What are the underlying sources (e.g. hardware, software, etc.) ? My code. :5. RECOVERY: How do you recover from them ? Sometimes poking in storage (under VM) is enough - otherwise an SA diump. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
It's not strictly related to the OP question, but it is very important issue when talking about IPL problems. We pay much attention to avoid duplicateonline volsers. BTW: in our case duplicates come from clones performed using PiT copy, it's not matter of naming convention. -- Radoslaw Skorupka Lodz, Poland W dniu 2012-04-29 03:15, Skip Robinson pisze: As Radoslaw says, IPL failures in production are so rare and so varied that categorizing them is a an exercise in thrashing. Except for one cause: duplicate volume serial numbers. The fact that duplicates are the result of user error does not lessen the blow. In the case of only a handful of duplicates, the operator can reply a few times and move on. But we've had cases of dozens or scores of duplicates. NIP provides no mechanism for handling a flood of duplicates even though the cause may be obvious, such as volumes copied from one subsystem to another without the original volumes having yet been CLIPped to unique spares. Or an IODF has mistakenly connected an LPAR to a DASD subsystem it should not have access to. Whatever the cause, restarting the IPL is useless as the same duplicates will be prompted for again and again until they are eliminated. Take this simple case, Duplicate pairs: 4001 - 8001 4002 - 8002 4003 - 8003 ... The pattern is transparent. The only real question is whether 4xxx is 'current' or 8xxx is. There is currently no way tell NIP that, say, 8xxx is the range we want to keep online, while the corresponding 4xxx units should remain offline. Side irritant: why on earth do we have to tell NIP which volume we do *not* want online? How would that game plan play on a network quiz show? Back to the point. Although this stuation does not happen often, it can take ages to unravel. And best of luck if there's no running system available to undo the duplicates. . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: R.S.r.skoru...@bremultibank.com.pl To: IBM-MAIN@bama.ua.edu Date: 04/28/2012 12:47 AM Subject:Re: Early IPL problems Sent by:IBM Mainframe Discussion ListIBM-MAIN@bama.ua.edu W dniu 2012-04-27 23:03, John McDowell pisze: I'm trying to get a feel for problems that occur in the early stages of z/OS system start up (e.g. IPL/NIP). Generally problems in these stages result in a non-restartable wait state, for example wait state x'0B1' (e.g. LOADxx or IODF problem). Questions: 1. FREQUENCY: How often do they occur ? 2. DURATION: How long does it take to resolve them (e.g. minutes, hours, etc.) ? 3. IMPACT: What are the consequences (e.g. missed SLAs, etc.) ? 4. CAUSE: What are the underlying sources (e.g. hardware, software, etc.) ? 5. RECOVERY: How do you recover from them ? 1. Rarely. IPL is performed rarely. In my case I haven't noticed such problem *on production systems* for years. Such problems do happen during tests, like new system, PTFs applied (and IPLTEXT not refreshed), new CPC, new LPAR, DR test, etc. BTW: I *hate* looking at last 3 digits, then previous digits... ;-) Since the numbers are available on HMC, it would be nice to have button Explain which could (under the covers) open the book and perform the analysis for me. 2. The time depends on two-three elements: a) time to open the book. It can be few seconds when I'm on my PC (HMC accessed remotely), it can be minutes when I do it on real HMC and I have to use another PC for documentation access. b) time to write down the digits, extract wait state code and reason code. c) (optional) sometimes I need to check whether description is accurate or maybe fix something (like LOAD member). I usually logon to TSO on another system and view/modify the things. It could take 5 min. 3. Lost time, some stress. From business point of view it doesn't affect my SLA. 4. IODF in multiple extents, OS config with bad offline/online device set (i.e. IODF device is described as OFFLINE YES), mistakes in LOADxx, not refreshed IPLTEXT (after PTF APPLY), typo in LOAD window on HMC. 5. See 2. Regards -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail
Re: Early IPL problems
On Sat, 28 Apr 2012 09:47:29 +0200, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2012-04-27 23:03, John McDowell pisze: I'm trying to get a feel for problems that occur in the early stages of z/OS system start up (e.g. IPL/NIP). Generally problems in these stages result in a non-restartable wait state, for example wait state x'0B1' (e.g. LOADxx or IODF problem). Questions: 1. FREQUENCY: How often do they occur ? 2. DURATION: How long does it take to resolve them (e.g. minutes, hours, etc.) ? 3. IMPACT: What are the consequences (e.g. missed SLAs, etc.) ? 4. CAUSE: What are the underlying sources (e.g. hardware, software, etc.) ? 5. RECOVERY: How do you recover from them ? 1. Rarely. IPL is performed rarely. In my case I haven't noticed such problem *on production systems* for years. Such problems do happen during tests, like new system, PTFs applied (and IPLTEXT not refreshed), new CPC, new LPAR, DR test, etc. BTW: I *hate* looking at last 3 digits, then previous digits... ;-) Since the numbers are available on HMC, it would be nice to have button Explain which could (under the covers) open the book and perform the analysis for me. 2. The time depends on two-three elements: a) time to open the book. It can be few seconds when I'm on my PC (HMC accessed remotely), it can be minutes when I do it on real HMC and I have to use another PC for documentation access. b) time to write down the digits, extract wait state code and reason code. c) (optional) sometimes I need to check whether description is accurate or maybe fix something (like LOAD member). I usually logon to TSO on another system and view/modify the things. It could take 5 min. 3. Lost time, some stress. From business point of view it doesn't affect my SLA. 4. IODF in multiple extents, OS config with bad offline/online device set (i.e. IODF device is described as OFFLINE YES), mistakes in LOADxx, not refreshed IPLTEXT (after PTF APPLY), typo in LOAD window on HMC. 5. See 2. I think R.S.'s response is typical for most of us. Although I can't remember the last time I had a wait due to nucleus or IODF in multiple extents, occasionally I have typo'd a loadparm when IPLing one of my sandbox LPARs. Loadparms never change in production except for a brief period when migrating to a new OS release and the sysprog will do that initial IPL/change and the HMC remembers it of course. Load addresses change often, but no one ever seems to type those in wrong. I really like the idea of the HMC being able to quickly open a reference to the correct wait state code. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
W dniu 2012-04-27 23:03, John McDowell pisze: I'm trying to get a feel for problems that occur in the early stages of z/OS system start up (e.g. IPL/NIP). Generally problems in these stages result in a non-restartable wait state, for example wait state x'0B1' (e.g. LOADxx or IODF problem). Questions: 1. FREQUENCY: How often do they occur ? 2. DURATION: How long does it take to resolve them (e.g. minutes, hours, etc.) ? 3. IMPACT: What are the consequences (e.g. missed SLAs, etc.) ? 4. CAUSE: What are the underlying sources (e.g. hardware, software, etc.) ? 5. RECOVERY: How do you recover from them ? 1. Rarely. IPL is performed rarely. In my case I haven't noticed such problem *on production systems* for years. Such problems do happen during tests, like new system, PTFs applied (and IPLTEXT not refreshed), new CPC, new LPAR, DR test, etc. BTW: I *hate* looking at last 3 digits, then previous digits... ;-) Since the numbers are available on HMC, it would be nice to have button Explain which could (under the covers) open the book and perform the analysis for me. 2. The time depends on two-three elements: a) time to open the book. It can be few seconds when I'm on my PC (HMC accessed remotely), it can be minutes when I do it on real HMC and I have to use another PC for documentation access. b) time to write down the digits, extract wait state code and reason code. c) (optional) sometimes I need to check whether description is accurate or maybe fix something (like LOAD member). I usually logon to TSO on another system and view/modify the things. It could take 5 min. 3. Lost time, some stress. From business point of view it doesn't affect my SLA. 4. IODF in multiple extents, OS config with bad offline/online device set (i.e. IODF device is described as OFFLINE YES), mistakes in LOADxx, not refreshed IPLTEXT (after PTF APPLY), typo in LOAD window on HMC. 5. See 2. Regards -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 22 829 00 00, fax +48 22 829 00 33, www.brebank.pl, e-mail: i...@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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
As Radoslaw says, IPL failures in production are so rare and so varied that categorizing them is a an exercise in thrashing. Except for one cause: duplicate volume serial numbers. The fact that duplicates are the result of user error does not lessen the blow. In the case of only a handful of duplicates, the operator can reply a few times and move on. But we've had cases of dozens or scores of duplicates. NIP provides no mechanism for handling a flood of duplicates even though the cause may be obvious, such as volumes copied from one subsystem to another without the original volumes having yet been CLIPped to unique spares. Or an IODF has mistakenly connected an LPAR to a DASD subsystem it should not have access to. Whatever the cause, restarting the IPL is useless as the same duplicates will be prompted for again and again until they are eliminated. Take this simple case, Duplicate pairs: 4001 - 8001 4002 - 8002 4003 - 8003 ... The pattern is transparent. The only real question is whether 4xxx is 'current' or 8xxx is. There is currently no way tell NIP that, say, 8xxx is the range we want to keep online, while the corresponding 4xxx units should remain offline. Side irritant: why on earth do we have to tell NIP which volume we do *not* want online? How would that game plan play on a network quiz show? Back to the point. Although this stuation does not happen often, it can take ages to unravel. And best of luck if there's no running system available to undo the duplicates. . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: R.S. r.skoru...@bremultibank.com.pl To: IBM-MAIN@bama.ua.edu Date: 04/28/2012 12:47 AM Subject:Re: Early IPL problems Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu W dniu 2012-04-27 23:03, John McDowell pisze: I'm trying to get a feel for problems that occur in the early stages of z/OS system start up (e.g. IPL/NIP). Generally problems in these stages result in a non-restartable wait state, for example wait state x'0B1' (e.g. LOADxx or IODF problem). Questions: 1. FREQUENCY: How often do they occur ? 2. DURATION: How long does it take to resolve them (e.g. minutes, hours, etc.) ? 3. IMPACT: What are the consequences (e.g. missed SLAs, etc.) ? 4. CAUSE: What are the underlying sources (e.g. hardware, software, etc.) ? 5. RECOVERY: How do you recover from them ? 1. Rarely. IPL is performed rarely. In my case I haven't noticed such problem *on production systems* for years. Such problems do happen during tests, like new system, PTFs applied (and IPLTEXT not refreshed), new CPC, new LPAR, DR test, etc. BTW: I *hate* looking at last 3 digits, then previous digits... ;-) Since the numbers are available on HMC, it would be nice to have button Explain which could (under the covers) open the book and perform the analysis for me. 2. The time depends on two-three elements: a) time to open the book. It can be few seconds when I'm on my PC (HMC accessed remotely), it can be minutes when I do it on real HMC and I have to use another PC for documentation access. b) time to write down the digits, extract wait state code and reason code. c) (optional) sometimes I need to check whether description is accurate or maybe fix something (like LOAD member). I usually logon to TSO on another system and view/modify the things. It could take 5 min. 3. Lost time, some stress. From business point of view it doesn't affect my SLA. 4. IODF in multiple extents, OS config with bad offline/online device set (i.e. IODF device is described as OFFLINE YES), mistakes in LOADxx, not refreshed IPLTEXT (after PTF APPLY), typo in LOAD window on HMC. 5. See 2. Regards -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity
Re: Early IPL problems
1)Maybe twice a year with hardware and software upgrades. 2)Usually a few minutes(IPL 3)Destroys 5 nines 4)Lack of support. No boots on the ground(SEs particularly) 5)Trial and error 'til you get it right. In a message dated 4/27/2012 4:14:29 P.M. Central Daylight Time, john...@us.ibm.com writes: 1. FREQUENCY: How often do they occur ? 2. DURATION: How long does it take to resolve them (e.g. minutes, hours, etc.) ? 3. IMPACT: What are the consequences (e.g. missed SLAs, etc.) ? 4. CAUSE: What are the underlying sources (e.g. hardware, software, etc.) ? 5. RECOVERY: How do you recover from them ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
