I was suggesting to try a PDS/E V2 to see if the issue was still there. I have V2.1 and I ran your JCL as is with both V1 and V2 PDS/E and in both cases the ZZZZ member contained the information expect. So A1 and A2 ZZZZ member has the ###ZZZZ### information
Do you see the following messages when doing IEBCOPY? IEB1135I IEBCOPY FMID HDZ2210 SERVICE LEVEL UA74516 IEB1035I LKOEH05O COPY#A1 08:03:55 FRI 20 MAR 2015 P COPY#A1 COPY INDD=SYSUT1,OUTDD=SYSUT2 IEB1013I COPYING FROM PDSE INDD=SYSUT1 VOL=TSOT15 IEB1014I TO PDSE OUTDD=SYSUT2 VOL=TSOT14 IGW01551I MEMBER DUMMY HAS BEEN COPIED IGW01551I MEMBER ZZZZ HAS BEEN COPIED IGW01550I 2 OF 2 MEMBERS WERE COPIED IEB147I END OF JOB - 0 WAS HIGHEST SEVERITY CODE Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Henn, Karl > Sent: Friday, March 20, 2015 7:03 AM > To: [email protected] > Subject: Re: Intermittent, not consistently reproducible problems with PDSEs > on z/OS V2R1 (incl. infrequent S0F4-20 RSN 1C0752EE ABENDs) > > I checked that. There are *no* version-2 PDSEs involved in the problem. > > Thanks. > > Karl > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Lizette Koehler > Sent: Friday, March 20, 2015 2:46 PM > To: [email protected] > Subject: Re: Intermittent, not consistently reproducible problems with PDSEs > on z/OS V2R1 (incl. infrequent S0F4-20 RSN 1C0752EE ABENDs) > > You might also try making the PDS/Es a Version 2. > > Just to verify it is due to z/OS V2.1. V2 PDS/Es are available in z/OS V2.1 > with > the JCL statement DSNTYPE=(LIBRARY,2) or selection Version in the ISPF 3.2 > panel. > > Might just add to the documentation of this issue. > > Lizette > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM- > [email protected]] > > On Behalf Of Vernooij, CP (ITOPT1) - KLM > > Sent: Friday, March 20, 2015 6:41 AM > > To: [email protected] > > Subject: Re: Intermittent, not consistently reproducible problems with > > PDSEs on z/OS V2R1 (incl. infrequent S0F4-20 RSN 1C0752EE ABENDs) > > > > Did you check the latest PTFs? > > We discovered a PDSE problem 2 weeks ago, for which the PTF was only > > made available a few weeks before. I don't have the details, but you > > might find a hit on the abend/rsn codes. > > > > Kees. > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM- > [email protected]] > > On Behalf Of Karl Henn > > Sent: 20 March, 2015 14:03 > > 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
