Take a look at this APAR: http://www-01.ibm.com/support/docview.wss?uid=isg1OA44607
In the APAR it has: " Sparse datasets from release 1.13 or lower and subsequent updated in R2.1 may cause an index corruption. R2.1 collapse sparse indexes and it did not delete an empty page in a particular delete path." Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mark Jacobs - Listserv Sent: Monday, May 25, 2015 10:04 PM To: [email protected] Subject: Re: Corrupt PDSE - IGW699I PDSE Directory Validation Unsuccessful Yea, it looks damaged to me too. I'd still recommend that you validate the integrity of the restored dataset, just to be safe. Mark Jacobs > Thomas Berg <mailto:[email protected]> May 25, 2015 at 10:00 PM > Tried on another prodsystem. Got this: > > IGW699I PDSE Directory Validation Unsuccessful IEA995I SYMPTOM DUMP > OUTPUT SYSTEM COMPLETION CODE=0F4 REASON CODE=00000024 > TIME=03.59.10 SEQ=44968 CPU=0000 ASID=01F8 PSW AT TIME OF ERROR > 075C1000 88FDA690 ILC 2 INTC 0D NO ACTIVE MODULE FOUND - PRIMARY NOT > EQUAL TO HOME NAME=UNKNOWN DATA AT PSW 08FDA68A - 58F05048 0A0DB219 > 0000A788 AR/GR 0: 008FF6C8/01188012 1: 00000000/040F4000 > 2: 00000001/00FDB9A0 3: 00000000/7EC6E268 > 4: 00000002/00007703 5: 00000000/7EC73400 > 6: 00000000/7EC6E060 7: 00000000/00FE0548 > 8: 00000000/00FE05B8 9: 00000001/7EC6E268 > A: 00000000/7EC73868 B: 00000000/00000000 > C: 00000000/08FDA012 D: 00000000/7EC73778 > E: 00000000/88FDA682 F: 00000000/00000024 END OF SYMPTOM DUMP > DESC:PDSE structure is corrupted ERROR NUM:103 > DSN:SYS6.IDI.PROD5.HIST.FEL > VOLSER:GEM040 > ADPages:10169 IXRecords:405168 > ADPagesInCore:159 ADPagesRead:10010 > ADTreeLevels:3 > NDPages:21 IXRecords:2460 > NDPagesInCore:7 NDPagesRead:14 > NDTreeLevels:2 > AD ND Tree Nodes:2430 > Version:1 > Orphan Pages:4682 > RC:4 RS:01188012 > IGW702I PDSE Directory Validation Unsuccessful DESC:<AD> Structure is > corrupted > LTK:D561C14040404040404040404040404040404040 > ERROR NUM:1 > DSN:SYS6.IDI.PROD5.HIST.FEL > VOLSER:GEM040 > RC:4 RS:01188012 R14:08E8D2A4 > RPN:N/A > VPTVFN:N/A > IEC036I 002-A4,IGC0005E,S000TBE,KAT30,ISP03594,786B,GEM040, > SYS6.IDI.PROD5.HIST.FEL > IRX0250E System abend code 002, reason code 00000164. > IRX0255E Abend in host command SELECT or address environment routine > ISPEXEC. > *** > > > > Best Regards, > Thomas Berg > ___________________________________________________________________ > Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ) > > Interactive is 'manual.' Batch is 'automatic.' > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN Mark > Jacobs - Listserv <mailto:[email protected]> May 25, 2015 at > 9:50 PM Three more questions. > > 1. Do you have all the required toleration maintenance applied on your > 1.13 system? > 2. Does the hang occur on all systems in the sysplex or just one? > 1. If only on one, can you recycle the SMSPDSE1 address space and > see if that fixes the problem? > > Mark Jacobs > > > Thomas Berg <mailto:[email protected]> May 25, 2015 at 9:47 PM > BTW, we are on zOS 2.1 in the DEV system and zOS 1.13 in the prod system. > > > > Best Regards, > Thomas Berg > ___________________________________________________________________ > Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ) > > Interactive is 'manual.' Batch is 'automatic.' > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN Mark > Jacobs - Listserv <mailto:[email protected]> May 25, 2015 at > 9:27 PM If you take a physical dump of the dataset and send it into > IBM for analysis they might be able to get to the root cause. Assuming > you're on zOS 1.13 or higher did you execute IEBPDSE against the > restored dataset to verify its structure? > > Mark Jacobs > > > Thomas Berg <mailto:[email protected]> May 25, 2015 at 9:23 PM > AFAIK it should have a very low probability. This due to that those > that can access from outside of the Sysplex (special sysprogs) have > neither reason or interest of doing that. And this is 3.00 AM here. > (At least the operator I spoke to had no knowledge of anyone else that > me working at this time.) > > I have restored a backup from yesterday now so the immediate problem > is solved. (And saved the corrupted PDSE in case anyone except me is > interested.) > > > > Best Regards, > Thomas Berg > ___________________________________________________________________ > Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ) > > Interactive is 'manual.' Batch is 'automatic.' > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN -- Mark Jacobs Time Customer Service Technology and Product Engineering The standard you walk past is the standard you accept. Lt. Gen. David Morrison ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
