UNABLE TO COPY PDS.

[John Dawes]

G'Day,

Just wondering if it is possible to copy a pds with the following attributes:

INPUT DSN:

RECFM=U
LRECL=137
BLKSIZE=32760

OUTPUT DSN:
REDFM=VBA
LRECL=137
BLKSIZE=27920

Below are the error messages:

IEB120I INDD VALIDATION ERROR
IEB127I RECFM INCOMPATIBLE -- INPUT RECFM=U OUTPUT RECFM=VBA

The reason for my madness is that the INPUT dsn was corrupted i.e. I/O error when browsing a member.

I ran the following jcl (which was posted about 3 years ago) to fix a problem with a pds i.e. I/O ERROR.

/*
//GENER EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD *
X
//SYSUT2 DD DSN=PFAX.APPL.JCL.COPY2(X1),DISP=OLD,
// DCB=(LRECL=133,RECFM=U,BLKSIZE=32760)
//

Can IEBCOPY be used or should I use another utility? Could someone suggest a solution. Thanks.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

[retired mainframer]

Does the problem occur with only one member? Is the presumed corruption in the member or is it in the directory?

Consider what would have happened if this had worked. An input record which consists of
BDW-RDW-data-RDW-data...
would be treated as monolithic due to the RECFM=U. The resulting output record would have a single RDW inserted in front as a result of the RECFM=VBA and would look like
RDW- BDW-RDW-data-RDW-data...
This would be barely browsable. Furthermore, several such records would be combined into a single output block and look like
BDW- RDW- BDW-RDW-data-RDW-data...- RDW- BDW-RDW-data-RDW-data...

Also consider the fact that it is very likely many input records (actually blocks of original PDS records) would exceed the 133 byte limit for an output record. Even if the output software did not catch this, any subsequent attempt to read such a record would result in a "WRONG LENGTH RECORD" error from the deblocking function.

[Willie Bunter]

I browsed most of the members and I am getting the I/O errors.

[Mark Steely]

Is it possible the DCB was overwritten. Do you have a way to determine if the recfm, lrecl & blksize has changed and that’s why the I/O's error are occurring.

******* CONFIDENTIALITY NOTICE *******

This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you.

[Paul Gilmartin]

On Fri, 7 Nov 2014 07:13:11 -0800, John Dawes wrote:
>
>Just wondering if it is possible to copy a pds with the following attributes:
>
>INPUT DSN:
>
>RECFM=U
>LRECL=137
>BLKSIZE=32760
>
>OUTPUT DSN:
>REDFM=VBA
>LRECL=137
>BLKSIZE=27920
>

I have done this with some success with IDCAMS/TSO REPRO. It
depends on having no block in the input larger than 32752
(32760-BDW-RDW). I'd use:

OUTPUT DSN:
RECFM=VBA /* ANSI Carriage control? Really? */
LRECL=32756
BLKSIZE=32760

If it succeeds, then what would you do?

>Below are the error messages:
>
>IEB120I INDD VALIDATION ERROR
>IEB127I RECFM INCOMPATIBLE -- INPUT RECFM=U OUTPUT RECFM=VBA
>
>The reason for my madness is that the INPUT dsn was corrupted i.e. I/O error when browsing a member.
>

Browse!? Browse shouldn't update the data set!

