PDS I/O ERROR

[Claudio]

I have I loadlib that when I try to compress it I got the following error
message:

IEB1021E 1E28,D,INPUT   ,READ  ,NO RECORD FOUND,039219,BSAM 
IEB1022I I/O ERROR ONDDN= VOL= DSN=
IEB1023I COPYMOD READ MEMBER=  TTR=X'029617' MBBCCHHR=X'4040

I then deleted member "" and run it again. The same error for
another member. What I need to know is if there is any utility that is able
to give me a list of all members in error. Any clue ?


Thanks in advance

Claudio 

--
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: PDS I/O ERROR

[Knutson, Sam]

The free PDS command has a VERIFY option that will do this.  Search the
archives using VERIFY and PDS as keywords to find some more detailed
posts.

http://www.cbttape.org/freepds.htm

You can grab file 035 for a load library that includes a current version
of PDS.

Best Regards, Sam

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Claudio 
Sent: Thursday, August 03, 2006 6:08 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: PDS I/O ERROR

I have I loadlib that when I try to compress it I got the following
error
message:

IEB1021E 1E28,D,INPUT   ,READ  ,NO RECORD FOUND,039219,BSAM 
IEB1022I I/O ERROR ONDDN= VOL= DSN=
IEB1023I COPYMOD READ MEMBER=  TTR=X'029617' MBBCCHHR=X'4040

I then deleted member "" and run it again. The same error for
another member. What I need to know is if there is any utility that is
able to give me a list of all members in error. Any clue ?


Thanks in advance

Claudio 

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
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: PDS I/O ERROR

[Ed Finnell]

 
In a message dated 8/3/2006 5:30:30 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

The free  PDS command has a VERIFY option that will do this.  Search  the
archives using VERIFY and PDS as keywords to find some more  detailed
posts.




>>
Yep, used it hundreds of times. Might be somebody did a GENER
instead of a COPY(from the x'4040's. Also IEHLIST with LISTVTOC might point  
to pointer problems on the pack. And a DIAGNOSE against the PACK and VTOC 
might  be in order. 

--
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: PDS I/O ERROR

[Arthur T.]

On 3 Aug 2006 15:08:38 -0700, in bit.listserv.ibm-main 
(Message-ID:<[EMAIL PROTECTED]>) 
[EMAIL PROTECTED] (Claudio ) wrote:


I have I loadlib that when I try to compress it I got the 
following error

message:

IEB1021E 1E28,D,INPUT   ,READ  ,NO RECORD 
FOUND,039219,BSAM 
IEB1022I I/O ERROR ONDDN= VOL= 
DSN=
IEB1023I COPYMOD READ MEMBER=  TTR=X'029617' 
MBBCCHHR=X'4040


I then deleted member "" and run it again. The 
same error for
another member. What I need to know is if there is any 
utility that is able

to give me a list of all members in error. Any clue ?


 Among the things I might try:

1.  Restore a backup copy with a new name.  (You *do* take 
backups, don't you?)  See if that's in good shape, and/or 
if there are any discrepancies (see below).


2.  Do some kind of image copy before making any further 
changes to the dataset.


3.  As already suggested, try the PDS command.  It may be 
useful for the following, too.


4.  Check the DCB attributes.  Has someone set the BLKSIZE 
lower?  If so, raise it back.  If not, did PDS VERIFY show 
some larger blocks, anyway?


5.  If some of the TTRs of members are beyond the end of 
used space, but within the extent(s), try resetting lastttr 
(I can't remember the PDS command for that, offhand).


6.  If the directory is cached, de-cache it or tell the 
system to recreate its cache.


7.  Check record types 14 and 15 to see last good accesses, 
first bad access, and what happened in between.  This could 
be useful even if you've fixed the dataset, as you might 
need to make some procedure changes so this kind of thing 
doesn't happen again.


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

CORRUPT PDS - I/O ERROR

[esmie moo]

Good Morning Gentle Readers,
 
When I try to browse a member of  my pds I get a I/O error.  I tried browsing 
several members but I get the same error message.  Is there a way of fixing 
it?  For some reason the storage group is NOT backed up so I cannot restore it 
from an old backup.  I recovered the PDS from a DFHSM backup but when I try to 
browse any members I still get the I/O error.  Is there a work around to this 
problem or should I consider it lost?
 
Thanks. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Starr, Alan]

There are many possibilities but first things first. A common cause of this is 
that somebody wrote a member and changed DCB attributes.

If you know what the DCB attributes are supposed to be (e.g. BLKSIZE and 
RECFM), check them.  Otherwise, do you have an older HSM backup that you can 
restore?

The DCB can be changed back by writing a new member (e.g. with IEBGENER) and 
specifying all DCB attributes.

If the aforementioned isn't the problem, please provide the text of the error 
message; others will probably have additional ideas.

Alan

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
esmie moo
Sent: Tuesday, July 26, 2011 10:03 AM
To: IBM-MAIN@bama.ua.edu
Subject: CORRUPT PDS - I/O ERROR

Good Morning Gentle Readers,
 
When I try to browse a member of  my pds I get a I/O error.  I tried browsing 
several members but I get the same error message.  Is there a way of fixing 
it?  For some reason the storage group is NOT backed up so I cannot restore it 
from an old backup.  I recovered the PDS from a DFHSM backup but when I try to 
browse any members I still get the I/O error.  Is there a work around to this 
problem or should I consider it lost?
 
Thanks. 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Lizette Koehler]

> 
>When I try to browse a member of  my pds I get a I/O error.  I tried browsing 
>several members but I get the same error message.  Is there a way of fixing 
>it?  For some reason the storage group is NOT backed up so I cannot restore it 
>from an old backup.  I recovered the PDS from a DFHSM backup but when I try to 
>browse any members I still get the I/O error.  Is there a work around to this 
>problem or should I consider it lost?
> 
>Thanks. 
>


First, check what the attributes should be.

If there is a backup of the file, I would download it and compare the LRECL 
BLKSIZE DSORG RECFM and DIR Blks.

Typically this type of error happens when someone uses a process like IEBGENER 
to add a member but changes the dcb attributes.

Or they use IEBGENER and forget the member and write over the directory at the 
beginning of the PDS.


Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[McKown, John]

I had this happen in the past. A programmer modified the DCB attributes on the 
DSCB. If you know what they are supposed to be, then run an IEBGENER to set 
them to something good. For a "card image" (source) type library, I do:

//GENER EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD *
X
//SYSUT2 DD DSN=MY.SOURCE.PDS(JUNK),DISP=OLD,
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920,DSORG=PO)
//

this is only an example! You need to know what the DCB characters really are 
(too large a BLKSIZE is usually OK).

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 . N. Richland Hills . TX 76010
(817) 255-3225 phone . 
john.mck...@healthmarkets.com . www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of esmie moo
> Sent: Tuesday, July 26, 2011 12:03 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: CORRUPT PDS - I/O ERROR
> 
> Good Morning Gentle Readers,
>  
> When I try to browse a member of  my pds I get a I/O error.  
> I tried browsing several members but I get the same error 
> message.  Is there a way of fixing it?  For some reason the 
> storage group is NOT backed up so I cannot restore it from an 
> old backup.  I recovered the PDS from a DFHSM backup but when 
> I try to browse any members I still get the I/O error.  Is 
> there a work around to this problem or should I consider it lost?
>  
> Thanks. 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[John Mattson]

Create a new larger pds.  Use ISPF option 3.3 to copy any members... one 
at a time... as you can.  That should save some 
PRINT the data set and that may show you "some parts" of the missing 
members in a flat file 
Finally try to compress it.   Compress may save it... or totally destroy 
it. 
So, exactly WHY are you not backing this thing up ?   Naughty boy. 



From:   esmie moo 
To: IBM-MAIN@bama.ua.edu
Date:   07/26/2011 10:03 AM
Subject:    CORRUPT PDS - I/O ERROR
Sent by:IBM Mainframe Discussion List 



Good Morning Gentle Readers,
 
When I try to browse a member of  my pds I get a I/O error.  I tried 
browsing several members but I get the same error message.  Is there a way 
of fixing it?  For some reason the storage group is NOT backed up so I 
cannot restore it from an old backup.  I recovered the PDS from a DFHSM 
backup but when I try to browse any members I still get the I/O error.  Is 
there a work around to this problem or should I consider it lost?
 
Thanks. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[esmie moo]

John,
 
Just to clarify, you have an X do I include it?  Also, I noticed that you the 
SYSUT2 has the PDS name as well as the member name (JUNK).  Could you tell me 
what it is for?

From: "McKown, John" 
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, July 26, 2011 1:13:12 PM
Subject: Re: CORRUPT PDS - I/O ERROR

I had this happen in the past. A programmer modified the DCB attributes on the 
DSCB. If you know what they are supposed to be, then run an IEBGENER to set 
them to something good. For a "card image" (source) type library, I do:

//GENER EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD *
X
//SYSUT2 DD DSN=MY.SOURCE.PDS(JUNK),DISP=OLD,
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920,DSORG=PO)
//

this is only an example! You need to know what the DCB characters really are 
(too large a BLKSIZE is usually OK).

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 . N. Richland Hills . TX 76010
(817) 255-3225 phone . 
john.mck...@healthmarkets.com . www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM



> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of esmie moo
> Sent: Tuesday, July 26, 2011 12:03 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: CORRUPT PDS - I/O ERROR
> 
> Good Morning Gentle Readers,
>  
> When I try to browse a member of  my pds I get a I/O error.  
> I tried browsing several members but I get the same error 
> message.  Is there a way of fixing it?  For some reason the 
> storage group is NOT backed up so I cannot restore it from an 
> old backup.  I recovered the PDS from a DFHSM backup but when 
> I try to browse any members I still get the I/O error.  Is 
> there a work around to this problem or should I consider it lost?
>  
> Thanks. 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[McKown, John]

The "X" is just junk instream data to put into the member JUNK. What it is 
doesn't matter. I just put it there for completeness.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 . N. Richland Hills . TX 76010
(817) 255-3225 phone . 
john.mck...@healthmarkets.com . www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of esmie moo
> Sent: Tuesday, July 26, 2011 12:17 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> John,
>  
> Just to clarify, you have an X do I include it?  Also, I 
> noticed that you the SYSUT2 has the PDS name as well as the 
> member name (JUNK).  Could you tell me what it is for?
> 
> From: "McKown, John" 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tuesday, July 26, 2011 1:13:12 PM
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> I had this happen in the past. A programmer modified the DCB 
> attributes on the DSCB. If you know what they are supposed to 
> be, then run an IEBGENER to set them to something good. For a 
> "card image" (source) type library, I do:
> 
> //GENER EXEC PGM=IEBGENER
> //SYSPRINT DD SYSOUT=*
> //SYSIN DD DUMMY
> //SYSUT1 DD *
> X
> //SYSUT2 DD DSN=MY.SOURCE.PDS(JUNK),DISP=OLD,
> // DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920,DSORG=PO)
> //
> 
> this is only an example! You need to know what the DCB 
> characters really are (too large a BLKSIZE is usually OK).
> 
> --
> John McKown 
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets®
> 
> 9151 Boulevard 26 . N. Richland Hills . TX 76010
> (817) 255-3225 phone . 
> john.mck...@healthmarkets.com . www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain 
> confidential or proprietary information. If you are not the 
> intended recipient, please contact the sender by reply e-mail 
> and destroy all copies of the original message. 
> HealthMarkets® is the brand name for products underwritten 
> and issued by the insurance subsidiaries of HealthMarkets, 
> Inc. -The Chesapeake Life Insurance Company®, Mid-West 
> National Life Insurance Company of TennesseeSM and The MEGA 
> Life and Health Insurance Company.SM
> 
> 
> 
> > -----Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of esmie moo
> > Sent: Tuesday, July 26, 2011 12:03 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: CORRUPT PDS - I/O ERROR
> > 
> > Good Morning Gentle Readers,
> >  
> > When I try to browse a member of  my pds I get a I/O error.  
> > I tried browsing several members but I get the same error 
> > message.  Is there a way of fixing it?  For some reason the 
> > storage group is NOT backed up so I cannot restore it from an 
> > old backup.  I recovered the PDS from a DFHSM backup but when 
> > I try to browse any members I still get the I/O error.  Is 
> > there a work around to this problem or should I consider it lost?
> >  
> > Thanks. 
> > 
> > 
> --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET 
> IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> > 
> > 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[esmie moo]

John,
 
I followed  your example it add the member JUNK to the pds and I was able to 
browse the member JUNK which has the X in it.  However, the rest of the members 
still give the I/O error.  I know that am sounding thick however I am not sure 
as to what I should do for the other members.  Could you give me an example? 

From: "McKown, John" 
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, July 26, 2011 1:22:20 PM
Subject: Re: CORRUPT PDS - I/O ERROR

The "X" is just junk instream data to put into the member JUNK. What it is 
doesn't matter. I just put it there for completeness.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 . N. Richland Hills . TX 76010
(817) 255-3225 phone . 
john.mck...@healthmarkets.com . www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM



> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of esmie moo
> Sent: Tuesday, July 26, 2011 12:17 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> John,
>  
> Just to clarify, you have an X do I include it?  Also, I 
> noticed that you the SYSUT2 has the PDS name as well as the 
> member name (JUNK).  Could you tell me what it is for?
> 
> From: "McKown, John" 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tuesday, July 26, 2011 1:13:12 PM
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> I had this happen in the past. A programmer modified the DCB 
> attributes on the DSCB. If you know what they are supposed to 
> be, then run an IEBGENER to set them to something good. For a 
> "card image" (source) type library, I do:
> 
> //GENER EXEC PGM=IEBGENER
> //SYSPRINT DD SYSOUT=*
> //SYSIN DD DUMMY
> //SYSUT1 DD *
> X
> //SYSUT2 DD DSN=MY.SOURCE.PDS(JUNK),DISP=OLD,
> // DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920,DSORG=PO)
> //
> 
> this is only an example! You need to know what the DCB 
> characters really are (too large a BLKSIZE is usually OK).
> 
> --
> John McKown 
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets®
> 
> 9151 Boulevard 26 . N. Richland Hills . TX 76010
> (817) 255-3225 phone . 
> john.mck...@healthmarkets.com . www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain 
> confidential or proprietary information. If you are not the 
> intended recipient, please contact the sender by reply e-mail 
> and destroy all copies of the original message. 
> HealthMarkets® is the brand name for products underwritten 
> and issued by the insurance subsidiaries of HealthMarkets, 
> Inc. -The Chesapeake Life Insurance Company®, Mid-West 
> National Life Insurance Company of TennesseeSM and The MEGA 
> Life and Health Insurance Company.SM
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of esmie moo
> > Sent: Tuesday, July 26, 2011 12:03 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: CORRUPT PDS - I/O ERROR
> > 
> > Good Morning Gentle Readers,
> >  
> > When I try to browse a member of  my pds I get a I/O error.  
> > I tried browsing several members but I get the same error 
> > message.  Is there a way of fixing it?  For some reason the 
> > storage group is NOT backed up so I cannot restore it from an 
> > old backup.  I recovered the PDS from a DFHSM backup but when 
> > I try to browse any members I still get the I/O error.  Is 
> > there a work around to this problem or should I consider it lost?
> >  
> > Thanks. 
> > 
> > 
> --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET 
> IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> > 
> > 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 

Re: CORRUPT PDS - I/O ERROR

[esmie moo]

I tried it but when I try the copy command it gives me the I/O error.  Thanks 
for your suggestion.

From: John Mattson 
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, July 26, 2011 1:16:05 PM
Subject: Re: CORRUPT PDS - I/O ERROR

Create a new larger pds.  Use ISPF option 3.3 to copy any members... one 
at a time... as you can.  That should save some 
PRINT the data set and that may show you "some parts" of the missing 
members in a flat file 
Finally try to compress it.  Compress may save it... or totally destroy 
it. 
So, exactly WHY are you not backing this thing up ?  Naughty boy. 



From:  esmie moo 
To:    IBM-MAIN@bama.ua.edu
Date:  07/26/2011 10:03 AM
Subject:        CORRUPT PDS - I/O ERROR
Sent by:        IBM Mainframe Discussion List 



Good Morning Gentle Readers,

When I try to browse a member of  my pds I get a I/O error.  I tried 
browsing several members but I get the same error message.  Is there a way 
of fixing it?  For some reason the storage group is NOT backed up so I 
cannot restore it from an old backup.  I recovered the PDS from a DFHSM 
backup but when I try to browse any members I still get the I/O error.  Is 
there a work around to this problem or should I consider it lost?

Thanks. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Mingee, David]

Hi,  If you have PDS85 or PDS86 utility from the CBT tape - it can repair the 
file.  What does 3.4 show for all the dcb values?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
esmie moo
Sent: Tuesday, July 26, 2011 1:42 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CORRUPT PDS - I/O ERROR



I tried it but when I try the copy command it gives me the I/O error.  Thanks 
for your suggestion.

From: John Mattson 
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, July 26, 2011 1:16:05 PM
Subject: Re: CORRUPT PDS - I/O ERROR

Create a new larger pds.  Use ISPF option 3.3 to copy any members... one at a 
time... as you can.  That should save some PRINT the data set and that may show 
you "some parts" of the missing members in a flat file Finally try to compress 
it.  Compress may save it... or totally destroy it. 
So, exactly WHY are you not backing this thing up ?  Naughty boy. 



From:  esmie moo 
To:    IBM-MAIN@bama.ua.edu
Date:  07/26/2011 10:03 AM
Subject:        CORRUPT PDS - I/O ERROR
Sent by:        IBM Mainframe Discussion List 



Good Morning Gentle Readers,

When I try to browse a member of  my pds I get a I/O error.  I tried browsing 
several members but I get the same error message.  Is there a way of fixing 
it?  For some reason the storage group is NOT backed up so I cannot restore it 
from an old backup.  I recovered the PDS from a DFHSM backup but when I try to 
browse any members I still get the I/O error.  Is there a work around to this 
problem or should I consider it lost?

Thanks. 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Gibney, Dave]

You have yet to provide the precise text of the i/o error message. Have you 
confirmed the LRECL and RECFM are as expected? Do you have PDS from the CBT 
tape or STARTOOLS?

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of esmie moo
> Sent: Tuesday, July 26, 2011 10:42 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> 
> 
> I tried it but when I try the copy command it gives me the I/O error.  Thanks
> for your suggestion.
> 
> From: John Mattson 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tuesday, July 26, 2011 1:16:05 PM
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> Create a new larger pds.  Use ISPF option 3.3 to copy any members... one
> at a time... as you can.  That should save some
> PRINT the data set and that may show you "some parts" of the missing
> members in a flat file
> Finally try to compress it.  Compress may save it... or totally destroy
> it.
> So, exactly WHY are you not backing this thing up ?  Naughty boy.
> 
> 
> 
> From:  esmie moo 
> To:    IBM-MAIN@bama.ua.edu
> Date:  07/26/2011 10:03 AM
> Subject:        CORRUPT PDS - I/O ERROR
> Sent by:        IBM Mainframe Discussion List 
> 
> 
> 
> Good Morning Gentle Readers,
> 
> When I try to browse a member of  my pds I get a I/O error.  I tried
> browsing several members but I get the same error message.  Is there a way
> of fixing it?  For some reason the storage group is NOT backed up so I
> cannot restore it from an old backup.  I recovered the PDS from a DFHSM
> backup but when I try to browse any members I still get the I/O error.  Is
> there a work around to this problem or should I consider it lost?
> 
> Thanks.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Ted MacNEIL]

The usual suspect is specifying blocksize. 
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: "Starr, Alan" 
Sender: IBM Mainframe Discussion List 
Date: Tue, 26 Jul 2011 10:07:56 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: CORRUPT PDS - I/O ERROR

There are many possibilities but first things first. A common cause of this is 
that somebody wrote a member and changed DCB attributes.

If you know what the DCB attributes are supposed to be (e.g. BLKSIZE and 
RECFM), check them.  Otherwise, do you have an older HSM backup that you can 
restore?

The DCB can be changed back by writing a new member (e.g. with IEBGENER) and 
specifying all DCB attributes.

If the aforementioned isn't the problem, please provide the text of the error 
message; others will probably have additional ideas.

Alan

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
esmie moo
Sent: Tuesday, July 26, 2011 10:03 AM
To: IBM-MAIN@bama.ua.edu
Subject: CORRUPT PDS - I/O ERROR

Good Morning Gentle Readers,
 
When I try to browse a member of  my pds I get a I/O error.  I tried browsing 
several members but I get the same error message.  Is there a way of fixing 
it?  For some reason the storage group is NOT backed up so I cannot restore it 
from an old backup.  I recovered the PDS from a DFHSM backup but when I try to 
browse any members I still get the I/O error.  Is there a work around to this 
problem or should I consider it lost?
 
