Re: APAR OA30338 for PDSE Users - HIPER DATALOSS
Edward Jaffe wrote: I can't for the life of me explain why this is not HIPER, but if you use PDSEs in your shop I highly recommend APAR OA30338. FYI. This APAR has now been marked HIPER DATALOSS. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
In aanlktilz54dpdvn9nnrtxhovla8is-215vzl-csaz...@mail.gmail.com, on 06/08/2010 at 01:17 PM, Tony Harminc t...@harminc.net said: I discovered much to my surprise today that TSO EDIT doesn't support PDSEs. Ouch! Well perhaps I'm the only person left on the planet who still remembers how to use TSO EDIT, You may be the only one who will admit I, but I guaranty that you aren't the only one to know it, or even the only one to use it. It still has a niche. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
In f255efe0ecf08c4a9c1db6aff423541710389...@ch2wpmail1.na.ds.ussco.com, on 06/08/2010 at 12:29 PM, Chase, John jch...@ussco.com said: I'll hazard a guess that you're still proficient with EDLIN on DOS, too. :-) But why would he admit to a familiarity with Mr. EDLIN? Of course, I too have dark secrets in my past. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
Edward Jaffe edja...@phoenixsoftware.com wrote in message news:4c0def64.9020...@phoenixsoftware.com... I can't for the life of me explain why this is not HIPER, but if you use PDSEs in your shop I highly recommend APAR OA30338. Without this fix, we had broken PDSEs that could not be read, accessed, or even deleted and that led to abends in HSM, CATALOG errors, DADSM errors, corrupted VTOCs with overlapping extents--the works. The VTOC on one volume (an EAV) was so screwed up, we had to completely reINIT it. To get rid of these bad PDSEs, we had to one-at-a-time ZAP the FMT-1 DSCB in the VTOC to turn off the PDSE flag, delete the PDSE, immediately allocate a dummy sequential data set to reuse the just-freed DSCB for non-PDSE data set, and then either restore the PDSE from a backup or recreate from scratch. It was ugly! Unfortunately, an IPL is required to make the fix effective. But, it's worth it! -- Edward E Jaffe You mentioned the EAV volume. Do you have indications that this is part of the problem, i.e. the problem only occurs on EAV volumes? Kees. 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
Vernooij, CP - SPLXM wrote: You mentioned the EAV volume. Do you have indications that this is part of the problem, i.e. the problem only occurs on EAV volumes? No. EAV has nothing to do with it. The problem can occur on volumes of any size. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
APAR OA30338 for PDSE Users
I can't for the life of me explain why this is not HIPER, but if you use PDSEs in your shop I highly recommend APAR OA30338. Without this fix, we had broken PDSEs that could not be read, accessed, or even deleted and that led to abends in HSM, CATALOG errors, DADSM errors, corrupted VTOCs with overlapping extents--the works. The VTOC on one volume (an EAV) was so screwed up, we had to completely reINIT it. To get rid of these bad PDSEs, we had to one-at-a-time ZAP the FMT-1 DSCB in the VTOC to turn off the PDSE flag, delete the PDSE, immediately allocate a dummy sequential data set to reuse the just-freed DSCB for non-PDSE data set, and then either restore the PDSE from a backup or recreate from scratch. It was ugly! Unfortunately, an IPL is required to make the fix effective. But, it's worth it! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
I can't for the life of me explain why this is not HIPER, but if you use PDSEs in your shop I highly recommend APAR OA30338. Thanks for the heads-up! After reading the apar description and resolution, it doesn't even sound like IBM has found out *why* there was an overlaid eyecatcher. This sounds like the usual bandaid *after* things were broken just to prevent them from breaking further. Do you have any more news on that? Oh, my 100% wto buffer shortage apar (oa32676) is closed, but also also NOT hiper Best regards, Barbara ps: that reminds me, I still need to take IBM to task why PDSE doesn't honour directory caching after close, not even for the first 15 minutes.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
On Tue, 8 Jun 2010 00:21:08 -0700, Edward Jaffe edja...@phoenixsoftware.com wrote: I can't for the life of me explain why this is not HIPER, Ed, I guess your shop isn't big enough or important enough. :-) It's not marked DATALOSS either. My guess is after this thread it will be. but if you use PDSEs in your shop I highly recommend APAR OA30338. Without this fix, we had broken PDSEs that could not be read, accessed, or even deleted and that led to abends in HSM, CATALOG errors, DADSM errors, corrupted VTOCs with overlapping extents--the works. The VTOC on one volume (an EAV) was so screwed up, we had to completely reINIT it. To get rid of these bad PDSEs, we had to one-at-a-time ZAP the FMT-1 DSCB in the VTOC to turn off the PDSE flag, delete the PDSE, immediately allocate a dummy sequential data set to reuse the just-freed DSCB for non-PDSE data set, and then either restore the PDSE from a backup or recreate from scratch. It was ugly! Unfortunately, an IPL is required to make the fix effective. But, it's worth it! Reading the description, it looks like a problem that would only affect a single data set. How did it affect so many data sets and volumes in your environment? Thanks for the head's up. Cheers, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
Far be it from me to debunk PDSE after all these years as one of IBMs flagship products, but I only use PDSE when I have to. Nice concept, badly implemented - has always looked like the marketing droids driving the techos. Shane ... I can't for the life of me explain why this is not HIPER, but if you use PDSEs in your shop I highly recommend APAR OA30338. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
If you have free time (ha-ha) do an IBMLINK search on PDSE APARs since January 2010. You will get a ton of hits with a lot of them still open with etas sometime in the fall. Not the most stable product that IBM has. Jon L. Veilleux veilleu...@aetna.com (860) 636-9179 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shane Ginnane Sent: Tuesday, June 08, 2010 9:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: APAR OA30338 for PDSE Users Far be it from me to debunk PDSE after all these years as one of IBMs flagship products, but I only use PDSE when I have to. Nice concept, badly implemented - has always looked like the marketing droids driving the techos. Shane ... I can't for the life of me explain why this is not HIPER, but if you use PDSEs in your shop I highly recommend APAR OA30338. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
In a message dated 6/8/2010 8:00:40 A.M. Central Daylight Time, mzel...@flash.net writes: Reading the description, it looks like a problem that would only affect a single data set. How did it affect so many data sets and volumes in your environment? What was the one at AA back in early eighties with TPF. The dasd INIT got hung and the operators kept replying U hoping it would go away. Well it did-after over 1000 volumes were INIT'd. Too much funkanation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
Mark Zelden wrote: Ed, I guess your shop isn't big enough or important enough. :-) It's not marked DATALOSS either. My guess is after this thread it will be. I just complained that it wasn't marked DATALOSS or HIPER. It seems like DATALOSS applies for sure. And, if it was HIPER I would have had it installed already. Maybe it's not HIPER because research shows nobody but me uses PDSE. ;-) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
Maybe it's not HIPER because research shows nobody but me uses PDSE. ;-) Unfortunately we have tons of them. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
On 06/08/10 10:45, Edward Jaffe wrote: Mark Zelden wrote: Ed, I guess your shop isn't big enough or important enough. :-) It's not marked DATALOSS either. My guess is after this thread it will be. I just complained that it wasn't marked DATALOSS or HIPER. It seems like DATALOSS applies for sure. And, if it was HIPER I would have had it installed already. Maybe it's not HIPER because research shows nobody but me uses PDSE. ;-) We're a big PDSE user also and without too much analysis on my part I also feel that the PDSE component has more than its share of problems. I take a special look at the current PDSE maintenance informational APAR ( II14519 for zOS 1.11) on a regular basis. -- Mark Jacobs Time Customer Service Tampa, FL It is impossible to make anything foolproof, because fools are so ingenious. -- Robert Heinlein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
That's a good idea, but it is only updated once a month and that could still leave out a fair number of new APARs. Jon L. Veilleux veilleu...@aetna.com (860) 636-9179 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Jacobs Sent: Tuesday, June 08, 2010 10:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: APAR OA30338 for PDSE Users On 06/08/10 10:45, Edward Jaffe wrote: Mark Zelden wrote: Ed, I guess your shop isn't big enough or important enough. :-) It's not marked DATALOSS either. My guess is after this thread it will be. I just complained that it wasn't marked DATALOSS or HIPER. It seems like DATALOSS applies for sure. And, if it was HIPER I would have had it installed already. Maybe it's not HIPER because research shows nobody but me uses PDSE. ;-) We're a big PDSE user also and without too much analysis on my part I also feel that the PDSE component has more than its share of problems. I take a special look at the current PDSE maintenance informational APAR ( II14519 for zOS 1.11) on a regular basis. -- Mark Jacobs Time Customer Service Tampa, FL It is impossible to make anything foolproof, because fools are so ingenious. -- Robert Heinlein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
On Tue, 8 Jun 2010 07:45:57 -0700, Edward Jaffe edja...@phoenixsoftware.com wrote: Mark Zelden wrote: Ed, I guess your shop isn't big enough or important enough. :-) It's not marked DATALOSS either. My guess is after this thread it will be. I just complained that it wasn't marked DATALOSS or HIPER. It seems like DATALOSS applies for sure. And, if it was HIPER I would have had it installed already. Maybe it's not HIPER because research shows nobody but me uses PDSE. ;-) It think if IBM marks it DATALOSS, then it is also HIPER by definition. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
On 8 Jun 2010 08:05:51 -0700, in bit.listserv.ibm-main Jon L. Veilleux wrote: That's a good idea, but it is only updated once a month and that could still leave out a fair number of new APARs. Jon L. Veilleux veilleu...@aetna.com (860) 636-9179 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Jacobs Sent: Tuesday, June 08, 2010 10:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: APAR OA30338 for PDSE Users On 06/08/10 10:45, Edward Jaffe wrote: Mark Zelden wrote: Ed, I guess your shop isn't big enough or important enough. :-) It's not marked DATALOSS either. My guess is after this thread it will be. I just complained that it wasn't marked DATALOSS or HIPER. It seems like DATALOSS applies for sure. And, if it was HIPER I would have had it installed already. Maybe it's not HIPER because research shows nobody but me uses PDSE. ;-) We're a big PDSE user also and without too much analysis on my part I also feel that the PDSE component has more than its share of problems. I take a special look at the current PDSE maintenance informational APAR ( II14519 for zOS 1.11) on a regular basis. And we knock Microsoft Windows. Somehow the reliability and design of PDSE seems to be lacking. For starters it isn't even a superset of PDS when it comes to function because it can't be used for SYS1.NUCLEUS, SYS1.LINKLIB or SYS1.LPALIB. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
Mark Jacobs wrote: On 06/08/10 10:45, Edward Jaffe wrote: Mark Zelden wrote: Ed, I guess your shop isn't big enough or important enough. :-) It's not marked DATALOSS either. My guess is after this thread it will be. I just complained that it wasn't marked DATALOSS or HIPER. It seems like DATALOSS applies for sure. And, if it was HIPER I would have had it installed already. Maybe it's not HIPER because research shows nobody but me uses PDSE. ;-) We're a big PDSE user also and without too much analysis on my part I also feel that the PDSE component has more than its share of problems. I take a special look at the current PDSE maintenance informational APAR ( II14519 for zOS 1.11) on a regular basis. Mark, that's great advice if you have the time. We rely on weekly APPLY PTFS after RECEIVE ORDER with CONTENT(RECOMMENDED) to keep things running smoothly. That process picks up RSUyymm and HIPER/PE. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
On 8 June 2010 11:54, Clark Morris cfmpub...@ns.sympatico.ca wrote: And we knock Microsoft Windows. Somehow the reliability and design of PDSE seems to be lacking. For starters it isn't even a superset of PDS when it comes to function because it can't be used for SYS1.NUCLEUS, SYS1.LINKLIB or SYS1.LPALIB. I discovered much to my surprise today that TSO EDIT doesn't support PDSEs. IKJ52330I PDSE ORGANIZATION OF DATA SET JCL.CNTL(HEX) NOT ACCEPTABLE+ READY ? IKJ52330I ORGANIZATION MUST BE PARTITIONED OR SEQUENTIAL Well perhaps I'm the only person left on the planet who still remembers how to use TSO EDIT, but still. I thought PDSEs *were* of partitioned organization, and indeed LISTDS agrees with me. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc On 8 June 2010 11:54, Clark Morris cfmpub...@ns.sympatico.ca wrote: And we knock Microsoft Windows. Somehow the reliability and design of PDSE seems to be lacking. For starters it isn't even a superset of PDS when it comes to function because it can't be used for SYS1.NUCLEUS, SYS1.LINKLIB or SYS1.LPALIB. I discovered much to my surprise today that TSO EDIT doesn't support PDSEs. IKJ52330I PDSE ORGANIZATION OF DATA SET JCL.CNTL(HEX) NOT ACCEPTABLE+ READY ? IKJ52330I ORGANIZATION MUST BE PARTITIONED OR SEQUENTIAL Well perhaps I'm the only person left on the planet who still remembers how to use TSO EDIT, but still. I thought PDSEs *were* of partitioned organization, and indeed LISTDS agrees with me. I'll hazard a guess that you're still proficient with EDLIN on DOS, too. :-) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc On 8 June 2010 11:54, Clark Morris cfmpub...@ns.sympatico.ca wrote: And we knock Microsoft Windows. Somehow the reliability and design of PDSE seems to be lacking. For starters it isn't even a superset of PDS when it comes to function because it can't be used for SYS1.NUCLEUS, SYS1.LINKLIB or SYS1.LPALIB. I discovered much to my surprise today that TSO EDIT doesn't support PDSEs. IKJ52330I PDSE ORGANIZATION OF DATA SET JCL.CNTL(HEX) NOT ACCEPTABLE+ READY ? IKJ52330I ORGANIZATION MUST BE PARTITIONED OR SEQUENTIAL Well perhaps I'm the only person left on the planet who still remembers how to use TSO EDIT, but still. I thought PDSEs *were* of partitioned organization, and indeed LISTDS agrees with me. I'll hazard a guess that you're still proficient with EDLIN on DOS, too. :-) -jc- Ooooh, h! I wrote an accounting package for my business in DBase using edlin over 25 years ago. 3 lines. I still use it. Hey, a legacy! :-) Also, we still include a lecture on TSO EDIT in our CLIST course (but not our REXX course), and I actually had to use TSO EDIT for the prep work for a course I once wrote on what was then called WebSphere Developer four z (WD4z), since you couldn't count on having ISPF but you could count on having TSO. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
On 06/08/10 13:17, Tony Harminc wrote: On 8 June 2010 11:54, Clark Morriscfmpub...@ns.sympatico.ca wrote: And we knock Microsoft Windows. Somehow the reliability and design of PDSE seems to be lacking. For starters it isn't even a superset of PDS when it comes to function because it can't be used for SYS1.NUCLEUS, SYS1.LINKLIB or SYS1.LPALIB. I discovered much to my surprise today that TSO EDIT doesn't support PDSEs. IKJ52330I PDSE ORGANIZATION OF DATA SET JCL.CNTL(HEX) NOT ACCEPTABLE+ READY ? IKJ52330I ORGANIZATION MUST BE PARTITIONED OR SEQUENTIAL Well perhaps I'm the only person left on the planet who still remembers how to use TSO EDIT, but still. I thought PDSEs *were* of partitioned organization, and indeed LISTDS agrees with me. Tony H. -- That's my apar. I discovered the problem back about 18 years ago and IBM 'fixed' the problem by adding the above messages to TSO/E edit. I also remember how to use TSO/E edit but I haven't used it in many years. -- Mark Jacobs Time Customer Service Tampa, FL It is impossible to make anything foolproof, because fools are so ingenious. -- Robert Heinlein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
Ed Finnell wrote: In a message dated 6/8/2010 8:00:40 A.M. Central Daylight Time, mzel...@flash.net writes: Reading the description, it looks like a problem that would only affect a single data set. How did it affect so many data sets and volumes in your environment? Yes. The problem happens one data set at a time (or maybe it can affect all OPEN-for-output PDSEs when a job is canceled). As I understand it, PDSE modules get called by CATALOG/DADSM if DS1PDSE is ON in the FMT-1 or FMT-8 DSCB and if there is an abend in PDSE code at an inopportune time, it can be disruptive to those operations. As near as I can tell, in one case someone renamed one of the corrupted PDSEs and that somehow led to overlapping extents with 22 other data sets. (These are big PDSEs used to hold ADATA from product builds.) That overlap led to a lot of heartache and a reINITed volume. After getting current with recommended maintenance and IPLing, we had issues with CATALOG errors trying to delete another one of the corrupted PDSEs via IDCAMS: DELETE EJES.PRODGEN.ADATA PURGE 0IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 102 - REASON CODE IS IGG0CLFM-2 IDC0551I ** ENTRY EJES.PRODGEN.ADATA NOT DELETED 0IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8 And DADSM errors trying to delete via ISPF 3.2 or TSO/E DELETE command with ISPF error messages and accompanying SVC dumps: | An internal service failed with return code = 12 decimal, reason code | X'280F01D5'. ISPF may be unable to obtain information about an HFS file or | PDSE. More information may be available in the ISPF log. IEC331I 042-006(043D57D3),EDJXADM ,$IKJTEST,SCRT,IGG0CLH0 IEC331I VOL,MVSEV0,NAME,EJES.PRODGEN.ADATA IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (043D57D3), $IKJTEST,MVSEV0,EJES.PRODGEN.ADATA *** IEA045I AN SVC DUMP HAS STARTED AT TIME=10.39.19 DATE=06/05/2010 085 FOR ASIDS(0009,0071) ERROR ID = SEQ00044 CPU00 ASID0071 TIME10.39.19.2 QUIESCE = YES IEA794I SVC DUMP HAS CAPTURED: 086 DUMPID=001 REQUESTED BY JOB (EDJXADM ) DUMP TITLE=COMPID=DF115,CSECT=IGWDACND+1AFA,DATE=04/06/09,MAINT ID= NONE ,ABND=0F4,RC=0024,RSN=01045AF1 IEF196I IGD17070I DATA SET SYS3.DUMP.D100605.T103919.EDJXADM.S1 IEF196I ALLOCATED SUCCESSFULLY WITH 1 STRIPE(S). IEF196I IGD17160I DATA SET SYS3.DUMP.D100605.T103919.EDJXADM.S1 IEF196I IS ELIGIBLE FOR COMPRESSION IEF196I IGD101I SMS ALLOCATED TO DDNAME (SYS2) IEF196I DSN (SYS3.DUMP.D100605.T103919.EDJXADM.S1) IEF196I STORCLAS (SVCDUMP) MGMTCLAS (DUMPS) DATACLAS (SVCDUMP) IEF196I VOL SER NOS= MVSEV0 IEC331I 042-006(043D57D3),EDJXADM ,$IKJTEST,SCRT,IGG0CLH0 IEC331I VOL,MVSEV0,NAME,EJES.PRODGEN.ADATA IGD17040I ERROR IN DADSM PROCESSING ON VOLUME MVSEV0 FOR DATA SET 097 EJES.PRODGEN.ADATA HISTORIC RETURN CODE IS 8 DIAGNOSTIC INFORMATION IS 043D57D3 IGD306I UNEXPECTED ERROR DURING IGGDAS02 PROCESSING 098 RETURN CODE 4 REASON CODE 211 THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA SMS MODULE TRACE BACK - VTSDA VTSCU VTSCT VTSDL SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD0 IEF196I IGD104I SYS3.DUMP.D100605.T103919.EDJXADM.S1 RETAINED, IEF196I DDNAME=SYS2 IEA611I COMPLETE DUMP ON SYS3.DUMP.D100605.T103919.EDJXADM.S1 102 DUMPID=001 REQUESTED BY JOB (EDJXADM ) FOR ASIDS(0009,0071) INCIDENT TOKEN: PHXHQMVS6006/05/2010 17:39:19 ERROR ID = SEQ00044 CPU00 ASID0071 TIME10.39.19.2 IEF196I IEF237I 8112 ALLOCATED TO IPCSDDIR The fix is to follow the somewhat convoluted process I described earlier zapping VTOC, deleting the PDSE, allocating a dummy sequential file, etc. for each PDSE so affected. Then recovering from backup or rebuilding. I suppose the pervasiveness of this issue depends entirely on how many PDSEs you have in your shop and how many of them get corrupted before you notice there is an issue. FWIW, IBM says they are looking into adding DATALOSS/HIPER flags. I'll keep you posted. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
On Tue, 8 Jun 2010 13:17:05 -0400, Tony Harminc t...@harminc.net wrote: On 8 June 2010 11:54, Clark Morris cfmpub...@ns.sympatico.ca wrote: And we knock Microsoft Windows. Somehow the reliability and design of PDSE seems to be lacking. For starters it isn't even a superset of PDS when it comes to function because it can't be used for SYS1.NUCLEUS, SYS1.LINKLIB or SYS1.LPALIB. I discovered much to my surprise today that TSO EDIT doesn't support PDSEs. IKJ52330I PDSE ORGANIZATION OF DATA SET JCL.CNTL(HEX) NOT ACCEPTABLE+ READY ? IKJ52330I ORGANIZATION MUST BE PARTITIONED OR SEQUENTIAL Well perhaps I'm the only person left on the planet who still remembers how to use TSO EDIT, but still. I thought PDSEs *were* of partitioned organization, and indeed LISTDS agrees with me. Tony H. It appears you did this just as a test or to prove a point, but regardless, if you or anyone does want full screen ISPF like edit from native TSO that fully supports PDSE and z/OS Unix, I would suggest picking up a copy of Greg Price's REVIEW. http://www.cbttape.org/ Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
I suppose the pervasiveness of this issue depends entirely on how many PDSEs you have in your shop and how many of them get corrupted before you notice there is an issue. And, over on the CICS-L, people are recommending PDSE for production DFHRPL libraries. I would think NOT! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
On Tue, 8 Jun 2010 18:38:47 +, Ted MacNEIL eamacn...@yahoo.ca wrote: I suppose the pervasiveness of this issue depends entirely on how many PDSEs you have in your shop and how many of them get corrupted before you notice there is an issue. And, over on the CICS-L, people are recommending PDSE for production DFHRPL libraries. I would think NOT! - You can go back to past posts of mine and see... but my client has been using Endevor controlled PDSEs for production for many years and we haven't had any problems. This includes CICS DFHRPL libraries, batch production JCL and PROCLIBs that were statically defined to JES2 in the past and have been dynamically defined since z/OS 1.4 (they migrated from OS/390 2.10 directly to z/OS 1.4). And this is a large production environment. We even have a small monoplex LPAR where IGDSMSxx is set to have the default PO as PDSE (so even ISPF work data sets and profile data sets get created as PDSE, against IBM's recommendations). The only problem my client ever had was when they first started using PDSE and inadvertently shared a couple of the DFHRPL libraries across sysplex boundaries as all the DASD is shared and MIM (MII) is used. Better controls and SMS rules were put in place to prevent that and hasn't happened since. Now VSAM RLS (SMSVSAM) is another story, but that's another thread! :-) Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
We even have a small monoplex LPAR where IGDSMSxx is set to have the default PO as PDSE (so even ISPF work data sets and profile data sets get created as PDSE, against IBM's recommendations). I used to be a big fan of PDSE, when it first came out. But, I've seen so many problems over the past 8-10 years, that require your system(s) to be up-to-date, and when they're not, you're toast. It depends on individual experiences, but I shall not be recommending PDSE for a long while. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
Mark Zelden wrote: You can go back to past posts of mine and see... but my client has been using Endevor controlled PDSEs for production for many years and we haven't had any problems. This includes CICS DFHRPL libraries, batch production JCL and PROCLIBs that were statically defined to JES2 in the past and have been dynamically defined since z/OS 1.4 (they migrated from OS/390 2.10 directly to z/OS 1.4). And this is a large production environment. We even have a small monoplex LPAR where IGDSMSxx is set to have the default PO as PDSE (so even ISPF work data sets and profile data sets get created as PDSE, against IBM's recommendations). We have been using PDSE almost exclusively for at least a decade. We also specify DSNTYPE(LIBRARY) in IGDSMSxx and have done so for many years. There are very few old-style PDS libraries here--almost all of them are on SYSRES. This is the worst experience I can recall us ever having with PDSE. In general, I recommend them highly. Being a software developer myself, my issue here is not that the software has a bug. Any time you improve a product, there is always that exposure. And, this bug was already discovered and solved before I experienced it. The purpose of my post was to warn my friends on IBM-MAIN about this problem so they can avoid some pain -- AND -- to express my humble opinion that this APAR/PTF be marked HIPER. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
I would NOT suggest PDSE for large libraries that are constantly opened and closed. This has proven disastrous for an extremely large customer in the west with CA7 JCL Libraries (we're talking 22-30 seconds to get to the member and open it). Recent PTFs (in the last year or so), have fixed it somewhat (reduced by 5 seconds), but still not good enough. zNorman formerly of ca.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Tuesday, June 08, 2010 Tuesday 12:41 PM To: IBM-MAIN@bama.ua.edu Subject: Re: APAR OA30338 for PDSE Users Mark Zelden wrote: You can go back to past posts of mine and see... but my client has been using Endevor controlled PDSEs for production for many years and we haven't had any problems. This includes CICS DFHRPL libraries, batch production JCL and PROCLIBs that were statically defined to JES2 in the past and have been dynamically defined since z/OS 1.4 (they migrated from OS/390 2.10 directly to z/OS 1.4). And this is a large production environment. We even have a small monoplex LPAR where IGDSMSxx is set to have the default PO as PDSE (so even ISPF work data sets and profile data sets get created as PDSE, against IBM's recommendations). We have been using PDSE almost exclusively for at least a decade. We also specify DSNTYPE(LIBRARY) in IGDSMSxx and have done so for many years. There are very few old-style PDS libraries here--almost all of them are on SYSRES. This is the worst experience I can recall us ever having with PDSE. In general, I recommend them highly. Being a software developer myself, my issue here is not that the software has a bug. Any time you improve a product, there is always that exposure. And, this bug was already discovered and solved before I experienced it. The purpose of my post was to warn my friends on IBM-MAIN about this problem so they can avoid some pain -- AND -- to express my humble opinion that this APAR/PTF be marked HIPER. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APAR OA30338 for PDSE Users
I would NOT suggest PDSE for large libraries that are constantly opened and closed. This has proven disastrous for an extremely large customer in the west with CA7 JCL Libraries (we're talking 22-30 seconds to get to the member and open it). Recent PTFs (in the last year or so), have fixed it somewhat (reduced by 5 seconds), but still not good enough. 22-30 seconds is FAST! Ours (4500cyl, 1 members) take 90-100s! And due to the nature of Fault Ananlyzer that uses it, they get constantly opened and closed. We have about ten of those huge non-performing beasts, and we cannot convert to PDS because they are too big and the contents cannot otherwise get separated. And BUFFER_BEYOND_CLOSE doesn't do a thing, either. The directory is NOT cached despite that being the default. - You could try my 'Keep the PDSE open' program, a small thing that just does an open on all of them and then goes to sleep forver. That keeps the connection, and for the next 15 minutes or so, the opening by someone else is actually fast. After the 15 or so minutes of having the dataset open but no activity, things go back to a lng wait. - Back to the apar: Does anyone know if an overlay done by someone else is the cause of the first PDSE abend and if so, what has caused that overlay? Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
