Re: z/OS IPL Issue
On Sat, Oct 26, 2013 at 7:50 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In caajsdjilg3pg1p41eh5pqyjl5-2ex6yc3q5u2lz44_gga33...@mail.gmail.com, on 10/26/2013 at 07:45 AM, John McKown john.archie.mck...@gmail.com said: The PC (actually 3 of them) even has the old IBM 122 key converged keyboard. What's the emoticon for lust in my heart? I was horrified when ESD didn't use the converged keyboard layout. Really? If so, then fulfil your lust at: http://pckeyboard.com/page/category/PC122 . This is like the original IBM buckling spring keyboard. IMO, even better than the Cherry MX blue. Cost is $99.00, USB connects. If you need one, there are USB to PS2 converters. They have other configurations of the buckling spring (aka original IBM) keyboards. I have one of their keyboards and it is FANTASIC. Not the 122 version, but an APL keyboard. Talk about old style. Not all change is progress. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
For NIP consoles, we use a coax attached PC running, I think, the old IRMA emulation software (or equivalent). This is attached to a Visara which emulates a 3174. It is on an Escon CHP. The PC (actually 3 of them) even has the old IBM 122 key converged keyboard. The one with the 24 PFK keys along the top in a double row. Talk about old style. I often wonder about this. But the argument is that even if the LAN dies, a production control person can go use this PC to log onto CA-7 and continue to run our z/OS scheduled jobs. At least until we need data from a LAN attached server. And don't do any ftp. We have reason to not really trust the LAN people. On Fri, Oct 25, 2013 at 5:23 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 20131023075515.07f678e2041c928bd4cca...@gmx.net, on 10/23/2013 at 07:55 AM, nitz-...@gmx.net nitz-...@gmx.net said: 'we have always used a real console for NIP, we want to keep it', They consider a TN3270 session from a PC to be a real console? -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
In 5268bbab.4090...@bremultibank.com.pl, on 10/24/2013 at 08:18 AM, R.S. r.skoru...@bremultibank.com.pl said: No. Master console *was* a thing from MCS world. During NIP there weren't master console - just console, only one. Nonsense. The following two quotes are for OS/360 and MVS, reaspectively: NIP converts any time-slice intervals to timer units, obtains a primary/master console, Initializing System Consoles The system console is the I/O device tIle system operator uses to provide system parameters and otherwise control the initialization process. Because it is used for operator-to-system communication, it is actually one of the first devices to be initialized. The RIM that initializes the system console must locate an available console, designate it as the master console, and initialize it. The concept of a NIP console came later. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Mike, The use of the Integrated 3270 is not limited to the model of use embodied by z/OS MCS console interaction (e.g. a single line of input) but rather supports a broader range of the 3270 data stream. In z/OS terms think about the possibility (not currently available) of having a TSO session running ISPF available. With this use in mind I think you can see fighting about keyboard inputs would be very difficult. (Note: VM does support the use of the Integrated 3270 for a virtual machine console which could result in an ISPF presentation.) I think the current limitation of not allowing multiple concurrent accessors represents a typical first implementation (i.e. very conservative) that the designers of z are wont to do. My suggestion would be that anyone who is interested in seeing this change find Ed Jaffe's requirement and concur with it or alternatively open a similar requirement of their own. Like many other features/functions of the z platform the Integrated 3270 does not behave exactly was one might like but none the less even with it's current limitations it is useful. John McDowell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
In 20131023075515.07f678e2041c928bd4cca...@gmx.net, on 10/23/2013 at 07:55 AM, nitz-...@gmx.net nitz-...@gmx.net said: 'we have always used a real console for NIP, we want to keep it', They consider a TN3270 session from a PC to be a real console? -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
On 10/23/2013 3:19 PM, Thomas Conley wrote: On 10/23/2013 3:47 PM, John McKown wrote: Curiosity question: Why do you need multiple remote I3270C sessions per LPAR? If we ever go to z/OS 2.1 (iffy), we would only use it for IPLing. We use SMCS consoles via TN3270 for other consoles, beyond the Visara ones in the NOC (computer room adjunct). We often have multiple people looking at the console messages via the Java app on the HMC, especially when we're having a problem shutting down a system after TSO is gone or starting a system up before TSO is available. My good friend the distinguished gentleman from California is correct, this is a serious shortcoming in the Integrated 3270 console support. This example was well very illustrated using real life, every day situations by my friend and distinguished colleague from the great state of New York. I will yield him the remainder of my time.. :-) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
No. Master console *was* a thing from MCS world. During NIP there weren't master console - just console, only one. And there was (and still is) an order which console will be used from devices available. First on the list taken (if available), but it has nothing to do with master. Nowadays there is no master console in MCS even. -- Radoslaw Skorupka Lodz, Poland W dniu 2013-10-23 22:11, efinnell15 pisze: It used to be that if the Master was unavailable, the first interrupt from a defined consol became the Master.(Meatball hoagie in tape shop taught us this). In a message dated 10/23/13 14:36:28 Central Daylight Time, d10j...@us.ibm.com writes: If no valid NIP console has been found, we will use the system console (a.k.a. Opeating System Messages on the HMC) to IPL the system. -- 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.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Thanks. I am so used to being the _only_ person in our _very small_ shop who does IPLs that it never occurred that the person doing the IPL or shutdown would need a helper. Unfortunately, one of the other people here who will (1%) occasionally IPL tends to just punch it out if the shutdown doesn't complete in a reasonable time. Which I why I prefer to do the IPLs. On Wed, Oct 23, 2013 at 5:19 PM, Thomas Conley pinnc...@rochester.rr.comwrote: On 10/23/2013 3:47 PM, John McKown wrote: Curiosity question: Why do you need multiple remote I3270C sessions per LPAR? If we ever go to z/OS 2.1 (iffy), we would only use it for IPLing. We use SMCS consoles via TN3270 for other consoles, beyond the Visara ones in the NOC (computer room adjunct). We often have multiple people looking at the console messages via the Java app on the HMC, especially when we're having a problem shutting down a system after TSO is gone or starting a system up before TSO is available. My good friend the distinguished gentleman from California is correct, this is a serious shortcoming in the Integrated 3270 console support. Regards, Tom Conley --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
On Wed, 23 Oct 2013 21:54:54 -0500, John McDowell jmcd...@gmail.com wrote: I agree that the inability to share the Integrated 3270 among multiple concurrent sessions is unfortunate and that it would be a useful enhancement to list that restriction. Off the top of my head I can see that the ownership of the keyboard will need to be resolved in some way, that is only one session should be allowed to provide keyboard inputs (i.e. cursor movement, attention keys, etc.). Otherwise each session could be fighting with the other about what is being done :-( I don't think this problem is insurmountable and in fact I can think of a couple of different design approaches that could be used to solve it. Anyone who has used one of the Windows based conferencing tools has seen how this can be resolved. I run into that sometimes now with fellow sysprogs (usually not operations) when IPLing LPARs during a maintenance window. Not a huge deal. We either see two people are entering keystrokes or it ends up as an invalid command / reply if someone hits the enter key before we notice. The shared consoles are via CA Automation Point, but also use AF Remote for this. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
As long as you accept a complete line at a time, like multiple SDSF operator sessions, it should work, unless two people happen to issue the same command and it causes problems. On Thu, Oct 24, 2013 at 11:28 AM, John McDowell jmcd...@gmail.com wrote: Mark, I understand what you are saying, the unintentional interleaving of multiple user inputs, is something you can accept/overcome. This is one possible resolution of allowing multiple concurrent uses of the Integrated 3270, I personally favor a model of one writer/multiple readers such is often employed in the various screen sharing technologies found in many conferencing solutions. (Note: I'm guessing the specific examples you offer are not for the Integrated 3270 but your essential point remains the same.) The only question in my mind is how sophisticated a mechanism is needed to pass the baton (e.g. become the one writer). My initial thought is to keep it simple, the first session is the writer, all subsequent sessions are readers, the current writer can pass the baton to any reader. If there is no inter-session awareness then the writer can simply lay down the baton (e.g. surrender the write privilege) and any reader can then pick it up. I'm sure there are other models that could be adopted but the key point that I think we all agree on is that lifting the current restriction that prevents multiple concurrent accessors of the Integrated 3270 is very desirable. John McDowell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
On 10/22/2013 11:06 PM, nitz-...@gmx.net wrote: This kind of error rarely gets mentioned on IBM-MAIN because SAD of early IPL failure is super fast and IPCS takes only seconds to init such a dump. The problems are usually fixed immediately and folks move on to more challenging issues. I agree completely. But if there isn't someone forceful around that insists on taking the sadump, in many installations the knowledge how to read a dump, much less an sadump is a lost art. So sadumps don't get taken because there's nobody there who knows how to read it. That is SAD. ;-) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
IBM is able to read them. They might request the SA dump if you report the problem and you will be glad you took it. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of nitz-...@gmx.net Sent: Wednesday, October 23, 2013 08:06 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue This kind of error rarely gets mentioned on IBM-MAIN because SAD of early IPL failure is super fast and IPCS takes only seconds to init such a dump. The problems are usually fixed immediately and folks move on to more challenging issues. I agree completely. But if there isn't someone forceful around that insists on taking the sadump, in many installations the knowledge how to read a dump, much less an sadump is a lost art. So sadumps don't get taken because there's nobody there who knows how to read it. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
One of the areas in the SAD is the NIP console. You can see all of the NIP messages - similar to syslog - that occur at IPL time. These messages have been very helpful whenever I have had a problem during IPL and I did not have the HMC handy. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM Sent: Wednesday, October 23, 2013 12:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue IBM is able to read them. They might request the SA dump if you report the problem and you will be glad you took it. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of nitz-...@gmx.net Sent: Wednesday, October 23, 2013 08:06 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue This kind of error rarely gets mentioned on IBM-MAIN because SAD of early IPL failure is super fast and IPCS takes only seconds to init such a dump. The problems are usually fixed immediately and folks move on to more challenging issues. I agree completely. But if there isn't someone forceful around that insists on taking the sadump, in many installations the knowledge how to read a dump, much less an sadump is a lost art. So sadumps don't get taken because there's nobody there who knows how to read it. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
IBM is able to read them. They might request the SA dump if you report the problem and you will be glad you took it. I disagree. Sort of. The customer had asked IBM Why did the restart of SMSPDSE1 not complete? and the customer had given IBM an sadump. IBM support said that they cannot answer that question and that the customer should reproduce the problem and take another set of docs (not an sadump) that PDSE support is familiar with. The question Why did SMSPDSE1 restart not complete? was easily answerable from the sadump. The restart did not complete because there was unresolved contention on SYSIEFSD Q10. That ENQ was held in an authorized multitasking batch TSO address space that uses PDSE data sets. It had been held since *before* the SMSPDSE1 address space was terminated, and the customer had been fighting PDSE latch contention with the freelatch command for quite a while before Q10 got irrevocably held. So, yes, if you know what you're doing, a properly handled sadump will answer almost any question. Heavy emphasis on the 'if you know what you're doing'. I just don't think that many IBM support groups have a grasp on how to read a dump, much less an sadump. And many of those who have the mechanics of IPCS down have no knowledge how to interpret the clues that the sa/dump gives them. There are a few dinosaurs left who do, but when Ed Jaffe and I are among the 'youngsters' in that group - it speaks volumes for the platform. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
On Wed, 23 Oct 2013 08:06:20 +0200, nitz-...@gmx.net nitz-...@gmx.net wrote: in many installations the knowledge how to read a dump, much less an sadump is a lost art. So sadumps don't get taken because there's nobody there who knows how to read it. Barbara Exactly ties into the other thread referring to: John Dvorak explains.. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
The point was that the error was so severe that it caused a wait state and required a standalone dump for analysis. Typically, IPL should proceed at least to activate the console and place the message on the console. IPL did activate the console and place the message on the console. The OP might not have examined that info (because it might not have been convenient) In some console setups, as discussed by Skip Robinson and Jim Mulder, these messages can be viewed even after the wait state. In others they apparently cannot. What about the SAMPLIB SPPINST and SPPPACK ? According comments it is a kind of syntax checker. SPPPACK (via SPPINST) is a syntax checker for LOADxx primarily. And maybe GRSPRMxx, IIRC. Nothing else. It will let you view a member identified by an IEASYSxx parameter (with symbols resolved or not as you choose), but typically does no checking. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
In z/OS 2.1 support was added for the Integrated 3270 (i.e. a 3278-4 window on the HMC), it is supported both during NIP and as a normal system console. The Integrated 3270 must be activated on an LPAR by LPAR basis, if the activation is performed before the z/OS IPL then z/OS will find it and will prefer it. If you want to allow the use of it after NIP it needs to be defined in the CONSOLxx member. The Integrated 3270 is not channel attached and is therefore not subject to the clearing problem (resulting from the reset that Jim Mulder described) and as an added bonus (I believe it's true) that NIP will prefer the integrated 3270 over any NIP definition contained in the IODF. (I personally view this behavior is an advantage, if you asked for the Integrated 3270 (by activating it) then it should be used.) Note: I do not have access to a system to verify this preference in NIP. As an aside the Integrated 3270 is also virtualized in z/VM (Command: CP SET TERM SYS3270), unfortunately there is a similar loss of messages (caused by CP clearing the screen to display the wait state PSW) that will occur. Of course, when running under VM the simplest approach is to simply define your virtual machine CONSOLE at whatever (virtual) address is defined in your (IODF) NIP console list. The system reset that Jim Mulder described will not disturb the messages on your (virtual) NIP console :-) John McDowell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
In z/OS 2.1 support was added for the Integrated 3270 (i.e. a 3278-4 window on the HMC), it is supported both during NIP and as a normal system console. The Integrated 3270 must be activated on an LPAR by LPAR basis, if the activation is performed before the z/ OS IPL then z/OS will find it and will prefer it. If you want to allow the use of it after NIP it needs to be defined in the CONSOLxx member. The Integrated 3270 is not channel attached and is therefore not subject to the clearing problem (resulting from the reset that Jim Mulder described) and as an added bonus (I believe it's true) that NIP will prefer the integrated 3270 over any NIP definition contained in the IODF. (I personally view this behavior is an advantage, if you asked for the Integrated 3270 (by activating it) then it should be used.) Note: I do not have access to a system to verify this preference in NIP. According the comments in the module which does NIP console selection in z/OS 2.1, the preference order is: Determine if the Integrated 3270 Console (a.k.a. the HMCS console which is on the HMC) is attached to our system. If so, we will use it to IPL the system. If no HMCS console, select the NIP console from the NIP Console Records (NCRs) in the IODF. Verify the consoles in the order that the NCRs exist in the IODF searching for the first valid console. If no valid NIP console has been found, we will use the system console (a.k.a. Opeating System Messages on the HMC) to IPL the system. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
On 10/23/2013 10:46 AM, John McDowell wrote: In z/OS 2.1 support was added for the Integrated 3270 (i.e. a 3278-4 window on the HMC), it is supported both during NIP and as a normal system console. The Integrated 3270 must be activated on an LPAR by LPAR basis, if the activation is performed before the z/OS IPL then z/OS will find it and will prefer it. If you want to allow the use of it after NIP it needs to be defined in the CONSOLxx member. The Integrated 3270 is not channel attached and is therefore not subject to the clearing problem (resulting from the reset that Jim Mulder described) and as an added bonus (I believe it's true) that NIP will prefer the integrated 3270 over any NIP definition contained in the IODF. (I personally view this behavior is an advantage, if you asked for the Integrated 3270 (by activating it) then it should be used.) Note: I do not have access to a system to verify this preference in NIP. I also like the 3270 Integrated Console. However, the current implementation is disadvantageous. Unlike the Operating System Messages notebook, a 3270 Integrated Console cannot be shared among multiple, remote HMC users. If one has it open, the others get an error message stating that only one I3270C is allowed per HMC, per LPAR. I submitted a SHARE Requirement to address this. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Curiosity question: Why do you need multiple remote I3270C sessions per LPAR? If we ever go to z/OS 2.1 (iffy), we would only use it for IPLing. We use SMCS consoles via TN3270 for other consoles, beyond the Visara ones in the NOC (computer room adjunct). On Wed, Oct 23, 2013 at 2:40 PM, Ed Jaffe edja...@phoenixsoftware.comwrote: On 10/23/2013 10:46 AM, John McDowell wrote: In z/OS 2.1 support was added for the Integrated 3270 (i.e. a 3278-4 window on the HMC), it is supported both during NIP and as a normal system console. The Integrated 3270 must be activated on an LPAR by LPAR basis, if the activation is performed before the z/OS IPL then z/OS will find it and will prefer it. If you want to allow the use of it after NIP it needs to be defined in the CONSOLxx member. The Integrated 3270 is not channel attached and is therefore not subject to the clearing problem (resulting from the reset that Jim Mulder described) and as an added bonus (I believe it's true) that NIP will prefer the integrated 3270 over any NIP definition contained in the IODF. (I personally view this behavior is an advantage, if you asked for the Integrated 3270 (by activating it) then it should be used.) Note: I do not have access to a system to verify this preference in NIP. I also like the 3270 Integrated Console. However, the current implementation is disadvantageous. Unlike the Operating System Messages notebook, a 3270 Integrated Console cannot be shared among multiple, remote HMC users. If one has it open, the others get an error message stating that only one I3270C is allowed per HMC, per LPAR. I submitted a SHARE Requirement to address this. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.**com/ http://www.phoenixsoftware.com/ --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
It used to be that if the Master was unavailable, the first interrupt from a defined consol became the Master.(Meatball hoagie in tape shop taught us this). In a message dated 10/23/13 14:36:28 Central Daylight Time, d10j...@us.ibm.com writes: If no valid NIP console has been found, we will use the system console (a.k.a. Opeating System Messages on the HMC) to IPL the system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
On 10/23/2013 3:47 PM, John McKown wrote: Curiosity question: Why do you need multiple remote I3270C sessions per LPAR? If we ever go to z/OS 2.1 (iffy), we would only use it for IPLing. We use SMCS consoles via TN3270 for other consoles, beyond the Visara ones in the NOC (computer room adjunct). We often have multiple people looking at the console messages via the Java app on the HMC, especially when we're having a problem shutting down a system after TSO is gone or starting a system up before TSO is available. My good friend the distinguished gentleman from California is correct, this is a serious shortcoming in the Integrated 3270 console support. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
I agree that the inability to share the Integrated 3270 among multiple concurrent sessions is unfortunate and that it would be a useful enhancement to list that restriction. Off the top of my head I can see that the ownership of the keyboard will need to be resolved in some way, that is only one session should be allowed to provide keyboard inputs (i.e. cursor movement, attention keys, etc.). Otherwise each session could be fighting with the other about what is being done :-( I don't think this problem is insurmountable and in fact I can think of a couple of different design approaches that could be used to solve it. Anyone who has used one of the Windows based conferencing tools has seen how this can be resolved. Irregardless of the aforementioned restriction the use case of an Operator/Sysprog performing an IPL and wanting to be able to see whatever messages might be produced without worrying about losing them (to a reset resulting from a disabled wait state being loaded) is best served by using the Integrated 3270. And because of the designed preference order (thank you Rick) that Jim Mulder has confirmed (thank you Jim) it is as simple as activating the Integrated 3270 before the Load (IPL) is performed. No need to change the IODF (to remove any NIP consoles), the presence (or absence) of NIP consoles in the IODF does not make any difference, the Integrated 3270 will be used (for NIP in z/OS 2.1) if it is active. Testing/backoff is simply a matter of acvtivating/deactivating (at the HMC) before you Load/IPL nothing else need be done, try it you'll like it :-) In the interest of full disclosure I will mention that there are some differences in the use of the Integrated 3270 as a result of the keyboard mapping. I don't remember the specific details (and I don't have access to a system to confirm them) but my memory is that certain 3270 keys (e..g Clear, PA1, PA2, etc.) not found on modern keyboards require multiple keyboard inputs. The good news is that for simple text input and the Enter key life is simple :-) and the other good news is those two functions (combined with the text display) is all you really need to effectively use a z/OS console (both during NIP and beyond) :-) John McDowell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
W dniu 2013-10-22 05:44, saurabh khandelwal pisze: Hello, Yes, I have specified CLPA in IEASYSxx . But as Radoslaw mentioned, I think comment line can not be part of LPALAT member . So , this could only be a issue. Excuse me: COULD BE??? Haven't you tested it yet? That's really simple: IPL with the syntax error in LPALST, and IPL without the error. BTW: I wish I had a syntax checker tool for evey parmlib (and IPLPARM) member, at least for some subset of them. That of course won't preclude all the mistakes - one can still put wrong libriaries or omit needed ones, etc. etc. But the syntax would be fine then. -- 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.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
The point was that the error was so severe that it caused a wait state and required a standalone dump for analysis. Typically, IPL should proceed at least to activate the console and place the message on the console. IBM tries to make the system at least somewhat viable even if it cannot provide full functionality. Wait state codes without messages are typically a last resort situation. SYS1.LPALIB was probably after the coding error which would have made critical LPA programs unavailable. Jon Perryman. From: saurabh khandelwal sourabhkhandelwal...@gmail.com Yes, I have specified CLPA in IEASYSxx . But as Radoslaw mentioned, I think comment line can not be part of LPALAT member . So , this could only be a issue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Which is what OA38328 is an attempt to resolve. Works just fine on LPALSTxx and other members which is what the OP could have used. While I certainly recommend this APAR, this APAR is not about providing a common syntax. It is about providing the capability of putting comments anywhere in the affected parmlib members that you want. Not limited to after the first space, on a line with other data; and after the last line that ends with a comma as was the case for many. As this was done as inexpensively as possible, it chose a very inexpensive approach that some other parmlib members already used (but far from all). For this set of members, it is common syntax. No herding of cats is forthcoming. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
What about nerf herders? --- rel...@us.ibm.com wrote: From: Peter Relson rel...@us.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue Date: Tue, 22 Oct 2013 07:50:32 -0400 Which is what OA38328 is an attempt to resolve. Works just fine on LPALSTxx and other members which is what the OP could have used. While I certainly recommend this APAR, this APAR is not about providing a common syntax. It is about providing the capability of putting comments anywhere in the affected parmlib members that you want. Not limited to after the first space, on a line with other data; and after the last line that ends with a comma as was the case for many. As this was done as inexpensively as possible, it chose a very inexpensive approach that some other parmlib members already used (but far from all). For this set of members, it is common syntax. No herding of cats is forthcoming. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Hello R.S. , Yes, comment line was only issue for this problem. It would be really great to see,if any tool can help on syntax checker for parmlib member. Regards Saurabh On Tue, Oct 22, 2013 at 11:53 AM, R.S. r.skoru...@bremultibank.com.plwrote: W dniu 2013-10-22 05:44, saurabh khandelwal pisze: Hello, Yes, I have specified CLPA in IEASYSxx . But as Radoslaw mentioned, I think comment line can not be part of LPALAT member . So , this could only be a issue. Excuse me: COULD BE??? Haven't you tested it yet? That's really simple: IPL with the syntax error in LPALST, and IPL without the error. BTW: I wish I had a syntax checker tool for evey parmlib (and IPLPARM) member, at least for some subset of them. That of course won't preclude all the mistakes - one can still put wrong libriaries or omit needed ones, etc. etc. But the syntax would be fine then. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s u bowego adresata. Odbiorc mo e by jedynie jej adresat z wy czeniem dost pu osób trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma e t wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy aj c odpowied oraz trwale usun t wiadomo w czaj c 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 S d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP: 526-021-50-88. Wed ug stanu na dzie 01.01.2013 r. kapita zak adowy BRE Banku SA (w ca o ci wp acony) wynosi 168.555.904 z otych. --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
WIth a syntax error such as the one shown by the OP, there would have been an IPL-time message such as: IEA712I LPALST LIBRARY DATA SETS IGNORED /*-UNABLE TO LOCATE As to why it blew up, it was likely because one of the data sets later in the LPALSTxx definition was also therefore not included (this line was treated as the end of input because it had no trailing comma after the initial token which was the /*) and some later processing needed a module in one of the not-included data sets. FWIW, I would think that not very many things would treat /* SYS1.CICS41.SDFHLPA, as a valid comment since it does not have the traiilng */. Of course LPALSTxx wouldn't treat it as a valid comment even with the trailing */. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
On 10/21/2013 11:37 PM, Jon Perryman wrote: The point was that the error was so severe that it caused a wait state and required a standalone dump for analysis. Typically, IPL should proceed at least to activate the console and place the message on the console. IBM tries to make the system at least somewhat viable even if it cannot provide full functionality. Wait state codes without messages are typically a last resort situation. This kind of error rarely gets mentioned on IBM-MAIN because SAD of early IPL failure is super fast and IPCS takes only seconds to init such a dump. The problems are usually fixed immediately and folks move on to more challenging issues. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
What about the SAMPLIB SPPINST and SPPPACK ? According comments it is a kind of syntax checker. On 22.10.2013 15:22, Peter Relson wrote: WIth a syntax error such as the one shown by the OP, there would have been an IPL-time message such as: IEA712I LPALST LIBRARY DATA SETS IGNORED /*-UNABLE TO LOCATE As to why it blew up, it was likely because one of the data sets later in the LPALSTxx definition was also therefore not included (this line was treated as the end of input because it had no trailing comma after the initial token which was the /*) and some later processing needed a module in one of the not-included data sets. FWIW, I would think that not very many things would treat /* SYS1.CICS41.SDFHLPA, as a valid comment since it does not have the traiilng */. Of course LPALSTxx wouldn't treat it as a valid comment even with the trailing */. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
I believe we've discussed the 'NIP message' problem before. While a very useful message may well be displayed on the IPL-time console, in many (most?) cases it disappears instantly when the machine enters wait state. It's gone so fast that any detail is pretty much indecipherable. While SAD with IPCS is truly much more usable than it used to be, it's still a far cry from getting an operator to read you a message in an oh-dark-thirty phone call. It was discussed on Fri, 18 May 2012 01:43:56 -0400 https://listserv.ua.edu/cgi-bin/wa?A2=ind1205L=IBM-MAINP=R49539I=-3X=-Y=d10jhm1%40us.ibm.comd=No+Match%3BMatch%3BMatches I'll stick with what I said in that discussion - use Operating System Messages on the HMC as your NIP console. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
I confess that I have not tested this maneuver. Doesn't the OSM screen close as soon as the operating system stops? Maybe not. In any case, I do know this from experience: if the customer has configured any NIP console to an OSA device, NIP messages will go only to that device and not to the HMC at all. If a wait state occurs as discussed here, the OSA device will go blank as previously asserted. The only way to direct NIP messages to the OSM is to force offline (via HMC) the chpid that supports the OSA device in the IODF. Afterwards the chpid must be put back online in order to restore the operational environment. Speaking from experience, this is all doable with considerable care and effort. We're just in search of a simpler procedure, preferably one that can be dictated over the phone to the earnest individual who drew short straw for the night shift. Again. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Jim Mulder d10j...@us.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 10/22/2013 07:44 PM Subject:Re: z/OS IPL Issue Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU I believe we've discussed the 'NIP message' problem before. While a very useful message may well be displayed on the IPL-time console, in many (most?) cases it disappears instantly when the machine enters wait state. It's gone so fast that any detail is pretty much indecipherable. While SAD with IPCS is truly much more usable than it used to be, it's still a far cry from getting an operator to read you a message in an oh-dark-thirty phone call. It was discussed on Fri, 18 May 2012 01:43:56 -0400 https://listserv.ua.edu/cgi-bin/wa?A2=ind1205L=IBM-MAINP=R49539I=-3X=-Y=d10jhm1%40us.ibm.comd=No+Match%3BMatch%3BMatches I'll stick with what I said in that discussion - use Operating System Messages on the HMC as your NIP console. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
I confess that I have not tested this maneuver. Doesn't the OSM screen close as soon as the operating system stops? Maybe not. System Reset Normal does not close or clear Operating System Messages. In any case, I do know this from experience: if the customer has configured any NIP console to an OSA device, NIP messages will go only to that device and not to the HMC at all. If a wait state occurs as discussed here, the OSA device will go blank as previously asserted. The only way to direct NIP messages to the OSM is to force offline (via HMC) the chpid that supports the OSA device in the IODF. Afterwards the chpid must be put back online in order to restore the operational environment. z/OS always selects one and only one NIP console, which is either the first available device in the list that is specified as NIP consoles in your IODF, or Operating System Messages on the HMC. I recommend that you do not define any devices as NIP consoles in your IODF. Then Operating System Messages will always be used as the NIP console. This does not prevent you from defining an OSA device as a console in CONSOLxx, and thus using it as an MCS console. If you really want to use an OSA device as your NIP console most of the time, and OSM only for second-failure data capture, you could maintain 2 IODFs which are identical, except that one has the OSA device specified as a NIP console, and the other does not. Then your operator would only need to change the IODF specification in the Load Parameter in order to use OSM as the NIP console, which might be an easier operational procedure than forcing the OSA chpid (at the expense of the extra system programmer task of keeping 2 almost identical IODFs in synch). Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Hello, In my LPALST member, while adding dataset for CICS 5.1 , rather then removing entry for older CICS 4.2, I simply commented CICS 4.2 dataset line like below. /* SYS1.CICS41.SDFHLPA, And added CICS 5.1 dataset SYS1.CICS51.SDFHLPA. I think, this is only reason for this 064 wait code. But at last problem resolved. Thanks for all help. Regards Saurabh On Sun, Oct 20, 2013 at 6:30 PM, Peter Relson rel...@us.ibm.com wrote: Problem has been resolved. The issue was with syntax issue in LPALST parmlib member . Can you please explain exactly what the issue was? A syntax error in LPALST will not ordinarily result in a program check WAIT 064 unless it meant that your LPALST did not have a data set that the system requires during IPL. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
W dniu 2013-10-21 11:55, saurabh khandelwal pisze: Hello, In my LPALST member, while adding dataset for CICS 5.1 , rather then removing entry for older CICS 4.2, I simply commented CICS 4.2 dataset line like below. /* SYS1.CICS41.SDFHLPA, And added CICS 5.1 dataset SYS1.CICS51.SDFHLPA. I think, this is only reason for this 064 wait code. But at last problem resolved. Thanks for all help. The problem is not CICS 5.1 or any other version, you just made syntax error. The comment you used is not applicable to LPALST member. -- 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.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Hello, Was CLPA specified in IEASYSxx when you IPL'd first time ? .If not , that could lead to a wait 064 If not , I am wondering how you got a wait 064 for syntax error in LPALSTxx . On Monday, October 21, 2013 3:25 PM, saurabh khandelwal sourabhkhandelwal...@gmail.com wrote: Hello, In my LPALST member, while adding dataset for CICS 5.1 , rather then removing entry for older CICS 4.2, I simply commented CICS 4.2 dataset line like below. /* SYS1.CICS41.SDFHLPA, And added CICS 5.1 dataset SYS1.CICS51.SDFHLPA. I think, this is only reason for this 064 wait code. But at last problem resolved. Thanks for all help. Regards Saurabh On Sun, Oct 20, 2013 at 6:30 PM, Peter Relson rel...@us.ibm.com wrote: Problem has been resolved. The issue was with syntax issue in LPALST parmlib member . Can you please explain exactly what the issue was? A syntax error in LPALST will not ordinarily result in a program check WAIT 064 unless it meant that your LPALST did not have a data set that the system requires during IPL. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
As you have seen, the syntax rules for LPALST and comments do not follow other comment functions. This is probably due to where it is loaded and the process has a very strict syntax for the process. So depending on where you put your /* you could have lost many datasets that were to be loaded by LPALSTxx. From the Manual Syntax rules for LPALSTxx z/OS V1R12.0 MVS Initialization and Tuning Reference SA22-7592-21 The following rules apply to the creation of LPALSTxx: Comments: On a line, data entered after the last data set name and the optional comma continuation character is treated as a comment and ignored. A /* is not a recognized comment line in the LPALSTxx member. But you could do NAME1, NAME2, NAME3 this ends the list, anything that follows is a comment. Comments follow here. My two cents worth - IBM could clarify the comment process in LPALSTxx a bit better as well as provide a nice sample of how to place comments in LPALSTxx. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of saurabh khandelwal Sent: Monday, October 21, 2013 2:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue Hello, In my LPALST member, while adding dataset for CICS 5.1 , rather then removing entry for older CICS 4.2, I simply commented CICS 4.2 dataset line like below. /* SYS1.CICS41.SDFHLPA, And added CICS 5.1 dataset SYS1.CICS51.SDFHLPA. I think, this is only reason for this 064 wait code. But at last problem resolved. Thanks for all help. Regards Saurabh On Sun, Oct 20, 2013 at 6:30 PM, Peter Relson rel...@us.ibm.com wrote: Problem has been resolved. The issue was with syntax issue in LPALST parmlib member . Can you please explain exactly what the issue was? A syntax error in LPALST will not ordinarily result in a program check WAIT 064 unless it meant that your LPALST did not have a data set that the system requires during IPL. Peter Relson z/OS Core Technology Design -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Just one comment, When I run into these types of issues, I usually add a comment to that member with a warning on how to code things. You might want to consider adding comments at the end of this member explaining how to comment out a line. It may save you or someone else in the future - how to avoid any confusion on comments and 064 Wait states. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, October 21, 2013 6:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue As you have seen, the syntax rules for LPALST and comments do not follow other comment functions. This is probably due to where it is loaded and the process has a very strict syntax for the process. So depending on where you put your /* you could have lost many datasets that were to be loaded by LPALSTxx. From the Manual Syntax rules for LPALSTxx z/OS V1R12.0 MVS Initialization and Tuning Reference SA22-7592-21 The following rules apply to the creation of LPALSTxx: Comments: On a line, data entered after the last data set name and the optional comma continuation character is treated as a comment and ignored. A /* is not a recognized comment line in the LPALSTxx member. But you could do NAME1, NAME2, NAME3 this ends the list, anything that follows is a comment. Comments follow here. My two cents worth - IBM could clarify the comment process in LPALSTxx a bit better as well as provide a nice sample of how to place comments in LPALSTxx. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of saurabh khandelwal Sent: Monday, October 21, 2013 2:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue Hello, In my LPALST member, while adding dataset for CICS 5.1 , rather then removing entry for older CICS 4.2, I simply commented CICS 4.2 dataset line like below. /* SYS1.CICS41.SDFHLPA, And added CICS 5.1 dataset SYS1.CICS51.SDFHLPA. I think, this is only reason for this 064 wait code. But at last problem resolved. Thanks for all help. Regards Saurabh On Sun, Oct 20, 2013 at 6:30 PM, Peter Relson rel...@us.ibm.com wrote: Problem has been resolved. The issue was with syntax issue in LPALST parmlib member . Can you please explain exactly what the issue was? A syntax error in LPALST will not ordinarily result in a program check WAIT 064 unless it meant that your LPALST did not have a data set that the system requires during IPL. Peter Relson z/OS Core Technology Design -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Lizette, Apology If my thoughts are different. Does the wait state 064 really has to do anything with the wrong syntax ? On Mon, Oct 21, 2013 at 6:52 PM, Lizette Koehler stars...@mindspring.comwrote: Just one comment, When I run into these types of issues, I usually add a comment to that member with a warning on how to code things. You might want to consider adding comments at the end of this member explaining how to comment out a line. It may save you or someone else in the future - how to avoid any confusion on comments and 064 Wait states. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, October 21, 2013 6:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue As you have seen, the syntax rules for LPALST and comments do not follow other comment functions. This is probably due to where it is loaded and the process has a very strict syntax for the process. So depending on where you put your /* you could have lost many datasets that were to be loaded by LPALSTxx. From the Manual Syntax rules for LPALSTxx z/OS V1R12.0 MVS Initialization and Tuning Reference SA22-7592-21 The following rules apply to the creation of LPALSTxx: Comments: On a line, data entered after the last data set name and the optional comma continuation character is treated as a comment and ignored. A /* is not a recognized comment line in the LPALSTxx member. But you could do NAME1, NAME2, NAME3 this ends the list, anything that follows is a comment. Comments follow here. My two cents worth - IBM could clarify the comment process in LPALSTxx a bit better as well as provide a nice sample of how to place comments in LPALSTxx. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of saurabh khandelwal Sent: Monday, October 21, 2013 2:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue Hello, In my LPALST member, while adding dataset for CICS 5.1 , rather then removing entry for older CICS 4.2, I simply commented CICS 4.2 dataset line like below. /* SYS1.CICS41.SDFHLPA, And added CICS 5.1 dataset SYS1.CICS51.SDFHLPA. I think, this is only reason for this 064 wait code. But at last problem resolved. Thanks for all help. Regards Saurabh On Sun, Oct 20, 2013 at 6:30 PM, Peter Relson rel...@us.ibm.com wrote: Problem has been resolved. The issue was with syntax issue in LPALST parmlib member . Can you please explain exactly what the issue was? A syntax error in LPALST will not ordinarily result in a program check WAIT 064 unless it meant that your LPALST did not have a data set that the system requires during IPL. Peter Relson z/OS Core Technology Design -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
My favorite hot button is itching...The underlying problem here is one I've trotted out during several user sessions at SHARE: the various members of SYS1.PARMLIB are managed by the various development groups that own them. We as customers tend to view PARMLIB as a single entity. It actually consists of many entities packaged together in a single PDS. While there is some commonality, a syntactic structure (thank you, Noam Chomsky) that's legal in one member will get disastrous results in another. My favorite whassup is the so-called embedded comment: /* PARM123 /* Set system value /* Parm no longer used but left here for reference */ This seemingly innocuous historical note will work fine in some places, but if found in IEASYMxx, NIP will issue a WTOR demanding respecification. In order to subject all PARMLIB members to a single set of syntactic rules, all participating development cats would have to be herded into a one big room with no windows and all doors locked. Even I would not want the job of herder-in-charge. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 10/21/2013 07:53 AM Subject:Re: z/OS IPL Issue Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Only if the data set that was missing was really needed. Not sure what the OP list looked like or what might have followed the incorrect comment card. So, best guess is there was something important. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Monday, October 21, 2013 7:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue Lizette, Apology If my thoughts are different. Does the wait state 064 really has to do anything with the wrong syntax ? On Mon, Oct 21, 2013 at 6:52 PM, Lizette Koehler stars...@mindspring.comwrote: Just one comment, When I run into these types of issues, I usually add a comment to that member with a warning on how to code things. You might want to consider adding comments at the end of this member explaining how to comment out a line. It may save you or someone else in the future - how to avoid any confusion on comments and 064 Wait states. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, October 21, 2013 6:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue As you have seen, the syntax rules for LPALST and comments do not follow other comment functions. This is probably due to where it is loaded and the process has a very strict syntax for the process. So depending on where you put your /* you could have lost many datasets that were to be loaded by LPALSTxx. From the Manual Syntax rules for LPALSTxx z/OS V1R12.0 MVS Initialization and Tuning Reference SA22-7592-21 The following rules apply to the creation of LPALSTxx: Comments: On a line, data entered after the last data set name and the optional comma continuation character is treated as a comment and ignored. A /* is not a recognized comment line in the LPALSTxx member. But you could do NAME1, NAME2, NAME3 this ends the list, anything that follows is a comment. Comments follow here. My two cents worth - IBM could clarify the comment process in LPALSTxx a bit better as well as provide a nice sample of how to place comments in LPALSTxx. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of saurabh khandelwal Sent: Monday, October 21, 2013 2:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue Hello, In my LPALST member, while adding dataset for CICS 5.1 , rather then removing entry for older CICS 4.2, I simply commented CICS 4.2 dataset line like below. /* SYS1.CICS41.SDFHLPA, And added CICS 5.1 dataset SYS1.CICS51.SDFHLPA. I think, this is only reason for this 064 wait code. But at last problem resolved. Thanks for all help. Regards Saurabh On Sun, Oct 20, 2013 at 6:30 PM, Peter Relson rel...@us.ibm.com wrote: Problem has been resolved. The issue was with syntax issue in LPALST parmlib member . Can you please explain exactly what the issue was? A syntax error in LPALST will not ordinarily result in a program check WAIT 064 unless it meant that your LPALST did not have a data set that the system requires during IPL. Peter
Re: z/OS IPL Issue
Everybody chant: XML! XML! XML! Ouch, don't hit! grin/. On Mon, Oct 21, 2013 at 11:24 AM, Skip Robinson jo.skip.robin...@sce.comwrote: My favorite hot button is itching...The underlying problem here is one I've trotted out during several user sessions at SHARE: the various members of SYS1.PARMLIB are managed by the various development groups that own them. We as customers tend to view PARMLIB as a single entity. It actually consists of many entities packaged together in a single PDS. While there is some commonality, a syntactic structure (thank you, Noam Chomsky) that's legal in one member will get disastrous results in another. My favorite whassup is the so-called embedded comment: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
On Oct 21, 2013, at 11:24 AM, Skip Robinson wrote: --SNIP In order to subject all PARMLIB members to a single set of syntactic rules, all participating development cats would have to be herded into a one big room with no windows and all doors locked. Even I would not want the job of herder-in-charge. . .Skip: Bet Peter could do it:) Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Thank to Dennis Trojak for this headsup. OA38328 is now on my to-do list. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Dennis Trojak dennis.tro...@radioshack.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 10/21/2013 11:15 AM Subject:Re: z/OS IPL Issue Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Which is what OA38328 is an attempt to resolve. Works just fine on LPALSTxx and other members which is what the OP could have used. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Monday, October 21, 2013 11:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue My favorite hot button is itching...The underlying problem here is one I've trotted out during several user sessions at SHARE: the various members of SYS1.PARMLIB are managed by the various development groups that own them. We as customers tend to view PARMLIB as a single entity. It actually consists of many entities packaged together in a single PDS. While there is some commonality, a syntactic structure (thank you, Noam Chomsky) that's legal in one member will get disastrous results in another. My favorite whassup is the so-called embedded comment: /* PARM123 /* Set system value /* Parm no longer used but left here for reference */ This seemingly innocuous historical note will work fine in some places, but if found in IEASYMxx, NIP will issue a WTOR demanding respecification. In order to subject all PARMLIB members to a single set of syntactic rules, all participating development cats would have to be herded into a one big room with no windows and all doors locked. Even I would not want the job of herder-in-charge. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 10/21/2013 07:53 AM Subject:Re: z/OS IPL Issue Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Only if the data set that was missing was really needed. Not sure what the OP list looked like or what might have followed the incorrect comment card. So, best guess is there was something important. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Monday, October 21, 2013 7:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue Lizette, Apology If my thoughts are different. Does the wait state 064 really has to do anything with the wrong syntax ? On Mon, Oct 21, 2013 at 6:52 PM, Lizette Koehler stars...@mindspring.comwrote: Just one comment, When I run into these types of issues, I usually add a comment to that member with a warning on how to code things. You might want to consider adding comments at the end of this member explaining how to comment out a line. It may save you or someone else in the future - how to avoid any confusion on comments and 064 Wait states. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, October 21, 2013 6:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue As you have seen, the syntax rules for LPALST and comments do not follow other comment functions. This is probably due to where it is loaded and the process has a very strict syntax for the process. So depending on where you put your /* you could have lost many datasets that were to be loaded by LPALSTxx. From the Manual Syntax rules for LPALSTxx z/OS V1R12.0 MVS Initialization and Tuning Reference SA22-7592-21 The following rules apply to the creation of LPALSTxx: Comments: On a line, data entered after the last data set name and the optional comma continuation character is treated as a comment and ignored. A /* is not a recognized comment line in the LPALSTxx member. But you could do NAME1, NAME2, NAME3 this ends the list, anything that follows is a comment. Comments follow here. My two cents worth - IBM could clarify the comment process in LPALSTxx a bit better as well as provide a nice sample of how to place comments in LPALSTxx. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of saurabh khandelwal Sent: Monday, October 21, 2013 2:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS IPL Issue Hello, In my LPALST member, while adding
Re: z/OS IPL Issue
Hello, Yes, I have specified CLPA in IEASYSxx . But as Radoslaw mentioned, I think comment line can not be part of LPALAT member . So , this could only be a issue. Regards Saurabh On Mon, Oct 21, 2013 at 4:24 PM, Roger Steyn roger.st...@yahoo.com wrote: Hello, Was CLPA specified in IEASYSxx when you IPL'd first time ? .If not , that could lead to a wait 064 If not , I am wondering how you got a wait 064 for syntax error in LPALSTxx . On Monday, October 21, 2013 3:25 PM, saurabh khandelwal sourabhkhandelwal...@gmail.com wrote: Hello, In my LPALST member, while adding dataset for CICS 5.1 , rather then removing entry for older CICS 4.2, I simply commented CICS 4.2 dataset line like below. /* SYS1.CICS41.SDFHLPA, And added CICS 5.1 dataset SYS1.CICS51.SDFHLPA. I think, this is only reason for this 064 wait code. But at last problem resolved. Thanks for all help. Regards Saurabh On Sun, Oct 20, 2013 at 6:30 PM, Peter Relson rel...@us.ibm.com wrote: Problem has been resolved. The issue was with syntax issue in LPALST parmlib member . Can you please explain exactly what the issue was? A syntax error in LPALST will not ordinarily result in a program check WAIT 064 unless it meant that your LPALST did not have a data set that the system requires during IPL. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Problem has been resolved. The issue was with syntax issue in LPALST parmlib member . Can you please explain exactly what the issue was? A syntax error in LPALST will not ordinarily result in a program check WAIT 064 unless it meant that your LPALST did not have a data set that the system requires during IPL. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
As Ed pointed out, you can't see the message as it is in the WSMA , but you need the IEA304W message. You can take a standalone dump or use the HMC alter/display to find CVT pointer, CVTWSMA, and WSMA see MVS Data Area (for me volume 5) On 19.10.2013 07:53, saurabh khandelwal wrote: Hello, I had checked for this IEA304W this message but, I couldn't find it . The message I am getting on HMC hardware message is Central processor (CP) 0 is in a nonrestartable stopped state due to a System Control Program (SCP) initiated reset of the I/O interface for partition PROD01. The disabled wait program status word (PSW) is 000280009064. When I am trying to load LPAR, I am getting success message but after that I don't get to see anything on operating system message scree and LPAR color become RED. Does it mean that operating system is able to load successfully in the initial level but after that because of memory its crashing. I don't have INITSQA entry in my LOADXX member but in IEASYS member we have specified SQA=(1792K,50M).. Do I need to make INITSQA entry in LOADXX member to solve this issue, If yes, then how much I need to specify. Please suggest. Regards Saurabh On Sat, Oct 19, 2013 at 11:15 AM, Ed Jaffe edja...@phoenixsoftware.comwrote: On 10/18/2013 10:15 PM, saurabh khandelwal wrote: But while loading LPAR from HMC, I get success message on load screen but I don't see anything in operating system message screen . When I tried checking Hardware message, I have got below PSW code there 0002800090**64. I am not getting any clue to solve this issue. Kindly advise . z/OS MVS System Codes A program check occurred. Accompanying message IEA304W further explains this wait state and entry code. If the message does not appear on the console, you can find the message in the wait state message area (WSMA). /z/OS MVS System Codes -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.**com/ http://www.phoenixsoftware.com/ --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
On Fri, 18 Oct 2013 23:38:27 -0700, Ed Jaffe edja...@phoenixsoftware.com wrote: On 10/18/2013 10:53 PM, saurabh khandelwal wrote: Does it mean that operating system is able to load successfully in the initial level but after that because of memory its crashing. Yes. SAD is your friend... One thing you can look at before the SAD is do you specify a nuclst. In ours we have a Cics Module (we are CICS 4.2) for DFHHPSVC meaning that we have to find that CICS module in SYS1.NUCLEUS. Maybe this has changed for CICS 5.1 ? Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Hello All, Problem has been resolved. The issue was with syntax issue in LPALST parmlib member . I corrected that syntax and re IPL'd system again. Thanks for all help. Regards Saurabh On Sat, Oct 19, 2013 at 5:21 PM, Doug Henry doug_he...@usbank.com wrote: On Fri, 18 Oct 2013 23:38:27 -0700, Ed Jaffe edja...@phoenixsoftware.com wrote: On 10/18/2013 10:53 PM, saurabh khandelwal wrote: Does it mean that operating system is able to load successfully in the initial level but after that because of memory its crashing. Yes. SAD is your friend... One thing you can look at before the SAD is do you specify a nuclst. In ours we have a Cics Module (we are CICS 4.2) for DFHHPSVC meaning that we have to find that CICS module in SYS1.NUCLEUS. Maybe this has changed for CICS 5.1 ? Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Glad it worked out for you. What was the diagnostic that told you this? IEHIBALL? :-) Or the message that was suggested? Or something else? Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: saurabh khandelwal sourabhkhandelwal...@gmail.com To: IBM-MAIN@listserv.ua.edu Date: 19/10/2013 17:02 Subject:Re: z/OS IPL Issue Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Hello All, Problem has been resolved. The issue was with syntax issue in LPALST parmlib member . I corrected that syntax and re IPL'd system again. Thanks for all help. Regards Saurabh On Sat, Oct 19, 2013 at 5:21 PM, Doug Henry doug_he...@usbank.com wrote: On Fri, 18 Oct 2013 23:38:27 -0700, Ed Jaffe edja...@phoenixsoftware.com wrote: On 10/18/2013 10:53 PM, saurabh khandelwal wrote: Does it mean that operating system is able to load successfully in the initial level but after that because of memory its crashing. Yes. SAD is your friend... One thing you can look at before the SAD is do you specify a nuclst. In ours we have a Cics Module (we are CICS 4.2) for DFHHPSVC meaning that we have to find that CICS module in SYS1.NUCLEUS. Maybe this has changed for CICS 5.1 ? Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
On 19 October 2013 01:53, saurabh khandelwal sourabhkhandelwal...@gmail.com wrote: I had checked for this IEA304W this message but, I couldn't find it . What do you mean by I couldn't find it? You don't know how to display it, or you just didn't see it already displayed anywhere, or...? The message I am getting on HMC hardware message is Central processor (CP) 0 is in a nonrestartable stopped state due to a System Control Program (SCP) initiated reset of the I/O interface for partition PROD01. The disabled wait program status word (PSW) is 000280009064. Sure - you already reported the wait state code. When I am trying to load LPAR, I am getting success message but after that I don't get to see anything on operating system message scree and LPAR color become RED. Yes - the OS has loaded a disabled wait PSW. It isn't going to restart itself. You do understand what a disabled wait means? Does it mean that operating system is able to load successfully in the initial level but after that because of memory its crashing. Why are you thinking this has something to do with memory? Is there any evidence for this, or is it just something you feel is a good guess? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
On 10/18/2013 10:15 PM, saurabh khandelwal wrote: But while loading LPAR from HMC, I get success message on load screen but I don't see anything in operating system message screen . When I tried checking Hardware message, I have got below PSW code there 000280009064. I am not getting any clue to solve this issue. Kindly advise . z/OS MVS System Codes A program check occurred. Accompanying message IEA304W further explains this wait state and entry code. If the message does not appear on the console, you can find the message in the wait state message area (WSMA). /z/OS MVS System Codes -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
Hello, I had checked for this IEA304W this message but, I couldn't find it . The message I am getting on HMC hardware message is Central processor (CP) 0 is in a nonrestartable stopped state due to a System Control Program (SCP) initiated reset of the I/O interface for partition PROD01. The disabled wait program status word (PSW) is 000280009064. When I am trying to load LPAR, I am getting success message but after that I don't get to see anything on operating system message scree and LPAR color become RED. Does it mean that operating system is able to load successfully in the initial level but after that because of memory its crashing. I don't have INITSQA entry in my LOADXX member but in IEASYS member we have specified SQA=(1792K,50M).. Do I need to make INITSQA entry in LOADXX member to solve this issue, If yes, then how much I need to specify. Please suggest. Regards Saurabh On Sat, Oct 19, 2013 at 11:15 AM, Ed Jaffe edja...@phoenixsoftware.comwrote: On 10/18/2013 10:15 PM, saurabh khandelwal wrote: But while loading LPAR from HMC, I get success message on load screen but I don't see anything in operating system message screen . When I tried checking Hardware message, I have got below PSW code there 0002800090**64. I am not getting any clue to solve this issue. Kindly advise . z/OS MVS System Codes A program check occurred. Accompanying message IEA304W further explains this wait state and entry code. If the message does not appear on the console, you can find the message in the wait state message area (WSMA). /z/OS MVS System Codes -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.**com/ http://www.phoenixsoftware.com/ --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