Thanks. 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[McKown, John]

Well, perhaps my guess was just plain wrong. Maybe something more is wrong than 
with the DCB information. Can you use AMASPZAP to dump the dataset in hex? I've 
done that in the past, too.



John McKown 

Systems Engineer IV

IT

 

Administrative Services Group

 

HealthMarkets®

 

9151 Boulevard 26 . N. Richland Hills . TX 76010

(817) 255-3225 phone . 

john.mck...@healthmarkets.com . www.HealthMarkets.com

 

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of esmie moo
> Sent: Tuesday, July 26, 2011 12:41 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> John,
>  
> I followed  your example it add the member JUNK to the pds 
> and I was able to browse the member JUNK which has the X in 
> it.  However, the rest of the members still give the I/O 
> error.  I know that am sounding thick however I am not sure 
> as to what I should do for the other members.  Could you give 
> me an example? 
> 
> From: "McKown, John" 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tuesday, July 26, 2011 1:22:20 PM
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> The "X" is just junk instream data to put into the member 
> JUNK. What it is doesn't matter. I just put it there for completeness.
> 
> --
> John McKown 
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets®
> 
> 9151 Boulevard 26 . N. Richland Hills . TX 76010
> (817) 255-3225 phone . 
> john.mck...@healthmarkets.com . www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain 
> confidential or proprietary information. If you are not the 
> intended recipient, please contact the sender by reply e-mail 
> and destroy all copies of the original message. 
> HealthMarkets® is the brand name for products underwritten 
> and issued by the insurance subsidiaries of HealthMarkets, 
> Inc. -The Chesapeake Life Insurance Company®, Mid-West 
> National Life Insurance Company of TennesseeSM and The MEGA 
> Life and Health Insurance Company.SM
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of esmie moo
> > Sent: Tuesday, July 26, 2011 12:17 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: CORRUPT PDS - I/O ERROR
> > 
> > John,
> >  
> > Just to clarify, you have an X do I include it?  Also, I 
> > noticed that you the SYSUT2 has the PDS name as well as the 
> > member name (JUNK).  Could you tell me what it is for?
> > 
> > From: "McKown, John" 
> > To: IBM-MAIN@bama.ua.edu
> > Sent: Tuesday, July 26, 2011 1:13:12 PM
> > Subject: Re: CORRUPT PDS - I/O ERROR
> > 
> > I had this happen in the past. A programmer modified the DCB 
> > attributes on the DSCB. If you know what they are supposed to 
> > be, then run an IEBGENER to set them to something good. For a 
> > "card image" (source) type library, I do:
> > 
> > //GENER EXEC PGM=IEBGENER
> > //SYSPRINT DD SYSOUT=*
> > //SYSIN DD DUMMY
> > //SYSUT1 DD *
> > X
> > //SYSUT2 DD DSN=MY.SOURCE.PDS(JUNK),DISP=OLD,
> > // DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920,DSORG=PO)
> > //
> > 
> > this is only an example! You need to know what the DCB 
> > characters really are (too large a BLKSIZE is usually OK).
> > 
> > --
> > John McKown 
> > Systems Engineer IV
> > IT
> > 
> > Administrative Services Group
> > 
> > HealthMarkets®
> > 
> > 9151 Boulevard 26 . N. Richland Hills . TX 76010
> > (817) 255-3225 phone . 
> > john.mck...@healthmarkets.com . www.HealthMarkets.com
> > 
> > Confidentiality Notice: This e-mail message may contain 
> > confidential or proprietary information. If you are not the 
> > intended recipient, please contact the sender by reply e-mail 
> > and destroy all copies of the original message. 
> > HealthMarkets® is the brand name for products underwritten 
> > and issued by the insurance subsidiaries of HealthMarkets, 
> > Inc. -The Chesapeake Life Insurance Company®, Mid-West 
> > National Life 

Re: CORRUPT PDS - I/O ERROR

[Schwarz, Barry A]

If the storage group is not backed up, how did HSM ever back up a copy for you 
to recover from?  Was there a copy of the dataset on disk when you recovered it 
from HSM?  What was the command you used to perform the recovery?  When you 
browse the PDS, does the member list display correctly?  What are the DCB 
attributes of the PDS?  Do they match what you think they should be?  What is 
the exact error message?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of esmie moo
> Sent: Tuesday, July 26, 2011 10:03 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: CORRUPT PDS - I/O ERROR
>
> Good Morning Gentle Readers,
>
> When I try to browse a member of  my pds I get a I/O error.  I tried
> browsing several members but I get the same error message.  Is there a way
> of fixing it?  For some reason the storage group is NOT backed up so I
> cannot restore it from an old backup.  I recovered the PDS from a DFHSM
> backup but when I try to browse any members I still get the I/O error.  Is
> there a work around to this problem or should I consider it lost?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

This can happen with any PDS if it is opened for output with a DCB other 
than its original one (e.g. originally RECFM=FB, but opened with 
RECFM=VB etc.) When opening for output, the DCB used is (a) the one 
specified in the program; (b) the one in the JCL; (c) the one on DASD - 
in that order of priority. When opening for input, the priority order is 
reversed (DASD, JCL, program). If the incorrect output DCB was specified 
in a program, it needs to be fixed there: this program should then be 
rerun to open the PDS with its correct attributes; then close the PDS. 
After that, the original members will be accessible again. But any 
members which were created using the program's previously incorrect DCB 
will now hit I/O errors (so copy them to another PDS beforehand if they 
need to be kept).


Schwarz, Barry A wrote:


If the storage group is not backed up, how did HSM ever back up a copy for you 
to recover from?  Was there a copy of the dataset on disk when you recovered it 
from HSM?  What was the command you used to perform the recovery?  When you 
browse the PDS, does the member list display correctly?  What are the DCB 
attributes of the PDS?  Do they match what you think they should be?  What is 
the exact error message?

 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of esmie moo
Sent: Tuesday, July 26, 2011 10:03 AM
To: IBM-MAIN@bama.ua.edu
Subject: CORRUPT PDS - I/O ERROR

Good Morning Gentle Readers,

When I try to browse a member of  my pds I get a I/O error.  I tried
browsing several members but I get the same error message.  Is there a way
of fixing it?  For some reason the storage group is NOT backed up so I
cannot restore it from an old backup.  I recovered the PDS from a DFHSM
backup but when I try to browse any members I still get the I/O error.  Is
there a work around to this problem or should I consider it lost?
   



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

This can happen with any PDS if it is opened for output with a DCB other 
than its original one (e.g. originally RECFM=FB, but opened with 
RECFM=VB etc.) When opening for output, the DCB used is: (a) the one 
specified in the program; (b) the one in the JCL; (c) the one on DASD - 
in that order of priority. When opening for input, the priority order is 
reversed (DASD, JCL, program). If the incorrect output DCB was specified 
in a program, it needs to be fixed there: this program should then be 
rerun to open the PDS with its correct attributes; then close the PDS. 
After that, the original members will be accessible again. But any 
members which were created using the program's previously incorrect DCB 
will now hit I/O errors (so copy them to another PDS beforehand if they 
need to be kept).


esmie moo wrote:


Good Morning Gentle Readers,

When I try to browse a member of  my pds I get a I/O error.  I tried browsing 
several members but I get the same error message.  Is there a way of fixing it? 
 For some reason the storage group is NOT backed up so I cannot restore it from 
an old backup.  I recovered the PDS from a DFHSM backup but when I try to 
browse any members I still get the I/O error.  Is there a work around to this 
problem or should I consider it lost?

Thanks. 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Tom Marchant]

On Tue, 26 Jul 2011 22:47:16 +0100, CM Poncelet wrote:

>When opening for output, the DCB used is (a) the one
>specified in the program; (b) the one in the JCL; (c) the one on DASD -
>in that order of priority.

Correct, but incomplete.  There are exits points that can alter the DCB 
attributes too.

>When opening for input, the priority order is
>reversed (DASD, JCL, program).

I don't think so, and Using Data Sets seems to say otherwise. 
Can you cite a reference?

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

But the exit points 'count' as program DCBs ... as they execute first 
and override what is in the JCL. I don't check "Using Data Sets"; but 
that is how things were in the days of MVS OS/VS SP1 (1985): if things 
have 'changed' since then, so be it.


Tom Marchant wrote:


On Tue, 26 Jul 2011 22:47:16 +0100, CM Poncelet wrote:

 


When opening for output, the DCB used is (a) the one
specified in the program; (b) the one in the JCL; (c) the one on DASD -
in that order of priority.
   



Correct, but incomplete.  There are exits points that can alter the DCB 
attributes too.


 


When opening for input, the priority order is
reversed (DASD, JCL, program).
   



I don't think so, and Using Data Sets seems to say otherwise. 
Can you cite a reference?


 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Ed Gould]

Chances are thar DFHSM did not back up the dataset after it was corrupted. 
Check DFHSM for the error. Not sure what DFHSM would do if DFDSS were the data 
mover. I would guess that DFDSS invokes IEBCOPY under the covers and it 
wouldn't work so.

Ed

Sent from my iPad

On Jul 26, 2011, at 4:47 PM, CM Poncelet  wrote:

> This can happen with any PDS if it is opened for output with a DCB other than 
> its original one (e.g. originally RECFM=FB, but opened with RECFM=VB etc.) 
> When opening for output, the DCB used is (a) the one specified in the 
> program; (b) the one in the JCL; (c) the one on DASD - in that order of 
> priority. When opening for input, the priority order is reversed (DASD, JCL, 
> program). If the incorrect output DCB was specified in a program, it needs to 
> be fixed there: this program should then be rerun to open the PDS with its 
> correct attributes; then close the PDS. After that, the original members will 
> be accessible again. But any members which were created using the program's 
> previously incorrect DCB will now hit I/O errors (so copy them to another PDS 
> beforehand if they need to be kept).
> 
> Schwarz, Barry A wrote:
> 
>> If the storage group is not backed up, how did HSM ever back up a copy for 
>> you to recover from?  Was there a copy of the dataset on disk when you 
>> recovered it from HSM?  What was the command you used to perform the 
>> recovery?  When you browse the PDS, does the member list display correctly?  
>> What are the DCB attributes of the PDS?  Do they match what you think they 
>> should be?  What is the exact error message?
>> 
>> 
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
>>> Behalf Of esmie moo
>>> Sent: Tuesday, July 26, 2011 10:03 AM
>>> To: IBM-MAIN@bama.ua.edu
>>> Subject: CORRUPT PDS - I/O ERROR
>>> 
>>> Good Morning Gentle Readers,
>>> 
>>> When I try to browse a member of  my pds I get a I/O error.  I tried
>>> browsing several members but I get the same error message.  Is there a way
>>> of fixing it?  For some reason the storage group is NOT backed up so I
>>> cannot restore it from an old backup.  I recovered the PDS from a DFHSM
>>> backup but when I try to browse any members I still get the I/O error.  Is
>>> there a work around to this problem or should I consider it lost?
>>>   
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>> 
>> 
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Ravi Gaur]

I would like to know what really other message you get with I/O error..any more 
informatory..go with the PDS80 or PDSMAN and see if with the scan members or 
fix you can see more information about the ttoc's etc and it also give you 
report which is more descriptory...I am not sure if it is availablein your 
environment however remember have had one on cbttape..

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[esmie moo]

Ed,
 
When I recovered the dsn from the HSM incremental backup there were no error 
messages posted - I received the standard ARC0778I DATA SET WAS RECOVERED 
message.  The datamover is DFDSS.
 
 

From: Ed Gould 
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, July 26, 2011 7:30:51 PM
Subject: Re: CORRUPT PDS - I/O ERROR

Chances are thar DFHSM did not back up the dataset after it was corrupted. 
Check DFHSM for the error. Not sure what DFHSM would do if DFDSS were the data 
mover. I would guess that DFDSS invokes IEBCOPY under the covers and it 
wouldn't work so.

Ed

Sent from my iPad

On Jul 26, 2011, at 4:47 PM, CM Poncelet  wrote:

> This can happen with any PDS if it is opened for output with a DCB other than 
> its original one (e.g. originally RECFM=FB, but opened with RECFM=VB etc.) 
> When opening for output, the DCB used is (a) the one specified in the 
> program; (b) the one in the JCL; (c) the one on DASD - in that order of 
> priority. When opening for input, the priority order is reversed (DASD, JCL, 
> program). If the incorrect output DCB was specified in a program, it needs to 
> be fixed there: this program should then be rerun to open the PDS with its 
> correct attributes; then close the PDS. After that, the original members will 
> be accessible again. But any members which were created using the program's 
> previously incorrect DCB will now hit I/O errors (so copy them to another PDS 
> beforehand if they need to be kept).
> 
> Schwarz, Barry A wrote:
> 
>> If the storage group is not backed up, how did HSM ever back up a copy for 
>> you to recover from?  Was there a copy of the dataset on disk when you 
>> recovered it from HSM?  What was the command you used to perform the 
>> recovery?  When you browse the PDS, does the member list display correctly?  
>> What are the DCB attributes of the PDS?  Do they match what you think they 
>> should be?  What is the exact error message?
>> 
>> 
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
>>> Behalf Of esmie moo
>>> Sent: Tuesday, July 26, 2011 10:03 AM
>>> To: IBM-MAIN@bama.ua.edu
>>> Subject: CORRUPT PDS - I/O ERROR
>>> 
>>> Good Morning Gentle Readers,
>>> 
>>> When I try to browse a member of  my pds I get a I/O error.  I tried
>>> browsing several members but I get the same error message.  Is there a way
>>> of fixing it?  For some reason the storage group is NOT backed up so I
>>> cannot restore it from an old backup.  I recovered the PDS from a DFHSM
>>> backup but when I try to browse any members I still get the I/O error.  Is
>>> there a work around to this problem or should I consider it lost?
>>>  
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>> 
>> 
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[esmie moo]

The message I receive is :
 
I/O error

When I hit F1 (help) I get the following :
 
I/O error

An I/O error was encountered reading the first record requested


From: Ravi Gaur 
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, July 26, 2011 11:06:03 PM
Subject: Re: CORRUPT PDS - I/O ERROR

I would like to know what really other message you get with I/O error..any more 
informatory..go with the PDS80 or PDSMAN and see if with the scan members or 
fix you can see more information about the ttoc's etc and it also give you 
report which is more descriptory...I am not sure if it is availablein your 
environment however remember have had one on cbttape..

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[esmie moo]

Barry,
 
The STORAGE GROUP was backed up via HSM, what I didn't say correctly that the 
volume was not backed up (full dump).
When I am able to do a browse of the dsn, all the members are displayed 
correctly, however when I browse each member I get the following :
 
I/O error 

When I press F1 for more info I get the following:
An I/O error was encountered reading the first record requested.

The DCB of the PDS is as follows, however I cannot be sure if it is correct 
since this PDS was inherited from a client
 
Organization  . . . : PO  
Record format . . . : FBA 
Record length . . . : 133 
Block size  . . . . : 133 
1st extent cylinders: 5   
Secondary cylinders : 2   
Data set name type  : PDS 


From: "Schwarz, Barry A" 
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, July 26, 2011 3:57:31 PM
Subject: Re: CORRUPT PDS - I/O ERROR

If the storage group is not backed up, how did HSM ever back up a copy for you 
to recover from?  Was there a copy of the dataset on disk when you recovered it 
from HSM?  What was the command you used to perform the recovery?  When you 
browse the PDS, does the member list display correctly?  What are the DCB 
attributes of the PDS?  Do they match what you think they should be?  What is 
the exact error message?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of esmie moo
> Sent: Tuesday, July 26, 2011 10:03 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: CORRUPT PDS - I/O ERROR
>
> Good Morning Gentle Readers,
>
> When I try to browse a member of  my pds I get a I/O error.  I tried
> browsing several members but I get the same error message.  Is there a way
> of fixing it?  For some reason the storage group is NOT backed up so I
> cannot restore it from an old backup.  I recovered the PDS from a DFHSM
> backup but when I try to browse any members I still get the I/O error.  Is
> there a work around to this problem or should I consider it lost?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[esmie moo]

The use of AMASPZAP is restricted.  No can do.  Thanks for the suggestion.


From: "McKown, John" 
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, July 26, 2011 1:58:53 PM
Subject: Re: CORRUPT PDS - I/O ERROR

Well, perhaps my guess was just plain wrong. Maybe something more is wrong than 
with the DCB information. Can you use AMASPZAP to dump the dataset in hex? I've 
done that in the past, too.



John McKown 

Systems Engineer IV

IT



Administrative Services Group



HealthMarkets®



9151 Boulevard 26 . N. Richland Hills . TX 76010

(817) 255-3225 phone . 

john.mck...@healthmarkets.com . www.HealthMarkets.com



Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM



> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of esmie moo
> Sent: Tuesday, July 26, 2011 12:41 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> John,
>  
> I followed  your example it add the member JUNK to the pds 
> and I was able to browse the member JUNK which has the X in 
> it.  However, the rest of the members still give the I/O 
> error.  I know that am sounding thick however I am not sure 
> as to what I should do for the other members.  Could you give 
> me an example? 
> 
> From: "McKown, John" 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tuesday, July 26, 2011 1:22:20 PM
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> The "X" is just junk instream data to put into the member 
> JUNK. What it is doesn't matter. I just put it there for completeness.
> 
> --
> John McKown 
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets®
> 
> 9151 Boulevard 26 . N. Richland Hills . TX 76010
> (817) 255-3225 phone . 
> john.mck...@healthmarkets.com . www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain 
> confidential or proprietary information. If you are not the 
> intended recipient, please contact the sender by reply e-mail 
> and destroy all copies of the original message. 
> HealthMarkets® is the brand name for products underwritten 
> and issued by the insurance subsidiaries of HealthMarkets, 
> Inc. -The Chesapeake Life Insurance Company®, Mid-West 
> National Life Insurance Company of TennesseeSM and The MEGA 
> Life and Health Insurance Company.SM
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of esmie moo
> > Sent: Tuesday, July 26, 2011 12:17 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: CORRUPT PDS - I/O ERROR
> > 
> > John,
> >  
> > Just to clarify, you have an X do I include it?  Also, I 
> > noticed that you the SYSUT2 has the PDS name as well as the 
> > member name (JUNK).  Could you tell me what it is for?
> > 
> > From: "McKown, John" 
> > To: IBM-MAIN@bama.ua.edu
> > Sent: Tuesday, July 26, 2011 1:13:12 PM
> > Subject: Re: CORRUPT PDS - I/O ERROR
> > 
> > I had this happen in the past. A programmer modified the DCB 
> > attributes on the DSCB. If you know what they are supposed to 
> > be, then run an IEBGENER to set them to something good. For a 
> > "card image" (source) type library, I do:
> > 
> > //GENER EXEC PGM=IEBGENER
> > //SYSPRINT DD SYSOUT=*
> > //SYSIN DD DUMMY
> > //SYSUT1 DD *
> > X
> > //SYSUT2 DD DSN=MY.SOURCE.PDS(JUNK),DISP=OLD,
> > // DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920,DSORG=PO)
> > //
> > 
> > this is only an example! You need to know what the DCB 
> > characters really are (too large a BLKSIZE is usually OK).
> > 
> > --
> > John McKown 
> > Systems Engineer IV
> > IT
> > 
> > Administrative Services Group
> > 
> > HealthMarkets®
> > 
> > 9151 Boulevard 26 . N. Richland Hills . TX 76010
> > (817) 255-3225 phone . 
> > john.mck...@healthmarkets.com . www.HealthMarkets.com
> > 
> > Confidentiality Notice: This e-mail message may contain 
> > confidential or proprietary information. If you are not the 
> > intended recipient, please contact the sender by reply e-mail 
> > and destroy all copies of the original message. 
> > HealthMarket

Re: CORRUPT PDS - I/O ERROR

[McKown, John]

Many placed do. I don't understand why. Yes, I've read the reasons. They are, 
IMO, invalid. If I can use AMASPZAP to modify something, then I can use some 
other program, so restricting AMASPZAP is generally silly. It just makes some 
things harder. Well, I guess to some "harder is better". 

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 . N. Richland Hills . TX 76010
(817) 255-3225 phone . 
john.mck...@healthmarkets.com . www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of esmie moo
> Sent: Wednesday, July 27, 2011 7:03 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> The use of AMASPZAP is restricted.  No can do.  Thanks for 
> the suggestion.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Tom Marchant]

On Wed, 27 Jul 2011 00:08:42 +0100, CM Poncelet wrote:

>I don't check "Using Data Sets";

Perhaps you should.

>but that is how things were in the days of MVS OS/VS SP1 (1985):

