> Have you tried with - directly after each IEBGENER step - do an IEBGENER from > the member to SYSOUT ? Yes. Makes no difference. Same problem
> Have you tried with only non-empty members? Yes. No empty members - no problem. > Have tried with DD * instead of DD DATA ? Yes. Makes no difference. Same problem. > Have you tried with something other than NULLFILE for empty members? (E g an > IEBCOPY from a third dataset with empty members.) Yes. Makes no difference. Same problem. Thanks. Karl -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Thomas Berg Sent: Friday, March 20, 2015 4:16 PM To: [email protected] Subject: Re: Intermittent, not consistently reproducible problems with PDSEs on z/OS V2R1 (incl. infrequent S0F4-20 RSN 1C0752EE ABENDs) Have you tried with - directly after each IEBGENER step - do an IEBGENER from the member to SYSOUT ? Have you tried with only non-empty members? Have tried with DD * instead of DD DATA ? Have you tried with something other than NULLFILE for empty members? (E g an IEBCOPY from a third dataset with empty members.) 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 Henn, Karl > Sent: Friday, March 20, 2015 4:06 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 created the following members, in the order shown below > > DUMMY (empty) > AAAA > ZZZZ > BBBB > NNNN (empty) > EEEE > > EB1135I IEBCOPY FMID HDZ2210 SERVICE LEVEL UA74516 DATED 20140814 DFSMS > 02.01.00 > z/OS 02.01.00 HBB7790 > EB1013I COPYING FROM PDSE INDD=SYSUT1 VOL=ST123B DSN=SYSADM.TEST.PDSE#A1 > EB1014I TO PDSE OUTDD=SYSUT2 VOL=ST113B DSN=SYSADM.TEST.PDSE#A2 > GW01551I MEMBER AAAA HAS BEEN COPIED > GW01551I MEMBER BBBB HAS BEEN COPIED > GW01551I MEMBER DUMMY HAS BEEN COPIED GW01551I MEMBER EEEE HAS BEEN > COPIED GW01551I MEMBER NNNN HAS BEEN COPIED GW01551I MEMBER ZZZZ HAS > BEEN COPIED GW01550I 6 OF 6 MEMBERS WERE COPIED EB147I END OF JOB - 0 > WAS HIGHEST SEVERITY CODE > > In SYSADM.TEST.PDSE#A2, members AAAA, ZZZZ, BBBB, and EEEE contain > *only* blanks. It looks as if no data was copied at all. The lexical > order of the member names does not seem to play a role. > > In addition to that, I did another test. > > (a) I created the members as shown above. > > (b) *Before* copying, I edited *all* of the empty members: DUMMY and > NNN. I just went in there with ISPF EDIT, and typed SAVE in the command line, > without having entered any data. > > (c) Ran IEBCOPY - and everything was fine! > > > So , something is wrong with the empty members in the copy source > (PDSE#A1). Once they are opened and closed once, the error is gone. I > must say that I can hardly see how this could be related to anything > we have set up wrong in our installation. On the other hand, Lizette > and Leonardo have indicated that the problem does not occur on their > respective z/OS V2R1 systems. > > Thanks. > > Karl > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Bernd Oppolzer > Sent: Friday, March 20, 2015 2:31 PM > To: [email protected] > Subject: Re: Intermittent, not consistently reproducible problems with PDSEs > on z/OS V2R1 (incl. > infrequent S0F4-20 RSN 1C0752EE ABENDs) > > 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 > > ---------------------------------------------------------------------- > 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
