That’s exactly my experience. The problem occurs with z/OS V2R1 *only*. Thanks.
Karl -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Thomas Berg Sent: Friday, March 20, 2015 2:44 PM To: [email protected] Subject: Re: Intermittent, not consistently reproducible problems with PDSEs on z/OS V2R1 (incl. infrequent S0F4-20 RSN 1C0752EE ABENDs) I submitted the JCL on z/OS 1.13 with expected result (that is: ZZZZ member is NOT empty). Best Regards, Thomas Berg ___________________________________________________________________ Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ) > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Karl Henn > Sent: Friday, March 20, 2015 2:03 PM > To: [email protected] > Subject: Intermittent, not consistently reproducible problems with PDSEs on > z/OS V2R1 (incl. > infrequent S0F4-20 RSN 1C0752EE ABENDs) > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
