The original test was batch only; the empty member was created with IEBGENER (see step CRE#A1D in the JCL of my original post below).
Thanks. Karl -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of ITURIEL DO NASCIMENTO NETO Sent: Friday, March 20, 2015 4:32 PM To: [email protected] Subject: RES: Intermittent, not consistently reproducible problems with PDSEs on z/OS V2R1 (incl. infrequent S0F4-20 RSN 1C0752EE ABENDs) Karl, I've run the same test you suggest and everything was fine. One question, how did you create an empty member without SAVE command ? Do you use AUTOSAVE ON/OFF ? Did you create them using IEBGENER or some other batch process ? Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto BANCO BRADESCO S.A. 4250 / DPCD Engenharia de Software Sistemas Operacionais Mainframes Tel: +55 11 3684-2177 R: 42177 3-1404 Fax: +55 11 3684-4427 Banco Bradesco. Patrocinador oficial dos Jogos Olímpicos e Paralímpicos Rio 2016. -----Mensagem original----- De: IBM Mainframe Discussion List [mailto:[email protected]] Em nome de Henn, Karl Enviada em: sexta-feira, 20 de março de 2015 12:06 Para: [email protected] Assunto: 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 AVISO LEGAL <br>...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. LEGAL ADVICE<br>...This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. ---------------------------------------------------------------------- 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
