Re: SUPERC allocation errors z/OS V1.8 - fix
From Shmuel Metz: Did he specify a member name or just a bare PDS name? If the former then I'd suggestopening a PMR; if the latter then I would say tha There is an ETR and IBM has recreated the problem. Yes, there was a member name. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SUPERC allocation errors z/OS V1.8 - fix
In [EMAIL PROTECTED], on 02/15/2007 at 01:46 PM, Veilleux, Jon L [EMAIL PROTECTED] said: We ran into an interesting situation with z/OS V1.8. One of our folks uses a PDS for his listing dataset in ISPF 3.12 and 3.14. This stopped working when we upgraded to z/OS V1.8. After hitting enter we got: Listing not generated. When we hit PF1 for more information we received: Abnormal completion (RC=25). Existing list DS attribute conflict. Did he specify a member name or just a bare PDS name? If the former then I'd suggest opening a PMR; if the latter then I would say that ISPF is working properly. Is it possible that IBM changed the DCB attributes for the listing? That could also explain the message. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SUPERC allocation errors z/OS V1.8 - fix
In this case, you are probably dealing with a record length type of error. I've seen this in the past, where a PDS has a record length of 133, and the output was probably trying to use 121 for its length. Most likely someone in SUPERC development closed(?) a hole in code. In my opinion, B. A. D. now. On Thu, 15 Feb 2007 13:06:54 -0700, Paul Gilmartin [EMAIL PROTECTED] wrote: In a recent note, Mark Zelden said: Date: Thu, 15 Feb 2007 12:56:03 -0600 On Thu, 15 Feb 2007 13:46:08 -0500, Veilleux, Jon L [EMAIL PROTECTED] wrote: We ran into an interesting situation with z/OS V1.8. One of our folks uses a PDS for his listing dataset in ISPF 3.12 and 3.14. This stopped working when we upgraded to z/OS V1.8. After hitting enter we got: Listing not generated. When we hit PF1 for more information we received: Abnormal completion (RC=25). Existing list DS attribute conflict. Through some diligent tracing by our ISPF support guy we found that PTF UA31856 caused the problem. When we removed it all was well. Just thought I'd let everyone know. Thanks for letting us know. But I just checked and that PTF is not marked PE (at least not yet), so what you really need to do is open a PMR with IBM to find out if this is WAD or BAD. Is it documented anywhere that the listing data set can't be a PDS member? It has long been my experience that while SuperC has accepted HFS members as comparands, ironically it will not allow its output to be directed to an HFS member. I haven't reported this because of the highly likely WAD (IMO BAD). Now I'd better check (before and after UA31856) to see that IBM hasn't made this even worse. It's my impression that much of IBM treats HFS as a second-class citizen -- if it's broke they see little need to fix it -- they take APARs as SUG, etc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SUPERC allocation errors z/OS V1.8 - fix
In a recent note, Matthew Stitt said: Date: Fri, 16 Feb 2007 08:41:37 -0600 In this case, you are probably dealing with a record length type of error. I've seen this in the past, where a PDS has a record length of 133, and the output was probably trying to use 121 for its length. Most likely someone in SUPERC development closed(?) a hole in code. In my opinion, B. A. D. now. This hole has existed in the Classic file system since OS/360. (Shmuel might correct my conjecture about history). Likewise there's the venerable pitfall of allocating a PDS and failing to specify a member, thus overwriting the directory. Rightly, both holes should be closed once and for all (perhaps leaving a back door to allow reading a PDS directory sequentially). But the fix should be done not haphazardly by individual applications, each applying its developers' idiosyncratic concept of what the rule should be, but uniformly, in OPEN code. For the PDS/PS fix, Rexx is an individual application that gets it right: It fails the attempt to open a PDS with no member specified, but allows it if the programmer allocates with overriding DSORG(PS) (the back door). Simply, that well-designed code should be moved from Rexx to OPEN, making the behavior uniform for all applications. Conway's law strikes again. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SUPERC allocation errors z/OS V1.8 - fix
On Thu, 15 Feb 2007 13:46:08 -0500, Veilleux, Jon L [EMAIL PROTECTED] wrote: We ran into an interesting situation with z/OS V1.8. One of our folks uses a PDS for his listing dataset in ISPF 3.12 and 3.14. This stopped working when we upgraded to z/OS V1.8. After hitting enter we got: Listing not generated. When we hit PF1 for more information we received: Abnormal completion (RC=25). Existing list DS attribute conflict. Through some diligent tracing by our ISPF support guy we found that PTF UA31856 caused the problem. When we removed it all was well. Just thought I'd let everyone know. Jon Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 Thanks for letting us know. But I just checked and that PTF is not marked PE (at least not yet), so what you really need to do is open a PMR with IBM to find out if this is WAD or BAD. Is it documented anywhere that the listing data set can't be a PDS member? Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SUPERC allocation errors z/OS V1.8 - fix
Mark Zelden wrote: Thanks for letting us know. But I just checked and that PTF is not marked PE (at least not yet), so what you really need to do is open a PMR with IBM to find out if this is WAD or BAD. Is it documented anywhere that the listing data setcan't be a PDS member? We have an ETR open with IBM. PDSes are supported. The ISPF User's Guide specifies: If you enter the name of a data set that does not exist, SuperC allocates it for you. The data set is allocated as a sequential data set unless you enter a member name after it, in which case it is allocated as a partitioned data set. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SUPERC allocation errors z/OS V1.8 - fix
In a recent note, Mark Zelden said: Date: Thu, 15 Feb 2007 12:56:03 -0600 On Thu, 15 Feb 2007 13:46:08 -0500, Veilleux, Jon L [EMAIL PROTECTED] wrote: We ran into an interesting situation with z/OS V1.8. One of our folks uses a PDS for his listing dataset in ISPF 3.12 and 3.14. This stopped working when we upgraded to z/OS V1.8. After hitting enter we got: Listing not generated. When we hit PF1 for more information we received: Abnormal completion (RC=25). Existing list DS attribute conflict. Through some diligent tracing by our ISPF support guy we found that PTF UA31856 caused the problem. When we removed it all was well. Just thought I'd let everyone know. Thanks for letting us know. But I just checked and that PTF is not marked PE (at least not yet), so what you really need to do is open a PMR with IBM to find out if this is WAD or BAD. Is it documented anywhere that the listing data set can't be a PDS member? It has long been my experience that while SuperC has accepted HFS members as comparands, ironically it will not allow its output to be directed to an HFS member. I haven't reported this because of the highly likely WAD (IMO BAD). Now I'd better check (before and after UA31856) to see that IBM hasn't made this even worse. It's my impression that much of IBM treats HFS as a second-class citizen -- if it's broke they see little need to fix it -- they take APARs as SUG, etc. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