It was not how it worked in OS/360.  I just looked it up in the JCL 
manual on bitsavers.  The sequence of completing a DCB is the 
same regardless of whether the data set is opened for input, 
output or I/O.

>if things
>have 'changed' since then, so be it.
>
>Tom Marchant wrote:
>
>>On Tue, 26 Jul 2011 22:47:16 +0100, CM Poncelet wrote:
>>
>>>When opening for input, the priority order is
>>>reversed (DASD, JCL, program).
>>
>>I don't think so, and Using Data Sets seems to say otherwise.
>>Can you cite a reference?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Pinnacle]

Esmie,

Download and install PDS, available as FILE182 at www.cbttape.org.  Once 
installed, bring up your corrupt PDS with PDS, and issue "VERIFY :".  
You will see a message after a while showing you the largest block 
written.  Issue "FIXPDS BLKSIZE(x)" and use the blocksize from the 
message.  If that doesn't fix your I/O error, you are SOL.


Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Rick Fochtman]

--


Barry,

The STORAGE GROUP was backed up via HSM, what I didn't say correctly that the 
volume was not backed up (full dump).
When I am able to do a browse of the dsn, all the members are displayed 
correctly, however when I browse each member I get the following :

I/O error 


When I press F1 for more info I get the following:
An I/O error was encountered reading the first record requested.

The DCB of the PDS is as follows, however I cannot be sure if it is correct 
since this PDS was inherited from a client

Organization  . . . : PO  
Record format . . . : FBA 
Record length . . . : 133 
Block size  . . . . : 133 
1st extent cylinders: 5   
Secondary cylinders : 2   
Data set name type  : PDS 
 


-
This looks very much like some program had its SYSPRINT directed to a 
member of this PDS, altering the DCB attributes in the process. You'll 
just have to experiment to find the correct attributes, but I'd find the 
one member that's readable and move it out to another dataset of FBA/133 
format and delete it from this *altered* PDS before doing anything. I 
think that as a starting point, I'd try a BLKSIZE that's as close to a 
half-track as I could get with this same lrecl value.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Rick Fochtman]

-
The use of AMASPZAP is restricted.  No can do.  Thanks for the suggestion.

Let me guess: another piece of mindless panic prompted by a know-nothing 
auditor.


None of them seem to realize that without update access to a dataset, 
AMASPZAP can do NO HARM!  :-)


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Joel C. Ewing]

ord length . . . : 133
Block size  . . . . : 133
1st extent cylinders: 5
Secondary cylinders : 2
Data set name type  : PDS


From: "Schwarz, Barry A"
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, July 26, 2011 3:57:31 PM
Subject: Re: CORRUPT PDS - I/O ERROR

If the storage group is not backed up, how did HSM ever back up a copy for you 
to recover from?  Was there a copy of the dataset on disk when you recovered it 
from HSM?  What was the command you used to perform the recovery?  When you 
browse the PDS, does the member list display correctly?  What are the DCB 
attributes of the PDS?  Do they match what you think they should be?  What is 
the exact error message?


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of esmie moo
Sent: Tuesday, July 26, 2011 10:03 AM
To: IBM-MAIN@bama.ua.edu
Subject: CORRUPT PDS - I/O ERROR

Good Morning Gentle Readers,

When I try to browse a member of  my pds I get a I/O error.  I tried
browsing several members but I get the same error message.  Is there a way
of fixing it?  For some reason the storage group is NOT backed up so I
cannot restore it from an old backup.  I recovered the PDS from a DFHSM
backup but when I try to browse any members I still get the I/O error.  Is
there a work around to this problem or should I consider it lost?

...
--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Ed Gould]

Chances are that the dataset was corrupted since the last backup, I would look 
through SMF for type 15 to see updated it. Assuming you know what the DCB was 
and the directory is intact then either I would amaszap in the correct block 
size and lrecl re fm or iebgener with the DCB of the desired DCB attributes 
into say member ( name of your choice).

If the directory is clobbered I would restore the last good backup.


Ed

Sent from my iPad

On Jul 27, 2011, at 6:43 AM, esmie moo  wrote:

> Ed,
>  
> When I recovered the dsn from the HSM incremental backup there were no error 
> messages posted - I received the standard ARC0778I DATA SET WAS RECOVERED 
> message.  The datamover is DFDSS.
>  
>  
> 
> From: Ed Gould 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tuesday, July 26, 2011 7:30:51 PM
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> Chances are thar DFHSM did not back up the dataset after it was corrupted. 
> Check DFHSM for the error. Not sure what DFHSM would do if DFDSS were the 
> data mover. I would guess that DFDSS invokes IEBCOPY under the covers and it 
> wouldn't work so.
> 
> Ed
> 
> Sent from my iPad
> 
> On Jul 26, 2011, at 4:47 PM, CM Poncelet  wrote:
> 
>> This can happen with any PDS if it is opened for output with a DCB other 
>> than its original one (e.g. originally RECFM=FB, but opened with RECFM=VB 
>> etc.) When opening for output, the DCB used is (a) the one specified in the 
>> program; (b) the one in the JCL; (c) the one on DASD - in that order of 
>> priority. When opening for input, the priority order is reversed (DASD, JCL, 
>> program). If the incorrect output DCB was specified in a program, it needs 
>> to be fixed there: this program should then be rerun to open the PDS with 
>> its correct attributes; then close the PDS. After that, the original members 
>> will be accessible again. But any members which were created using the 
>> program's previously incorrect DCB will now hit I/O errors (so copy them to 
>> another PDS beforehand if they need to be kept).
>> 
>> Schwarz, Barry A wrote:
>> 
>>> If the storage group is not backed up, how did HSM ever back up a copy for 
>>> you to recover from?  Was there a copy of the dataset on disk when you 
>>> recovered it from HSM?  What was the command you used to perform the 
>>> recovery?  When you browse the PDS, does the member list display correctly? 
>>>  What are the DCB attributes of the PDS?  Do they match what you think they 
>>> should be?  What is the exact error message?
>>> 
>>> 
>>>> -Original Message-
>>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
>>>> Behalf Of esmie moo
>>>> Sent: Tuesday, July 26, 2011 10:03 AM
>>>> To: IBM-MAIN@bama.ua.edu
>>>> Subject: CORRUPT PDS - I/O ERROR
>>>> 
>>>> Good Morning Gentle Readers,
>>>> 
>>>> When I try to browse a member of  my pds I get a I/O error.  I tried
>>>> browsing several members but I get the same error message.  Is there a way
>>>> of fixing it?  For some reason the storage group is NOT backed up so I
>>>> cannot restore it from an old backup.  I recovered the PDS from a DFHSM
>>>> backup but when I try to browse any members I still get the I/O error.  Is
>>>> there a work around to this problem or should I consider it lost?
>>>>   
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>>> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>>> 
>>> 
>>> 
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[esmie moo]

Joel,
 
I changed the PDS (via batch job as posted earlier) and that fixed the 
problem.  Thanks very much for the helping hand.

From: Joel C. Ewing 
To: IBM-MAIN@bama.ua.edu
Sent: Wednesday, July 27, 2011 12:00:56 PM
Subject: Re: CORRUPT PDS - I/O ERROR

FBA LRECL 133 BLKSIZE 133 is almost certainly NOT correct.  No one in their 
right mind would create a blocked PDS that is effectively unblocked with one 
record per block as you would be getting less the 5% effective track 
utilization on any DASD made in the last 20 years. Undoubtedly someone wrote a 
member to this PDS with batch JCL from a program that had these DCB parameters 
hard-coded internally or with these values hard-coded in the JCL and destroyed 
the correct values. Until you fix the LRECL and BLKSIZE values to something 
that is consistent with the old data you will continue to get I/O errors as 
either the physical blocks in the PDS will be longer than the current BLKSIZE 
or the physical blocks will not be a multiple of the current LRECL, or both.

You need to run some free utility, like the VERIFY command under freebie CBT 
utility PDS85 as others have already suggested, to find the true max blocksize, 
which will almost certainly not be 133.  Or a more complicated approach if you 
have a utility like DFDSS would be to do a hex dump of a track far enough 
inside the PDS to get past the directory blocks and at least that should give 
you the size of some data blocks and imply the LRECL (but unless you hit on a 
member that is multiple blocks, you may not see the max block size). Then it 
should be an easy matter to compute whether the max blocksize is a multiple of 
133, or possibly a multiple of 80, or some other value that would make sense in 
the context of the data contained, and that will enable you to deduce the true 
LRECL.  I'm assuming here the original data was not RECFM VB. If it was, about 
the only way to determine a compatible LRECL and BLKSIZE is to find the largest 
BLKSIZE and then try an
 LRECL of that value minus 4.  That would at least allow reading the data, but 
a complete scan of all logical records would be needed to find the minimum 
acceptable value for LRECL.

Your 2nd problem is to find what not-so-bright programmer or application caused 
the problem in the first place, as you could fix the problem and have it 
immediately re-occur when they re-run the same flawed job step.  The problem is 
undoubted caused by a batch process because there is no way the usual ISPF 
edit, move, copy processes would alter existing PDS DCB attributes.  When a 
batch job step sets the DCB attributes of a PDS to bad values, the new member 
created when the problem was caused will be readable, but it may be the only 
member readable.  This should be a clue as to where blame lies.  If most 
members in the PDS were created from ISPF and have member stats, then that 
would also narrow it down to members without member stats.  Of course if the 
guilty party recognized their error, they might have deleted the bad member to 
hide the evidence.

Once you know the correct BLKSIZE and LRECL, use PDS85 commands to set correct 
values, or JCL techniques previously mentioned in this thread to set those 
values.  That should make all the old members readable.  The RECFM FBA may also 
be suspect, but if the data is really FB this will not prevent viewing the 
members.  If none of the old members have carriage control characters in column 
1, then you should change RECFM to FB as well.

Once you can get to all the old members, only members created with bad LRECL or 
BLKSIZE might be unreadable.  After deleting any of those unreadable members, 
build a new PDS by copying all the members to a new PDS and either rename or 
delete the old PDS as appropriate.  Compress of the old PDS would also 
eliminate the bad block sizes of deleted members, but you might want to keep 
the original dataset around until you are sure there is no chance of needing to 
recover any more member data.

Every time I have seen this problem with a PDS, it is because some programmer 
got the bright idea of saving some batch report in an existing PDS that was 
designed for other uses without understanding that a PDS can only have one set 
of DCB attributes.  A hard rule should be that no batch job step should be 
allowed to write a PDS member without first setting up JCL to write to an 
ordinary sequential data set and verifying that the DCB attributes of the 
sequential data set can be made consistent with those of the PDS.  There are 
still ways to mess up, but the odds are much better.
  JC Ewing
On 07/27/2011 06:35 AM, esmie moo wrote:
> Barry,
> 
> The STORAGE GROUP was backed up via HSM, what I didn't say correctly that the 
> volume was not backed up (full dump).
> When I am able to do a browse of the dsn, all the members are displayed 
> correctly, however when I browse each member I get the following :
> 
> I/O error
> 
>

Re: CORRUPT PDS - I/O ERROR

[Richard L Peurifoy]

On 7/27/2011 7:12 AM, esmie moo wrote:

The use of AMASPZAP is restricted.  No can do.  Thanks for the suggestion.


You can get a dump of a member with IDCAMS:

//IDCAMS   JOB
//PRINT   EXEC PGM=IDCAMS,REGION=64M
//SYSPRINT  DD SYSOUT=A
//DSN1  DD DSN=your dsn(some member),
// DCB=(RECFM=U,BLKSIZE=32760),
// DISP=SHR
//SYSIN DD *
 PRINT INFILE(DSN1)

From this maybe you can figure out what the LRECL should be.
If the records appear to have a length in front of them,
try RECFM=VB, otherwise try FB. Then pick the largest multiple
that is less than or equal to 32760 for the BLKSIZE. If it's VB
add 4. This is not an ideal BLKSIZE, but hopefully will let you
read your members.

Add a dummy member specifying these values and see if you can read
the members (other than the one that caused this problem in the first
place).

--
Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

In that case I'd have to check it physically (with a 'program v. JCL' 
DCB with MACRF=(R/G)) ... and I don't have the time to do that. Thanks 
anyway.


Tom Marchant wrote:


On Wed, 27 Jul 2011 00:08:42 +0100, CM Poncelet wrote:

 


I don't check "Using Data Sets";
   



Perhaps you should.

 


but that is how things were in the days of MVS OS/VS SP1 (1985):
   



It was not how it worked in OS/360.  I just looked it up in the JCL 
manual on bitsavers.  The sequence of completing a DCB is the 
same regardless of whether the data set is opened for input, 
output or I/O.


 


if things
have 'changed' since then, so be it.

Tom Marchant wrote:

   


On Tue, 26 Jul 2011 22:47:16 +0100, CM Poncelet wrote:

 


When opening for input, the priority order is
reversed (DASD, JCL, program).
   


I don't think so, and Using Data Sets seems to say otherwise.
Can you cite a reference?
 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Ed Gould]

Well chances are then the block size is a multiple of 80 (this assumes some 
things but semi valid assumption) it wouldn't hurt to try this run an iebgener 
with sysut2 having a blsize of 32760 and lrecl of 80 recfm FB and a member name 
of say dummy this should make the data set usable.

Ed

Sent from my iPad

On Jul 27, 2011, at 6:43 AM, esmie moo  wrote:

> Ed,
>  
> When I recovered the dsn from the HSM incremental backup there were no error 
> messages posted - I received the standard ARC0778I DATA SET WAS RECOVERED 
> message.  The datamover is DFDSS.
>  
>  
> 
> From: Ed Gould 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tuesday, July 26, 2011 7:30:51 PM
> Subject: Re: CORRUPT PDS - I/O ERROR
> 
> Chances are thar DFHSM did not back up the dataset after it was corrupted. 
> Check DFHSM for the error. Not sure what DFHSM would do if DFDSS were the 
> data mover. I would guess that DFDSS invokes IEBCOPY under the covers and it 
> wouldn't work so.
> 
> Ed
> 
> Sent from my iPad
> 
> On Jul 26, 2011, at 4:47 PM, CM Poncelet  wrote:
> 
>> This can happen with any PDS if it is opened for output with a DCB other 
>> than its original one (e.g. originally RECFM=FB, but opened with RECFM=VB 
>> etc.) When opening for output, the DCB used is (a) the one specified in the 
>> program; (b) the one in the JCL; (c) the one on DASD - in that order of 
>> priority. When opening for input, the priority order is reversed (DASD, JCL, 
>> program). If the incorrect output DCB was specified in a program, it needs 
>> to be fixed there: this program should then be rerun to open the PDS with 
>> its correct attributes; then close the PDS. After that, the original members 
>> will be accessible again. But any members which were created using the 
>> program's previously incorrect DCB will now hit I/O errors (so copy them to 
>> another PDS beforehand if they need to be kept).
>> 
>> Schwarz, Barry A wrote:
>> 
>>> If the storage group is not backed up, how did HSM ever back up a copy for 
>>> you to recover from?  Was there a copy of the dataset on disk when you 
>>> recovered it from HSM?  What was the command you used to perform the 
>>> recovery?  When you browse the PDS, does the member list display correctly? 
>>>  What are the DCB attributes of the PDS?  Do they match what you think they 
>>> should be?  What is the exact error message?
>>> 
>>> 
>>>> -Original Message-
>>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
>>>> Behalf Of esmie moo
>>>> Sent: Tuesday, July 26, 2011 10:03 AM
>>>> To: IBM-MAIN@bama.ua.edu
>>>> Subject: CORRUPT PDS - I/O ERROR
>>>> 
>>>> Good Morning Gentle Readers,
>>>> 
>>>> When I try to browse a member of  my pds I get a I/O error.  I tried
>>>> browsing several members but I get the same error message.  Is there a way
>>>> of fixing it?  For some reason the storage group is NOT backed up so I
>>>> cannot restore it from an old backup.  I recovered the PDS from a DFHSM
>>>> backup but when I try to browse any members I still get the I/O error.  Is
>>>> there a work around to this problem or should I consider it lost?
>>>>   
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>>> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>>> 
>>> 
>>> 
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Paul Gilmartin]

On Wed, 27 Jul 2011 19:02:37 -0500, Ed Gould  wrote:

>Well chances are then the block size is a multiple of 80 (this assumes some 
>things but semi valid assumption) it wouldn't hurt to try this run an iebgener 
>with sysut2 having a blsize of 32760 and lrecl of 80 recfm FB and a member 
>name of say dummy this should make the data set usable.
>
Errr... Wouldn't it be better to use a BLKSIZE that's a multiple of 80?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Ed Gould]

 Paul,

Ugh of course you are correct. That is what happens when you do things on the 
fly and don't have access to a calculator. Mea culpa.

Ed


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Dale Miller]

I realize that the OP has been able to resolve the problem, but I  
think a couple of points need to be raised.
1) AMASPZAP is not needed to print the contents of a member, nor is it  
necessary to change the DCB attributes of the existing PDS. If the PDS  
member is allocated with a DD with the DCB attributes desired (or via  
dynalloc) neither of which actually change the attributes of the  
existing dataset, then IDCAMS PRINT will print the contents. I've been  
through this many times in the past.
2) There is a difference between the relative priority of DCB  
information, and the actual mechanism involved. The order of priority  
was stated correctly, but the exact mechanism is a little more complex  
and does depend on
	a) whether the DISP is NEW (or MOD if the dataset is not found and  
must be created), or OLD/SHR(or MOD if the dataset is found)

b) whether the file is opened for INPUT or OUTPUT.
Unless some UNIX programmers are lurking in the woodpile since I was  
current in this area, There is a "forward merge" (from dataset to JFCB  
to DCB) and a "reverse merge" of DCB information (from DCB to JFCB to  
dataset). The stated priority is observed (which is why one can  
TEMPORARILY override the dataset attributes with a DD card if the OPEN  
is for INPUT, or why using a BLOCK CONTAINS clause with other than 0  
on a COBOL input file is asking for problems). The "forward merge"  
from the dataset to the JFCB obviously cannot be done with a newly  
created dataset, and the "reverse merge" from the JFCB to the dataset  
is only done for a DISP=NEW or for an OPEN OUTPUT. which is why I can  
READ  an existing dataset using a bogus DCB parameter without actually  
changing the dataset attributes, but since, as has been pointed out, a  
PDS has only one set of DCB attributes, adding a member to a PDS using  
a JFCB/DD or DCB with invalid attributes corrupts the PDS and makes  
members unreadable.  It can even be more complex when such antics as  
RDJFCB are employed (there was a recent thread that got bogged down  
over confusion due to the way the old Linkage Editor (perhaps the  
Binder as well?) distinguished between DISP=SHR and DISP=MOD. Beware -  
all this is based on my admittedly rusty memory).
That said,  the advice to use PDSMAN or the CBT PDS command is well  
taken and is the best solution to the problem. The best long-term  
solution to the problem is to either remove the offending programmer  
from the gene pool, apply some behavior modification in terms of  
education, or use some proactive guard against modifying the DCB  
parameters of FB PDS's (I seem to recall a function of MIM which might  
do this), or make sure of frequent backups and frequent monitoring of  
the dataset's attributes.


Dale Miller

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Tom Marchant]

On Thu, 28 Jul 2011 12:04:37 -0700, Dale Miller wrote:

>2) There is a difference between the relative priority of DCB
>information, and the actual mechanism involved. The order of priority
>was stated correctly, 

stated correctly by whom?  AFAIK, CM Poncelet got it wrong.

>but the exact mechanism is a little more complex
>and does depend on
>   a) whether the DISP is NEW (or MOD if the dataset is not found and
>must be created), or OLD/SHR(or MOD if the dataset is found)

Label (DSCB or tape label) is only used for an existing data set

>   b) whether the file is opened for INPUT or OUTPUT.

Mr. Poncelet made the same assertion.  I'm pretty sure that it is incorrect. 
Do you have a manual reference that you can cite to justify it?

>one can
>TEMPORARILY override the dataset attributes with a DD card if the OPEN
>is for INPUT

No.  See for example the JCL Reference manual.

12.16.3 Completing the Data Control Block

The system obtains data control block information from the following sources, 
in override order:
- The processing program, that is, the DCB macro instruction in assembler 
  language programs or file definition statements or language-defined defaults 
  in programs in other languages.  
- The DCB subparameter of the DD statement.  
- The data set label.

Therefore, if you supply information for the same DCB field in your processing 
program and on a DD statement, the system ignores the DD DCB subparameter. 
If a DD statement and the data set label supply information for the same DCB 
field, the system ignores the data set label information.


-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Dale Miller]

In my previous note I said:

one can
TEMPORARILY override the dataset attributes with a DD card if the OPEN
is for INPUT
Mr. Marchant said "NO", and referred to the JCL Reference Manual  
section "Completing the data control block".
Please read again what I said. I said "dataset attributes", not the  
data control block. My discussion of the process indicated that  
because of the order of the merge, if I supply a DD card with "DCB"  
attributes, the ones supplied on the DD card (JFCB) will override the  
DSCB/label, which is supported by the material quoted. I failed to say  
that that overridden information is what is used only if the program's  
DCB does not supply that information (or if a RDJFCB is used to allow  
the DD to override any defaults in the DCB.), I don't know the  
internal logic of IDCAMS print, but it does something like this since  
one CAN override the DSCB info with a DD card.
Quite obviously, for a newly-created dataset, the information would  
have to come from the DD or the program DCB, but that is what I  
said:"the forward merge from the dataset to the JFCB obviously cannot  
be done for a newly-created dataset".
Since I no longer have much access to manuals or the class materials I  
generated relating to the OPEN process, I cannot cite any references,  
but they were there when I did the class.
I can only say that my experience is that using IDCAMS PRINT with a  
"bogus" DD works and does not alter the PDS DSCB. The quoted material  
does NOT say that the DSCB is updated from the DCB for a file opened  
INPUT. But one thing should be obvious: the OPEN process is much more  
complex than indicated by the section from the JCL Reference Manual.


Dale Miller
dalelmil...@comcast.net

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

What I am saying is that, on INPUT, a dataset's physical DCB attributes 
from its DSCB on DASD cannot be overriden by a JCL or program DCB.


Consider the following JCL where
SYS1.RECFMVBA.LRECL137.BLK27998 has physical 
DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS)
SYS1.RECFMFBA.LRECL137.BLK27948 has physical 
DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948,DSORG=PS):


//IEBGENER EXEC PGM=IEBGENER
//SYSPRINT  DD SYSOUT=*
//SYSIN DD DUMMY
//*
//SYSUT1DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998,
//* cannot override dataset's DCB on DASD via JCL, for INPUT:
// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
//* 
//SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948,

// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
//*
//IDCAMS  EXEC PGM=IDCAMS
//SYSPRINT  DD SYSOUT=*
//*
//SYSUT1DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998,
//* cannot override dataset's DCB on DASD via JCL, for INPUT:
// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
//* 
//SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948,

// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
//SYSIN DD *
 REPRO   INFILE(SYSUT1) +
OUTFILE(SYSUT2)
//*

According to you, the DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) on SYSUT1 
(opened for input) should override the dataset's 
DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) on DASD. But that is 
not the case.


If you set up and run the jobsteps above, both IEBGENER and IDCAMS 
report "IEB351I I/O ERROR  SYSUT1, READ, WRNG.LEN.RECORD, etc." 
when reading SYSUT1. This is because the dataset's DASD DSCB/DCB 
attributes override those coded in the JCL (and would also override the 
programs's DCB, if hard-coded), for INPUT.


If SYSUT1 and SYSUT2 are switched round as in:

//IEBGENER EXEC PGM=IEBGENER
//SYSPRINT  DD SYSOUT=*
//SYSIN DD DUMMY
//*
//SYSUT2DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998, 
//* can override dataset's DCB on DASD via JCL, for OUTPUT:

// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
//* 
//SYSUT1DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948,

// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
//*
//IDCAMS  EXEC PGM=IDCAMS
//SYSPRINT  DD SYSOUT=*
//*
//SYSUT2DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998,
//* can override dataset's DCB on DASD via JCL, for OUTPUT:
// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
//*  
//SYSUT1DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948,

// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
//SYSIN DD *
 REPRO   INFILE(SYSUT1) +
OUTFILE(SYSUT2)
//*

Then SYSUT1's JCL DCB matches the one on DASD's DSCB and no I/O error 
occurs when reading SYSUT1.


Likewise, no I/O error occurs when writing to SYSUT2 (although its JCL 
DCB does not match the one on DASD) because the JCL's DCB overrides the 
one on DASD, for OUTPUT.


To say that the order of priority for INPUT is 'program DCB -> JCL DCB 
-> DASD DCB' is meaningless if neither the program DCB nor JCL DCB can 
modify/override the DASD's DSCB/DCB to avoid physical I/O errors on INPUT.


I don't think I 'got it wrong' ...

Cheers,

Chris Poncelet
.

Tom Marchant wrote:


On Thu, 28 Jul 2011 12:04:37 -0700, Dale Miller wrote:

 


2) There is a difference between the relative priority of DCB
information, and the actual mechanism involved. The order of priority
was stated correctly, 
   



stated correctly by whom?  AFAIK, CM Poncelet got it wrong.

 


but the exact mechanism is a little more complex
and does depend on
a) whether the DISP is NEW (or MOD if the dataset is not found and
must be created), or OLD/SHR(or MOD if the dataset is found)
   



Label (DSCB or tape label) is only used for an existing data set

 


b) whether the file is opened for INPUT or OUTPUT.
   



Mr. Poncelet made the same assertion.  I'm pretty sure that it is incorrect. 
Do you have a manual reference that you can cite to justify it?


 


one can
TEMPORARILY override the dataset attributes with a DD card if the OPEN
is for INPUT
   



No.  See for example the JCL Reference manual.

12.16.3 Completing the Data Control Block

The system obtains data control block information from the following sources, 
in override order:
- The processing program, that is, the DCB macro instruction in assembler 
 language programs or file definition statements or language-defined defaults 
 in programs in other languages.  
- The DCB subparameter of the DD statement.  
- The data set label.


Therefore, if you supply information for the same DCB field in your processing 
program and on a DD statement, the system ignores the DD DCB subparameter. 
If a DD statement and the data set label supply information for the same DCB 
field, the system ignores the data set label information.



 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http

Re: CORRUPT PDS - I/O ERROR

[Binyamin Dissen]

On Sat, 30 Jul 2011 22:31:57 +0100 CM Poncelet  wrote:

:>What I am saying is that, on INPUT, a dataset's physical DCB attributes 
:>from its DSCB on DASD cannot be overriden by a JCL or program DCB.

:>Consider the following JCL where
:>SYS1.RECFMVBA.LRECL137.BLK27998 has physical 
:>DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS)
:>SYS1.RECFMFBA.LRECL137.BLK27948 has physical 
:>DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948,DSORG=PS):

:>//IEBGENER EXEC PGM=IEBGENER
:>//SYSPRINT  DD SYSOUT=*
:>//SYSIN DD DUMMY
:>//*
:>//SYSUT1DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998,
:>//* cannot override dataset's DCB on DASD via JCL, for INPUT:
:>// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
:>//* 
:>//SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948,
:>// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
:>//*
:>//IDCAMS  EXEC PGM=IDCAMS
:>//SYSPRINT  DD SYSOUT=*
:>//*
:>//SYSUT1DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998,
:>//* cannot override dataset's DCB on DASD via JCL, for INPUT:
:>// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
:>//* 
:>//SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948,
:>// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
:>//SYSIN DD *
:>  REPRO   INFILE(SYSUT1) +
:> OUTFILE(SYSUT2)
:>//*

:>According to you, the DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) on SYSUT1 
:>(opened for input) should override the dataset's 
:>DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) on DASD. But that is 
:>not the case.

:>If you set up and run the jobsteps above, both IEBGENER and IDCAMS 
:>report "IEB351I I/O ERROR  SYSUT1, READ, WRNG.LEN.RECORD, etc." 
:>when reading SYSUT1. This is because the dataset's DASD DSCB/DCB 
:>attributes override those coded in the JCL (and would also override the 
:>programs's DCB, if hard-coded), for INPUT.

Not at all. It proves that the DCB - was - overridden.

Of course, the DCB override does not affect the physical data. If the actual
data block length is longer than the DCB block length there will be an I/O
error.

For example, if your override was for a - larger - blocksize it would have
worked fine (other than perhaps IDCAMS/IEBGENER) warnings about different
block sizes.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

I'm afraid I disagree. What it proves is not that the DCB on DASD was 
overwritten by the one in the JCL, but that the DCB in the JCL was 
incorrect/incompatible with the one on DASD.


If I allocate SYSUT1 with DCB=(RECFM=FBA,LRECL=121,BLKSIZE=16093) and 
SYSUT2 with DCB=(REFM=FBA,LRECL=133,BLKSIZE=16093), where 121*133=16093, 
then both the physical RECFM and data block lengths are the same for 
SYSUT1 and SYSUT2. If I specify:


//IEBGENER EXEC PGM=IEBGENER
//SYSPRINT  DD SYSOUT=*
//SYSIN DD DUMMY
//*
//SYSUT1DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL121.BLK16093,
//* cannot override dataset's DCB on DASD via JCL, for INPUT:
// DCB=(RECFM=FBA,LRECL=133,BLKSIZE=16093)
//* 
//SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL133.BLK16093,

// DCB=(RECFM=FBA,LRECL=133,BLKSIZE=16093)
//*


I then still hit I/O errors without IEBGENER issuing message "IEB311I 
CONFLICTING DCB PARAMETERS" and the DCB BLKSIZEs are compatible, i.e. 
the physical data block size is not larger than the DCB BLKSIZE in the 
JCL's override.


If instead I allocate SYSUT1 with 
DCB=(RECFM=FBA,LRECL=121,BLKSIZE=16093) and SYSUT2 with 
DCB=(REFM=FBA,LRECL=133,BLKSIZE=27930) and specify


//IEBGENER EXEC PGM=IEBGENER
//SYSPRINT  DD SYSOUT=*
//SYSIN DD DUMMY
//*
//SYSUT1DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL121.BLK16093,
//* cannot override dataset's DCB on DASD via JCL, for INPUT:
// DCB=(RECFM=FBA,LRECL=133,BLKSIZE=27930)
//* 
//SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL133.BLK16093,

// DCB=(RECFM=FBA,LRECL=133,BLKSIZE=27930)
//*


I then still hit I/O errors without IEBGENER issuing message "IEB311I 
CONFLICTING DCB PARAMETERS" and the JCL's DCB BLKSIZE override for 
SYSUT1 is now greater than its physical data block size on DASD (hence 
there is enough buffer space allocated via the JCL DCB's override to 
read in a SYSUT1's complete physical data block from DASD).


Hence your "For example, if your override was for a - larger - blocksize 
it would have worked fine (other than perhaps IDCAMS/IEBGENER) warnings 
about different block sizes." is not correct. An equal or larger 
blocksize override in the JCL makes no difference.


What you are implicitly suggesting is that the I/O error has nothing to 
do with the JCL or program DCB being in error. But if so, is it then the 
one on DASD that is incorrect? I am saying that the DCB on DASD can be 
overridden only during OUTPUT, not INPUT.


That the JCL or program DCB specifies a 'round hole' override into which 
the DASD's 'square peg' DCB cannot fit does not imply that the JCL or 
program DCB has successfully overridden the one on DASD, but rather that 
the program or JCL DCB is wrong and cannot override the one on DASD.


Thanks anyway.

Chris Poncelet


Binyamin Dissen wrote:


On Sat, 30 Jul 2011 22:31:57 +0100 CM Poncelet  wrote:

:>What I am saying is that, on INPUT, a dataset's physical DCB attributes 
:>from its DSCB on DASD cannot be overriden by a JCL or program DCB.


:>Consider the following JCL where
:>SYS1.RECFMVBA.LRECL137.BLK27998 has physical 
:>DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS)
:>SYS1.RECFMFBA.LRECL137.BLK27948 has physical 
:>DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948,DSORG=PS):


:>//IEBGENER EXEC PGM=IEBGENER
:>//SYSPRINT  DD SYSOUT=*
:>//SYSIN DD DUMMY
:>//*
:>//SYSUT1DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998,
:>//* cannot override dataset's DCB on DASD via JCL, for INPUT:
:>// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
:>//* 
:>//SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948,

:>// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
:>//*
:>//IDCAMS  EXEC PGM=IDCAMS
:>//SYSPRINT  DD SYSOUT=*
:>//*
:>//SYSUT1DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998,
:>//* cannot override dataset's DCB on DASD via JCL, for INPUT:
:>// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
:>//* 
:>//SYSUT2DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948,

:>// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
:>//SYSIN DD *
:>  REPRO   INFILE(SYSUT1) +
:> OUTFILE(SYSUT2)
:>//*

:>According to you, the DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) on SYSUT1 
:>(opened for input) should override the dataset's 
:>DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) on DASD. But that is 
:>not the case.


:>If you set up and run the jobsteps above, both IEBGENER and IDCAMS 
:>report "IEB351I I/O ERROR  SYSUT1, READ, WRNG.LEN.RECORD, etc." 
:>when reading SYSUT1. This is because the dataset's DASD DSCB/DCB 
:>attributes override those coded in the JCL (and would also override the 
:>programs's DCB, if hard-coded), for INPUT.


Not at all. It proves that the DCB - was - overridden.

Of course, the DCB override does not affect the physical data. If the actual
data block length is longer than the DCB block length there will be an I/O
error.

For example, if your override was for a - larger - blocksize it would have
worked fine (other than perhaps IDCAMS/IEBGENER) warnings about di

Re: CORRUPT PDS - I/O ERROR

[Shmuel Metz (Seymour J.)]

In <1311699756.83896.yahoomail...@web34508.mail.mud.yahoo.com>, on
07/26/2011
   at 10:02 AM, esmie moo  said:

>When I try to browse a member of  my pds I get a I/O error.  I tried
>browsing several members but I get the same error message.  Is there
>a way of fixing it?

Not without knowing what the error message is.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Shmuel Metz (Seymour J.)]

In <4e2f48fa.8010...@bcs.org.uk>, on 07/27/2011
   at 12:08 AM, CM Poncelet  said:

>But the exit points 'count' as program DCBs

NFW; they count as exits. The actual priority order is:

   DSCB1
   JFCB[1]
   DCB
   Changes made by DCB Exit

regardless of whether it is input or output.

>as they execute first

No.

>and override what is in the JCL.

Some do, some don't.

>I don't check "Using Data Sets";

That was your first mistake.

>but that is how things were in the days of MVS OS/VS SP1 (1985): 

There was no such animal. That wasn't the way that OS/360, OS/VS1,
OS/VS2 R1, OS/VS2 MVS, MVS/SP or any subsequent version of MVS
behaved.

[1] Initially from JCL.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Shmuel Metz (Seymour J.)]

In ,
on 07/27/2011
   at 07:20 AM, "McKown, John"  said:

>Many placed do. I don't understand why. 

Stupidity above and beyond the call of duty. It's an example of
auditing by checklist, with the checklist written by Kafka.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Shmuel Metz (Seymour J.)]

In <7070637171425220.wa.m42tomibmmainyahoo@bama.ua.edu>, on
07/29/2011
   at 09:33 AM, Tom Marchant  said:

>On Thu, 28 Jul 2011 12:04:37 -0700, Dale Miller wrote:

>Label (DSCB or tape label) is only used for an existing data set

More precisely, the relevant fields for a new dataset are initialized
to zero, so the effect of the forward merge is nil.

>Mr. Poncelet made the same assertion.

No; he made a very different assertion. Dale Miller's assertion that
the reverse merge is not done for INPUT was correct.

>>one can TEMPORARILY override the dataset attributes with a DD 
>>card if the OPEN is for INPUT

>No.  See for example the JCL Reference manual.

Yes. The text you quote shows the data set label as lowest priority.

>Therefore, if you supply information for the same DCB field in your
>processing  program and on a DD statement,

That has nothing to do with what he wrote.

>If a DD statement and the data set label supply information for the
>same DCB field, the system ignores the data set label information.

No, it merges them.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Dale Miller]

I apparently am having trouble speaking English - I thought I said  
that in the open merge, "DCB" info coded into the DD/JFCB overrides  
information from the DSCB. I did NOT say that is replaces the  
information in the DSCB. IEBGENER and other utilities apparently use  
RDJFCB (or open exits? or do an OBTAIN of the DSCB) and play games.  
For a standard open (such as for a COBOL file) or a normal open in an  
ASM program, attributes coded in the DD/JFCB override the information  
from the DSCB. Consider a COBOL FD coded with "BLOCK CONTAINS nn"  
where "nn" is not 0. If "nn" in this case is either not a multiple of  
the LRECL, or is not greater than or equal to the DSCB BLKSIZE(for  
input), you get an open error or I/O error. With a COBOL FD "BLOCK  
contains 0", or a DCB BLKSIZE=0, then after the open, the program DCB  
will contain the merged-in BLKSIZE attribute. As everyone is saying, I  
think, any attributes coded in the DCB are not overridden by the  
merged-in attributes. The merged information (with any attributes  
coded in the program DCB having priority) are merged back to the JFCB,  
and  are merged back to the DSCB only if the open is for output.


Dale Miller

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

Shmuel Metz (Seymour J.) wrote:


In <4e2f48fa.8010...@bcs.org.uk>, on 07/27/2011
  at 12:08 AM, CM Poncelet  said:

 


But the exit points 'count' as program DCBs

they 'count' as program DCBs is short-speak for 'they are executable 
code' (as opposed to JCL and DASD)


   



NFW; they count as exits. The actual priority order is:

  DSCB1
  JFCB[1]
  DCB
  Changes made by DCB Exit

regardless of whether it is input or output.

I know that; but on input they do not override the DCB from DASD - and 
that is regardless of their order




 


as they execute first
   



No.

'short-speak' for they 'they are part of program code execution' in the 
'program -> JCL -> DASD' sequence (... and before you tell me that exits 
do not have to be part of a program, I know that too)




 


and override what is in the JCL.
   



Some do, some don't.

I am speaking within the context of the priority order of DCBs in the 
'program -> JCL -> DASD' sequence




 


I don't check "Using Data Sets";
   



That was your first mistake.

I don't need to check "Using Data Sets" (I did that more than 25 years 
ago  or the 'equivalent of ditto' before you say "Using Data Sets" 
was not being published more than 25 years ago).
Galileo did not need to check "the Bible" either before he said the 
earth was not at the center of the universe: was that his first mistake?




 

but that is how things were in the days of MVS OS/VS SP1 (1985): 
   



There was no such animal. That wasn't the way that OS/360, OS/VS1,
OS/VS2 R1, OS/VS2 MVS, MVS/SP or any subsequent version of MVS
behaved.

in that case it was one of OS/VS1 to MVS/SP (I don't spend time 
remembering these things, except vaguely)




[1] Initially from JCL.


I know that..

I think you are splitting hairs for the sake of arguing ...



 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Binyamin Dissen]

On Sun, 31 Jul 2011 15:43:15 +0100 CM Poncelet  wrote:

:>I know that; but on input they do not override the DCB from DASD - and 
:>that is regardless of their order

What do you mean by that statement?

Do you mean that they do not change the physical data already recorded? Nobody
would disagree. And that would equally apply to output.

Do you mean that the program will have its non-zero DCB overlaid with the data
from the DSCB? You are wrong.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

Binyamin Dissen wrote:


On Sun, 31 Jul 2011 15:43:15 +0100 CM Poncelet  wrote:

:>I know that; but on input they do not override the DCB from DASD - and 
:>that is regardless of their order


What do you mean by that statement?

Before the DCB on DASD can be accessed, the program's own 'completed' 
DCB (including any missing DCB parms filled-in from a RDJFCB of the 
JCL's DD and/or from an exit, if present) must be opened. This might 
suggest that the program's DCB, within the above context, overrides the 
one on DASD. But the DASD DCB attributes override the program's DCB 
attributes when the data is actually read - in the sense that the data 
on DASD will be INPUT without I/O error only if the opened program DCB's 
attributes are the same as those on DASD. It is not the program's DCB 
attributes (including any 'supplied' by exits etc.) but those on DASD 
which take priority and 'decide' what the DCB attributes should be on 
INPUT. If the program's DCB attributes could override those on DASD for 
INPUT, the program's 1st read after opening the DCB for INPUT would not 
fail with an I/O error if its DCB attributes were different from those 
on DASD - just as there is no I/O error when the program opens a DCB for 
OUTPUT and then writes to DASD (regardless of what the DCB attributes 
are on DASD).


The program's DCB attributes take priority over (i.e. 'override') the 
DCB attributes on DASD for OUTPUT, and the DCB attributes on DASD take 
priority over (i.e. 'override') the program's DCB for INPUT. If a 
program 'disagrees' with that and tries to override the DCB attributes 
on DASD anyway, with its own DCB attributes and for an INPUT, it crashes 
with an I/O error. Crashing with an I/O error indicates that the 
program's DCB was unable - not able - to override the DCB attributes on 
DASD.




Do you mean that they do not change the physical data already recorded? Nobody
would disagree. And that would equally apply to output.

On INPUT, the programs' DCB does not even change the RECFM, LRECL and 
BLKSIZE on DASD - never mind the physical data.
On OUTPUT, the program's DCB does change the RECFM, LRECL and BLKSIZE as 
well as the physical data on DASD - although a program would normally 
leave the RECFM, LRECL and BLKSIZE on DASD 'changed' to what they 
already are; otherwise we could get the sort of I/O errors which started 
this discussion thread.




Do you mean that the program will have its non-zero DCB overlaid with the data
from the DSCB? You are wrong.

No, only its zero DCB attributes are overlaid - i.e. those which need to 
be filled in to 'complete' the DCB.




--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Schwarz, Barry A]

