Tried on z/OS 2.1 here, could not duplicate your results. Browse of member
ZZZZ in PDSE#A2 shows the same contents as in PDSE#A1.
IEBCOPY messages follow:
IEB1135I IEBCOPY FMID HDZ2210 SERVICE LEVEL UA70793 DATED 20130919 DFSMS
02.01.00 z/OS 02.01.00 HBB7790 CPU 2817
IEB1035I TDPEFARI COPY#A1 11:46:36 FRI 20 MAR 2015 PARM=''
COPY#A1 COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT
IEB1013I COPYING FROM PDSE INDD=SYSUT1 VOL=WORKT5 DSN=TDPEFAR.TEST.PDSE#A1
IEB1014I TO PDSE OUTDD=SYSUT2 VOL=WORKT6 DSN=TDPEFAR.TEST.PDSE#A2
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
HTH
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Karl Henn
Sent: Friday, March 20, 2015 9: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
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
