Oppolzer - Informatik / Blog

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 K.H.:
> 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
>
> K.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to listserv@listserv.ua.edu with the message: INFO IBM-MAIN
>

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