If you use IDCAMS to print a VB dataset in dump format with no DD overrides, 
you will get a dump of the data portion of the records and never see the BDW or 
RDW.

If you run the same commands but specify RECFM=U and BLKSIZE=32760, your dump 
will be organized by blocks, not records, and you will see both the BDWs and 
RDWs.

While the data in the DSCB will not be changed, it seems fairly obvious that 
the DCB data from the DSCB was (temporarily) overridden by the DCB data in the 
DD statement.

And if you used a program that had DCB data hardcoded in the DCB macro, that 
data would override both the DSCB data and the DD statement data.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of CM Poncelet
> Sent: Sunday, July 31, 2011 9:35 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CORRUPT PDS - I/O ERROR


> Before the DCB on DASD can be accessed, the program's own 'completed'
> DCB (including any missing DCB parms filled-in from a RDJFCB of the
> JCL's DD and/or from an exit, if present) must be opened. This might
> suggest that the program's DCB, within the above context, overrides the
> one on DASD. But the DASD DCB attributes override the program's DCB
> attributes when the data is actually read - in the sense that the data
> on DASD will be INPUT without I/O error only if the opened program DCB's
> attributes are the same as those on DASD. It is not the program's DCB
> attributes (including any 'supplied' by exits etc.) but those on DASD
> which take priority and 'decide' what the DCB attributes should be on
> INPUT. If the program's DCB attributes could override those on DASD for
> INPUT, the program's 1st read after opening the DCB for INPUT would not
> fail with an I/O error if its DCB attributes were different from those
> on DASD - just as there is no I/O error when the program opens a DCB for
> OUTPUT and then writes to DASD (regardless of what the DCB attributes
> are on DASD).
>
> The program's DCB attributes take priority over (i.e. 'override') the
> DCB attributes on DASD for OUTPUT, and the DCB attributes on DASD take
> priority over (i.e. 'override') the program's DCB for INPUT. If a
> program 'disagrees' with that and tries to override the DCB attributes
> on DASD anyway, with its own DCB attributes and for an INPUT, it crashes
> with an I/O error. Crashing with an I/O error indicates that the
> program's DCB was unable - not able - to override the DCB attributes on
> DASD.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Gerhard Postpischil]

On 7/31/2011 12:35 PM, CM Poncelet wrote:

The program's DCB attributes take priority over (i.e.
'override') the DCB attributes on DASD for OUTPUT, and the DCB
attributes on DASD take priority over (i.e. 'override') the
program's DCB for INPUT. If a program 'disagrees' with that and
tries to override the DCB attributes on DASD anyway, with its
own DCB attributes and for an INPUT, it crashes with an I/O
error. Crashing with an I/O error indicates that the program's
DCB was unable - not able - to override the DCB attributes on DASD.


What we have here is a failure to communicate. Your statement 
above makes it evident that you are using "DCB attributes on 
DASD" as applying to the format of the data, whereas the other 
participants in this merry-go-round are referring to the DCB 
parameters in the format 1 DSCB (DS1RECFM, DS1LRECL, DS1BLKL).



Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Binyamin Dissen]

On Sun, 31 Jul 2011 18:19:11 -0400 Gerhard Postpischil 
wrote:

:>On 7/31/2011 12:35 PM, CM Poncelet wrote:
:>> The program's DCB attributes take priority over (i.e.
:>> 'override') the DCB attributes on DASD for OUTPUT, and the DCB
:>> attributes on DASD take priority over (i.e. 'override') the
:>> program's DCB for INPUT. If a program 'disagrees' with that and
:>> tries to override the DCB attributes on DASD anyway, with its
:>> own DCB attributes and for an INPUT, it crashes with an I/O
:>> error. Crashing with an I/O error indicates that the program's
:>> DCB was unable - not able - to override the DCB attributes on DASD.

:>What we have here is a failure to communicate. Your statement 
:>above makes it evident that you are using "DCB attributes on 
:>DASD" as applying to the format of the data, whereas the other 
:>participants in this merry-go-round are referring to the DCB 
:>parameters in the format 1 DSCB (DS1RECFM, DS1LRECL, DS1BLKL).

Yes, that was what I was trying to point out to him.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Shmuel Metz (Seymour J.)]

In <4e34784d.2020...@bcs.org.uk>, on 07/30/2011
   at 10:31 PM, CM Poncelet  said:

>What I am saying is that, on INPUT, a dataset's physical DCB
>attributes  from its DSCB on DASD cannot be overriden by a JCL or
>program DCB.

Yes, and what you are saying is wrong.

>According to you, the DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) on
>SYSUT1  (opened for input) should override the dataset's 
>DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) on DASD.

Correct.

>But that is not the case.

Yes it is.

>If you set up and run the jobsteps above, both IEBGENER and IDCAMS 
>report "IEB351I I/O ERROR  SYSUT1, READ, WRNG.LEN.RECORD,
>etc."  when reading SYSUT1.

Proving that the DCB information in the DD statement *did* override
the DSCB.

>This is because the dataset's DASD DSCB/DCB 
>attributes override those coded in the JCL (and would also override
>the  programs's DCB, if hard-coded), for INPUT.

No; if they overrode the DCB then you wouldn't get the I/O error.

>To say that the order of priority for INPUT is 'program DCB -> JCL
>DCB  -> DASD DCB' is meaningless if neither the program DCB nor JCL
>DCB can  modify/override the DASD's DSCB/DCB to avoid physical I/O
>errors on INPUT.

To say that your name is Poncelet is meaningless if the Sun is an
apple.

>I don't think I 'got it wrong' ...

Then RTFM.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Shmuel Metz (Seymour J.)]

In <4e349468.4060...@bcs.org.uk>, on 07/31/2011
   at 12:31 AM, CM Poncelet  said:

>I'm afraid I disagree.

Because you are confusing the DSCB with the blocks written in the
dataset.

>What it proves is not that the DCB on DASD was 
>overwritten by the one in the JCL, but that the DCB in the JCL was 
>incorrect/incompatible with the one on DASD.

Why would you get an I/O error if the DCB information on the DD
statement did not take precedence over that in the DSCB?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

The 'acid test' is whether the same program DCB (ignoring the MACRF= and 
EODAD=) can be used *both* for OUTPUT and for INPUT (with a change in 
MACFR= and adding EODAD= when opening for INPUT), when the dataset's 
physical DCB attributes on DASD are *different* from those specified in 
the program.


If this DCB is opened for OUTPUT (MACRF=PM|L), then the program's DCB 
attributes override those on DASD - and the program's DCB attributes 
then also become those stored on DASD, all without causing I/O errors. 
This is because the program's DCB attributes override the dataset's 
existing DCB attributes on DASD when opened for OUTPUT.


If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=), then the 
program's DCB attributes do *not* override those on DASD - and, as the 
program's DCB attributes are inconsistent with those of the dataset on 
DASD, they cause I/O errors ... because the dataset's DCB attributes on 
DASD take priority over those of the program's DCB. If the program's DCB 
attributes do not match those on DASD for INPUT, it's just another case 
of garbage-in / garbage-out. A program's DCB attributes do *not* 
override an existing dataset's DCB attributes on DASD when opened for INPUT.


Hence, if opened for OUTPUT, the priority order is "program DCB -> JCL 
DCB -> DASD DCB".


But if opened for INPUT, the priority order is "DASD DCB -> JCL DCB -> 
program DCB". If the program's DCB attributes are then inconsistent with 
the ones on DASD, on INPUT, the program hits I/O errors - because the 
DCB attributes on DASD override those hard-coded in the program on INPUT 
(and not, as has been suggested, the other way round). If the program's 
DCB attributes, for INPUT, are inconsistent with those of the physical 
dataset stored on DASD, they do not override those stored on DASD but 
cause I/O failures.


For the sake of expediency, "DCB" includes "DSCB" etc. - because this 
discussion topic is about DCBs.


If I am wrong, please prove it by submitting verifiable 'general 
purpose' examples of this (excluding 'reblocking' trivia). A 'verifiable 
example' is one in which all the program's DCB attributes are different 
from those of the dataset's physical DCB attributes on DASD - yet 
override the dataset's DCB attributes stored on DASD *both* when the 
dataset is opened and written for OUTPUT and also when it is opened and 
read for INPUT (subject to the appropriate MACRF= etc. being specified 
on the DCB in each case). If you cannot prove it by a 'verifiable 
example', then you are arguing high-falluting semantics where the 
interpretation of "DCB override" depends entirely upon what *you* mean 
by that, and is not subject to what "DCB override" is actually 
understood to mean in practice.


Thanks,

Chris Poncelet


Binyamin Dissen wrote:


On Sun, 31 Jul 2011 18:19:11 -0400 Gerhard Postpischil 
wrote:

:>On 7/31/2011 12:35 PM, CM Poncelet wrote:
:>> The program's DCB attributes take priority over (i.e.
:>> 'override') the DCB attributes on DASD for OUTPUT, and the DCB
:>> attributes on DASD take priority over (i.e. 'override') the
:>> program's DCB for INPUT. If a program 'disagrees' with that and
:>> tries to override the DCB attributes on DASD anyway, with its
:>> own DCB attributes and for an INPUT, it crashes with an I/O
:>> error. Crashing with an I/O error indicates that the program's
:>> DCB was unable - not able - to override the DCB attributes on DASD.

:>What we have here is a failure to communicate. Your statement 
:>above makes it evident that you are using "DCB attributes on 
:>DASD" as applying to the format of the data, whereas the other 
:>participants in this merry-go-round are referring to the DCB 
:>parameters in the format 1 DSCB (DS1RECFM, DS1LRECL, DS1BLKL).


Yes, that was what I was trying to point out to him.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

Shmuel Metz (Seymour J.) wrote:


In <4e349468.4060...@bcs.org.uk>, on 07/31/2011
  at 12:31 AM, CM Poncelet  said:

 


I'm afraid I disagree.
   



Because you are confusing the DSCB with the blocks written in the
dataset.


We are arguing semantics ...



 

What it proves is not that the DCB on DASD was 
overwritten by the one in the JCL, but that the DCB in the JCL was 
incorrect/incompatible with the one on DASD.
   



Why would you get an I/O error if the DCB information on the DD
statement did not take precedence over that in the DSCB?

Why would a square peg not fit in a round hole if the round hole did not 
take precedence over the square peg?




 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Rick Fochtman]

-- 




The program's DCB attributes take priority over (i.e.
'override') the DCB attributes on DASD for OUTPUT, and the DCB
attributes on DASD take priority over (i.e. 'override') the
program's DCB for INPUT. If a program 'disagrees' with that and
tries to override the DCB attributes on DASD anyway, with its
own DCB attributes and for an INPUT, it crashes with an I/O
error. Crashing with an I/O error indicates that the program's
DCB was unable - not able - to override the DCB attributes on DASD.



What we have here is a failure to communicate. Your statement above 
makes it evident that you are using "DCB attributes on DASD" as 
applying to the format of the data, whereas the other participants in 
this merry-go-round are referring to the DCB parameters in the format 
1 DSCB (DS1RECFM, DS1LRECL, DS1BLKL).


---
In several examples in this discussion, I've seen RECFM=VBA used to 
override RECFM=FBA. This leads me to believe, IMNSHO, that several 
contributors need to RTFM, especially with respect to the actual record 
contents and formats. Failure to grasp these differences can lead to 
endless frustration and gnashing of teeth.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Rick Fochtman]

-


I'm afraid I disagree.
   



Because you are confusing the DSCB with the blocks written in the
dataset.

 

What it proves is not that the DCB on DASD was 
overwritten by the one in the JCL, but that the DCB in the JCL was 
incorrect/incompatible with the one on DASD.
   



Why would you get an I/O error if the DCB information on the DD
statement did not take precedence over that in the DSCB?
 


--
I must agree with Shmuel here. Just because the Format-1 DSCB provides a 
set of attributes does NOT mean that the data was necessarily written 
with those attributes. Granted, the exceptions are not all that common, 
but they do occur, usually when somebody codes incorrect attributes on a 
output DD statement that modifies the content of the dataset.


In my last shop, coding DCB information on an output DD statement that 
wrote a member into an existing PDS was a severe no-no.


Sometimes it's acceptable to code overrides when adding a member to a 
PDS, but those instances are few and far between. They should be 
avoided, especially changes to the RECFM.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Rick Fochtman]

I'm afraid I disagree.   


Because you are confusing the DSCB with the blocks written in the
dataset.


We are arguing semantics ...


--
NOT HARDLY!



What it proves is not that the DCB on DASD was overwritten by the 
one in the JCL, but that the DCB in the JCL was 
incorrect/incompatible with the one on DASD.
  



Why would you get an I/O error if the DCB information on the DD
statement did not take precedence over that in the DSCB?

Why would a square peg not fit in a round hole if the round hole did 
not take precedence over the square peg?



If the attributes in the JCL are equally wrong, you'll still get that 
I/O error.


Read up on the handling and formats of FIXED vs. VARIABLE vs. UNDEFINED 
records. What you apperantly don't know CAN hurt you!


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

Shmuel Metz (Seymour J.) wrote:


In <4e34784d.2020...@bcs.org.uk>, on 07/30/2011
  at 10:31 PM, CM Poncelet  said:

 


What I am saying is that, on INPUT, a dataset's physical DCB
attributes  from its DSCB on DASD cannot be overriden by a JCL or
program DCB.
   



Yes, and what you are saying is wrong.

No, what I am saying is correct. What matters is not whether a program 
can open a DCB for input (trivial), but whether that DCB then actually 
works.




 


According to you, the DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) on
SYSUT1  (opened for input) should override the dataset's 
DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) on DASD.
   



Correct.

 


But that is not the case.
   



Yes it is.

No it isn't. What matters is whether the DCB opened for input *also* 
works when reading data from a dataset, when its attributes 
(RECFM=,LRECL=,BLKSIZE=) do not match those of the physical dataset on 
DASD.




 

If you set up and run the jobsteps above, both IEBGENER and IDCAMS 
report "IEB351I I/O ERROR  SYSUT1, READ, WRNG.LEN.RECORD,

etc."  when reading SYSUT1.
   



Proving that the DCB information in the DD statement *did* override
the DSCB.


in theory, but not in practice.



 

This is because the dataset's DASD DSCB/DCB 
attributes override those coded in the JCL (and would also override

the  programs's DCB, if hard-coded), for INPUT.
   



No; if they overrode the DCB then you wouldn't get the I/O error.


semantics ...



 


To say that the order of priority for INPUT is 'program DCB -> JCL
DCB  -> DASD DCB' is meaningless if neither the program DCB nor JCL
DCB can  modify/override the DASD's DSCB/DCB to avoid physical I/O
errors on INPUT.
   



To say that your name is Poncelet is meaningless if the Sun is an
apple.


argumentum ad hominem?



 


I don't think I 'got it wrong' ...
   



Then RTFM.


I don't need to.



 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

Rick Fochtman wrote:

 



I'm afraid I disagree.   



Because you are confusing the DSCB with the blocks written in the
dataset.


We are arguing semantics ...



-- 


NOT HARDLY!

 



What it proves is not that the DCB on DASD was overwritten by the 
one in the JCL, but that the DCB in the JCL was 
incorrect/incompatible with the one on DASD.
  




Why would you get an I/O error if the DCB information on the DD
statement did not take precedence over that in the DSCB?

Why would a square peg not fit in a round hole if the round hole did 
not take precedence over the square peg?



 

If the attributes in the JCL are equally wrong, you'll still get that 
I/O error. 


... because the DCB on DASD takes precedence over any coded in the JCL 
or in the program, in that order. The DCB attributes on DASD have the 
'final say' in whether an input I/O will complete successfully. That a 
program can populate its own DCB from the JCL's DCB attributes, and then 
open it for input *before* having to deal with the real DCB on DASD, is 
irrelevant if the JCL DCB's attibutes are inconsistent with those of the 
physical dataset on DASD. It is the physical dataset's DCB attributes on 
DASD, and not those of the DCB opened by the program, which determine 
whether the I/O is successful. If those of the program's opened DCB do 
not match those of the physical dataset on DASD, the I/O fails - because 
the DCB on DASD 'overrides' (or 'takes precedence over' etc.) the DCB in 
the program when it is opened for input and the program then issues a read.


Much of this 'discussion' has been akin to arguing that a bridge made of 
string and bamboo was correctly designed because, when a car tried to 
cross over it, the bridge broke and the car fell into the ravine ... and 
the car could not possibly have fallen into the ravine if the bridge had 
not been hanging across it in the first place - "QED".





Read up on the handling and formats of FIXED vs. VARIABLE vs. 
UNDEFINED records. What you apperantly don't know CAN hurt you! 


I don't need to be distracted by reading other people's opinions when I 
can think for myself. What I don't know can indeed hurt me - but what I 
know can't.


Cheers, Chris




Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Clement Clarke]

The DCB coded in the program over-rides everything.

If a data set has VB 133, 1330 and the program has FB 80,800 and opens 
it for either input or output, the DSCB will be changed to that coded in 
the program.


It's always been that way. (Except the Fujitsu equivalent MSP Operating 
system put out warnings, or optionally wouldn't let you change certain 
attributes.)


Cheers,

Clem



CM Poncelet wrote:

Rick Fochtman wrote:

 



I'm afraid I disagree. 



Because you are confusing the DSCB with the blocks written in the
dataset.


We are arguing semantics ...



-- 


NOT HARDLY!

 



What it proves is not that the DCB on DASD was overwritten by the 
one in the JCL, but that the DCB in the JCL was 
incorrect/incompatible with the one on DASD.




Why would you get an I/O error if the DCB information on the DD
statement did not take precedence over that in the DSCB?

Why would a square peg not fit in a round hole if the round hole did 
not take precedence over the square peg?



 

If the attributes in the JCL are equally wrong, you'll still get that 
I/O error. 


... because the DCB on DASD takes precedence over any coded in the JCL 
or in the program, in that order. The DCB attributes on DASD have the 
'final say' in whether an input I/O will complete successfully. That a 
program can populate its own DCB from the JCL's DCB attributes, and 
then open it for input *before* having to deal with the real DCB on 
DASD, is irrelevant if the JCL DCB's attibutes are inconsistent with 
those of the physical dataset on DASD. It is the physical dataset's 
DCB attributes on DASD, and not those of the DCB opened by the 
program, which determine whether the I/O is successful. If those of 
the program's opened DCB do not match those of the physical dataset on 
DASD, the I/O fails - because the DCB on DASD 'overrides' (or 'takes 
precedence over' etc.) the DCB in the program when it is opened for 
input and the program then issues a read.


Much of this 'discussion' has been akin to arguing that a bridge made 
of string and bamboo was correctly designed because, when a car tried 
to cross over it, the bridge broke and the car fell into the ravine 
... and the car could not possibly have fallen into the ravine if the 
bridge had not been hanging across it in the first place - "QED".





Read up on the handling and formats of FIXED vs. VARIABLE vs. 
UNDEFINED records. What you apperantly don't know CAN hurt you! 


I don't need to be distracted by reading other people's opinions when 
I can think for myself. What I don't know can indeed hurt me - but 
what I know can't.


Cheers, Chris




Rick



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Tom Marchant]

On Mon, 1 Aug 2011 13:50:09 +1000, Clement Clarke wrote:

>If a data set has VB 133, 1330 and the program has FB 80,800 and opens
>it for either input or output, the DSCB will be changed to that coded in
>the program.

Not quite.  If the data set is opened for input, the program will attempt to 
read 
the data set.  If a block > 800 bytes is read, there will be a wrong length 
record 
error.  Other errors might depend upon the access method used.  The DSCB 
will not be changed, though.

If the data set is opened for output, I don't know what happens if DISP=MOD. 
Is there an I/O error when the new data is written? If not there will surely be 
an 
error when the deat set is read with as either FB or VB.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Tom Marchant]

On Sat, 30 Jul 2011 04:27:44 -0700, Dale Miller wrote:

>In my previous note I said:
>> one can
>> TEMPORARILY override the dataset attributes with a DD card if the OPEN
>> is for INPUT
>Mr. Marchant said "NO", and referred to the JCL Reference Manual
>section "Completing the data control block".
>Please read again what I said.

