IMO, this is a bug.
Does the bug depend on the names of the members?
I would think that the bug only appears, if the empty member (in this
case DUMMY)
has a name lexically lower than the non-empty member (in this case ZZZZ).
Could you give this a try? I don't have access to a z/OS system today,
so I can't
try it myself.
What if there are non-empty members before the first empty member?
Maybe it works in this case, too.
Would you keep us informed? I would appreciate it.
Thank you, kind regards
Bernd
Am 20.03.2015 um 14:03 schrieb Karl Henn:
Hello,
The description of the following "problem" (if you prefer to call it such)
sounds a little unusual, and the sample JCL looks - and is! - trivial. I still kindly ask
the world to please read it, and maybe try it out. My primary goal is to make sure that
I'm not simply just out of my mind.
Ever since we're running z/OS V2R1, complaints about alleged problems with
PDSEs were forwarded to me, sporadically. The error descriptions were fairly
fuzzy, ranging from intermittent S0F4-20 RSN 1C0752EE ABENDs, problems with
empty members, as well as incomplete copies of PDSEs with IEBCOPY CC 00. Since
none of the problems were really consistently reproducible, I kind of just
brushed away the issue for a while.
The S0F4 ABENDs I could not ignore, though. The complaints didn’t stop, either.
So, in order to narrow down a possible problem, I started experimenting -
yielding a surprising result.
Please take a look at the following JCL. Don’t laugh, but as simple as it may
look, it *sometimes* does not work.
//*------------------------------------------------------------------*
//DELETE EXEC PGM=IDCAMS,COND=(0,NE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD DATA
DELETE <hlq>.TEST.PDSE#A1 NVSAM SCRATCH
DELETE <hlq>.TEST.PDSE#A2 NVSAM SCRATCH
SET MAXCC=00
/*
//*------------------------------------------------------------------*
//ALLOC EXEC PGM=IEFBR14,COND=(0,NE)
//SYSPRINT DD SYSOUT=*
//PDSE#A1 DD DISP=(NEW,CATLG),DSN=<hlq>.TEST.PDSE#A1,
// RECFM=FB,LRECL=80,SPACE=(CYL,(1,1,1)),UNIT=SYSALLDA,
// DSNTYPE=LIBRARY
//PDSE#A2 DD DISP=(NEW,CATLG),DSN=<hlq>.TEST.PDSE#A2,
// RECFM=FB,LRECL=80,SPACE=(CYL,(1,1,1)),UNIT=SYSALLDA,
// DSNTYPE=LIBRARY
//*------------------------------------------------------------------*
//CRE#A1D EXEC PGM=IEBGENER,COND=(0,NE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT2 DD DISP=SHR,DSN=<hlq>.TEST.PDSE#A1(DUMMY)
//SYSUT1 DD DSN=NULLFILE,RECFM=FB,LRECL=80,DSORG=PO
//*------------------------------------------------------------------*
//CRE#A1Z EXEC PGM=IEBGENER,COND=(0,NE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT2 DD DISP=SHR,DSN=<hlq>.TEST.PDSE#A1(ZZZZ)
//SYSUT1 DD DATA
###ZZZZ###
/*
//*------------------------------------------------------------------*
//COPY#A1 EXEC PGM=IEBCOPY,COND=(0,NE)
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=<hlq>.TEST.PDSE#A1
//SYSUT2 DD DISP=SHR,DSN=<hlq>.TEST.PDSE#A2
//SYSIN DD DUMMY
//*------------------------------------------------------------------*
//
All steps usually end with CC 00. So far, so good. Everything as expected.
However, if you BROWSE member ZZZZ in the two data sets involved, the result is
surprising, to say the least.
BROWSE SYSADM.TEST.PDSE#A1(ZZZZ)
Command ===>
********************************
--------------------------------
###ZZZZ###
777EEEE7774444444444444444444444
BBB9999BBB0000000000000000000000
--------------------------------
BROWSE SYSADM.TEST.PDSE#A2(ZZZZ)
Command ===>
********************************
--------------------------------
44444444444444444444444444444444
00000000000000000000000000000000
--------------------------------
Even though IEBCOPY (in step COPY#A1) ended with CC 00, and target member ZZZZ
is *empty*. Even more intriguing: This *only* happens if an empty member (DUMMY
in my example) already exists in the source PDSE, otherwise everything is fine
and good.
In my view, there are three possibilities.
(1) I'm crazy.
(2) In my 28 year as a Mainframe Systems Programmer, I somehow managed to miss
a crucial piece of information.
(3) There is a bad bug somewhere.
Once I can rule out No. 1 and No. 2, I might turn to IBM.
Thanks a lot in advance, everybody!
Best Regards
Karl
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