>I ran the following jcl (which was posted about 3 years ago) to fix a problem with a pds i.e. I/O ERROR.
>
>/*
>//GENER EXEC PGM=IEBGENER
>//SYSPRINT DD SYSOUT=*
>//SYSIN DD DUMMY
>//SYSUT1 DD *
>X
>//SYSUT2 DD DSN=PFAX.APPL.JCL.COPY2(X1),DISP=OLD,
>// DCB=(LRECL=133,RECFM=U,BLKSIZE=32760)
>//

I'm surprised; I would have expected the IEB127I here. That technique
is intended to restore corrupted DCB attributes in the label.

>Can IEBCOPY be used or should I use another utility? Could someone suggest a solution. Thanks.
>

What's your plan of attack?

-- gil

[CM Poncelet]

I guess that the PDS directory has been corrupted. If so, try reading
the PDS as a sequential file to extract/dump the directory
(RECFM=VB,BLKSIZE=256) and check that.

If it fails try resetting the PDS directory by opening it for output and
then closing it, e.g. with something like this:

*********************************************************************
00000100
* OPEN A PDS FOR OUTPUT THEN CLOSE IT TO RESTORE DIRECTORY. *
00000200
* *
00000500
*********************************************************************
00000600
*
00000700
* CREATED: CHRIS PONCELET 01/02/20
00002500
*
00002600
*********************************************************************
00002700
*
00002800
PRINT ON,NOGEN
00002900
*
00003000
EQUREGS REGITER EQUATES
00003100
*
00003200
PDSRESET CSECT START CONTROL SECTION
00003300
*
00003400
BEGIN STM R14,R12,12(R13) SAVE REGISTERS 14->12 TO OFFSET 12
00006300
LR R11,R15 LOAD ENTRY POINT LOCATION INTO R11
00006400
USING PDSRESET,R11 DEFINE R11 AS BASE REGISTER
00006500
ST R13,SAVEBLK+8 SAVEAREA BACKWARD POINTER
00006600
LR R6,R13
00006700
LA R13,SAVEBLK
00006800
ST R13,4(,R6) SAVEAREA FORWARD POINTER
00006900
*
00007000
* OPEN PDS DIRECTORY
00019000
*
00019100
OPEN (PDS,(OUTPUT))
00019200
*
00019300
* CLOSE PDS DIRECTORY
00019400
*
00019500
EOJ CLOSE (PDS)
00022200
*
00022300
FINISH L R13,SAVEBLK+8 RESTORE R13 FROM SAVE ADDRESS AREA
00022400
LM R14,R12,12(R13) RESTORE REGISTERS
00022500
XR R15,R15 CLEAR RETURN CODE
00022600
BR R14 RETURN CONTROL TO OPERATING SYSTEM
00022700
*
00022800
**********************************************************************
00022900
******** END OF PROGRAM CODE PROPER **********************************
00023000
**********************************************************************
00023100
*
00023200
**********************************************************************
00023300
******** FILES *******************************************************
00023400
**********************************************************************
00023500
*
00023600
* DEFINE PDS (BPAM)
00023700
* N.B. SEE 'DATA ADMINISTRATION : MACRO REF' FOR DETAILS
00023800
*
00023900
PDS DCB DDNAME=PDS,
*00025900
DSORG=PO,
*00026000
EODAD=EOJ, ADDRESS FOR BRANCHING, AT EOF
*00026100
MACRF=(W) WRITE
00026200
*
00026300
**********************************************************************
00031500
******** DEFINE SAVE AREA FOR THIS PROGRAM ***************************
00031600
**********************************************************************
00031700
*
00031800
SAVEBLK DC 18F'0' 18 FULLWORDS INITIALISED TO 0
00031900
*
00032000
**********************************************************************
00032100
******** THAT'S IT ***************************************************
00032200
**********************************************************************
00032300
*
00032400
END PDSRESET SPECIFY ENTRY POINT
00032500

BTW No idea whether this still works, so proceed with caution.

Cheers, CP

[retired mainframer]

I'm confused. The original message came from John Dawes. How (and why) did you get access to his PDS?

In any event, I suggest you use IEBPTPCH to dump the directory treating it as a sequential file with RECFM=U and BLKSIZE=32760. Verify that the TTRs for the members look reasonable.

Repeat the dump (same DCB attributes) for a member you cannot read. Verify the BDW and RDWs are consistent with the assumed DCB of the PDS. Also verify the data looks reasonable for the member (it appears to be a print file of some kind).

>-----Original Message-----
>From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
>On Behalf Of Willie Bunter
>Sent: Friday, November 7, 2014 7:58 AM
>To: IBM-...@LISTSERV.UA.EDU
>Subject: Re: UNABLE TO COPY PDS.
>

[Lizette Koehler]

I apologize for not having read the whole thread. So I might be repeating information

typically when someone uses a utility like IEBGENER with DCB attributes it will cause this type of error.

If you have a backup of the file, bring it back down to dasd and look at the attributes. Is it the same as the broken file. Keep a list of members you can browse before you fix the dataset. Those will probably need to be fixed after the PDS is fixed.

If not, then use IEBGENER to add a dummy member and include the correct DCB on the SYSUT2 dataset.

If the good file has LRECL=80, BLKSIZE=32760, RECFM=FB, DSORG=PO

Then your SYSUY2 in the IEBGENER is

//SYSUT2 DD DSN=MY.PDS(DUMMY1),DISP=SHR,
// DSORG=PO,LRECL=80,BLKSIZE=32760,RECFM=FB

This should correct the error in the PDS. Never use IEBGENER for a PDS. ALWAYS use IEBCOPY. It will save the pain of this type of problem. you then need to find the member that changed the DCB Attributes.

Lizette

[Robert A. Rosenberg]

At 07:13 -0800 on 11/07/2014, John Dawes wrote about UNABLE TO COPY PDS.:

><x-charset utf-8>G'Day,

>
>Just wondering if it is possible to copy a pds with the following attributes:
>
>INPUT DSN:
>
>RECFM=U
>LRECL=137
>BLKSIZE=32760
>
>OUTPUT DSN:
>REDFM=VBA
>LRECL=137
>BLKSIZE=27920
>
>Below are the error messages:
>
>IEB120I INDD VALIDATION ERROR                             
>IEB127I RECFM INCOMPATIBLE -- INPUT RECFM=U OUTPUT RECFM=VBA

Try adding DCB=(BLKSIZE=32760,RECFM=VBA,LRECL=137) to the Input DD and put
DCB=(BLKSIZE=27920,RECFM=VBA,LRECL=137) on the Output DD and run your
IEBCOPY again. Note that you need to create a new dataset as output.
See if that
fixes the situation so the new output dataset is usable.

>
>The reason for my madness is that the INPUT dsn was corrupted i.e.
>I/O error when browsing a member.
>
>I ran the following jcl (which was posted about 3 years ago) to fix
>a problem with a pds i.e. I/O ERROR.
>
>/*                                                      
>//GENER EXEC PGM=IEBGENER                               
>//SYSPRINT DD SYSOUT=*                                  
>//SYSIN DD DUMMY                                        
>//SYSUT1 DD *                                           
>X                                                       
>//SYSUT2 DD DSN=PFAX.APPL.JCL.COPY2(X1),DISP=OLD,       
>// DCB=(LRECL=133,RECFM=U,BLKSIZE=32760)               
>//                                                      
>
>Can IEBCOPY be used or should I use another utility? Could someone
>suggest a solution. Thanks.
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

></x-charset>

[R.S.]

W dniu 2014-11-07 o 16:13, John Dawes pisze:

> G'Day,
>
> Just wondering if it is possible to copy a pds with the following attributes:
>
> INPUT DSN:
>
> RECFM=U
> LRECL=137
> BLKSIZE=32760
>
> OUTPUT DSN:
> REDFM=VBA
> LRECL=137
> BLKSIZE=27920
>
>

I think nobody pointed this: RECFM=U means there are no records. In that
case LRECL field is simply N/A. It doesn't matter what the LRECL is,
although usually it is left/set to 0.
So - while it seems you try to copy 137-byte records from one PDS to
another it is NOT TRUE.
Of course potential errors in the PDS complicates it further.

HTH

--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kon...@mBank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote.

[R.S.]

W dniu 2014-11-07 o 16:13, John Dawes pisze:

> G'Day,
>
> Just wondering if it is possible to copy a pds with the following attributes:
>
> INPUT DSN:
>
> RECFM=U
> LRECL=137
> BLKSIZE=32760
>
> OUTPUT DSN:
> REDFM=VBA
> LRECL=137
> BLKSIZE=27920
>
>

(appendix).

First, try to copy the PDS to another RECFM=U PDS, or simply use LIKE=
JCL construct. In case of errors copy selected members.

--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kon...@mBank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote.

[Gibney, Dave]

I interpreted the original post as an attempt to recover from the classic mistake writing to a PDS using IEBGENER.
I suspect the original PDS, before corruption, was VBA137. With BLKSIZE 27920. The correct fix is to write a new member using IEBGNER and the correct DCB specified on SYSUT2. Given that there may have been other attempts at fixing this, I hope the OP has been working with a copy. Corrupting corruption is rarely a step in the right direction.

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of R.S.
> Sent: Friday, November 07, 2014 1:45 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: UNABLE TO COPY PDS.
>

[Shmuel Metz , Seymour J.]

In <545D3CC7...@bremultibank.com.pl>, on 11/07/2014

at 10:42 PM, "R.S." <R.Sko...@BREMULTIBANK.COM.PL> said:

>I think nobody pointed this: RECFM=U means there are no records.

What are you smoking?

--
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)

[Clark Morris]

On 8 Nov 2014 15:12:45 -0800, in bit.listserv.ibm-main Shmuel wrote:

>In <545D3CC7...@bremultibank.com.pl>, on 11/07/2014
> at 10:42 PM, "R.S." <R.Sko...@BREMULTIBANK.COM.PL> said:
>
>>I think nobody pointed this: RECFM=U means there are no records.
>
>What are you smoking?
>

I think the poster meant that each block is a unique record and that
for RECFM=U, RECSIZE is irrelevant and in many DSCBs, can be 0. This
of course means that when copying to another file, the block size of
the RECFM=U data set must be less than the record size of the
non-RECFM=U data set.

Clark Morris

[Shmuel Metz , Seymour J.]

In <v3ft5a97iuncjdk4h...@4ax.com>, on 11/08/2014

at 09:04 PM, Clark Morris <cfmp...@NS.SYMPATICO.CA> said:

>I think the poster meant that each block is a unique record and
>that for RECFM=U, RECSIZE is irrelevant and in many DSCBs, can
>be 0.

That's quite different from what he wrote.

>This of course means that when copying to another file,

The Devil is in the details. In this context, what do you mean by
"copy". What kind of file? FB? VB.

>the block size of the RECFM=U data set must be less than the
>record size of the non-RECFM=U data set.

If you are adding a BDW and an RDW to the record, then that is true.
If you are assumeing that the record was intended to be VB and that it
already contains a BDW and RDW, then that is false. D doesn't seem to
be an option for DASD, FB isn't relevant unless the U is really FB.

--
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)

[Vern]

The suggestions above about IEBGENER and SYSUT2 DCB is the way to go. There's a good chance this is how it got corrupted in the first place.

[John Dawes]

Willie answered for me on my behalf because I wasn't receiving Yahoo mail . Thanks Willie.

[John Dawes]

Dave,

Finally Yahoo e-mail is functioningg. I was not receiving any e-mails from IBM-MAIN0 Thanks Willie for helpin out.

You are correct. The PDS was corrupted i.e. every member I browsed gave an I/O error message. I used IEBGENER to correct the problem which I had gleaned from the archive files. If I understand you correctly there was no need to change the DCB of the corrupted dsn. All I had to do was wrie a new member in the pds.
Can I revert back from RECFM=U to RECFM=VBA etc? Or all is lost?


--------------------------------------------

On Fri, 7/11/14, Gibney, Dave <gib...@WSU.EDU> wrote:

Subject: Re: UNABLE TO COPY PDS.

To: IBM-...@LISTSERV.UA.EDU
Received: Friday, 7 November, 2014, 4:57 PM

[John Dawes]

Robert,

I tried your suggestion. I preallocated the dsn (via ISPF 3.2) and included the DCB in the IEBCOPY job as well.
I received the error :
IEB132I INVALID RE/DE-BLOCKING. INPUT BLKSIZE IS 32760, OUTPUT BLKSIZE IS 27920
IEB151I JOB HAS TERMINATED WITH ERROR(S)

[John Dawes]

Lizette,

Sorry, there is no backup file. I will keep your suggestion if this problem props up again.

Thank you.
--------------------------------------------

On Fri, 7/11/14, Lizette Koehler <star...@MINDSPRING.COM> wrote:

Subject: Re: UNABLE TO COPY PDS.

To: IBM-...@LISTSERV.UA.EDU
Received: Friday, 7 November, 2014, 3:56 PM

[John Dawes]

I checked if that was the case but no, the DCB was intact.
--------------------------------------------

On Fri, 7/11/14, Mark Steely <Mark....@WNCO.COM> wrote:

Subject: Re: UNABLE TO COPY PDS.

To: IBM-...@LISTSERV.UA.EDU
Received: Friday, 7 November, 2014, 11:00 AM

[Lizette Koehler]

If you have dfhsm and this is a critical file, I would have dfhsm do backups of it. They can be done everytime the file is changed.

Or if you have pdsman with fastcopy from CA, backups can be created on data changing in the pds

Lizette

-----Original Message-----
>From: John Dawes <jhn_...@YAHOO.COM.AU>
>Sent: Nov 11, 2014 10:56 AM
>To: IBM-...@LISTSERV.UA.EDU
>Subject: Re: UNABLE TO COPY PDS.
>

>Lizette,
>
>Sorry, there is no backup file. I will keep your suggestion if this problem props up again.
>
>Thank you.
>--------------------------------------------

>On Fri, 7/11/14, Lizette Koehler <star...@MINDSPRING.COM> wrote:
>
> Subject: Re: UNABLE TO COPY PDS.
> To: IBM-...@LISTSERV.UA.EDU

> Received: Friday, 7 November, 2014, 3:56 PM
>
> I apologize for not having read the
> whole thread. So I might be repeating information
>
> typically when someone uses a utility like IEBGENER with DCB
> attributes it will cause this type of error.
>
> If you have a backup of the file, bring it back down to dasd
> and look at the attributes.  Is it the same as the
> broken file.  Keep a list of members you can browse
> before you fix the dataset.  Those will probably need
> to be fixed after the PDS is fixed.
>
> If not, then use IEBGENER to add a dummy member and include
> the correct DCB on the SYSUT2 dataset.
>
> If the good file has LRECL=80, BLKSIZE=32760,
> RECFM=FB,  DSORG=PO
>
> Then your SYSUY2 in the IEBGENER is
>
> //SYSUT2   DD DSN=MY.PDS(DUMMY1),DISP=SHR,
> //           
> DSORG=PO,LRECL=80,BLKSIZE=32760,RECFM=FB
>
> This should correct the error in the PDS.  Never use
> IEBGENER for a PDS.  ALWAYS use IEBCOPY.  It will
> save the pain of this type of problem.  you then need
> to find the member that changed the DCB Attributes.
>
> Lizette
>
>
>

> >>-----Original Message-----
> >>From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> >>On Behalf Of Willie Bunter
> >>Sent: Friday, November 7, 2014 7:58 AM
> >>To: IBM-...@LISTSERV.UA.EDU
> >>Subject: Re: UNABLE TO COPY PDS.
> >>
> >>I browsed most of the members and I am getting the
> I/O errors.
> >
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access
> instructions,
> send email to list...@listserv.ua.edu
> with the message: INFO IBM-MAIN
>
>

[Gibney, Dave]

If as you said, you used IEBGENER (writing a NEW member using the correct DCB) to "correct" the problem and you still can't read the members, then it is probably not fixable.

Can you use absolute track addressing (ABSTRK it think, see JCL manual) and IDCAMS PRINT, or FDR DUMP, or ?? to read and reconstitute the data programmatically?

[David Mingee]

You might try the util PDS86, if you do not have it you can download it from CBT - http://www.cbttape.org/
It has a FIXPDS option and other options that might be helpful.




David Mingee
Mainframe Consulting
9206 Aintree Drive
Indianapolis, IN 46250

317 288-9588 Home
317 903-9455 Cell

[Paul Gilmartin]

On Fri, 7 Nov 2014 13:56:56 -0700, Lizette Koehler wrote:
>
>... Never use IEBGENER for a PDS. ALWAYS use IEBCOPY. ...
>
Can IEBCOPY create a PDS member from a PS data set?

I believe IEBGENER is safe provided the user doesn't override
attributes of the PDS.

On Tue, 11 Nov 2014 09:58:25 -0800, John Dawes wrote:

>I checked if that was the case but no, the DCB was intact.
>--------------------------------------------

>On Fri, 7/11/14, Mark Steely wrote:
> Received: Friday, 7 November, 2014, 11:00 AM
>
> Is it possible the DCB was
> overwritten. Do you have a way to determine if the recfm,
> lrecl & blksize has changed and that’s why the I/O's
> error are occurring.
>
> -----Original Message-----

> On Behalf Of Willie Bunter

> Sent: Friday, November 07, 2014 9:58 AM.

>
> I browsed most of the members and I am getting the I/O
> errors.
>

Are any members readable? If no members are readable, what
evidence have you that the DCB is intact?

-- gil

[Lizette Koehler]

If the user does not remember to put in a MEMBER name in the SYSUT2, then IEBGENER will trash the directory.

IEBCOPY us safer to use for a PDS.

Lizette

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Tuesday, November 11, 2014 2:31 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: UNABLE TO COPY PDS.
>

[Paul Gilmartin]

On 2014-11-11 17:41, Lizette Koehler wrote:
> If the user does not remember to put in a MEMBER name in the SYSUT2, then IEBGENER will trash the directory.
>

Ummm. No:

SDSF OUTPUT DISPLAY TRASHDIR JOB07246 DSID 103 LINE 0
COMMAND INPUT ===>
********************************* TOP OF DATA *****************
DATA SET UTILITY - GENERATE
IEB367I SYSUT2 MEMBER NAME NOT SPECIFIED FOR PDS
******************************** BOTTOM OF DATA ***************
(z/OS 1.13)

Can't even break it with //SYSUT2 DD DSORG=PS,...
I more frequently cause myself the problem because I forget that
the target is a PDS than because I omit (member).

Maybe they fixed something!? Nah. That would be incompatible.

> IEBCOPY us safer to use for a PDS.
>

I generally agree. But how do you use IEBCOPY to add a member
from a PS data set to a PDS. IEBGENER does it fine (untested,
today.) I suppose there's LMCOPY. PITA. And that doesn't
work if the source is a UNIX file. Or a tape data set. Or
anything else without a F1 DSCB.

[CM Poncelet]

Just a couple of points.

* The IEBGENER to a <PDS.>(member) will most likely have made the
situation worse by *not* restoring the original (corrupted)
directory but instead creating a new one. If so, and if the
IEBGENER was run against the original PDS (instead of against a
'mirror image' copy of it), then try to restore the original PDS
from an earlier full DASD volume backup and start again.
* Copy the restored original PDS to a different DSN and apply/verify
all tentative fixes only to the copy and *not* to the original PDS
itself. This copy could be done by IEBCOPY'ing the PDS to a flat
file and then IEBCOPY'ing this flat file to a new PDS with a JCL
LIKE=<original PDS>. If that fails, try backing up the original
PDS via PGM=ADRDSSU and restoring it from the ADRDSSU backup to a
new PDS DSN - then verify any would-be fix on the copy before
fixing the PDS itself.
* As regards "Can I revert back from RECFM=U to RECFM=VBA etc? Or
all is lost?", the 'A' in 'VBA' means the records have an ASA
print control character in their first byte. But RECFM=U is for
load modules (LMODs). They have no ASA printchars in their first
byte. So trying to convert them to VBAs, for 'printing purposes',
would just produce unprintable garbage. As has been mentioned
earlier, use "PGM=IEBPTPCH" with a SYSIN of
"PRINT,PREFORM=A,TYPORG=PO,TOTCONV=XE,<etc.>" if you want to print
your PDS LMODs ... although this is likely to fail if your PDS
directory has been corrupted (and it probably has). If so, to dump
your PDS directrory, read/print your PDS as a sequential file
(from memory e.g. using IDCAMS PRINT or similar) and bear in mind
that a PDS directory has RECFM=VB,BLKSIZE=256 and not
RECFM=U,BLKSIZE=32760.
* If none of that helps, let me know offline and I can send you some
assembler source to read your PDS and dump it in IPCS-readable
format (LRECL=BLKSIZE=4160). But you will have to assemble and
link-edit it beforehand. It might be quicker to tidy-up, assemble,
link-edit and then run whatever 'PDS directory fixer' code I
posted earlier - but then run only against a *copy* of your PDS
(so as to check that it still works) and verify that.


Cheers, CP (retired sysprog)

[Paul Gilmartin]

On Wed, 12 Nov 2014 02:49:45 +0000, CM Poncelet wrote:

>Just a couple of points.
>
> * The IEBGENER to a <PDS.>(member) will most likely have made the
> situation worse by *not* restoring the original (corrupted)
> directory but instead creating a new one. If so, and if the
> IEBGENER was run against the original PDS (instead of against a
> 'mirror image' copy of it), then try to restore the original PDS
> from an earlier full DASD volume backup and start again.
>

No. It will add an entry for a new member in the existing directory
or update the entry for an existing member. It will update the label
(F1 DSCB?) if the attributes different.

> * Copy the restored original PDS to a different DSN and apply/verify
> all tentative fixes only to the copy and *not* to the original PDS
> itself. This copy could be done by IEBCOPY'ing the PDS to a flat
> file and then IEBCOPY'ing this flat file to a new PDS with a JCL
> LIKE=<original PDS>.
>

Won't IEBCOPY itself restore the attributes. Will it fail if the attributes
are incompatible?

> ... If that fails, try backing up the original

> PDS via PGM=ADRDSSU and restoring it from the ADRDSSU backup to a
> new PDS DSN - then verify any would-be fix on the copy before
> fixing the PDS itself.

> * ... But RECFM=U is for load modules (LMODs).
>
Or whatever else the programmer chooses to use it for.

[CM Poncelet]

Paul Gilmartin wrote:

>On Wed, 12 Nov 2014 02:49:45 +0000, CM Poncelet wrote:
>
>
>
>>Just a couple of points.
>>
>> * The IEBGENER to a <PDS.>(member) will most likely have made the
>> situation worse by *not* restoring the original (corrupted)
>> directory but instead creating a new one. If so, and if the
>> IEBGENER was run against the original PDS (instead of against a
>> 'mirror image' copy of it), then try to restore the original PDS
>> from an earlier full DASD volume backup and start again.
>>
>>
>>
>No. It will add an entry for a new member in the existing directory
>or update the entry for an existing member. It will update the label
>(F1 DSCB?) if the attributes different.
>

It will add a new member, or update the entry for an existing member, if
the 'existing directory' still exists as a directory (and does not need
to be restored). But I am not sure it exists. If I understood correctly,
after the IEBGENER, there was only 1 member in the PDS (from an earlier
posting "If as you said, you used IEBGENER (writing a NEW member using

the correct DCB) to "correct" the problem and you still can't read the

members, then it is probably not fixable.") The question is, what is the
sequence of events that preceded 'UNABLE TO COPY PDS' - i.e. what was
the PDS when it could be copied?

>
>
>
>> * Copy the restored original PDS to a different DSN and apply/verify
>> all tentative fixes only to the copy and *not* to the original PDS
>> itself. This copy could be done by IEBCOPY'ing the PDS to a flat
>> file and then IEBCOPY'ing this flat file to a new PDS with a JCL
>> LIKE=<original PDS>.
>>
>>
>>
>Won't IEBCOPY itself restore the attributes. Will it fail if the attributes
>are incompatible?
>

That depends on what the problem is. E.g. a PDS can be created/populated
with RECFM=FB,LRECL=80,etc. A member can then be specified as the
SYSPRINT output of running, say, a batch LISTCAT. The LISTCAT output
with RECFM=FBA,LRECL=133 (if memory serves) will then be browsable in
the PDS, but the previous members (those with LRECL=80) will not. If the
PDS's DCB/DSCB is then overwritten to be RECFM=FB,LRECL=80, the original
members will be browsable again but now the LISTCAT member will not.
Writing members with DCB LRECL=8 to 27998, and with all permutations of
RECFM and BLKSIZE as well, would show there are 1,000's of ways of
corrupting a PDS even though it would still be a PDS. So, potentially
destructive 'fix' testing should be performed only on copies of the PDS
that has to be fixed - to avoid losing the original one while fixing it.
I do not know whether IEBCOPY would fail, but suggested using ADRDSSU if
it did. IEBCOPY could not restore a 'one size fits all' attribute to
cover both the FB80 and FBA133 ones above.

>
>
>
>>... If that fails, try backing up the original
>> PDS via PGM=ADRDSSU and restoring it from the ADRDSSU backup to a
>> new PDS DSN - then verify any would-be fix on the copy before
>> fixing the PDS itself.
>>
>>
>
>
>
>> * ... But RECFM=U is for load modules (LMODs).
>>
>>
>>
>Or whatever else the programmer chooses to use it for.
>

Of course. But when there is BLKSIZE=32760, then BLKSIZE=27920, then
RECFM=U, then RECFM=VBA, I try to make some sense of it.