I apologize.  I wrote too fast without understanding what you wrote. 
I even skipped over your statement in the previous post that "The 
stated priority is observed (which is why ... using a BLOCK 
CONTAINS clause with other than 0 on a COBOL input file is asking 
for problems)."  Of course you were saying that that the blocksize that 
was in the DCB is what is used.

Thanks to Shmuel for pointing out my error.

>Since I no longer have much access to manuals or the class materials I
>generated relating to the OPEN process, I cannot cite any references

They are readily available on the internet.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Tom Marchant]

On Sun, 31 Jul 2011 17:35:25 +0100, CM Poncelet wrote:

>Before the DCB on DASD can be accessed, the program's own 'completed'
>DCB (including any missing DCB parms filled-in from a RDJFCB of the
>JCL's DD and/or from an exit, if present) must be opened.

The DCB is completed during the open process

>This might
>suggest that the program's DCB, within the above context, overrides the
>one on DASD.

There is no DCB on DASD

>But the DASD DCB attributes override the program's DCB
>attributes when the data is actually read - in the sense that the data
>on DASD will be INPUT without I/O error only if the opened program DCB's
>attributes are the same as those on DASD.

That's an interesting and unusual definition of "override".  Now I see why you 
seem confused.  When we talk about DCB parameters being overridden, 
we are talking about how the fields in the DCB are filled in.  If, for example, 
the program has a blocksize specified in the DCB, the value in the DD 
statement or in the DSCB do not override that value.  It stays the way it was 
coded in the program.  That an I/O error might occur when reading the data set 
is not relevant to the way the DCB is filled in.

>It is not the program's DCB
>attributes (including any 'supplied' by exits etc.) but those on DASD
>which take priority and 'decide' what the DCB attributes should be on
>INPUT. If the program's DCB attributes could override those on DASD for
>INPUT, the program's 1st read after opening the DCB for INPUT would not
>fail with an I/O error if its DCB attributes were different from those
>on DASD

No.  When we say that the DCB attributes in the program override those 
in the DCB, we are not saying that those attributes in the DSCB are 
modified.  Indeed, if you have an existing data set with some RECFM, 
LRECL and BLKSIZE and you zap the DSCB to have different, 
incompatible values, when you try to open the you will get the same I/O 
errors as you would have if the DSCB was not altered but the program 
specified the incorrect DCB attributes.  In fact, if the program specifies 
the correct attributes, there will be no errors.

>On INPUT, the programs' DCB does not even change the RECFM, LRECL and
>BLKSIZE on DASD - never mind the physical data.

Of course not.  That is not what it means when we say that the DCB attributes 
in the program override those in the DSCB.  It means that the value in the DCB 
is the value specified in the program.  If the program does not specify an 
attribute 
that attribute comes from the JCL.  If it is not in the JCL either, it comes 
from the 
DSCB.

>On OUTPUT, the program's DCB does change the RECFM, LRECL and BLKSIZE as
>well as the physical data on DASD

The data on the DASD are overwritten if the disposition is OLD for a PS data 
set.  If 
the disposition is MOD or a member is written to a PO data set, the new data 
are 
written with the characteristics in the program.  I don't know whether this 
will cause 
an error in the case of a MOD PS data set, or whether the attributes are 
modified 
in the DSCB.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Tom Marchant]

On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet wrote:

>If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=), then the
>program's DCB attributes do *not* override those on DASD

Right.  No one said that they do.

>and, as the
>program's DCB attributes are inconsistent with those of the dataset on
>DASD, they cause I/O errors ... because the dataset's DCB attributes on
>DASD take priority over those of the program's DCB.

No.  Because the attributes specified in the completed DCB are inconsistent 
with the DATA on disk or tape.

Consider an unlabeled tape.  A data set that was written previously to tape 
is read by a program that specifies DCB attributes.  If it specifies incorrect 
attributes, the program may get I/O errors.  This is not because the DCB 
attributes on the tape override those coded in the DCB because there are 
no DCB attributes on an unlabeled tape.

>But if opened for INPUT, the priority order is "DASD DCB -> JCL DCB ->
>program DCB". If the program's DCB attributes are then inconsistent with
>the ones on DASD, on INPUT, the program hits I/O errors

It might very well

>because the
>DCB attributes on DASD override those hard-coded in the program on INPUT

No, because the data on DASD are not consistent with the DCB parameters 
in the program.  This would happen even of the DCB attributes in the DSCB 
were zapped to be the same as those in the program.

>If the program's
>DCB attributes, for INPUT, are inconsistent with those of the physical
>dataset stored on DASD, they do not override those stored on DASD

The attributes in the DCB of an input data set are not written to the DSCB. 
That is correct.  But for filling in the DCB, if a particular attribute is 
specified 
in the program, that attribute from the DSCB is not used.

>If I am wrong, please prove it by submitting verifiable 'general
>purpose' examples of this (excluding 'reblocking' trivia). A 'verifiable
>example' is one in which all the program's DCB attributes are different
>from those of the dataset's physical DCB attributes on DASD - yet
>override the dataset's DCB attributes stored on DASD *both* when the
>dataset is opened and written for OUTPUT and also when it is opened and
>read for INPUT

No one has claimed that the DCB attributes from the program are written 
to the DSCB when the data set is opened for input.

>If you cannot prove it by a 'verifiable
>example', then you are arguing high-falluting semantics where the
>interpretation of "DCB override" depends entirely upon what *you* mean
>by that, and is not subject to what "DCB override" is actually
>understood to mean in practice.

I think that you are the one who is using a non-standard definition of
what it means for a DCB attribute to be overridden.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Shane Ginnane]

I must admit most of this thread has made its way into the bin without more
than a perfunctory glance.
Toms latest contribution does however display admirable patience in the face
of intransigence. Kudos to Tom.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Donald Likens]

I did not look at all the other responses so please forgive me if someone 
already gave you the answer. Most the time I have seen this error the 
lrecl/blocksize was reset by creating a member with a different lrecl. All you 
have to do is create a member with the right lrecl/blksize and all but the bad 
member will be right again. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

Tom Marchant wrote:


On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet wrote:

 


If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=), then the
program's DCB attributes do *not* override those on DASD
   



Right.  No one said that they do.

 


and, as the
program's DCB attributes are inconsistent with those of the dataset on
DASD, they cause I/O errors ... because the dataset's DCB attributes on
DASD take priority over those of the program's DCB.
   



No.  Because the attributes specified in the completed DCB are inconsistent 
with the DATA on disk or tape.


Consider an unlabeled tape.  A data set that was written previously to tape 
is read by a program that specifies DCB attributes.  If it specifies incorrect 
attributes, the program may get I/O errors.  This is not because the DCB 
attributes on the tape override those coded in the DCB because there are 
no DCB attributes on an unlabeled tape.


 


But if opened for INPUT, the priority order is "DASD DCB -> JCL DCB ->
program DCB". If the program's DCB attributes are then inconsistent with
the ones on DASD, on INPUT, the program hits I/O errors
   



It might very well

 


because the
DCB attributes on DASD override those hard-coded in the program on INPUT
   



No, because the data on DASD are not consistent with the DCB parameters 
in the program.  This would happen even of the DCB attributes in the DSCB 
were zapped to be the same as those in the program.


 


If the program's
DCB attributes, for INPUT, are inconsistent with those of the physical
dataset stored on DASD, they do not override those stored on DASD
   



The attributes in the DCB of an input data set are not written to the DSCB. 
That is correct.  But for filling in the DCB, if a particular attribute is specified 
in the program, that attribute from the DSCB is not used.


 


If I am wrong, please prove it by submitting verifiable 'general
purpose' examples of this (excluding 'reblocking' trivia). A 'verifiable
example' is one in which all the program's DCB attributes are different
   


from those of the dataset's physical DCB attributes on DASD - yet
 


override the dataset's DCB attributes stored on DASD *both* when the
dataset is opened and written for OUTPUT and also when it is opened and
read for INPUT
   



No one has claimed that the DCB attributes from the program are written 
to the DSCB when the data set is opened for input.


 


If you cannot prove it by a 'verifiable
example', then you are arguing high-falluting semantics where the
interpretation of "DCB override" depends entirely upon what *you* mean
by that, and is not subject to what "DCB override" is actually
understood to mean in practice.
   



I think that you are the one who is using a non-standard definition of
what it means for a DCB attribute to be overridden.

Probably ... because my definition includes that the overriding DCB must 
then also be able to read successfully the dataset whose DCB attributes 
have been overridden - regardless of BDW, RDWs and data. Otherwise the 
'standard' definition of "DCB override" is purely academic and of no 
practical use. This 'standard' definition appears to mean that, 
regardless of its attributes being consistent or not with those of the 
dataset being read, the DCB which is opened first overrides the physical 
dataset's DCB attributes (and if the dataset cannot then be read, that 
is irrelevant). As I said earlier, 'DCB' includes 'DSCB' within the 
context of my argument: I refer to them all as DCBs for the sake of 
expediency.




 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Binyamin Dissen]

On Mon, 1 Aug 2011 16:19:26 +0100 CM Poncelet  wrote:

:>Probably ... because my definition includes that the overriding DCB must 
:>then also be able to read successfully the dataset whose DCB attributes 
:>have been overridden - regardless of BDW, RDWs and data. Otherwise the 
:>'standard' definition of "DCB override" is purely academic and of no 
:>practical use. This 'standard' definition appears to mean that, 
:>regardless of its attributes being consistent or not with those of the 
:>dataset being read, the DCB which is opened first overrides the physical 
:>dataset's DCB attributes (and if the dataset cannot then be read, that 
:>is irrelevant). As I said earlier, 'DCB' includes 'DSCB' within the 
:>context of my argument: I refer to them all as DCBs for the sake of 
:>expediency.

Then what you want is to write a subsystem which will map the specified DCB to
the physical file.

That if the DCB shows VB,255 and the data is FB,80 the subsystem will convert
the data for you. Not sure what you would expect if the DCB show FB,80 and the
actual data is FB,90 - return partial records?

But the basic point - you have your own private definition of these terms. It
is if you are speaking a different language.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Tom Marchant]

On Mon, 1 Aug 2011 00:45:05 -0500, Tom Marchant wrote:

>On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet wrote:
>
>>If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=), then the
>>program's DCB attributes do *not* override those on DASD
>
>Right.  No one said that they do.
>

I should have written,

I think you mean by that, that the DCB attributes on DASD (in the DSCB) do 
not get replaced by those in the DCB.  If that is what you mean, then you 
are correct.  No one said that they do.

If you mean that the DCB attributes that were specified by the program are 
not used when completing the DCB in preference to those in the DSCB, you 
are mistaken.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Dale R. Smith]

On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet  wrote:

>If I am wrong, please prove it by submitting verifiable 'general
>purpose' examples of this (excluding 'reblocking' trivia). A 'verifiable
>example' is one in which all the program's DCB attributes are different
>from those of the dataset's physical DCB attributes on DASD - yet
>override the dataset's DCB attributes stored on DASD *both* when the
>dataset is opened and written for OUTPUT and also when it is opened and
>read for INPUT (subject to the appropriate MACRF= etc. being specified
>on the DCB in each case). If you cannot prove it by a 'verifiable
>example', then you are arguing high-falluting semantics where the
>interpretation of "DCB override" depends entirely upon what *you* mean
>by that, and is not subject to what "DCB override" is actually
>understood to mean in practice.
>
>Thanks,
>
>Chris Poncelet

OK, explain how this JCL works.  I used JCL similar to the following for many 
years to copy VM/CMS files to MVS that were longer than 80 but a multiple of 80 
in length.  In this example, the records are 160 in length.  They are split 
into two 80 byte records, then "joined" into 160 byte records by overriding the 
LRECL of the disk file via JCL.

//COPYEXEC PGM=IEBGENER  
//SYSPRINT DD  SYSOUT=A  
//SYSINDD  DUMMY 
//SYSUT2   DD  DSN=&&TEMP,DISP=(,PASS,DELETE),   
// UNIT=SYSDA,SPACE=(1600,(10,10),RLSE), 
// RECFM=FB,LRECL=80,BLKSIZE=1600
//SYSUT1   DD  DATA,DLM='++' 
PART1
PART2
PART1
PART2
++   
//SORTEXEC PGM=SORT  
//SYSOUT   DD  SYSOUT=A  
//SORTIN   DD  DSN=&&TEMP,DISP=(OLD,DELETE), 
// RECFM=FB,LRECL=160,BLKSIZE=1600   
//SORTOUT  DD  DSN=MY.DATA.SET,DISP=(,CATLG,DELETE), 
// UNIT=SYSDA,SPACE=(1600,(10,10),RLSE), 
// RECFM=FB,LRECL=160,BLKSIZE=1600   
//SYSINDD  * 
  SORT FIELDS=COPY   
  END
