Re: FW: Deleted PDS
In [EMAIL PROTECTED], on 07/23/2007 at 07:33 PM, J R [EMAIL PROTECTED] said: ITYM 64Ki-1. Yes. Thanks. -- 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: FW: Deleted PDS - K - kg - Kg
--snip-- Usually they mean binary kilo and mega, although it is not proper in aspect of IS standard. However this is different story: for example every RAM manufacturer use MB and GB instead of correct MiB and GiB. Probably because the i qualifier is relatively recent? I do remember Seagate and others using decimal capacities because it made their disks appear bigger (e.g., 65K tracks rather than 64K). --snip-- I would say that it is still so (the 160GB Samsung disk I bought has about 149 GiB capacity) and have never thought of it made their disks appear bigger as a reason. Isn't that so because disk capacity is not base 2 (i.e. base 1024) dependent? --snip-- BTW: In Europe we *say* kilo as abbreviation of kilogram, but we *write* it properly: kg, so assumption about kilograms is bad shot. Perhaps in your neck of the woods, but I spent fourteen years in Austria and saw plenty of stores with prices with just a K. And technically, it should be Kg, not kg, because the convention is to capitalize multiplicative prefixes. --snip-- K instead of kg: prices written manually with a chalk on small paper or wooden surfaces? Or maybe it is normal to me and I just did/do not perceived that? And I don't know what technically means in this context, but it is kg: URL: http://physics.nist.gov/cuu/Units/units.html The smallest capitalized prefix is M for mega: URL: http://physics.nist.gov/cuu/Units/prefixes.html Binary multiplicative prefixes are all capitalized. -- Zaromil -- 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: FW: Deleted PDS
R.S. wrote: J.R. is more right than guy before him. 64k or 64Ki can be interpreted as numbers. In this case we talk about ABSTR, so the value is NUMBER OF TRACKS, not bytes. It is *not* 65536B-1, it is 65536-1 tracks. While Seymour was wrong with KiB, as you note that should have been Ki tracks, I've never seen K or Ki used for plain numerics. I don't know whether it is proper or IBM approved, but IT people often use 64k or 16M as numbers. No unit specified. Number only. Maybe it's improper, but it is *common*. Sorry, but in forty-odd years I've never seen that. Usually they mean binary kilo and mega, although it is not proper in aspect of IS standard. However this is different story: for example every RAM manufacturer use MB and GB instead of correct MiB and GiB. Probably because the i qualifier is relatively recent? I do remember Seagate and others using decimal capacities because it made their disks appear bigger (e.g., 65K tracks rather than 64K). BTW: In Europe we *say* kilo as abbreviation of kilogram, but we *write* it properly: kg, so assumption about kilograms is bad shot. Perhaps in your neck of the woods, but I spent fourteen years in Austria and saw plenty of stores with prices with just a K. And technically, it should be Kg, not kg, because the convention is to capitalize multiplicative prefixes. Gerhard Postpischil Bradford, VT new e-mail address: gerhardp (at) charter (dot) net -- 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: FW: Deleted PDS
Gerhard Postpischil wrote: J R wrote: Yes, ABSTR is limited to 64KiB-1. ITYM 64Ki-1. You may think that, but he doesn't. K and Ki are prefixes, meaningless without a unit to modify. Kilo is the rare exception in Europe, where it's used as an abbreviation of Kilogram as a unit of mass and (incorrectly) weight; neither applies here. J.R. is more right than guy before him. 64k or 64Ki can be interpreted as numbers. In this case we talk about ABSTR, so the value is NUMBER OF TRACKS, not bytes. It is *not* 65536B-1, it is 65536-1 tracks. I don't know whether it is proper or IBM approved, but IT people often use 64k or 16M as numbers. No unit specified. Number only. Maybe it's improper, but it is *common*. Usually they mean binary kilo and mega, although it is not proper in aspect of IS standard. However this is different story: for example every RAM manufacturer use MB and GB instead of correct MiB and GiB. BTW: In Europe we *say* kilo as abbreviation of kilogram, but we *write* it properly: kg, so assumption about kilograms is bad shot. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: FW: Deleted PDS
In [EMAIL PROTECTED], on 07/11/2007 at 12:51 PM, Sarel Swanepoel [EMAIL PROTECTED] said: I dumped the full volume using the tracks option and restored it on an empty volume on our test system. I located the PDS at location ** TRACK(CCHH) 1A58 R0 DATA COUNT 1A58010005A0 R0 is irrelevant for a PDS. Does R1 have a key length of 8 and a data length of 256? If not, you don't have a directory there. When I used this as the track address I am getting a JCL error. Yes, ABSTR is limited to 64KiB-1. I am also confused with what I checked in the JCL manual. The manual says that the primary space allocation is in tracks and not cylinders what manual, where, for what context? The primary quantity can be in any units supported by the SPACE keyword of DD, one of which is ABSTR. In the case of ABSTR there is no provision for a secondary quantity. -- 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: FW: Deleted PDS
Yes, ABSTR is limited to 64KiB-1. ITYM 64Ki-1. From: Shmuel Metz (Seymour J.) [EMAIL PROTECTED] Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FW: Deleted PDS Date: Mon, 23 Jul 2007 11:01:26 -0300 In [EMAIL PROTECTED], on 07/11/2007 at 12:51 PM, Sarel Swanepoel [EMAIL PROTECTED] said: I dumped the full volume using the tracks option and restored it on an empty volume on our test system. I located the PDS at location ** TRACK(CCHH) 1A58 R0 DATA COUNT 1A58010005A0 R0 is irrelevant for a PDS. Does R1 have a key length of 8 and a data length of 256? If not, you don't have a directory there. When I used this as the track address I am getting a JCL error. Yes, ABSTR is limited to 64KiB-1. I am also confused with what I checked in the JCL manual. The manual says that the primary space allocation is in tracks and not cylinders what manual, where, for what context? The primary quantity can be in any units supported by the SPACE keyword of DD, one of which is ABSTR. In the case of ABSTR there is no provision for a secondary quantity. -- 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) _ http://newlivehotmail.com -- 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: FW: Deleted PDS
J R wrote: Yes, ABSTR is limited to 64KiB-1. ITYM 64Ki-1. You may think that, but he doesn't. K and Ki are prefixes, meaningless without a unit to modify. Kilo is the rare exception in Europe, where it's used as an abbreviation of Kilogram as a unit of mass and (incorrectly) weight; neither applies here. Gerhard Postpischil Bradford, VT new e-mail address: gerhardp (at) charter (dot) net -- 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
Track size and maximum single volume data set size (was: Deleted PDS)
Many types of data sets are limited to 65 535 total tracks allocated on any one volume, and if a greater number of tracks is required, this attempt to create a data set will fail. One could enlarge those data set if a new unit type with larger tracks would be defined. I admit I'm too busy (lazy) right now to RTFM but would appreciate any toughts on this (just curious). Why do we still keep the ~55k track size and increase only the number of cylinders? With modern DASD subsystems it shouldn't matter, right? What are the track size limits in z/OS? I guess it's 64k, but still this would be 16% more. Peter Hunkeler Credit Suisse -- 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: Track size and maximum single volume data set size (was: Deleted PDS)
In a message dated 7/12/2007 1:36:11 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Why do we still keep the ~55k track size and increase only the number of cylinders? With modern DASD subsystems it shouldn't matter, right? What are the track size limits in z/OS? I guess it's 64k, but still this would be 16% more This was discussed in great detail ca. 2 years ago. Check the archives. The technology is here. IBM is in charge of all this architecture. They need a strong business case to do anything massive. Bill Fairchild Plainfield, IL ** Get a sneak peak of the all-new AOL at http://discover.aol.com/memed/aolcom30tour -- 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: 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 Many thanks to everyone that contributed to the successful restore of the PDS, especially to Jon Veilleux. This is the reply from our Storage Administrator: Hi Jon, I managed to recover the dataset. I dumped the tracks I identified and restored them to another disk at a lower location using the OUTTRKS option on the restore. I appreciate all your assistance. Thanks for the help. Warm Regards, Mohan Hansjee [EMAIL PROTECTED] +27 83 461 2783 +27 12 422 6599 Kind Regards, Sarel Swanepoel Service Availability: Service Business Capacity Management -- 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
FW: 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 All The question below on behalf of our Storage Administrator. Any help will be appreciated. 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] -Original Message- From: Mohan Hansjee Sent: 11 July 2007 12:19 PM Cc: Sarel Swanepoel Subject: Deleted PDS I am attempting to recover the PDS. I dumped the full volume using the tracks option and restored it on an empty volume on our test system. I located the PDS at location ** TRACK(CCHH) 1A58 R0 DATA COUNT 1A58010005A0 6CD385A3 40E2A8A2 7EE5C1E3 5E404040 40404040 40404040 40404040 40404040 0020 40404040 40404040 40404040 40404040 40404040 40404040 40404040 40404040 0040 TO 009F SAME AS ABOVE When I calculated the track address as 101160 (X'1A58' = 6744 * 15 tracks). When I used this as the track address I am getting a JCL error. 1 //FASYS03I JOB (DBI,SYS1),MOE,CLASS=S,MSGCLASS=T,NOTIFY=SYSUID //* TYPRUN=HOLD IEFC653I SUBSTITUTION JCL - (DBI,SYS1),MOE,CLASS=S,MSGCLASS=T,NOTIFY=F 2 //STEP1 EXEC PGM=IEFBR14 3 //DD1INDD DSN=FASYS03.SAS.DQ.SOURCLIB, // DISP=(NEW,CATLG), // VOL=SER=SA8F2C,LRECL=80,BLKSIZE=27920,RECFM=FB,UNIT=3390, // SPACE=(ABSTR,(100,101160,20)) STMT NO. MESSAGE 3 IEF642I EXCESSIVE PARAMETER LENGTH IN THE SPACE FIELD The data is on a 3390-9. Would this be a problem? I am also confused with what I checked in the JCL manual. The manual says that the primary space allocation is in tracks and not cylinders as you showed in your example. (referring to the example from Jon L. Veilleux sent on Monday to IBM-MAIN) I would appreciate it if you assist me with this. -- 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: Deleted PDS
In the JCL manual z/OS V1.6, it states: Do not code ABSTR for SMS-managed data sets SPACE=(ABSTR,(...)). When the absolute track technique is used, the designated tracks must make up a whole number of cylinders So, my question is - Have you made sure this file name is no longer SMS managed? And have you confirmed that 20 DIR Blks is correct for this dataset? Did you allocate a space size that is equal to WHOLE Cylinders (15, 30, 90, etc... is a cylinder number in tracks) - 100 does not look to be a true cylinder size. A JCL error like this usually will detail the last good thing it scanned just before the error. Lizette Hi All The question below on behalf of our Storage Administrator. Any help will be appreciated. Kind Regards, I am attempting to recover the PDS. I dumped the full volume using the tracks option and restored it on an empty volume on our test system. I located the PDS at location ** TRACK(CCHH) 1A58 R0 DATA COUNT 1A58010005A0 6CD385A3 40E2A8A2 7EE5C1E3 5E404040 40404040 40404040 40404040 40404040 0020 40404040 40404040 40404040 40404040 40404040 40404040 40404040 40404040 0040 TO 009F SAME AS ABOVE When I calculated the track address as 101160 (X'1A58' = 6744 * 15 tracks). When I used this as the track address I am getting a JCL error. 1 //FASYS03I JOB (DBI,SYS1),MOE,CLASS=S,MSGCLASS=T,NOTIFY=SYSUID //* TYPRUN=HOLD IEFC653I SUBSTITUTION JCL - (DBI,SYS1),MOE,CLASS=S,MSGCLASS=T,NOTIFY=F 2 //STEP1 EXEC PGM=IEFBR14 3 //DD1INDD DSN=FASYS03.SAS.DQ.SOURCLIB, // DISP=(NEW,CATLG), // VOL=SER=SA8F2C,LRECL=80,BLKSIZE=27920,RECFM=FB,UNIT=3390, // SPACE=(ABSTR,(100,101160,20)) STMT NO. MESSAGE 3 IEF642I EXCESSIVE PARAMETER LENGTH IN THE SPACE FIELD The data is on a 3390-9. Would this be a problem? I am also confused with what I checked in the JCL manual. The manual says that the primary space allocation is in tracks and not cylinders as you showed in your example. (referring to the example from Jon L. Veilleux sent on Monday to IBM-MAIN) -- 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
FW: Deleted PDS (Reply)
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 The reply from Jon: Kind Regards, Sarel Swanepoel -Original Message- From: Veilleux, Jon L [mailto:[EMAIL PROTECTED] Sent: 11 July 2007 01:53 PM To: Mohan Hansjee Cc: Sarel Swanepoel Subject: RE: Deleted PDS I think that you have a problem with the track address due to this being a 3390-9. According to the z/OS 1.7 JCL manual the track address must be 65535 or less. They don't seem to have updated the code to accept larger DASD sizes. This seems like an oversight by IBM. I have a contact in IBM SMS development. I will see if they have any suggestions. In the mean time you might try the IBM-MAIN list again. Someone there might have a suggestion. address Specifies the track number of the first track to be allocated. Count the first track of the first cylinder on the volume as 0. Count through the tracks on each cylinder until you reach the track on which you want the data set to start. The absolute track address must be a decimal number equal to or less than 65535. I will let you know what I hear from IBM. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 From: Mohan Hansjee [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 11, 2007 6:19 AM To: Veilleux, Jon L Cc: Sarel Swanepoel Subject: 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 Jon, I am attempting to recover the dataset for Sarel. I dumped the full volume using the tracks option and restored it on an empty volume on our test system. I located the PDS at location ** TRACK(CCHH) 1A58 R0 DATA COUNT 1A58010005A0 6CD385A3 40E2A8A2 7EE5C1E3 5E404040 40404040 40404040 40404040 40404040 0020 40404040 40404040 40404040 40404040 40404040 40404040 40404040 40404040 0040 TO 009F SAME AS ABOVE When I calculated the track address as 101160 (X'1A58' = 6744 * 15 tracks). When I used this as the track address I am getting a JCL error. 1 //FASYS03I JOB (DBI,SYS1),MOE,CLASS=S,MSGCLASS=T,NOTIFY=SYSUID //* TYPRUN=HOLD IEFC653I SUBSTITUTION JCL - (DBI,SYS1),MOE,CLASS=S,MSGCLASS=T,NOTIFY=F 2 //STEP1 EXEC PGM=IEFBR14 3 //DD1INDD DSN=FASYS03.SAS.DQ.SOURCLIB, // DISP=(NEW,CATLG), // VOL=SER=SA8F2C,LRECL=80,BLKSIZE=27920,RECFM=FB,UNIT=3390, // SPACE=(ABSTR,(100,101160,20)) STMT NO. MESSAGE 3 IEF642I EXCESSIVE PARAMETER LENGTH IN THE SPACE FIELD The data is on a 3390-9. Would this be a problem? I am also confused with what I checked in the JCL manual. The manual says that the primary space allocation is in tracks and not cylinders as you showed in your example that you sent Sarel. I would appreciate it if you assist me with this. 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: FW: Deleted PDS
On Wed, 11 Jul 2007 12:51:43 +0200, Sarel Swanepoel wrote: 3 //DD1INDD DSN=FASYS03.SAS.DQ.SOURCLIB, // DISP=(NEW,CATLG), // VOL=SER=SA8F2C,LRECL=80,BLKSIZE=27920,RECFM=FB,UNIT=3390, // SPACE=(ABSTR,(100,101160,20)) STMT NO. MESSAGE 3 IEF642I EXCESSIVE PARAMETER LENGTH IN THE SPACE FIELD The JCL reference manual says, The absolute track address must be a decimal number equal to or less than 65535. -- Tom Marchant -- 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: FW: Deleted PDS
One thing that you can try is to use DFDSS to copy the tracks from their current location to a new location below the 65535 limit. The TRACKS and OUTTRACKS paramters SHOULD allow you to do this. Then you might be able to do the allocation using ABSTR. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant Sent: Wednesday, July 11, 2007 9:33 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FW: Deleted PDS On Wed, 11 Jul 2007 12:51:43 +0200, Sarel Swanepoel wrote: 3 //DD1INDD DSN=FASYS03.SAS.DQ.SOURCLIB, // DISP=(NEW,CATLG), // VOL=SER=SA8F2C,LRECL=80,BLKSIZE=27920,RECFM=FB,UNIT=3390, // SPACE=(ABSTR,(100,101160,20)) STMT NO. MESSAGE 3 IEF642I EXCESSIVE PARAMETER LENGTH IN THE SPACE FIELD The JCL reference manual says, The absolute track address must be a decimal number equal to or less than 65535. -- Tom Marchant -- 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
Re: FW: Deleted PDS
In a message dated 7/11/2007 5:53:55 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: I located the PDS at location ** TRACK(CCHH) 1A58 R0 DATA COUNT 1A58010005A0 6CD385A3 40E2A8A2 7EE5C1E3 5E404040 40404040 40404040 40404040 40404040 0020 40404040 40404040 40404040 40404040 40404040 40404040 40404040 40404040 0040 TO 009F SAME AS ABOVE Even worse than the absolute track number's being larger than 65535 is the fact that what you show at that track number does not look at all like a standard IBM PDS. If this is supposed to be the first track of the PDS, then either your PDS has been hosed (e.g., re-written) or you have not found the first track of it correctly. The Count field you show has a data length of 5A0, which is incorrect for a directory block, which should be 0100 (decimal 256). The data in that block looks seriously wrong for a directory block. The first 160 bytes which you show contain the following in EBCDIC/eyeball-readable form: 'Let Sys=VAT) (or something like that). This data is completely inconsistent with what should be in any block in a PDS directory. Bill Fairchild Plainfield, IL ** See what's free at http://www.aol.com. -- 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: FW: Deleted PDS
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of (IBM Mainframe Discussion List) Sent: Wednesday, July 11, 2007 9:04 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FW: Deleted PDS SNIP I've been kinda following this, and it leaves me with a question: Can a PDS even exist beyond track 65535? The directory entries are 0TTR, not TTTR, right? Regards, Steve Thompson -- 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: FW: Deleted PDS
---snip-- I've been kinda following this, and it leaves me with a question: Can a PDS even exist beyond track 65535? The directory entries are 0TTR, not TTTR, right? ---unsnip-- Yes, a PDS can exist beyond track 65535. The 0TTR value in the directory is relative to the begining of the dataset, not the volume. -- 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: FW: Deleted PDS
Rick Fochtman wrote: ---snip-- I've been kinda following this, and it leaves me with a question: Can a PDS even exist beyond track 65535? The directory entries are 0TTR, not TTTR, right? ---unsnip-- Yes, a PDS can exist beyond track 65535. The 0TTR value in the directory is relative to the begining of the dataset, not the volume. It doesn't look like a pds can be larger than 65535 tracks however. DATA SET AIMJ.TESTPDS NOT ALLOCATED+ IGD17051I ALLOCATION FAILED FOR DATA SET AIMJ.TESTPDS , PRIMARY SPACE EXCEEDS 65535 TRKS -- Mark Jacobs Technical Services Time Customer Service - Tampa, FL -- Victory in defeat, there is none higher. She didn't give up, Ben; she's still trying to lift that stone after it has crushed her. She's a father going down to a dull office job while cancer is painfully eating away his insides, so as to bring home one more pay check for the kids. She's a twelve-year-old girl trying to mother her baby brothers and sisters because Mama had to go to Heaven. She's a switchboard operator sticking to her job while smoke is choking her and the fire is cutting off her escape. She's all the unsung heroes who couldn't quite cut it but never quit.* Robert A. Heinlein - Stranger in a Strange Land *Referring to the Auguste Rodin sculpture, Caryatid Who Has Fallen under Her Stone -- 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: FW: Deleted PDS
On Wed, 11 Jul 2007 10:55:25 -0400, Mark Jacobs [EMAIL PROTECTED] wrote: It doesn't look like a pds can be larger than 65535 tracks however. DATA SET AIMJ.TESTPDS NOT ALLOCATED+ IGD17051I ALLOCATION FAILED FOR DATA SET AIMJ.TESTPDS , PRIMARY SPACE EXCEEDS 65535 TRKS I found out the hard way (i.e. not reading this bit in the MANUAL:) Many types of data sets are limited to 65 535 total tracks allocated on any one volume, and if a greater number of tracks is required, this attempt to create a data set will fail. Data sets that are not limited to 65 535 total tracks allocated on any one volume are: * Large format sequential * Extended-format sequential * UNIX files * PDSE * VSAM Seb -- 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: FW: Deleted PDS
Mark Jacobs wrote: Rick Fochtman wrote: ---snip-- I've been kinda following this, and it leaves me with a question: Can a PDS even exist beyond track 65535? The directory entries are 0TTR, not TTTR, right? ---unsnip-- Yes, a PDS can exist beyond track 65535. The 0TTR value in the directory is relative to the begining of the dataset, not the volume. It doesn't look like a pds can be larger than 65535 tracks however. DATA SET AIMJ.TESTPDS NOT ALLOCATED+ IGD17051I ALLOCATION FAILED FOR DATA SET AIMJ.TESTPDS , PRIMARY SPACE EXCEEDS 65535 TRKS Size is limited to 64 tracks, but not position on the volume. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: FW: Deleted PDS
In a message dated 7/11/2007 10:33:15 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: PRIMARY SPACE EXCEEDS 65535 TRKS Size is limited to 64 tracks, but not position on the volume. You obviously meant 64K tracks. The position on the volume is irrelevant if you allocate the PDS via some method other than ABSTR, in which case another constraint comes into play, namely the JCL restriction that ... the absolute track address must be a decimal number equal to or less than 65535. So sometimes position on the volume is limited to 64K. Bill Fairchild Plainfield, IL ** See what's free at http://www.aol.com. -- 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: FW: Deleted PDS
---snip-- Size is limited to 64 tracks, but not position on the volume. You obviously meant 64K tracks. The position on the volume is irrelevant if you allocate the PDS via some method other than ABSTR, in which case another constraint comes into play, namely the JCL restriction that ... the absolute track address must be a decimal number equal to or less than 65535. So sometimes position on the volume is limited to 64K. --unsnip- I didn't know that ABSTR could be used to allocate a PDS. Was I wrong?? -- 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: FW: Deleted PDS
In a message dated 7/11/2007 11:25:41 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: I didn't know that ABSTR could be used to allocate a PDS. Was I wrong?? The fact that the JCL Reference book has the following text means this combination is supported: SPACE=(ABSTR,(primary=qty,address[,directory]}. The author of this text omitted a necessary right parenthesis. The presence of the third positional operand called directory tells allocation to format the number of directory blocks that you indicated in that operand. If you try to allocate a new PDS via ISPF 3.4 and you indicate that the Data set name type is PDS but do not code a number of directory blocks, you will get a new PS allocated instead of a PO. If you use JCL and code DSORG=PO but do not give a directory value you will get a DSORG of PO, Data set name type of PDS, but with 0 directory blocks, which renders it unusable as a PDS. After creating this PDS wannabe, I tried to copy a member from a real PDS into the mutant PDS and got an I/O error on BLDL message. All of these experiments were done using SMS-managed new data sets. Bill Fairchild Plainfield, IL ** See what's free at http://www.aol.com. -- 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: FW: Deleted PDS
In a message dated 7/11/2007 12:03:42 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: SPACE=(ABSTR,(primary=qty,address[,directory]}. The author of this text omitted a necessary right parenthesis. And I couldn't even correctly copy the incorrect text. I meant SPACE=(ABSTR,(primary=qty,address[,directory]). Bill Fairchild Plainfield, IL ** See what's free at http://www.aol.com. -- 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: FW: Deleted PDS
I did it when I recovered the PDS in my earlier example Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Wednesday, July 11, 2007 12:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FW: Deleted PDS ---snip-- Size is limited to 64 tracks, but not position on the volume. You obviously meant 64K tracks. The position on the volume is irrelevant if you allocate the PDS via some method other than ABSTR, in which case another constraint comes into play, namely the JCL restriction that ... the absolute track address must be a decimal number equal to or less than 65535. So sometimes position on the volume is limited to 64K. --unsnip- I didn't know that ABSTR could be used to allocate a PDS. Was I wrong?? -- 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
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
Re: Deleted PDS
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 000301080100
C1C4E8E2 C5E3F0F2 00FE5B5B 5BC3D6C9 C2D40016 190F0A00 0083 34
0020 349F1701 00180018 E2E8 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 0133 0097323F 00
00A0 15230012 0012 E3F8E2D3 C2404040 4040C1C4 E8E2C5E3 F0F10028 0C
00C0 00200097 323F0097 323F1524 000B000B E3F8 E2D3C240 40404040 C1
00E0 C5E3F0F2 00280E0F 0120 0097323F 0097323F 15260012 0012 E3
0100 C2404040 4040
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 000301
REP C1C4E8E2,C5E3F0F2,00FE5B5B,5BC3D6C9
REP 0010 C2D40016,190F0A00,0083,349F0083
REP 0020 349F1701,00180018,E2E8,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,0133,0097323F,0097323F
REP 00A0 15230012,0012,E3F8E2D3,C2404040
REP 00B0 4040C1C4,E8E2C5E3,F0F10028,0C0F0100
REP 00C0 00200097,323F0097,323F1524,000B000B
REP 00D0 E3F8,E2D3C240,40404040,C1C4E8E2
REP 00E0 C5E3F0F2,00280E0F,0120,0097323F
REP 00F0 0097323F,15260012,0012,E3F8E2D3
REP 0100 C2404040,4040
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: IBM-MAIN@BAMA.UA.EDU
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
Re: Deleted PDS
Sarel i had this years ago with an SMPPTS dataset - and could recover it by doing an IEFBR14 with allocation specifying ABSTRK (absolute track allocation) . It is just like recreating the pointer to the dataset . If you know where it start and how large it was incl. Directory blocks this should work Frank Krueger Montag, 9. Juli 2007 15:43 To: IBM-MAIN@BAMA.UA.EDU cc: From: Sarel Swanepoel [EMAIL PROTECTED] Subject: Re: Deleted PDS 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. -- 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: Deleted PDS
First of all, you did the right thing by stopping future allocations, but you should also stop ANY DEFRAGS that may be automatically run. If you have RTD(Real Time Defrag) DFDSS or compactor running, don't run them against that pack. Do that first then we'll talk. I want to get this to you fast so I'll send the rest in another msg. Bill From: Sarel Swanepoel [EMAIL PROTECTED] Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Deleted PDS Date: Mon, 9 Jul 2007 15:20:24 +0200 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 _ http://liveearth.msn.com -- 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: Deleted PDS
In a message dated 7/9/2007 8:50:34 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: /STEP1 EXEC PGM=IEFBR14 //DD1INDDDSN=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? I don't understand the need to supply any DCB parameters, the number of directory blocks, or DSORG. After allocating the data set on top of the original PDS, you then zap the F1 DSCB for all the parameters you didn't supply. And the F1 does not contain the number of directory blocks anyway. This would result in a lot less error-prone work. Bill Fairchild Plainfield, IL ** See what's free at http://www.aol.com. -- 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: Deleted PDS
On 9 Jul 2007 06:43:19 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (Sarel Swanepoel) wrote: 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? Jon L. Veilleux's solution is close to what I did, but I think mine is easier. With multiple techniques, you can choose. Instead of listing open areas and trying to figure which was the dataset, I just ran IEFBR14s with MXIG DD allocations until I got all free space on the volume. Rather than DFDSS dumps, I used full-screen zap from the CBT tape until I found the data. Then I deleted the MXIG allocations. When allocating the dataset, use ABSTRK, but don't specify dsorg or number of directory blocks. Then use CDSCB (CBT tape, again) to make it PO with the correct number of directory blocks. Use PDS command (or Startools) to set the last used track (DLISTAR?) to the end. This should allow you to keep the directory as it was. Upon successful read of the dataset, immediately copy it and use the copy instead of the original from now on (in case there's something strange left from all of this diddling). There are possible gotchas, though, regardless of technique: 1. You may have to make the disk (or a copy of it) non-SMS in order to MXIG and/or ABSTRK. 2. New allocations on SMS volumes automatically write an EOF for some datasets. Try it out on another volume, first. 3. Worst: Some RAIDs do not necessarily allocate the same physical location for new allocations as for the old allocations of the same tracks. Some automatically clear data on new allocations. If yours is one of these, you may either be out of luck or forced to call the RAID manufacturer for help. Some things are easier with SLEDs. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot com -- 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: Deleted PDS
- Original Message - From: Sarel Swanepoel [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Monday, July 09, 2007 9:43 AM 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? FULLSCREEN ZAP (file 34?) at www.cbttape.org will recover files from free on a standard IBM disk drive (have not done this on RAID). Regards, Tom Conley -- 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: Deleted PDS
You are probably right but when we did this it was maybe 15-20 years since the last time we did it and there weren't any written procedures so we made some mistakes along the way. That was what led me to write the document. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of (IBM Mainframe Discussion List) Sent: Monday, July 09, 2007 10:57 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Deleted PDS In a message dated 7/9/2007 8:50:34 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: /STEP1 EXEC PGM=IEFBR14 //DD1INDDDSN=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? I don't understand the need to supply any DCB parameters, the number of directory blocks, or DSORG. After allocating the data set on top of the original PDS, you then zap the F1 DSCB for all the parameters you didn't supply. And the F1 does not contain the number of directory blocks anyway. This would result in a lot less error-prone work. Bill Fairchild Plainfield, IL ** See what's free at http://www.aol.com. -- 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
