Dave,
We had a similar problem a couple of releases ago with DASD Error Recovery
which was zeroing out the IOBCSW field on certain error conditions. This
EXCP program had been running OK for over 25 years. IBM told us we should
be using SEEK HEAD CCW's instead of SEEK CCW's even though it was within
the extent. We didn't buy that and eventually they gave us a fix.
Regards,
John K
From: Scott Rowe <scott.r...@joann.com>
To: IBM-MAIN@bama.ua.edu
Date: 06/08/2011 03:26 PM
Subject: Re: DCBs and DCBEs - Could IBM have done it any worse?
Dave,
I was happy to see that you are only "barking: at the hand that feeds you
;-)
Have you opened a PMR with IBM on this to see if it is WAD?
Scott
On Wed, Jun 8, 2011 at 4:14 PM, David Cole <dbc...@colesoft.com> wrote:
> <rant-on>
>
> I just shot a bug in z/XDC that occurred only rarely, but once it
occurred,
> it drove me nuts! And frankly, I don't think it's even "my fault". It
comes
> from what seems to me (to put it as politely as I can) to be IBM's clear
> violation of the principle of least surprise...
>
> Ok, first of all, here it is around 3 decades(!) after the introduction
of
> 31-bit addressing, and DCBs still must reside in 24-bit storage?????? And
> the best "solution" to this intransigence is the DCBE??? [sigh...] But
I
> digress. That's a subject for an entirely different rant. <rant off>
>
>
> <nope, rant on and on and on ...>
>
> What's got me going today is this. For very good reasons, I have created
my
> DCB and DCBE (as well as a host of other data areas and control blocks)
in
> key-9 storage. But my code (z/XDC), when running non-authorized, runs
with
> execution key-8. So when I open my dataset, OPEN does the following:
>
> - OPEN services opens the key-9 DCB just fine, no complaints, not a
peep.
> - But when OPEN sees that:
> - It's caller (z/XDC) is running in problem state,
> - And it's caller is running in execution key-8,
> - But the DCBE is in key-9 storage,
> OPEN zero's out the DCBDCBE field (the DCB's link to the DCBE),
> and proceeds to open the DCB without the DCBE.
>
> Nevermind that key-9 storage is problem program storage.
> Nevermind that problem state key-8 programs are free to write to key-9
> storage no matter what.
> Nevermind that OPEN has no complaint about the key-9 DCB.
> Nevermind that neither GET nor PUT nor READ nor WRITE nor CHECK nor FIND
> have ever complained about the key-9 DCB and DCBE.
> (How do I know WRT the DCBE? See below...)
> Nevermind that CLOSE has ever had a problem with the key-9 DCB and DCBE.
> OPEN simply blows away the DCBDCBE field as if nobody would care...
>
> Worse, OPEN gives no notice that it has done this!
> - OPEN does not abend.
> - OPEN does not fail to open the dataset.
> - OPEN does not set any return or reason code.
> - OPEN does not set any error, warning or informational flag.
> OPEN just proceeds as if the DCBE simply does not matter...
> [It's just unbelievable!]
>
> So I never noticed this issue until I had a broken file that resulted in
> s001 abends, which, I knew, "couldn't happen"... [Boy, I wish I had a
dime
> for every time I've heard that...]
>
> So when I investigated, it took me a rather long time to figure it all
out.
> Particularly because I couldn't believe that OPEN would do such a stupid
> thing! I was, well... surprised!
>
>
>
>
> Well, it turns out that there is a pretty simple workaround. Out of
> desperation, after OPEN completed, all dumb and happy,
> - I just slammed @'DCBE back into the DCBDCBE field,
> - And I turned DCBH0 and DCBH1 flags back on,
> - And voilà, my 31-bit EODAD and SYNAD routines now work just fine.
>
> Now, I don't use any of the other advanced services of the DCBE, so I
don't
> know if this kludge would work with respect to those, but as far as I/O
> errors and end of data are concerned, my code is now happy, so I'm happy
too
> [sort of... at least until IBM decides to "fix" against my workaround...]
>
> But come-on IBM, can't you do better than this????
> <rant off>
>
> I want to thank IBM for the wonderful life they and their software have
> given me for the past 45+ years! It's things like this that help sell
z/XDC
> [;)]
>
>
>
> Dave Cole REPLY TO: dbc...@colesoft.com
> ColeSoft Marketing WEB PAGE: http://www.colesoft.com
> 736 Fox Hollow Road VOICE: 540-456-8536
> Afton, VA 22920 FAX: 540-456-6658
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