/*   

The key for this to work is that the BLKSIZE has to be a multiple of 80 and 
160.  This will work for any records that are a multiple of 80, (160, 240, 
etc.).  I needed to put the VM/CMS file inline so it had to be a multiple of 80 
bytes to work.  This example clearly shows that the JCL LRECL overrides the 
file setting and no error occurs.   

-- 
Dale R. Smith

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

What I would expect, if the program's DCB attributes 'overrode'/'took 
precedence over'/etc. those of the physical dataset on DASD, is that the 
attributes in the dataset's DSCB on DASD would be overriden by the 
program DCB's attributes during the *read* (without changing the DSCB on 
DASD), and whatever garbage was then read in, as a consequence of the 
changed RECFM, LRECL and BLKSIZE in the program's DCB, would then be 
acceptable - provided the data (including the BDWs and RDWs, if 
necessary [all hypothetical, this]) was actually read in using the 
program's changed LRECL etc., ... instead of hitting I/O errors during 
the read (because the physical dataset's actual LRECL, not the changed 
one in the program's DCB, defines how its data on DASD should be read).


The 'raw' data could be retrieved from DASD via CCWs, irrespective of 
LRECL etc. (because data on DASD is I/O'd via CCW EXCPs anyway). So I 
would expect a program's changed DCB attributes to override those on 
DASD in the same way, as if processing 'raw' data. That would be *my* 
interpretation of the program's DCB attributes having successfully 
overridden those of the dataset on DASD when opened for input. But as 
this does not happen, the program's DCB attributes 'overriding' those on 
DASD is at best theoretical/academic. In practice, it is the attributes 
on DASD which take precedence over those specified in the program's DCB 
during input - and it is up to the program's DCB to comply with the 
'attributes-on-DASD-first' order of priority for input, or hit I/O 
errors. I do not consider a program's DCB having to *comply* with a 
dataset's attributes on DASD, in order to function correctly, as 
indicating that this program's DCB successfully *overrides* that 
dataset's attributes on DASD.


If the DCB had 'FB,80' and the actual data had 'FB,90' - then I would 
expect the first 80 bytes to be read in, then the next 81st to 160th 
bytes etc. until all the data had been read in using 'FB,80' (and with 
the last record in a block being appended with X'00's, if necessary, to 
complete the 80 bytes).



Binyamin Dissen wrote:


On Mon, 1 Aug 2011 16:19:26 +0100 CM Poncelet  wrote:

:>Probably ... because my definition includes that the overriding DCB must 
:>then also be able to read successfully the dataset whose DCB attributes 
:>have been overridden - regardless of BDW, RDWs and data. Otherwise the 
:>'standard' definition of "DCB override" is purely academic and of no 
:>practical use. This 'standard' definition appears to mean that, 
:>regardless of its attributes being consistent or not with those of the 
:>dataset being read, the DCB which is opened first overrides the physical 
:>dataset's DCB attributes (and if the dataset cannot then be read, that 
:>is irrelevant). As I said earlier, 'DCB' includes 'DSCB' within the 
:>context of my argument: I refer to them all as DCBs for the sake of 
:>expediency.


Then what you want is to write a subsystem which will map the specified DCB to
the physical file.

That if the DCB shows VB,255 and the data is FB,80 the subsystem will convert
the data for you. Not sure what you would expect if the DCB show FB,80 and the
actual data is FB,90 - return partial records?

But the basic point - you have your own private definition of these terms. It
is if you are speaking a different language.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

Quite possibly; but it's a contrived case where the 2nd LRECL is a fixed 
length multiple of the first (so there is one BDW and one RDW, and the 
records follow each other consecutively in the buffer).


By 'general purpose' example I meant one where the LRECLs, RECFMs and 
BLKSIZEs in the input source dataset are different, and independently 
so, from those in the program's DCB - i.e. where they can be completely 
random and yet still work. If the DCB is opened for output, the I/O will 
complete successfully if the dataset and program DCB attributes are 
chosen completely at random, without having to be multiples or divisors 
of each other (excluding BLKSIZE if FB etc.); but if the DCB is opened 
for input this is not the case, because the program's DCB attributes 
must now be compatible with those of the source dataset on DASD to avoid 
I/O errors. Hence, the assertion that DCB attribute override priority is 
'program -> JCL -> DASD' is true if the DCB is opened for output; but it 
is false (or at least 'it does not work', for the benefit of those who 
can stomach only a politically correct version of the truth) if it is 
opened for input, because it then hits I/O errors.


Dale R. Smith wrote:


On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet  wrote:

 


If I am wrong, please prove it by submitting verifiable 'general
purpose' examples of this (excluding 'reblocking' trivia). A 'verifiable
example' is one in which all the program's DCB attributes are different
   


from those of the dataset's physical DCB attributes on DASD - yet
 


override the dataset's DCB attributes stored on DASD *both* when the
dataset is opened and written for OUTPUT and also when it is opened and
read for INPUT (subject to the appropriate MACRF= etc. being specified
on the DCB in each case). If you cannot prove it by a 'verifiable
example', then you are arguing high-falluting semantics where the
interpretation of "DCB override" depends entirely upon what *you* mean
by that, and is not subject to what "DCB override" is actually
understood to mean in practice.

Thanks,

Chris Poncelet
   



OK, explain how this JCL works.  I used JCL similar to the following for many years to 
copy VM/CMS files to MVS that were longer than 80 but a multiple of 80 in length.  In 
this example, the records are 160 in length.  They are split into two 80 byte records, 
then "joined" into 160 byte records by overriding the LRECL of the disk file 
via JCL.

//COPYEXEC PGM=IEBGENER  
//SYSPRINT DD  SYSOUT=A  
//SYSINDD  DUMMY 
//SYSUT2   DD  DSN=&&TEMP,DISP=(,PASS,DELETE),   
// UNIT=SYSDA,SPACE=(1600,(10,10),RLSE), 
// RECFM=FB,LRECL=80,BLKSIZE=1600
//SYSUT1   DD  DATA,DLM='++' 
PART1
PART2
PART1
PART2
++   
//SORTEXEC PGM=SORT  
//SYSOUT   DD  SYSOUT=A  
//SORTIN   DD  DSN=&&TEMP,DISP=(OLD,DELETE), 
// RECFM=FB,LRECL=160,BLKSIZE=1600   
//SORTOUT  DD  DSN=MY.DATA.SET,DISP=(,CATLG,DELETE), 
// UNIT=SYSDA,SPACE=(1600,(10,10),RLSE), 
// RECFM=FB,LRECL=160,BLKSIZE=1600   
//SYSINDD  * 
 SORT FIELDS=COPY   
 END
/*   

The key for this to work is that the BLKSIZE has to be a multiple of 80 and 160.  This will work for any records that are a multiple of 80, (160, 240, etc.).  I needed to put the VM/CMS file inline so it had to be a multiple of 80 bytes to work.  This example clearly shows that the JCL LRECL overrides the file setting and no error occurs.   

 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Gerhard Postpischil]

On 8/1/2011 9:18 PM, CM Poncelet wrote:

If the DCB had 'FB,80' and the actual data had 'FB,90' - then I
would expect the first 80 bytes to be read in, then the next
81st to 160th bytes etc. until all the data had been read in
using 'FB,80' (and with the last record in a block being
appended with X'00's, if necessary, to complete the 80 bytes).


Your expectation runs afoul of reality. If the block is not a 
multiple of 80 (as well as 90), then the I/O fails (incorrect 
length), and your program would get a system 001 abend.


Your scenario can be produced using EXCP (or EXCPVR or STARTIO) 
or BSAM, provided the CCWs had the SLI bit on, and you had code 
to zero the buffer prior to the read, and your deblock code went 
past the block end.




Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Gerhard Postpischil]

On 8/1/2011 9:53 PM, CM Poncelet wrote:

Quite possibly; but it's a contrived case where the 2nd LRECL is
a fixed length multiple of the first (so there is one BDW and
one RDW, and the records follow each other consecutively in the
buffer).


His example used RECFM=FB, so there are no BDWs and no RDWs (if 
there were, then the first four bytes of the second record would 
be the RDW, not data).



to avoid I/O errors. Hence, the assertion that DCB attribute
override priority is 'program -> JCL -> DASD' is true if the DCB
is opened for output; but it is false (or at least 'it does not
work', for the benefit of those who can stomach only a
politically correct version of the truth) if it is opened for
input, because it then hits I/O errors.


DCB is short for Data Control Block. These exist only in memory, 
and are specific to the zOS operating systems (and earlier MVS 
and OS/360). I can read DASD written on MVS on VSE, and vice 
versa. VSE has no DCBs, but it manages to read data anyway.


On DASD, each block of data is preceded by a count field 
containing a logical (alternate track) or physical address 
(CCHHR), a key length, and a data length. There is no RECFM, no 
LRECL, and the physical block may have a length other than that 
specified by BLKSIZE. Regardless of how often you repeat 
yourself, there is no DCB on DASD.


Furthermore, your discussion of I/O seems to indicate that 
either you do not understand English, or that you are unaware of 
the differences between BSAM and QSAM. I would suggest that you 
read up on system control blocks, notable the IOB and ICB, look 
at some in a dump, and get a better understanding of how I/O 
functions. Requisite manuals are available online. While "Using 
Data Sets" is a bit daunting, it contains most of the information.



Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Corrupt PDS - I/O ERROR

[Dale Miller]

Mr. Poncelet said "We are arguing semantics". Yes, computer language  
statements have syntax requirements and properly-written statements  
have semantics associated with them. The language in the JCL Reference  
Manual specifically refers to the relative priority of information  
provided in the program DCB vs the DD/JFCB vs the DSCB, as is attested  
by the section title in the manual. The actual semantics of the OPEN  
statement are more complex.
Mr. Poncelet argues that his meaning of "override" is the correct one.  
I would go with the meaning of "override" in the documentation, and as  
I used it. If my manager sends me an message telling me to do  
something, I may (with risks) override his wishes by doing something  
different, but that does not mean that I rewrote his message. The  
actual semantics of OPEN are that the "DCB" attributes in the DSCB are  
NOT rewritten on an OPEN for input.
Mr. Poncelet demanded a verifiable example. I provided one. Read a  
member of a PDS with IDCAMS PRINT with a DD specifying  
"RECFM=U,BLKSIZE=32760" This works, and does NOT update the DSCB.


Dale Miller

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Corrupt PDS - I/O ERROR

[CM Poncelet]

I'll look into it when I have the time.

Dale Miller wrote:

Mr. Poncelet said "We are arguing semantics". Yes, computer language  
statements have syntax requirements and properly-written statements  
have semantics associated with them. The language in the JCL 
Reference  Manual specifically refers to the relative priority of 
information  provided in the program DCB vs the DD/JFCB vs the DSCB, 
as is attested  by the section title in the manual. The actual 
semantics of the OPEN  statement are more complex.
Mr. Poncelet argues that his meaning of "override" is the correct 
one.  I would go with the meaning of "override" in the documentation, 
and as  I used it. If my manager sends me an message telling me to do  
something, I may (with risks) override his wishes by doing something  
different, but that does not mean that I rewrote his message. The  
actual semantics of OPEN are that the "DCB" attributes in the DSCB 
are  NOT rewritten on an OPEN for input.
Mr. Poncelet demanded a verifiable example. I provided one. Read a  
member of a PDS with IDCAMS PRINT with a DD specifying  
"RECFM=U,BLKSIZE=32760" This works, and does NOT update the DSCB.


Dale Miller

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

Gerhard Postpischil wrote:


On 8/1/2011 9:53 PM, CM Poncelet wrote:


Quite possibly; but it's a contrived case where the 2nd LRECL is
a fixed length multiple of the first (so there is one BDW and
one RDW, and the records follow each other consecutively in the
buffer).



His example used RECFM=FB, so there are no BDWs and no RDWs (if there 
were, then the first four bytes of the second record would be the RDW, 
not data). 


Yes ... and I am writing from memory, probably confusing 
controlintervals (which always have a CIDF and at least one RDF) with 
blocks. I would have to dump a non-VSAM dataset to verify this. But in 
any case the BDW and RDW would not be loaded into the buffer. So, if 
SORT is doing GLs to read the records from the buffer, it will have no 
problem reading 2*80 instead of 80 bytes at a time - because the BLKSIZE 
is a multiple of 160, the buffer size is the same as the BLKSIZE and the 
records are fixed length.






to avoid I/O errors. Hence, the assertion that DCB attribute
override priority is 'program -> JCL -> DASD' is true if the DCB
is opened for output; but it is false (or at least 'it does not
work', for the benefit of those who can stomach only a
politically correct version of the truth) if it is opened for
input, because it then hits I/O errors.



DCB is short for Data Control Block. These exist only in memory, and 
are specific to the zOS operating systems (and earlier MVS and 
OS/360). I can read DASD written on MVS on VSE, and vice versa. VSE 
has no DCBs, but it manages to read data anyway. 


... and DSCB is short for Data Set Control Block, SIOT is short for Step 
I/O Table, JFCB is short for Job File Control Block, etc. - but thanks 
for reminding me.





On DASD, each block of data is preceded by a count field containing a 
logical (alternate track) or physical address (CCHHR), a key length, 
and a data length. There is no RECFM, no LRECL, and the physical block 
may have a length other than that specified by BLKSIZE. Regardless of 
how often you repeat yourself, there is no DCB on DASD.


Furthermore, your discussion of I/O seems to indicate that either you 
do not understand English, or that you are unaware of the differences 
between BSAM and QSAM. I would suggest that you read up on system 
control blocks, notable the IOB and ICB, look at some in a dump, and 
get a better understanding of how I/O functions. Requisite manuals are 
available online. While "Using Data Sets" is a bit daunting, it 
contains most of the information. 


I have no time for that. If something is true it can remember itself; if 
it is false it is not worth remembering. Hence I remember what I am 
dealing with and forget it afterwards. Do you expect me to *remember* 
system control blocks? When I *need* to remember them, I dump them and 
look at them - or I look at the "Data Areas" manuals or at the DSECTs - 
and then I forget about them again, unless I am still using them that 
is. I have been reading system dumps for more than 25 years, but don't 
expect me to *remember* them afterwards. This topic is about the order 
of priority of DCB attributes when opening a dataset for input v. 
output, and not about system control blocks. If it were about the 
latter, I would check and re-remember them beforehand: but as it isn't, 
I don't bother (I have other things to get on with).


'DCB' is shorter than the 'RECFM=,LRECL=,BLKSIZE=' I am actually 
referring to when I say 'DCB'; so I say 'DCB' for short.






Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Gibney, Dave]

   I really wish you folks would get your semantics clear. The original problem 
and solution proves the facts without need for further discussion.

1. Take a perfectly good, LRECL=80 PDS. Maybe to be really clear, find a PDS 
with LERECL > 133.
2. trash it by pointing any SYSOUT DD to a "NEW" member.
The original problem is now there and:

3. confirm that the DSCB in the VTOC for the PDS now claims LRECL=133 (or maybe 
121).
4. Fail to browse using ISPF or read any older member using IEBGENER
5. Run IEBGENER specifying (overriding) 
LRECL=correctlrecl,BLKSIZE=correct(old)blksize) on the input DD and it works.
6. Run  IEBGENER to a new member or even the "bad"  member specifying 
(overriding) LRECL=80 (old lrecl)

7. PDS is now fixed.

Dave Gibney
Information Technology Services
Washington State University

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Gerhard Postpischil]

On 8/2/2011 3:11 PM, CM Poncelet wrote:

this. But in any case the BDW and RDW would not be loaded into
the buffer.


The BDW and RDW are always included in the buffer. They may not 
be seen at the application level (e.g., on a ForTran read or 
write, or in CoBOL).



I have no time for that. If something is true it can remember
itself; if it is false it is not worth remembering. Hence I
remember what I am dealing with and forget it afterwards. Do you
expect me to *remember* system control blocks?


But as is obvious from this thread, you are making assertions 
based on (mis)information where you should have refreshed your 
memory. I still don't know what you meant by "CCW EXCPs", for 
example.



'DCB' is shorter than the 'RECFM=,LRECL=,BLKSIZE=' I am actually
referring to when I say 'DCB'; so I say 'DCB' for short.


'Data format' is also shorter than those, and a lot less ambiguous.

Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Rick Fochtman]

---
What I would expect, if the program's DCB attributes 'overrode'/'took 
precedence over'/etc. those of the physical dataset on DASD, is that the 
attributes in the dataset's DSCB on DASD would be overriden by the 
program DCB's attributes during the *read* (without changing the DSCB on 
DASD), and whatever garbage was then read in, as a consequence of the 
changed RECFM, LRECL and BLKSIZE in the program's DCB, would then be 
acceptable - provided the data (including the BDWs and RDWs, if 
necessary [all hypothetical, this]) was actually read in using the 
program's changed LRECL etc., ... instead of hitting I/O errors during 
the read (because the physical dataset's actual LRECL, not the changed 
one in the program's DCB, defines how its data on DASD should be read).

---
The "Incorrect Length" error is usually generated by a CCW that 
specifies a length smaller than the actual length of the block on the 
DASD device. The CCW length, in turn, is set by the BLKSIZE value 
supplied that is ultimately applied to the dataset, whether the value 
comes from a program-coded value, a JCL value or the value specified in 
the FORMAT-1 DSCB of the dataset. How the LRECL is used depends on the 
RECFM value and the access method in use. For example, BSAM does NO 
deblocking or blocking, expecting the program to take care of these 
types of details. On the other hand, QSAM does all the blocking and 
deblocking "under the covers", returning a logical record instead of a 
complete block.


--
The 'raw' data could be retrieved from DASD via CCWs, irrespective of 
LRECL etc. (because data on DASD is I/O'd via CCW EXCPs anyway). So I 
would expect a program's changed DCB attributes to override those on 
DASD in the same way, as if processing 'raw' data. That would be *my* 
interpretation of the program's DCB attributes having successfully 
overridden those of the dataset on DASD when opened for input. But as 
this does not happen, the program's DCB attributes 'overriding' those on 
DASD is at best theoretical/academic. In practice, it is the attributes 
on DASD which take precedence over those specified in the program's DCB 
during input - and it is up to the program's DCB to comply with the 
'attributes-on-DASD-first' order of priority for input, or hit I/O 
errors. I do not consider a program's DCB having to *comply* with a 
dataset's attributes on DASD, in order to function correctly, as 
indicating that this program's DCB successfully *overrides* that 
dataset's attributes on DASD.

---
NO NO NO. The attributes in the FORMAT-1 DSCB can be over-ridden by JCL 
OR DCB attributes in the program. They can also be altered to invalid 
values by injudicious use of DCB attributes in a program or JCL when 
adding/replacing a PDS member. Would you define a card reader with a 
logical record length of 50 bytes, expecting that the next logical 
record would be the last 30 bytes of the current image and 20 bytes of 
the next image? On a card reader, the blksize is 80 bytes and record 
format is either F or FB. Period. On DASD, the blocksize is that which 
is written in the count field of the actual block, as written on the 
disk. As far as the channel program is concerned, the only significant 
length field is the one written in the block's count field.


Padding records with x'00' values when a block is "short", can lead to 
all kinds of errors. Which values are valid for the program and which 
ones are trash and should be ignored?


We won't even get into keyed records, which are still prominent in DASD 
data management.


When half a dozen people, all with 30+ years of detailed experience, 
tell you you're wrong, I strongly suggest you start cracking open some 
manuals.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Rick Fochtman]

---
Quite possibly; but it's a contrived case where the 2nd LRECL is a fixed 
length multiple of the first (so there is one BDW and one RDW, and the 
records follow each other consecutively in the buffer).

--
Wrong. There are no BDW's or RDW's in RECFM=F. Or in FB. The access 
method code (for QSAM) or program code (for BSAM) are responsible for 
breaking a block into logical records. This is why, with this format, 
the BLKSIZE MUST be an integral multiple of the LRECL value. Similarly, 
there are no BDW's or RDW's for RECFM=U and the blocks may be any random 
length, up to and including the BLKSIZE defined for the dataset.



By 'general purpose' example I meant one where the LRECLs, RECFMs and 
BLKSIZEs in the input source dataset are different, and independently 
so, from those in the program's DCB - i.e. where they can be completely 
random and yet still work. If the DCB is opened for output, the I/O will 
complete successfully if the dataset and program DCB attributes are 
chosen completely at random, without having to be multiples or divisors 
of each other (excluding BLKSIZE if FB etc.); but if the DCB is opened 
for input this is not the case, because the program's DCB attributes 
must now be compatible with those of the source dataset on DASD to avoid 
I/O errors. Hence, the assertion that DCB attribute override priority is 
'program -> JCL -> DASD' is true if the DCB is opened for output; but it 
is false (or at least 'it does not work', for the benefit of those who 
can stomach only a politically correct version of the truth) if it is 
opened for input, because it then hits I/O errors.

---
If you have DCB values coded in the program, they will rule and you have 
no right to expect them to work every time. Different formats of records 
have their uses, assets and drawbacks. If you code the program to accept 
anything, you'll have a serious amount of code dedicated to handling the 
different types of RECFM and you'd better NOT have any values coded in 
the DCB in the program. You can always interrogate those values after 
the dataset has been successfuly OPEN'ed.


You don't have to like it; just live with it. Cuz' them's the conditions 
that prevail.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Joel C. Ewing]

To quote Mark Twain: "It ain’t what you don’t know that gets you into 
trouble.   It’s what you know for sure that just ain’t so."


After dealing with computers for 40+ years, I can tell you that some of 
the most important concepts are (1)to know when you don't know the right 
answer, (2)know where to find the right answers, and (3)have enough 
curiosity to look up the right answer, especially if multiple people 
tell you that of which you are certain is wrong.  You seemed to have 
unfortunately managed to remember some false things that in your words 
were "not worth remembering".


No one expects one to remember all the fields in all the system control 
blocks, much less values from specific dumps, but you do have to 
remember enough of the basics in order to make sense out of what the 
manuals tell you.  The arguments in this thread over the last several 
weeks have basically boiled down to a failure to make a proper 
distinction between DCB attribute values stored in a program DCB versus 
similar values maintained in a DSCB in a DASD VTOC, and the related 
refusal to understand that when talking about overrides to DCB 
parameters that this is an explicit reference to 
overriding/changing/altering field values in a DCB control block and has 
nothing to do with altering data content of existing datasets or 
existing DSCB values in the VTOC.


One should also remember enough of the basics to understand that it is 
the merged DCB values in the in-memory DCB that control how the access 
methods manipulate data associated with physical data blocks, not the 
DASD DSCB, which only contributes during the OPEN processing. 
Understanding that the physical DASD representation of VB sequential 
files contains embedded record/block control information and variable 
block sizes, versus FB files with no control information but physical 
block sizes constrained by both LRECL and BLKSIZE is also pretty basic 
stuff - and if you understand that, you would never expect any merge of 
DCB parameters that attempted to read existing physical data with the 
wrong V versus F RECFM protocol to do anything useful.  That the attempt 
fails doesn't mean the DCB merge didn't work as documented, it means you 
have managed to construct a dataset, JCL, program combination that 
violates the semantic rules of MVS.  It doesn't take much experience 
with MVS macros or JCL parameters to learn that syntactic correctness 
doesn't prevent semantic nonsense.


To almost take pride in not having the time to consult appropriate 
references, and yet at the same time be adamant that you are right and 
others wrong when they have, is not exactly a way to win admiration 
among this group.  Working with computers is not like belonging to the 
Tea Party.  When it comes down to what works, only facts matter, 
opinions don't.

   Joel C. Ewing

On 08/02/2011 02:11 PM, CM Poncelet wrote:

Gerhard Postpischil wrote:


On 8/1/2011 9:53 PM, CM Poncelet wrote:


Quite possibly; but it's a contrived case where the 2nd LRECL is
a fixed length multiple of the first (so there is one BDW and
one RDW, and the records follow each other consecutively in the
buffer).



His example used RECFM=FB, so there are no BDWs and no RDWs (if there
were, then the first four bytes of the second record would be the RDW,
not data).


Yes ... and I am writing from memory, probably confusing
controlintervals (which always have a CIDF and at least one RDF) with
blocks. I would have to dump a non-VSAM dataset to verify this. But in
any case the BDW and RDW would not be loaded into the buffer. So, if
SORT is doing GLs to read the records from the buffer, it will have no
problem reading 2*80 instead of 80 bytes at a time - because the BLKSIZE
is a multiple of 160, the buffer size is the same as the BLKSIZE and the
records are fixed length.





to avoid I/O errors. Hence, the assertion that DCB attribute
override priority is 'program -> JCL -> DASD' is true if the DCB
is opened for output; but it is false (or at least 'it does not
work', for the benefit of those who can stomach only a
politically correct version of the truth) if it is opened for
input, because it then hits I/O errors.



DCB is short for Data Control Block. These exist only in memory, and
are specific to the zOS operating systems (and earlier MVS and
OS/360). I can read DASD written on MVS on VSE, and vice versa. VSE
has no DCBs, but it manages to read data anyway.


... and DSCB is short for Data Set Control Block, SIOT is short for Step
I/O Table, JFCB is short for Job File Control Block, etc. - but thanks
for reminding me.




On DASD, each block of data is preceded by a count field containing a
logical (alternate track) or physical address (CCHHR), a key length,
and a data length. There is no RECFM, no LRECL, and the physical block
may have a length other than that specified by BLKSIZE. Regardless of
how often you repeat yourself, there is no DCB on DASD.

Furthermore, your discussion of I/O seems to indicate tha

Re: CORRUPT PDS - I/O ERROR

[Shmuel Metz (Seymour J.)]

In <4e35f6d3.9090...@bcs.org.uk>, on 08/01/2011
   at 01:44 AM, CM Poncelet  said:

>The 'acid test' is whether the same program DCB (ignoring the MACRF=
>and  EODAD=) can be used *both* for OUTPUT and for INPUT (with a
>change in MACFR= and adding EODAD= when opening for INPUT), when the
>dataset's  physical DCB attributes on DASD are *different* from those
>specified in the program.

No. The acid test is whether the system behaves in accordance with the
published documentation. It does.

>when the dataset's physical DCB attributes on DASD

There is no such thing.

>If this DCB is opened for OUTPUT (MACRF=PM|L), then the program's
>DCB  attributes override those on DASD - and the program's DCB
>attributes  then also become those stored on DASD, all without
>causing I/O errors. 

No. An incorrect BLKSIZE on output could also cause an I/O error, back
when there where DASD with tracks smaller than 32 KiB.

>If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=), then
>the program's DCB attributes do *not* override those on DASD

Were that true then there wouldn't be an I/O error.

>and, as the program's DCB attributes are inconsistent

They wouldn't be inconsistent if they didn't override.



>high-falluting semantics

Like the NCO's in Basic Training who argued "high-falluting semantics"
for no better reason than a prejudice against our killing each other
with "unloaded" rifles. The word "semantics" doesn't mean what you
believe it means.


In <4e35f8cb.7090...@bcs.org.uk>, on 08/01/2011
   at 01:52 AM, CM Poncelet  said:

>We are arguing semantics ...

Indeed, but "semantics" doesn't mean what you believe. Essentially all
arguments are about semantics.


In <4e360d24.4010...@bcs.org.uk>, on 08/01/2011
   at 03:19 AM, CM Poncelet  said:

>No, what I am saying is correct.

ROTF,LMAO!

>What matters is not whether a program can open a DCB for input 
>(trivial), but whether that DCB then actually works.

No, what matters is whether the results are in accordance with the
published documentation or in accordance with your beliefs.

>argumentum ad hominem?

No. Ridicule of a an inference with false premises.


In <4e3618ba.8050...@bcs.org.uk>, on 08/01/2011
   at 04:08 AM, CM Poncelet  said:

>when I can think for myself.

Obviously not. Otherwise you wouldn't keep insisting that you don't
need to read the manuals. 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Shmuel Metz (Seymour J.)]

In <4e36c3fe.30...@bcs.org.uk>, on 08/01/2011
   at 04:19 PM, CM Poncelet  said:

>Probably ... because my definition 

Your definition is irrelevant. The documentation of how OPEN behaves
uses IBM's definitions.

>Otherwise the 'standard' definition of "DCB override" is purely 
>academic and of no practical use. 

The fact that you don't understand it doesn't make it useless.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Shmuel Metz (Seymour J.)]

In <4e356a03.4060...@bcs.org.uk>, on 07/31/2011
   at 03:43 PM, CM Poncelet  said:

>they 'count' as program DCBs is short-speak for 'they are executable 
>code' (as opposed to JCL and DASD)

A DCB is not executable code; it is a data area.

>I know that; but on input they do not override the DCB from DASD

Changes made by the DCB exit do override; nobody claimed that the DSCV
or JFCV override the DCB. That's the same processing as for output.

>'short-speak' for they 'they are part of program code execution' in
>the  'program -> JCL -> DASD' sequence

"Part of" is not the same as "first", and there is no "'program -> JCL
-> DASD' sequence".

>I am speaking within the context of the priority order of DCBs in
>the  'program -> JCL -> DASD' sequence

Incorrectly.

>I don't need to check "Using Data Sets"

Then why do you keep getting it wrong.

>Galileo did not need to check "the Bible"

You are not Galileo

>was that his first mistake?

No; perhaps his first mistake was claiming that comets were
atmospheric phenomena.

>in that case it was one of OS/VS1 to MVS/SP

No.

>(I don't spend time remembering these things, except vaguely)

Obviously.

>I think you are splitting hairs for the sake of arguing ...

No, just trying to explain things to the willfully ignorant.


In <4e35844d.8030...@bcs.org.uk>, on 07/31/2011
   at 05:35 PM, CM Poncelet  said:

>Before the DCB on DASD can be accessed,

I hope that you mean "data set attributes in the DSCB1".

>the program's own 'completed' DCB (including any missing DCB 
>parms filled-in from a RDJFCB of the JCL's DD and/or from an exit, 
>if present) must be opened.

Here's one place where you're going wrong. A JFCB entry in the DCB
exit list is distinct from a DCB exit entry, and points to a data area
rather than to an exit. The DCB exit specified in the DCB exit list is
not called at the beginning of the merge, but after the end of it.

>But the DASD DCB attributes

Here's another place where you are going wrong; you are confusing
dataset attributes with the physical records in the dataset.

>in the sense that the data on DASD will be INPUT without I/O 
>error only if the opened program DCB's attributes are the same as 
>those on DASD. 

No. As others have explained, BSAM/QSAM will read the data without I/O
error only if the physical records in the data set are small enough to
fit in the buffer, which is sized[1] as the resolved BLKSIZE. The
sizes of the physical records are not dataset attributes as the term
is used by OPEN et al.

>The program's DCB attributes take priority over (i.e. 'override')
>the  DCB attributes on DASD for OUTPUT, and the DCB attributes on
>DASD take  priority over (i.e. 'override') the program's DCB for
>INPUT.

Repeating it won't make it true.

>If a program 'disagrees' with that and tries to override the DCB
>attributes on DASD anyway, with its own DCB attributes and for an
>INPUT, it crashes  with an I/O error.

Only if it does so improperly.

>Crashing with an I/O error indicates that the program's DCB was 
>unable - not able - to override the DCB attributes
>on DASD.

No, as Binyamin has explained to you multiple times.

>On INPUT, the programs' DCB does not even change the RECFM, LRECL
>and BLKSIZE on DASD

Demonstrably false.

>- never mind the physical data.

Nobody claimed that it altered the physical data in the dataset.

[1] Discussion omits concatenation for simplicity.
 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

... but open for output, followed by write, works - whereas open for 
input, followed by read, doesn't (it fails with an "I/O ERR"): that is a 
fact, not an opinion.


So unless the "I/O ERR" is actually the desired outcome, it is an error. 
If it needs to be fixed, then either the program's merged DCB or the 
dataset on DASD is in error. If the dataset is thought to be in error, 
raise a PMR with IBM. Otherwise it is the program's merged DCB that is 
in error - which is what I am saying. As this defines the scope and 
boundaries of the topic - i.e. who prevails over what (which is what I 
mean by 'this overrides that'), during input and output - there is no 
need to examine all the entrails in-between.


I do not disagree with the details of the points you make about RECFMs 
etc., but they are not relevant to the topic under discussion (i.e. that 
'output' works and that 'input' doesn't, and why).



Joel C. Ewing wrote:

To quote Mark Twain: "It ain’t what you don’t know that gets you into 
trouble.   It’s what you know for sure that just ain’t so."


After dealing with computers for 40+ years, I can tell you that some 
of the most important concepts are (1)to know when you don't know the 
right answer, (2)know where to find the right answers, and (3)have 
enough curiosity to look up the right answer, especially if multiple 
people tell you that of which you are certain is wrong.  You seemed to 
have unfortunately managed to remember some false things that in your 
words were "not worth remembering".


No one expects one to remember all the fields in all the system 
control blocks, much less values from specific dumps, but you do have 
to remember enough of the basics in order to make sense out of what 
the manuals tell you.  The arguments in this thread over the last 
several weeks have basically boiled down to a failure to make a proper 
distinction between DCB attribute values stored in a program DCB 
versus similar values maintained in a DSCB in a DASD VTOC, and the 
related refusal to understand that when talking about overrides to DCB 
parameters that this is an explicit reference to 
overriding/changing/altering field values in a DCB control block and 
has nothing to do with altering data content of existing datasets or 
existing DSCB values in the VTOC.


One should also remember enough of the basics to understand that it is 
the merged DCB values in the in-memory DCB that control how the access 
methods manipulate data associated with physical data blocks, not the 
DASD DSCB, which only contributes during the OPEN processing. 
Understanding that the physical DASD representation of VB sequential 
files contains embedded record/block control information and variable 
block sizes, versus FB files with no control information but physical 
block sizes constrained by both LRECL and BLKSIZE is also pretty basic 
stuff - and if you understand that, you would never expect any merge 
of DCB parameters that attempted to read existing physical data with 
the wrong V versus F RECFM protocol to do anything useful.  That the 
attempt fails doesn't mean the DCB merge didn't work as documented, it 
means you have managed to construct a dataset, JCL, program 
combination that violates the semantic rules of MVS.  It doesn't take 
much experience with MVS macros or JCL parameters to learn that 
syntactic correctness doesn't prevent semantic nonsense.


To almost take pride in not having the time to consult appropriate 
references, and yet at the same time be adamant that you are right and 
others wrong when they have, is not exactly a way to win admiration 
among this group.  Working with computers is not like belonging to the 
Tea Party.  When it comes down to what works, only facts matter, 
opinions don't.

   Joel C. Ewing

On 08/02/2011 02:11 PM, CM Poncelet wrote:


Gerhard Postpischil wrote:


On 8/1/2011 9:53 PM, CM Poncelet wrote:


Quite possibly; but it's a contrived case where the 2nd LRECL is
a fixed length multiple of the first (so there is one BDW and
one RDW, and the records follow each other consecutively in the
buffer).




His example used RECFM=FB, so there are no BDWs and no RDWs (if there
were, then the first four bytes of the second record would be the RDW,
not data).



Yes ... and I am writing from memory, probably confusing
controlintervals (which always have a CIDF and at least one RDF) with
blocks. I would have to dump a non-VSAM dataset to verify this. But in
any case the BDW and RDW would not be loaded into the buffer. So, if
SORT is doing GLs to read the records from the buffer, it will have no
problem reading 2*80 instead of 80 bytes at a time - because the BLKSIZE
is a multiple of 160, the buffer size is the same as the BLKSIZE and the
records are fixed length.





to avoid I/O errors. Hence, the assertion that DCB attribute
override priority is 'program -> JCL -> DASD' is true if the DCB
is opened for output; but it is false (or at least 'it does not
work', for the benefit of those

Re: CORRUPT PDS - I/O ERROR

[Scott Rowe]

Open for output merges all the attributes and then REPLACES the DSCB values
with the result of the merge.

On Tue, Aug 2, 2011 at 8:15 PM, CM Poncelet  wrote:

> ... but open for output, followed by write, works - whereas open for input,
> followed by read, doesn't (it fails with an "I/O ERR"): that is a fact, not
> an opinion.
>
> So unless the "I/O ERR" is actually the desired outcome, it is an error. If
> it needs to be fixed, then either the program's merged DCB or the dataset on
> DASD is in error. If the dataset is thought to be in error, raise a PMR with
> IBM. Otherwise it is the program's merged DCB that is in error - which is
> what I am saying. As this defines the scope and boundaries of the topic -
> i.e. who prevails over what (which is what I mean by 'this overrides that'),
> during input and output - there is no need to examine all the entrails
> in-between.
>
> I do not disagree with the details of the points you make about RECFMs
> etc., but they are not relevant to the topic under discussion (i.e. that
> 'output' works and that 'input' doesn't, and why).
>
>
>
> Joel C. Ewing wrote:
>
>  To quote Mark Twain: "It ain’t what you don’t know that gets you into
>> trouble.   It’s what you know for sure that just ain’t so."
>>
>> After dealing with computers for 40+ years, I can tell you that some of
>> the most important concepts are (1)to know when you don't know the right
>> answer, (2)know where to find the right answers, and (3)have enough
>> curiosity to look up the right answer, especially if multiple people tell
>> you that of which you are certain is wrong.  You seemed to have
>> unfortunately managed to remember some false things that in your words were
>> "not worth remembering".
>>
>> No one expects one to remember all the fields in all the system control
>> blocks, much less values from specific dumps, but you do have to remember
>> enough of the basics in order to make sense out of what the manuals tell
>> you.  The arguments in this thread over the last several weeks have
>> basically boiled down to a failure to make a proper distinction between DCB
>> attribute values stored in a program DCB versus similar values maintained in
>> a DSCB in a DASD VTOC, and the related refusal to understand that when
>> talking about overrides to DCB parameters that this is an explicit reference
>> to overriding/changing/altering field values in a DCB control block and has
>> nothing to do with altering data content of existing datasets or existing
>> DSCB values in the VTOC.
>>
>> One should also remember enough of the basics to understand that it is the
>> merged DCB values in the in-memory DCB that control how the access methods
>> manipulate data associated with physical data blocks, not the DASD DSCB,
>> which only contributes during the OPEN processing. Understanding that the
>> physical DASD representation of VB sequential files contains embedded
>> record/block control information and variable block sizes, versus FB files
>> with no control information but physical block sizes constrained by both
>> LRECL and BLKSIZE is also pretty basic stuff - and if you understand that,
>> you would never expect any merge of DCB parameters that attempted to read
>> existing physical data with the wrong V versus F RECFM protocol to do
>> anything useful.  That the attempt fails doesn't mean the DCB merge didn't
>> work as documented, it means you have managed to construct a dataset, JCL,
>> program combination that violates the semantic rules of MVS.  It doesn't
>> take much experience with MVS macros or JCL parameters to learn that
>> syntactic correctness doesn't prevent semantic nonsense.
>>
>> To almost take pride in not having the time to consult appropriate
>> references, and yet at the same time be adamant that you are right and
>> others wrong when they have, is not exactly a way to win admiration among
>> this group.  Working with computers is not like belonging to the Tea Party.
>>  When it comes down to what works, only facts matter, opinions don't.
>>   Joel C. Ewing
>>
>> On 08/02/2011 02:11 PM, CM Poncelet wrote:
>>
>>  Gerhard Postpischil wrote:
>>>
>>>  On 8/1/2011 9:53 PM, CM Poncelet wrote:

  Quite possibly; but it's a contrived case where the 2nd LRECL is
> a fixed length multiple of the first (so there is one BDW and
> one RDW, and the records follow each other consecutively in the
> buffer).
>



 His example used RECFM=FB, so there are no BDWs and no RDWs (if there
 were, then the first four bytes of the second record would be the RDW,
 not data).

>>>
>>>
>>> Yes ... and I am writing from memory, probably confusing
>>> controlintervals (which always have a CIDF and at least one RDF) with
>>> blocks. I would have to dump a non-VSAM dataset to verify this. But in
>>> any case the BDW and RDW would not be loaded into the buffer. So, if
>>> SORT is doing GLs to read the records from the buffer, it will have no
>>> problem reading 2*

Re: CORRUPT PDS - I/O ERROR

[Tom Marchant]

On Tue, 2 Aug 2011 20:11:27 +0100, CM Poncelet  wrote:

>Gerhard Postpischil wrote:
>>
>> His example used RECFM=FB, so there are no BDWs and no RDWs (if there
>> were, then the first four bytes of the second record would be the RDW,
>> not data).
>
>Yes ... and I am writing from memory, 

Obviously, and your memory is in error.  It would help if you would check 
a reference manual rather than continuing to post incorrect information, 
even after having been corrected multiple times.

>But in
>any case the BDW and RDW would not be loaded into the buffer. 

Wrong again.  The BDW and RDW of a variable length data set are 
part of the data in the buffer.

>> Requisite manuals are
>> available online. While "Using Data Sets" is a bit daunting, it
>> contains most of the information.
>
>I have no time for that. 

Then why do you have time to post so much incorrect information?

>If something is true it can remember itself; 

Oh, really?

>Do you expect me to *remember*
>system control blocks?

Actually, no, I don't.  But I do expect you to check what you post.  We 
all occasionally post incorrectly from memory, some of us more often than 
others.  Most of us will at least look it up after someone points out that 
what we posted was wrong.  You, on the other hand, repeatedly post the 
same erroneous information and steadfastly refuse to look it up.  Because 
of that, I don't expect you to *know* what you are talking about.

> I have been reading system dumps for more than 25 years

Well, good for you.  I've been doing it for 40.  I think Gerhard has been 
doing it for considerably longer and I know that Shmuel has.


>This topic is about the order
>of priority of DCB attributes when opening a dataset for input v.
>output,

And your insistence that there is a difference in the priority of filling in 
the DCB between input and output is demonstrably wrong.  There is no 
difference.  The DCB is filled in exactly the same way.  If you don't believe 
me, take  dump after opening a data set for input and see what the 
values are.  Let me guess.  you don't have time for that either.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[CM Poncelet]

NO NO NO again. What I did was prove by 'reductio ad absurdum' that if 
the premiss/assertion "On input, the order of override priority is 
program DCB -> JCL DCB -> dataset attributes" is true then its 
consequences are absurd: therefore the premiss/assertion is false. 
Please note that, at the beginning, I did say "What I *would* expect 
..." and not "What I expect ..."


To finish this off. It is *not* valid to argue that 'this' overrides 
'that', if 'this' having overridden 'that' results in 'this' not working 
unless it happens to be equal to 'that' - where 'this' and 'that' can be 
any permissible values, with no imposed conditions or constraints.


Thanks, Chris Poncelet


Rick Fochtman wrote:

--- 

What I would expect, if the program's DCB attributes 'overrode'/'took 
precedence over'/etc. those of the physical dataset on DASD, is that 
the attributes in the dataset's DSCB on DASD would be overriden by the 
program DCB's attributes during the *read* (without changing the DSCB 
on DASD), and whatever garbage was then read in, as a consequence of 
the changed RECFM, LRECL and BLKSIZE in the program's DCB, would then 
be acceptable - provided the data (including the BDWs and RDWs, if 
necessary [all hypothetical, this]) was actually read in using the 
program's changed LRECL etc., ... instead of hitting I/O errors during 
the read (because the physical dataset's actual LRECL, not the changed 
one in the program's DCB, defines how its data on DASD should be read).
--- 

The "Incorrect Length" error is usually generated by a CCW that 
specifies a length smaller than the actual length of the block on the 
DASD device. The CCW length, in turn, is set by the BLKSIZE value 
supplied that is ultimately applied to the dataset, whether the value 
comes from a program-coded value, a JCL value or the value specified 
in the FORMAT-1 DSCB of the dataset. How the LRECL is used depends on 
the RECFM value and the access method in use. For example, BSAM does 
NO deblocking or blocking, expecting the program to take care of these 
types of details. On the other hand, QSAM does all the blocking and 
deblocking "under the covers", returning a logical record instead of a 
complete block.


-- 

The 'raw' data could be retrieved from DASD via CCWs, irrespective of 
LRECL etc. (because data on DASD is I/O'd via CCW EXCPs anyway). So I 
would expect a program's changed DCB attributes to override those on 
DASD in the same way, as if processing 'raw' data. That would be *my* 
interpretation of the program's DCB attributes having successfully 
overridden those of the dataset on DASD when opened for input. But as 
this does not happen, the program's DCB attributes 'overriding' those 
on DASD is at best theoretical/academic. In practice, it is the 
attributes on DASD which take precedence over those specified in the 
program's DCB during input - and it is up to the program's DCB to 
comply with the 'attributes-on-DASD-first' order of priority for 
input, or hit I/O errors. I do not consider a program's DCB having to 
*comply* with a dataset's attributes on DASD, in order to function 
correctly, as indicating that this program's DCB successfully 
*overrides* that dataset's attributes on DASD.
--- 

NO NO NO. The attributes in the FORMAT-1 DSCB can be over-ridden by 
JCL OR DCB attributes in the program. They can also be altered to 
invalid values by injudicious use of DCB attributes in a program or 
JCL when adding/replacing a PDS member. Would you define a card reader 
with a logical record length of 50 bytes, expecting that the next 
logical record would be the last 30 bytes of the current image and 20 
bytes of the next image? On a card reader, the blksize is 80 bytes and 
record format is either F or FB. Period. On DASD, the blocksize is 
that which is written in the count field of the actual block, as 
written on the disk. As far as the channel program is concerned, the 
only significant length field is the one written in the block's count 
field.


Padding records with x'00' values when a block is "short", can lead to 
all kinds of errors. Which values are valid for the program and which 
ones are trash and should be ignored?


We won't even get into keyed records, which are still prominent in 
DASD data management.


When half a dozen people, all with 30+ years of detailed experience, 
tell you you're wrong, I strongly suggest you start cracking open some 
manuals.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at 

Re: CORRUPT PDS - I/O ERROR

[Shmuel Metz (Seymour J.)]

In <4e386bfb.7030...@acm.org>, on 08/02/2011
   at 04:28 PM, "Joel C. Ewing"  said:

>To almost take pride in not having the time to consult appropriate 
>references, and yet at the same time be adamant that you are right
>and others wrong when they have,

Some of us[1] have read not only the manuals but also the code.

[1] I'd guess half a dozen; possibly much more but definitely not
much less.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Shmuel Metz (Seymour J.)]

In <4e37505a.7090...@bcs.org.uk>, on 08/02/2011
   at 02:18 AM, CM Poncelet  said:

>What I would expect, if the program's DCB attributes 'overrode'/'took
> precedence over'/etc. those of the physical dataset on DASD, is that
>the  attributes in the dataset's DSCB on DASD would be overriden by
>the  program DCB's attributes during the *read* (without changing the
>DSCB on DASD), and whatever garbage was then read in, as a
>consequence of the changed RECFM, LRECL and BLKSIZE in the program's
>DCB, would then be acceptable

That is an unreasonable expectation. It is the responsibility of the
user to determine whether an override is appropriate and to determine
whether an input dataset matches the requirements of the application.
If the data length on DASD exceeds the block size, why would you
expect anything other than an I/O error. If your specify RECFM=FB and
the data length is not a multiple of LRECL, why would you expect
anything but a logical error?

>The 'raw' data could be retrieved from DASD via CCWs, irrespective
>of  LRECL etc.

At which point it is the programmer's responsible to figure out how to
handle them.

>So I would expect a program's changed DCB attributes to override 
>those on DASD in the same way, as if processing 'raw' data. 

It does. What it doesn't do is to magically figure out that you didn't
really mean it when you provided the wrong attributes.

>That would be *my* interpretation of the program's DCB attributes 
>having successfully overridden those of the dataset on DASD when 
>opened for input.

Your interpretation is irrelevant; what matters is the documentation
that you refuse to consult.

>But as this does not happen, the program's DCB attributes 
>'overriding' those on DASD is at best theoretical/academic.

No, just unrelated to anything that IBM claims to do. Again, you are
confusing the dataset with the DSCB1 describing the dataset.


In <4e3758a4.8070...@bcs.org.uk>, on 08/02/2011
   at 02:53 AM, CM Poncelet  said:

>Quite possibly; but it's a contrived case 

The fact that you don't understand it doesn't make it contrived. The
fact is that what Binyamin describes is relatively common among those
that understand the software, and quite useful.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CORRUPT PDS - I/O ERROR

[Shmuel Metz (Seymour J.)]

In <4e38932c.2030...@bcs.org.uk>, on 08/03/2011
   at 01:15 AM, CM Poncelet  said:

>... but open for output, followed by write, works - whereas open for 
>input, followed by read, doesn't (it fails with an "I/O ERR"): that
>is a fact, not an opinion.

No, it is not a fact. It is a fact that you can cause an I/O error
with an incorrect BLKSIZE. It is false that you always get an I/O
error when you override dataset attributes on input.

>So unless the "I/O ERR" is actually the desired outcome, it is an
>error. 

A user error.

>If the dataset is thought to be in error, raise a PMR with IBM.

Don't create a PMR for a user error.

>Otherwise it is the program's merged DCB that is 
>in error - which is what I am saying. 

That isn't what you have been saying. You have been confusing open
with read and confusing the DSCB1 with the dataset itself.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html