On Wed, Apr 26, 2023 at 08:00:07AM -0500, Pierre Fichaud wrote:
> Seymour's response made me realize that my post was incomplete.
Yes, source? JCL? I/O error info (CSW IOB stuff, sense data..)
DCB contents: LRECL/BLKSIZE/RECFM?
It's some sort of I/O error but what?
. incorrect length (caused by block > blksize?)
. real I/O error
Thoughts which come to mind:
1. The LRECL/BLKSIZE/RECFM has 3 sources: DCB, JCL(JFCB), DSCB.
I think they are used in that order. While I've never tried the
unlike data set concatenation, I'd suspect that setting the "wrong"
value in either the DCB or JCL(JFCB) won't get fixed by the close/open
merging in the (correct) DSCB value if the original value was specified
in the DCB or JCL(JFCB).
So the DCB has to start out before the first open with LRECL and
BLKSIZE not specified and they have to not be specified on the JCL.
Then the unlike concatenation close/open can restore them and the
DSCB values can be used by the next concatenation open.
2. Are there partial VBS segments at the end of the first file?
3. A separate solution (as previously seen on this list) is to
put the largest LRECL/BLKSIZE on the JCL of the first
dataset and not use unlike concatenation...
PS: DEBLRECL in the access method DEB segment appears to hold the
DCBLRECL saved during open which gets restored by close. (MVT source:
IGG0201X) What does this contain during the time the first in the
concatenation is open?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
