Karl,

This is probably a dumb question/observation, but in step CRE#A1D the SYSUT1 DD 
has DSORG=PO on it.  Is this correct?  Granted it is a dummy dataset, but what 
happens when you try to use *GENER to copy a PDS into a PDS member?  I tested 
it on 1.13 and it works the same either way, but I thought this was strange.  

To repeat Elardus' question - are you getting IEBCOPY messages stating the 
members are being copied?

IGW01551I MEMBER DUMMY  HAS BEEN COPIED                                        
IGW01551I MEMBER ZZZZ  HAS BEEN COPIED                                         
IGW01550I 2 OF 2  MEMBERS WERE COPIED                                          

Rex

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Karl Henn
Sent: Friday, March 20, 2015 8:03 AM
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

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to