Thanks for your note.
I guess/hope that everybody pulls the latest HOLDDATA very frequently.
The submitted date of OA47338 is March 20th, 2015 - the very day this thread
was started. The existence of the APAR was brought to my attention 5 days later
(Thanks to Bob Rutledge). All in all, that
The PE HOLDs showed up on the 20th as well:
++HOLD(HDZ1D10) FMID(HDZ1D10) REASON(AA47338) ERROR DATE(15079)
COMMENT(SMRTDATA(SYMP(DAL) CHGDT(150320)))
CLASS(HIPER).
++HOLD(HDZ2210) FMID(HDZ2210) REASON(AA47338) ERROR
Thanks for your note, Bob.
One can easily agree on the idea of pulling HOLDDATA (plus running ERRSYSMODS
and MISSINGFIX reports) on a daily basis; it makes a lot of good sense.
Aside from that, however, the problem had initially occurred earlier, and I had
already researched the matter for
Well, we all appreciate you taking one for the team! smile
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Henn, Karl
Sent: Friday, March 27, 2015 7:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intermittent, not consistently
World,
Luckily, I'm not crazy. Who would have thought that ...?
The error was introduced with the PTFs for OA46598, which were: UA75869 (D10)
and UA75875 (210).
There is a fairly fresh APAR that addresses this problem; OA47338 (special
thanks to Tony Harminc for pointing me to this
* USERS AFFECTED: IEBCOPY of a RECFM=F or RECFM=FB PDSE
* results in a broken PDSE. The only members
* which can be accessed in the target PDSE
* are the empty members.
The special thanks should really go to Bob Rutledge. He's the one that pointed
out the APAR. Tony just gave you a public url.
In article
am3pr03mb340e276be01c7ceb5f1c6a4ec...@am3pr03mb340.eurprd03.prod.outlook.com
you wrote:
World,
Luckily, I'm not crazy. Who would have thought that ...?
Very true, Don. That must have temporarily slipped my attention. May I blame it
on lack of sleep? ;-)
Special thanks to Bob Rutledge as well, of course!
And, once again: I do appreciate y'all's input and help.
Regards
Karl
-Original Message-
From: IBM Mainframe Discussion List
(Just picked off the last note in the thread.) I hate to leave this intriguing
discussion without a stab at lessons learned. Given that the problem was
finally solved and remediated through a PE APAR, there are a couple of actions
that might have led to faster resolution.
1. Rigorously pull
Thanks a lot, Tony!
I don't know why I didn't see/find it yesterday. The error description of this
brand-new APAR does exactly fit the situation I'm facing. I'll RESTORE UA75875
right away in order to verify this.
Regards,
Karl
-Original Message-
From: IBM Mainframe Discussion List
On 26 Mar 2015 03:33:25 -0700, in bit.listserv.ibm-main you wrote:
* USERS AFFECTED: IEBCOPY of a RECFM=F or RECFM=FB PDSE
* results in a broken PDSE. The only members
* which can be accessed in the
On 26 March 2015 at 08:06, Don Poitras sas...@sas.com wrote:
The special thanks should really go to Bob Rutledge. He's the one that pointed
out the APAR. Tony just gave you a public url.
I was about to point that out. Thanks for doing it for me. :-)
Tony H.
basking in undeserved glory...
Henn, Karl wrote:
It took me a while to get back to the discussion.
Thanks for coming back to IBM-MAIN.
In order to convince «the world» (incl. myself) that I'm not crazy, ...
You forgot other planets and their worlds, they would go crazy if they find
out... ;-D
... when exactly the
Hello,
It took me a while to get back to the discussion.
In order to convince «the world» (incl. myself) that I'm not crazy, and since
nobody seemed to be able to recreate the problem, I freshly re-installed z/OS
V2R1 (based on the ADLT tapes created June 26th, 2014) in an isolated test LPAR
Henn, Karl wrote:
... when exactly the error was introduced, but it was somewhere between
HDZ2210 at UA70793 and HDZ2210 at UA74516.
Hi Karl,
I ran your test and we have HDZ2210 at UA74516 installed. I don't get your
results. The pds#2() has the correct data.
Doug
Have you seen OA47338?
Bob
IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on
03/25/2015 12:27:33 PM:
From: Henn, Karl k.h...@seg.de
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 03/25/2015 12:27 PM
Subject: Re: Intermittent, not consistently reproducible problems
with PDSEs on z/OS
Thanks, Doug.
I do have a z/OS V2R1 *with* the error, as well as one *without* the error, the
difference being a couple of hundred PTFs - otherwise same HW, some setup, same
customization etc.
It could be that the error was not introduced with a PTF for HDZ2210. If that's
the case, what else
On Wed, 25 Mar 2015 16:27:33 +, Henn, Karl wrote:
I do have a z/OS V2R1 *with* the error, as well as one *without* the error,
the difference being a couple of hundred PTFs - otherwise same HW, some
setup, same customization etc.
It could be that the error was not introduced with a PTF
No, I havn't seen it, and I don't find it , either. Typo?
Thanks.
Karl
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bob Rutledge
Sent: Wednesday, March 25, 2015 6:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intermittent, not
On 25 March 2015 at 13:17, Henn, Karl k.h...@seg.de wrote:
No, I havn't seen it, and I don't find it , either. Typo?
No typo - works for me with a general public access, i.e. not logged
on to IBM in any way. Try
http://www-01.ibm.com/support/docview.wss?uid=isg1OA47338
Tony H.
The mathematician sounds like a lawyer to me...
:)
Best Regards,
Thomas Berg
___
Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ)
-Original Message-
From: IBM Mainframe Discussion List
On Fri, 20 Mar 2015 08:03:09 -0500, Karl Henn wrote:
BROWSESYSADM.TEST.PDSE#A2()
Command ===
Hello Karl,
I did ran your job, without changing a comma, on one of our z/OS 2.1
systems.Member is identical on both PDSEs.
Walter Marguccio
z/OS Systems Programmer
BELENUS LOB Informatic GmbH
Munich - Germany
--
For
Sorry for the OT, but that response somehow made me think of this:
An astronomer, a physicist and a mathematician are on a train in Scotland. The
astronomer looks out of the window, sees a black sheep standing in a field, and
remarks, How odd. All the sheep in Scotland are black! No, no, no!
Thanks for taking the time to do a test, Walter.
Unfortunately, the problem does not seem to occur in any other installation. A
couple of folks already ran my JCL; up until now, nobody could confirm my
results.
Best Regards,
Karl
-Original Message-
From: IBM Mainframe Discussion List
The subject of your post suggests, and I don't remember if you
said, that sometimes it works correctly. Is that right?
--
Tom Marchant
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
There IS difference between an empty member and a member with a blank line. It
could shed a light on the type of error we are looking for.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Thomas Berg
Sent: 23 March, 2015 14:37
Hello Karl,
you are welcome; you said the problem is intermittent. Running only once on my
z/OS 2.1 doesn't necessarily mean that it will run correctly the next 100
times. I ran the job a second time in order to call IEBGENER, rather than
ICEGENER.Still, I get a 'clean' in both datasets.
Tom,
Admittedly, the wording of the subject is maybe not clear enough; it goes back
to an earlier point in time in the course of the error analysis.
Originally, I had thought that there was some kind of (say) general error,
which I suspected to occur for *any* PDSE under - then unknown -
Kees,
That is indeed a valid question; it was already raised before. We *are* using
the original IBM IEBCOPY and IEBGENER, *no* replacement products.
Best Regards,
Karl
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Vernooij, CP
Karl,
Did you run IBM's IEBGENER and IEBCOPY, not replacement products?
I remember a very weird, similar problem we had many years ago with 3390
compatible hardware: intermittently we suffered from corrupted PDS members.
After thorough tests, it appeared to be time dependent. If we waited an
http://controlgeek.net/blog/2009/3/30/why-the-samsung-extreme-sheep-led-art-video-is-fake.html
On Mon, Mar 23, 2015 at 8:33 AM, Ambros, Thomas
thomas_amb...@keybank.com wrote:
Sorry for the OT, but that response somehow made me think of this:
An astronomer, a physicist and a mathematician
I ran the test job, but could not recreate the problem.
One thing that I realized while running the test was, that we have some
plug-ins to replace IEBCOPY and IEBGENER. To make the test comparable, I had to
rerun the test with the original tools, and the result was Ok.
Did everybody who ran
Thanks, Bernd.
We do have PDSESHARING = EXTENDED set (during IPL already).
Regarding Thomas Reed's presentation on using PDSEs in a SYSPLEX: I do not see
any improper PDSE sharing going on in our installation, in particular *not* the
scenario shown on slide number 9.
Best Regards
Karl
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.
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 ).
Could you give this a try? I don't have access to a z/OS system
Karl,
did you see APAR OA24679?
Regards,
Werner
Von:Karl Henn k.h...@seg.de
An: IBM-MAIN@LISTSERV.UA.EDU,
Datum: 20.03.2015 14:13
Betreff:Intermittent, not consistently reproducible problems with
PDSEs on z/OS V2R1 (incl. infrequent S0F4-20 RSN 1C0752EE ABENDs)
Gesendet von:
Same here, z/OS 2.1 and both members have ######, no issues.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent: Friday, March 20, 2015 10:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intermittent, not
I submitted the JCL on z/OS 1.13 with expected result (that is: member is
NOT empty).
Best Regards,
Thomas Berg
___
Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ)
-Original Message-
From: IBM
I misunderstood that. I'll try a version-2 PDSE during my next round of tests.
Here's the message output.
IEB1135I IEBCOPY FMID HDZ2210 SERVICE LEVEL UA74516 DATED 20140814 DFSMS
02.01.00 z/OS02.01.00 HBB7790
IEB1013I COPYING FROM PDSE INDD=SYSUT1 VOL=STR40F DSN=SYSADM.TEST.PDSE#A1
Karl Henn wrote:
In my view, there are three possibilities.
(1) I'm crazy.
No. Seriously.
(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.
What is running as IEBGENER and IEBCOPY? Don't laugh
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 member contained the information expect. So A1 and A2
member has the ###### information
Do you see the following messages
Yes, I saw that. Yet, OA24679 holds no PTF for z/OS V2R1.
Thanks.
Karl
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Werner Kuehnel
Sent: Friday, March 20, 2015 2:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Antwort: Intermittent,
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
Yes. I did that. We are PTF-wise up-to-date.
Thanks.
Karl
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Vernooij, CP (ITOPT1) - KLM
Sent: Friday, March 20, 2015 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intermittent,
That’s exactly my experience. The problem occurs with z/OS V2R1 *only*.
Thanks.
Karl
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Thomas Berg
Sent: Friday, March 20, 2015 2:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re:
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
Tried on z/OS 2.1 here, could not duplicate your results. Browse of member
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/OS02.01.00 HBB7790 CPU 2817
IEB1035I TDPEFARI
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
I created the following members, in the order shown below
DUMMY (empty)
(empty)
EB1135I IEBCOPY FMID HDZ2210 SERVICE LEVEL UA74516 DATED 20140814 DFSMS
02.01.00 z/OS02.01.00 HBB7790
EB1013I COPYING FROM PDSE INDD=SYSUT1 VOL=ST123B DSN=SYSADM.TEST.PDSE#A1
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
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
I checked that. There are *no* version-2 PDSEs involved in the problem.
Thanks.
Karl
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent: Friday, March 20, 2015 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re:
I won't laugh and kick ...
We are definitely running the IBM original IEBGENER and IEBCOPY.
IEB1135I IEBCOPY FMID HDZ2210 SERVICE LEVEL UA74516 DATED 20140814 DFSMS
02.01.00 z/OS02.01.00 HBB7790
IGW01551I MEMBER DUMMY HAS BEEN COPIED
IGW01551I MEMBER HAS BEEN COPIED
There is
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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of ITURIEL DO NASCIMENTO NETO
Sent:
what is this? Has this already been covered by the preceeding discussions?
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.12.0/com.ibm.zos.r12.idad400/pdsesh.htm%23pdsesh
Normal or Extended PDSE Sharing
Kind regards
Bernd
Am 20.03.2015 um 17:45 schrieb Henn, Karl:
Yes, the problem
I also found this; seems very good to me:
https://share.confex.com/share/120/webprogram/Handout/Session12981/SHARE%20PDSE%20Best%20Practices.pdf
Kind regards
Bernd
Am 20.03.2015 um 19:52 schrieb Bernd Oppolzer:
what is this? Has this already been covered by the preceeding
discussions?
Bernd,
Me too, you can filter also my special characters , maybe it's on my
default ...
Regards,
Scott
On Friday, March 20, 2015, Bernd Oppolzer bernd.oppol...@t-online.de
wrote:
I also found this; seems very good to me:
https://share.confex.com/share/120/webprogram/Handout/
On 3/20/2015 1:10 PM, Thomas Conley wrote:
On 3/20/2015 9:13 AM, Karl Henn wrote:
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
so there is something strange that IEBGENER does to
empty PDSE members (when closing them) on your system
that it does not do on others' systems?
Only meant to summarize the conclusions so far ...
isn't there a mechanism to cache PDSE directories system wide,
to fasten up library searches?
Am 20.03.2015 um 17:02 schrieb Henn, Karl:
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 *
The additional IEBGENER steps (to print the data) all ran OK: for the source
members originally containing data, the output was as expected; for the
originally empty members, there was no output, naturally.
When I said Same problem, I meant that the additional IEBGENER's OPEN and
CLOSE
Sounds like time for a PMR.
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Henn, Karl
Sent: Friday, March 20, 2015 9:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intermittent, not consistently reproducible problems
On 3/20/2015 9:13 AM, Karl Henn wrote:
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
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.
Good point! Could be guaranteed synchronous write in the SMS storage class
definition. But what if have a non-SMS managed PDSE?
Thanks.
Karl
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bernd Oppolzer
Sent: Friday, March 20,
None of us is infallible, not even after decades of MVS systems programming.
Four times YES.
Thanks.
Karl
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John Eells
Sent: Friday, March 20, 2015 5:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of
Henn, Karl
Sent: Friday, March 20, 2015 5:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intermittent, not consistently reproducible problems with PDSEs
on z/OS V2R1 (incl.
Yes, the problem *only* occurs ...
... with z/OS V2R1,
... with PDSEs,
... in case at least one empty member exists in the source PDSE of the copy
operation (IEBCOPY), irrespective of how the empty member was created.
We do have SMSPDSE and SMSPDSE1 set up and running.
guaranteed synchronous
I'm sure you've already thought of stuff like this but when I see
apparent intermittent single-installation data integrity problems it
always leads me to poke at things like...
The PDSEs are shared only within a sysplex?
All the DASD volumes are defined as shared if actually shared?
CLPA IPL
Yep.
Thanks.
Karl
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent: Friday, March 20, 2015 6:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intermittent, not consistently reproducible problems with PDSEs on
71 matches
Mail list logo
