Try this if your PDS was in one extent. This happened to us a while back and
this is how we got out....
Raiders of the Lost Parmlib
Our story begins as one lone figure stares at their computer screen. A victim
of the proximity of the 'S' and 'D' keys on the keyboard and the ability to
disable 'Confirm Data Set Delete' in TSO. They are temporarily relieved to
remember that all of our system-related volumes are backed up every week, until
they find out that due to a coding error, this particular volume has not been
being backed up.
The Raiders of the Lost Parmlib now step in to recover the deleted file.
DISCLAIMER: Do not try this at home! Closed Course, Professional Drivers! The
following scenario will only work if the lost dataset is in one extent. If
there are multiple extents the level of difficulty grows exponentially!
Step 1 was to get a track map of the volume that once contained the dataset
using STARTOOL option 'VMAP' entered on the command line:
Track map (VMAP)
CCHH End CCHH EX# DATA/MSG ---------DATA SET NAME --------------------
00000001 0000000E 1 *----14 SYS1.VTOCIX.SYI07A__________________________
00010000 0001000E 1 *----15 *** FORMAT 4 (VTOC) EXTENT ***______________
00020000 00020004 1 *-----5 SYS1.VVDS.VSYI07A___________________________
00020005 0002000E 1 *----10 SYS1.ADR.SAIPLD.VSYI07A_____________________
00030000 005C000E 1 *--1350 *** FREE SPACE EXTENT ***___________________
005D0000 0175000E 1 *--4215 SYSC.IODF00_________________________________
01760000 0270000E 1 *--3765 SYSC.IODF01_________________________________
02710000 037B000E 1 *--4005 SYSC.IODF02_________________________________
037C0000 0392000E 1 *---345 *** FREE SPACE EXTENT ***___________________
03930000 0483000E 1 *--3615 SYSC.IODF03_________________________________
04840000 0D0A000E 1 *-32745 *** FREE SPACE EXTENT ***___________________
Step 2 was to guess which of the free space extents was most likely to have
contained the missing dataset. In this case it appears to be the extents at
00030000 - 005C000E.
Step 3 was to use DFDSS 'PRINT' to dump the tracks in the suspected area.
//PRINT EXEC PGM=ADRDSSU REGION=2000K,PARM='SIZE=1000K'
//SYSPRINT DD SYSOUT=*
//IN1 DD DISP=SHR,UNIT=3390,VOL=SER=SYI07A
//OUT DD DUMMY
//SYSIN DD *
PRINT TRACKS (X'0003',X'0000',X'005C',X'000E') INDDNAME(IN1)
This gave the following output: (**Note: the data at the bottom actually
appears on the right in the JES listing. It is the EBCDIC version of the data)
*** TRACK(CCHH) 00030000 R0 DATA 0000000000000000
COUNT 0003000001080100
0000 C1C4E8E2 C5E3F0F2 00FE5B5B 5BC3D6C9 C2D40016 190F0A00 00000083 349F0083
0020 349F1701 00180018 0000E2E8 E2C9D7D6 40404040 5B5BE2E4 C6C6C9E7 0020010F
0040 01020037 0093053F 0097068F 09240006 00010006 E3F4C3E3 D9D1D640 40405BD4
0060 C5D4C2C5 D9400028 220F012F 00430098 005F0098 008F1442 002C000F 002CE3F4
0080 C3E3D9D1 D6404040 C1C4E8E2 C5E3F0F0 00280A0F 01000033 0097323F 0097323F
00A0 15230012 00120000 E3F8E2D3 C2404040 4040C1C4 E8E2C5E3 F0F10028 0C0F0100
00C0 00200097 323F0097 323F1524 000B000B 0000E3F8 E2D3C240 40404040 C1C4E8E2
00E0 C5E3F0F2 00280E0F 01000020 0097323F 0097323F 15260012 00120000 E3F8E2D3
0100 C2404040 40400000
*ADYSET02..$$$COIBM.........c...c*
*..........SYSIPO....$$SUFFIX....*
*.....l...p..........T4CTRJO...$M*
*EMBER..........q.¬.q..........T4*
*CTRJO...ADYSET00.........p...p..*
*........T8SLB.....ADYSET01......*
*...p...p..........T8SLB.....ADYS*
*ET02.........p...p..........T8SL*
*B....... *
This data appears to be a valid PDS directory, so we were pretty sure that this
was the original location of the file.
Step 4 was to allocate a new dataset at this exact location using ABSTR to
point to the absolute track address. Remember that the addresses above are
CCHHR Cylinder Head Record and there are 15 tracks per cylinder, so our
starting track address was 45 (3*15).
The 3 came from the cylinder address (TRACK(CCHH) 00030000).
//STEP1 EXEC PGM=IEFBR14
//DD1IN DD DSN=SYS1.PARMLIB.AEPLEX07,DISP=(NEW,CATLG),
// VOL=SER=SYI07A,LRECL=80,BLKSIZE=6160,RECFM=FB,UNIT=SYSALLDA,
// SPACE=(ABSTR,(1350,0045,1000))
//* 1350 = # cylinders, 0045 = track address, 1000 = # of directory blocks */
This created a new dataset at the correct location, however, since we specified
directory blocks in the SPACE parms, the directory entries that were still on
the disk from the original dataset were overlaid by the new formatted
directory. We might have been able to avoid this problem by allocating a
sequential dataset and then zapping the DSCB to make it a PDS. But we didn't,
so the next step was to recreate the original PDS directory. Remember the DFDSS
PRINT of the tracks?
Step 5. Using this listing and knowing that the PDS directory entries have a
blocksize of 256 ('x'100), we created a dataset that had only the listing of
the directory entries in it. Using some judicious editing we created a file
that looked something like this, where the first 10 characters of the COUNT
record are the absolute cylinder address, and the following lines have the data
prefixed by the offset from the beginning of the cylinder.
COUNT 0003000001080100
0000 C1C4E8E2 C5E3F0F2 00FE5B5B 5BC3D6C9 C2D40016 190F0A00 00000083 34
0020 349F1701 00180018 0000E2E8 E2C9D7D6 40404040 5B5BE2E4 C6C6C9E7 00
0040 01020037 0093053F 0097068F 09240006 00010006 E3F4C3E3 D9D1D640 40
0060 C5D4C2C5 D9400028 220F012F 00430098 005F0098 008F1442 002C000F 00
0080 C3E3D9D1 D6404040 C1C4E8E2 C5E3F0F0 00280A0F 01000033 0097323F 00
00A0 15230012 00120000 E3F8E2D3 C2404040 4040C1C4 E8E2C5E3 F0F10028 0C
00C0 00200097 323F0097 323F1524 000B000B 0000E3F8 E2D3C240 40404040 C1
00E0 C5E3F0F2 00280E0F 01000020 0097323F 0097323F 15260012 00120000 E3
0100 C2404040 40400000
Step 6 was to write a REXX exec to read this file and format the data into
AMASPZAP control cards. The output from the REXX exec looked like this: **NOTE:
there are no VER statements so use with EXTREME caution **
CCHHR 0003000001
REP 0000 C1C4E8E2,C5E3F0F2,00FE5B5B,5BC3D6C9
REP 0010 C2D40016,190F0A00,00000083,349F0083
REP 0020 349F1701,00180018,0000E2E8,E2C9D7D6
REP 0030 40404040,5B5BE2E4,C6C6C9E7,0020010F
REP 0040 01020037,0093053F,0097068F,09240006
REP 0050 00010006,E3F4C3E3,D9D1D640,40405BD4
REP 0060 C5D4C2C5,D9400028,220F012F,00430098
REP 0070 005F0098,008F1442,002C000F,002CE3F4
REP 0080 C3E3D9D1,D6404040,C1C4E8E2,C5E3F0F0
REP 0090 00280A0F,01000033,0097323F,0097323F
REP 00A0 15230012,00120000,E3F8E2D3,C2404040
REP 00B0 4040C1C4,E8E2C5E3,F0F10028,0C0F0100
REP 00C0 00200097,323F0097,323F1524,000B000B
REP 00D0 0000E3F8,E2D3C240,40404040,C1C4E8E2
REP 00E0 C5E3F0F2,00280E0F,01000020,0097323F
REP 00F0 0097323F,15260012,00120000,E3F8E2D3
REP 0100 C2404040,40400000
Step 7 was to create JCL to run the AMASPZAP using the above file as input. The
JCL looked like this:
// EXEC PGM=AMASPZAP
//SYSLIB DD DISP=OLD,UNIT=3390,VOL=SER=SYI07A,
// DSN=SYS1.PARMLIB.AEPLEX07.OLD
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN DD DISP=SHR,DSN=F8CAUB.JLV.JCL(DIRCRDS)
After this was run the dataset was pretty much back to normal. However, due to
the fact that we had no correct model for the dataset, we over allocated the
PDS directory and the first 8 members of the dataset were overlaid by the
expanded PDS directory.
Lessons to be learned:
0. Before starting a procedure like this back up at least the tracks that
you'll be affecting, preferably take a full-pack image copy. That way you can
get back to where you started if you mess up. (see Step 4 above)
1. Never assume that a dataset is being properly backed up.
2. Try to keep your datasets in single extents.
3. NEVER leave 'Confirm Data Set Delete' disabled in your TSO
session!!!!!!! (We all turn it off at times, but make sure you turn it back on
immediately)
Format of a PDS
Mem1 mem2 mem3
Mem4
Mem1
Mem2
Mem3
Mem4
Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of
Sarel Swanepoel
Sent: Monday, July 09, 2007 9:20 AM
To: [email protected]
Subject: Re: Deleted PDS
NB: This email and its contents are subject to our email legal notice which can
be viewed at http://www.sars.gov.za/Email_Disclaimer.pdf
----
Hi
One of our guys has mistakenly deleted a PDS for which we have no backups at
all (naming standards point to a dev PDS but it is a production PDS).
We know on what volume the dataset was cataloged and the storage administrator
has 'DISNEW' the SMS volume in order to prevent any new allocations in order to
recover it.
Could anyone with tips on the recovery process please let us know of it as the
storage administrator will try and recover the PDS tomorrow?
Kind Regards,
Sarel Swanepoel
Service Availability: Service & Business Capacity Management
South African Revenue Services
Office:
+27 (0)12 422 5033
Mobile:
+27 (0)82 4927 321
Fax:
+27 (0)12 422 6068
Email:
[EMAIL PROTECTED]
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
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
