Re: DCBs and DCBEs - Could IBM have done it any worse?
On Mon, 13 Jun 2011 08:44:03 -0400, Peter Relson wrote: IBM very rarely will change an existing RC=0 to some non-0 value. This is for compatibility reasons. Even rarer (if ever) would be to do this in the service stream. We would not want to break some potentially critical application that had a correct program ... z/OS is full of horrible defaults and behaviors that are legacy behaviors that we don't dare change and instead must make a user overtly request new behavior. The price of maintaining compatibility with such defective (not correct) user programs is burdening customers with an endless increase in needless complexity and astonishment factors, such as Ed and Dave encountered. In the (not very) long term, this price exceeds the value of the compatibility provided. I prefer to be told when I make a programming error. -- gil -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
IBM very rarely will change an existing RC=0 to some non-0 value. This is for compatibility reasons. Even rarer (if ever) would be to do this in the service stream. We would not want to break some potentially critical application that had a correct program such as OPEN If R15 not-equal 0 then abend When the application had, in effect, wanted the long-standing (somewhat strange) behavior of ignoring the DCBE because of its key (or any of the other reasons why a DCBE might be ignored). Likely? No. Impossible? No. z/OS is full of horrible defaults and behaviors that are legacy behaviors that we don't dare change and instead must make a user overtly request new behavior. Peter Relson z/OS Core Technology Design -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
Hi Peter, Although I have a lot of disagreement over the original design of silently blowing away the DCBE for one (not disclosed) reason from a list of (disclosed much later) reasons, I can certainly understand not wanting to change that behavior now that it has been released into the wild. However, that does not foreclose all possible solutions. One that occurs to me would be to create a new option (perhaps in the DCB, perhaps the new 31-bit OPEN plist) whereby the developer can explicitly request a more reasonable handling of a bad DCBE error. WRT creating an option flag in the DCB, in regards to signalling the presence of the DCBE, you deftly finessed the no available flag problem by using a 2-bit signal. I bet you can do something like that for this as well. In any case, you know as well as I that downward compatible solutions can be created. I expect at this point the real issue is cost-vs-benefit (ie, resources which is just a synonym for money and commitment). Dave At 6/13/2011 08:44 AM, Peter Relson wrote: IBM very rarely will change an existing RC=0 to some non-0 value. This is for compatibility reasons. Even rarer (if ever) would be to do this in the service stream. We would not want to break some potentially critical application that had a correct program such as OPEN If R15 not-equal 0 then abend When the application had, in effect, wanted the long-standing (somewhat strange) behavior of ignoring the DCBE because of its key (or any of the other reasons why a DCBE might be ignored). Likely? No. Impossible? No. z/OS is full of horrible defaults and behaviors that are legacy behaviors that we don't dare change and instead must make a user overtly request new behavior. Peter Relson z/OS Core Technology Design -- 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 Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On 6/13/2011 5:44 AM, Peter Relson wrote: We would not want to break some potentially critical application that had a correct program such as OPEN If R15 not-equal 0 then abend When the application had, in effect, wanted the long-standing (somewhat strange) behavior of ignoring the DCBE because of its key (or any of the other reasons why a DCBE might be ignored). My assumption is that (nearly) 100% of ignored DCBEs are a total surprise to the programmer. Creating a DCBE is extra work. No programmer I know would intentionally go to that much trouble for a No-Op. If any of our DCBEs are being ignored (maybe some are!), we would consider that a bug in our code. Therefore, I favor an abend for 'bad' DCBEs analogous to many similar abends for 'bad' DCBs. The same tracker technology that was used for the EAV project could be used to empirically identify cases where a DCBE is being unilaterally ignored by the system. As I said, I predict that (nearly) 100% of identified cases will come as a total surprise to the programmer and the problems will be fixed. There might not be any cases left after that! For the highly-unlikely (yet possible) case in which a program provides a DCBE and expects it to be ignored, those programmers could remove the DCBE themselves prior to OPEN or set a new option in the DCB/DCBE that would tell the system to use the old behavior. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
In listserv%20110611211153.0...@bama.ua.edu, on 06/11/2011 at 09:33 PM, Paul Gilmartin paulgboul...@aim.com said: Does OPEN generally set RC? Yes. I thought it either succeeds or causes an ABEND Do an OPEN with an undefined ddname. That the reason for all of those tests of DCBOFLGS,DCBOFOPN. It's a holdover from a batch/production mindset: data sets are to be allocated statically, and there's no recovery when one can't be accessed. Lots of batch programs have optional data sets, and the recovery if they're not there is to not use them. But, yes, I agree; OPEN should provide notification, via a mechanism that programmers have come over decades to handle, when it does something underhanded. I'd go beyond that and say that OPEN shouldn't do anythiong underhanded. If the DCBE pointer is invalid then fail the OPEN. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
In ioo8v65nqocp4jiiddhdhsdpftnrjab...@4ax.com, on 06/12/2011 at 10:01 AM, Binyamin Dissen bdis...@dissensoftware.com said: At one time OPEN non-VSAM did not have return codes. You had to check DCBOFOPN to see if it did its job. Seems like that has changed. No, because an OPEN of multiple DCB's has only one return code, so you still need to check DCBOFOPN to determine which DCB's are open. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
In listserv%201106121700383928.0...@bama.ua.edu, on 06/12/2011 at 05:00 PM, Paul Gilmartin paulgboul...@aim.com said: That just shows it's inconsistent. Only in treating different errors as having different degrees of severity. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On Sat, 11 Jun 2011 20:42:22 -0400 Robert A. Rosenberg hal9...@panix.com wrote: :At 22:44 +0300 on 06/11/2011, Binyamin Dissen wrote about Re: DCBs :and DCBEs - Could IBM have done it any worse?: : :The only thing that I can think of is that IBM was trying to be user :friendly and was concerned that programmers may not have read the :instructions that DCBE's need to be in writable storage and as DCBE's may be :ignored decided that the best approach was to ignore the DCBE if not in the :PSW key. :This analysis fails on two points. :First, if the DCBE resides in writable storage then the programmer :has followed the rules. Zeroing the pointer (and flags) would only be :valid if the DCBE was NOT writable. DFSMS development overlooked special key 9. :Second, it should return a RC when it overrode the programmer's :instructions so that the RC can be used to trigger some action, if :desired, due to the request being unilaterally denied by IBM. Thus :the action is user unfriendly due to the stealth nature of the :zero'ing (ie: Doing it without notifying the program that it was :done). At one time OPEN non-VSAM did not have return codes. You had to check DCBOFOPN to see if it did its job. Seems like that has changed. :I have a vague memory of cases where an operation returns a success :RC but also a subcode that indicates that the classification of :success was due to some requests not being serviced or some :conditions having occurred that allowed the operation to continue in :a degraded mode. This case would, IMO, fall into this type of :situation. IOW: You can continue BUT if you do, it will be without :the routines that were listed in the DCBE being used. OPEN RC=4 seems appropriate, and as DCBE is new code no downward compatibility issue. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On Sun, 12 Jun 2011 10:01:14 +0300, Binyamin Dissen wrote:
At one time OPEN non-VSAM did not have return codes. You had to check DCBOFOPN
to see if it did its job. Seems like that has changed.
It hasn't changed a whole lot; it's still way easy to get Sx13 ABENDs:
READY
allocate dd(sysin) shr reuse dsn('sys1.maclib(nonesuch)')
READY
call *(iebgener)
DATA SET UTILITY - GENERATE PAGE 0001
IEC141I 013-18,IGG0191B,user,$STCTSO1,SYSIN,4140,MVS3RS,SYS1.MACLIB(NONESUCH)
IKJ56641I IEBGENER ENDED DUE TO ERROR+
READY
-- gil
--
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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On 6/12/2011 9:24 AM, Paul Gilmartin wrote:
allocate dd(sysin) shr reuse dsn('sys1.maclib(nonesuch)')
READY
call *(iebgener)
DATA SET UTILITY - GENERATE PAGE 0001
IEC141I 013-18,IGG0191B,user,$STCTSO1,SYSIN,4140,MVS3RS,SYS1.MACLIB(NONESUCH)
IKJ56641I IEBGENER ENDED DUE TO ERROR+
READY
You must already have SYSPRINT allocated somewhere (not shown) or IEBGENER would
have ended with a simple OPEN failure for SYSPRINT sans abend:
call *(iebgener)
IEC130I SYSPRINT DD STATEMENT MISSING
READY
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/
--
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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On Sun, 12 Jun 2011 14:33:39 -0700, Edward Jaffe wrote:
On 6/12/2011 9:24 AM, Paul Gilmartin wrote:
allocate dd(sysin) shr reuse dsn('sys1.maclib(nonesuch)')
READY
call *(iebgener)
DATA SET UTILITY - GENERATE PAGE
0001
IEC141I
013-18,IGG0191B,user,$STCTSO1,SYSIN,4140,MVS3RS,SYS1.MACLIB(NONESUCH)
IKJ56641I IEBGENER ENDED DUE TO ERROR+
READY
You must already have SYSPRINT allocated somewhere (not shown) or IEBGENER
would
have ended with a simple OPEN failure for SYSPRINT sans abend:
call *(iebgener)
IEC130I SYSPRINT DD STATEMENT MISSING
READY
That just shows it's inconsistent. Sometimes RC0; sometimes Sx13.
I suspect (with no evidence whatever) the utility checks for a DDNAME
allocation (but why bother?) If it's absent, exit with return code;
if it's present, attempt the OPEN which may ABEND.
IIRC, our TSO LOGON proc allocates SYSIN and SYSPRINT to terminal.
IBM recommends this by example in:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b4b0/3.2.3.2
Title: z/OS V1R12.0 TSO/E Customization
Document Number: SA22-7783-11
-- gil
--
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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On 6/12/2011 3:00 PM, Paul Gilmartin wrote: That just shows it's inconsistent. Sometimes RC0; sometimes Sx13. I suspect (with no evidence whatever) the utility checks for a DDNAME allocation (but why bother?) If it's absent, exit with return code; if it's present, attempt the OPEN which may ABEND. No. IEC130I is the standard message produced by OPEN when a DD name is missing. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On 13/06/2011 02:24 AM, Paul Gilmartin wrote:
It hasn't changed a whole lot; it's still way easy to get Sx13 ABENDs:
READY
allocate dd(sysin) shr reuse dsn('sys1.maclib(nonesuch)')
READY
call *(iebgener)
DATA SET UTILITY - GENERATE PAGE 0001
IEC141I 013-18,IGG0191B,user,$STCTSO1,SYSIN,4140,MVS3RS,SYS1.MACLIB(NONESUCH)
IKJ56641I IEBGENER ENDED DUE TO ERROR+
READY
-- gil
Gil,
an unfair test.
The test should be
OPEN (TEXTDCB,,CONVDCB,(OUTPUT),PRINTDCB, X
(OUTPUT))
LTR RF,RF
BZ OPEN_OK
various error testing routines
wrapped of course in the rest of the module, compiled, linked and
executed with the appropriate JCL.
I don't, without going top the MVS 3.8 source know the extent of
IEBGENER's error checking
Ken
--
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
Re: DCBs and DCBEs - Could IBM have done it any worse?
At 10:01 +0300 on 06/12/2011, Binyamin Dissen wrote about Re: DCBs and DCBEs - Could IBM have done it any worse?: :I have a vague memory of cases where an operation returns a success :RC but also a subcode that indicates that the classification of :success was due to some requests not being serviced or some :conditions having occurred that allowed the operation to continue in :a degraded mode. This case would, IMO, fall into this type of :situation. IOW: You can continue BUT if you do, it will be without :the routines that were listed in the DCBE being used. OPEN RC=4 seems appropriate, and as DCBE is new code no downward compatibility issue. I agree. A warning message should also be issued so that there is some documentation of what went wrong for post analysis. A multi-DCB/ACB open would need to require the program to step though the CBs to find the error flags (but this is normal in that situation) and which CB had the partial failure. -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
At 6/11/2011 01:29 AM, Jim Mulder wrote: The particular documentation to which Ed refers is available only to ISVs who are under nondisclosure. Dave Cole is among those, and thus he should have access to it. For the rest of the IBM-MAIN folks, I will say that it just describes the issue which Dave Cole has very accurately described, and says that it has been resolved in z/OS 1.13. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY Thanks Jim. I, of course, was not free to make that disclosure. I appreciate your doing so for the list's benefit. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On Sat, 11 Jun 2011 10:52:10 -0400, David Cole wrote: At 6/11/2011 01:29 AM, Jim Mulder wrote: The particular documentation to which Ed refers is available only to ISVs who are under nondisclosure. Dave Cole is among those, and thus he should have access to it. For the rest of the IBM-MAIN folks, I will say that it just describes the issue which Dave Cole has very accurately described, and says that it has been resolved in z/OS 1.13. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY Thanks Jim. I, of course, was not free to make that disclosure. I appreciate your doing so for the list's benefit. But was Jim free to make that disclosure? I would expect that confidientiality clause, typical in NDAs to be bilateral. Of course, you seem pleased with Jim's action, and it's quite possible, AFAIK, that Jim first contacted you privately to obtain your permission to disclose that an NDA exists between IBM and ColeSoft. (Who'd be surprised?) But wouldn't a FIN APAR obviate much of the cloak-and-dagger? The only thing inappropriate to a FIN APAR is preannouncing the particular future release. Apparently Jim is authorized to make such an announcement here. (This in no way obligates IBM, blah, blah, blah.) -- gil -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On Sat, Jun 11, 2011 at 10:42 AM, Paul Gilmartin paulgboul...@aim.com wrote: deleted But wouldn't a FIN APAR obviate much of the cloak-and-dagger? The only thing inappropriate to a FIN APAR is preannouncing the particular future release. Apparently Jim is authorized to make such an announcement here. (This in no way obligates IBM, blah, blah, blah.) -- gil An APAR can be closed as Fixed in a future release. Doesn't specify anything about which release or any other fixes or changes. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On Sat, 11 Jun 2011 12:50:35 -0500, Mike Schwab wrote: On Sat, Jun 11, 2011 at 10:42 AM, Paul Gilmartin wrote: deleted But wouldn't a FIN APAR obviate much of the cloak-and-dagger? The only thing inappropriate to a FIN APAR is preannouncing the particular future release. Apparently Jim is authorized to make such an announcement here. (This in no way obligates IBM, blah, blah, blah.) An APAR can be closed as Fixed in a future release. Doesn't specify anything about which release or any other fixes or changes. That's what I was trying to say. This issue could be described in a FIN APAR, omitting identification of the future release, but otherwise dispelling most of the mystery. -- gil -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On Sat, 11 Jun 2011 10:42:58 -0500 Paul Gilmartin paulgboul...@aim.com wrote: :On Sat, 11 Jun 2011 10:52:10 -0400, David Cole wrote: :At 6/11/2011 01:29 AM, Jim Mulder wrote: :The particular documentation to which Ed refers is available only to :ISVs who are under nondisclosure. Dave Cole is among those, and :thus he should have access to it. :For the rest of the IBM-MAIN folks, I will say that it just :describes the issue which Dave Cole has very accurately described, :and says that it has been resolved in z/OS 1.13. :Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY :Thanks Jim. I, of course, was not free to make that disclosure. I :appreciate your doing so for the list's benefit. :But was Jim free to make that disclosure? I would expect that :confidientiality clause, typical in NDAs to be bilateral. Of :course, you seem pleased with Jim's action, and it's quite :possible, AFAIK, that Jim first contacted you privately to :obtain your permission to disclose that an NDA exists between :IBM and ColeSoft. (Who'd be surprised?) :But wouldn't a FIN APAR obviate much of the cloak-and-dagger? :The only thing inappropriate to a FIN APAR is preannouncing the :particular future release. Apparently Jim is authorized to :make such an announcement here. (This in no way obligates :IBM, blah, blah, blah.) Or one can write a similar program, have it fail in a similar way and open a PMR. I fail to see why this is super sekrit. I was trying to find the exposure. I don't see any protected block that saves the DCBE address and even if there was (such as the DEB having the DCB address) system code cannot guarantee that the storage is not freed and reassigned to a protected subpool, i.e., any supervisor code that modifies these control blocks must do it in user key. The only thing that I can think of is that IBM was trying to be user friendly and was concerned that programmers may not have read the instructions that DCBE's need to be in writable storage and as DCBE's may be ignored decided that the best approach was to ignore the DCBE if not in the PSW key. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On 6/11/2011 12:44 PM, Binyamin Dissen wrote: The only thing that I can think of is that IBM was trying to be user friendly and was concerned that programmers may not have read the instructions that DCBE's need to be in writable storage and as DCBE's may be ignored decided that the best approach was to ignore the DCBE if not in the PSW key. OPEN ignores--without a message, abend or other feedback--the DCBE provided by the program for numerous reasons, including 'DCBE storage is not in key of caller'. Therefore, even though key9 DCBEs will be accepted in z/OS 1.13, it seems like a good idea to check to be sure your DCBE has not been ignored after receiving RC=0 from OPEN no matter what release you're running on. For the record, I don't like this one bit. IMHO, it would be far better if OPEN abended, issued a message and/or failed with a non-zero return code if the DCBE does not pass the validity checks. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
At 22:44 +0300 on 06/11/2011, Binyamin Dissen wrote about Re: DCBs and DCBEs - Could IBM have done it any worse?: The only thing that I can think of is that IBM was trying to be user friendly and was concerned that programmers may not have read the instructions that DCBE's need to be in writable storage and as DCBE's may be ignored decided that the best approach was to ignore the DCBE if not in the PSW key. This analysis fails on two points. First, if the DCBE resides in writable storage then the programmer has followed the rules. Zeroing the pointer (and flags) would only be valid if the DCBE was NOT writable. Second, it should return a RC when it overrode the programmer's instructions so that the RC can be used to trigger some action, if desired, due to the request being unilaterally denied by IBM. Thus the action is user unfriendly due to the stealth nature of the zero'ing (ie: Doing it without notifying the program that it was done). I have a vague memory of cases where an operation returns a success RC but also a subcode that indicates that the classification of success was due to some requests not being serviced or some conditions having occurred that allowed the operation to continue in a degraded mode. This case would, IMO, fall into this type of situation. IOW: You can continue BUT if you do, it will be without the routines that were listed in the DCBE being used. -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On Sat, 11 Jun 2011 20:42:22 -0400, Robert A. Rosenberg wrote: Second, it should return a RC when it overrode the programmer's instructions so that the RC can be used to trigger some action, if desired, due to the request being unilaterally denied by IBM. Thus the action is user unfriendly due to the stealth nature of the zero'ing (ie: Doing it without notifying the program that it was done). Does OPEN generally set RC? I thought it either succeeds or causes an ABEND (which could be trapped). Are programmers accustomed to testing RC after OPEN. It's a holdover from a batch/production mindset: data sets are to be allocated statically, and there's no recovery when one can't be accessed. But, yes, I agree; OPEN should provide notification, via a mechanism that programmers have come over decades to handle, when it does something underhanded. -- gil -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
Paul: How would you handle it if you open a dataset with a blksize=0 in your DCB and the system fills in another number? Open is doing as it should as blksize is almost universilly filled in by open for both input and output. The actual number may not come from Open though and can be filled in by several different components. How would you handle the return code when it could come from say 4-5 places and how would you document any resultant return codes as to who filled it in? I am not necessarily disagreeing but there are sort of issues with your stance, no? Ed From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@bama.ua.edu Sent: Sat, June 11, 2011 9:33:33 PM Subject: Re: DCBs and DCBEs - Could IBM have done it any worse? On Sat, 11 Jun 2011 20:42:22 -0400, Robert A. Rosenberg wrote: Second, it should return a RC when it overrode the programmer's instructions so that the RC can be used to trigger some action, if desired, due to the request being unilaterally denied by IBM. Thus the action is user unfriendly due to the stealth nature of the zero'ing (ie: Doing it without notifying the program that it was done). Does OPEN generally set RC? I thought it either succeeds or causes an ABEND (which could be trapped). Are programmers accustomed to testing RC after OPEN. It's a holdover from a batch/production mindset: data sets are to be allocated statically, and there's no recovery when one can't be accessed. But, yes, I agree; OPEN should provide notification, via a mechanism that programmers have come over decades to handle, when it does something underhanded. -- gil -- 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 -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
:But wouldn't a FIN APAR obviate much of the cloak-and-dagger? :The only thing inappropriate to a FIN APAR is preannouncing the :particular future release. Apparently Jim is authorized to :make such an announcement here. (This in no way obligates :IBM, blah, blah, blah.) Or one can write a similar program, have it fail in a similar way and open a PMR. I fail to see why this is super sekrit. There is nothing cloak-and-dagger or secret about this. DFSMS development at some point became aware of this issue and fixed it in the release which was in development at that time, which happened to be z/OS 1.13. Some number of old problems get fixed that way in every new release, and there is nothing unusual about it. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On 6/11/2011 7:33 PM, Paul Gilmartin wrote: Does OPEN generally set RC? I thought it either succeeds or causes an ABEND (which could be trapped). Are programmers accustomed to testing RC after OPEN. Yes. OPEN sets a return code in R15. RC=0 means everything AOK. RC=4 means open succeeded but a message was issued. RC=8/12 means an ACB/DCB failed to open. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On Thu, 9 Jun 2011 21:37:44 -0700 Edward Jaffe edja...@phoenixsoftware.com wrote: :On 6/8/2011 1:14 PM, David Cole wrote: : 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. :This issue, and IBM's resolution intended for a release not yet generally :available, was covered at the April 2010 TDM (session 36, pp. 84-85). How might one access this document? -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On 6/9/2011 11:24 PM, Binyamin Dissen wrote: How might one access this document? Partnerworld members with the appropriate AECI in place can download it from a secure IBM web site. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
At 6/10/2011 12:37 AM, Edward Jaffe wrote: This issue, and IBM's resolution intended for a release not yet generally available, was covered at the April 2010 TDM (session 36, pp. 84-85). Ah. You, sir, obviously are far more able to stay awake at those meetings than I. Your cite is exactly on point. THANK YOU! [:)] -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
Ed, Can you provide a link, of post the text? TIA, snip On 6/8/2011 1:14 PM, David Cole wrote: 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. This issue, and IBM's resolution intended for a release not yet generally available, was covered at the April 2010 TDM (session 36, pp. 84-85). /snip -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
In nvn2v6p37eql91tk4ikc396renn881v...@4ax.com, on 06/09/2011 at 09:08 PM, Clark Morris cfmpub...@ns.sympatico.ca said: How hard would it be for IBM to allow use of the ACB for QSAM data sets? BSAM? BPAM? PDSE? BDAM? You mean like the RCI in OS/VS1? I believe that the problems are political. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 06/10/2011 08:25:43 AM: Ed, Can you provide a link, of post the text? TIA, snip On 6/8/2011 1:14 PM, David Cole wrote: 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. This issue, and IBM's resolution intended for a release not yet generally available, was covered at the April 2010 TDM (session 36, pp. 84-85). /snip The particular documentation to which Ed refers is available only to ISVs who are under nondisclosure. Dave Cole is among those, and thus he should have access to it. the For the rest of the IBM-MAIN folks, I will say that it just describes the issue which Dave Cole has very accurately described, and says that it has been resolved in z/OS 1.13. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On 8 June 2011 23:56, Robert A. Rosenberg hal9...@panix.com wrote: At 17:09 -0400 on 06/08/2011, Tony Harminc wrote about Re: DCBs and DCBEs - Could IBM have done it any worse?: So OPEN not only zeroed out the DCBE pointer, but it also turned off the flags that show that such a pointer exists? I suppose that's considerate... Considerate Nothing - Since it destroyed the DCBE Pointer (by setting it to Zero) it HAD to reset the flags or the first time something tried to access the DCBE Pointer (since the flags were still set) it would ABEND/0cx. The only way to avoid this is to unset the flags that would cause the pointer to be referenced. I omitted the :-) to save bandwidth. Tony H. -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On 9 Jun 2011 08:07:21 -0700, in bit.listserv.ibm-main you wrote: On 8 June 2011 23:56, Robert A. Rosenberg hal9...@panix.com wrote: At 17:09 -0400 on 06/08/2011, Tony Harminc wrote about Re: DCBs and DCBEs - Could IBM have done it any worse?: So OPEN not only zeroed out the DCBE pointer, but it also turned off the flags that show that such a pointer exists? I suppose that's considerate... Considerate Nothing - Since it destroyed the DCBE Pointer (by setting it to Zero) it HAD to reset the flags or the first time something tried to access the DCBE Pointer (since the flags were still set) it would ABEND/0cx. The only way to avoid this is to unset the flags that would cause the pointer to be referenced. I omitted the :-) to save bandwidth. How hard would it be for IBM to allow use of the ACB for QSAM data sets? BSAM? BPAM? PDSE? BDAM? Clark Morris Tony H. -- 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 -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
At 11:06 -0400 on 06/09/2011, Tony Harminc wrote about Re: DCBs and DCBEs - Could IBM have done it any worse?: On 8 June 2011 23:56, Robert A. Rosenberg hal9...@panix.com wrote: At 17:09 -0400 on 06/08/2011, Tony Harminc wrote about Re: DCBs and DCBEs - Could IBM have done it any worse?: So OPEN not only zeroed out the DCBE pointer, but it also turned off the flags that show that such a pointer exists? I suppose that's considerate... Considerate Nothing - Since it destroyed the DCBE Pointer (by setting it to Zero) it HAD to reset the flags or the first time something tried to access the DCBE Pointer (since the flags were still set) it would ABEND/0cx. The only way to avoid this is to unset the flags that would cause the pointer to be referenced. I omitted the grin to save bandwidth. Tony H. I realize that. I was just commenting for those who might have overlooked the linkage between the flags and the zero'ing and the consequences of leaving the flags set. In some cases, the fall-out from an action is missed and explicitly mentioning it is always useful. -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On 6/8/2011 1:14 PM, David Cole wrote: 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. This issue, and IBM's resolution intended for a release not yet generally available, was covered at the April 2010 TDM (session 36, pp. 84-85). -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
DCBs and DCBEs - Could IBM have done it any worse?
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 RoadVOICE:540-456-8536 Afton, VA 22920FAX: 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
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 RoadVOICE:540-456-8536 Afton, VA 22920FAX: 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET
Re: DCBs and DCBEs - Could IBM have done it any worse?
At 6/8/2011 04:25 PM, Scott Rowe wrote: 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? Well, it's certainly WAC... For reason's I cannot get into, I am unable to open PMRs... Maybe my rant will move someone else to do so. In any case, I've got my workaround, and now you do too... Dave -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
On 8 June 2011 16:14, David Cole dbc...@colesoft.com wrote: [...] - 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. [...] 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. So OPEN not only zeroed out the DCBE pointer, but it also turned off the flags that show that such a pointer exists? I suppose that's considerate... Tony H. -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
Dave, But doesn't everything WAC? (I presume you mean Works As Coded). :-) Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Cole Sent: Wednesday, June 08, 2011 3:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: DCBs and DCBEs - Could IBM have done it any worse? At 6/8/2011 04:25 PM, Scott Rowe wrote: 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? Well, it's certainly WAC... For reason's I cannot get into, I am unable to open PMRs... Maybe my rant will move someone else to do so. In any case, I've got my workaround, and now you do too... Dave -- 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 The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
Harken back to the days when a REWIND 9 and Write 9 in Fortran would overwrite the Volume label! In a message dated 6/8/2011 4:09:43 P.M. Central Daylight Time, t...@harminc.net writes: but it also turned off the flags that show that such a pointer exists? I suppose that's -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
At 6/8/2011 05:10 PM, Pommier, Rex R. wrote: Dave, But doesn't everything WAC? (I presume you mean Works As Coded). :-) Rex Uh-huh... Way back in the '70s, when a colleague tried to file an APAR (remember what that actually stands for?) over some now forgotten issue, IBM refused to do so, saying It doesn't need 'fixing' because [you guessed it] it works as coded... -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
Some program features have also been described as BAD (Broken As Designed). An APAR [1] is a South American armadillo with three bands of bony plates: http://www.thefreedictionary.com/Apar. Bill Fairchild Rocket Software [1] It might also refer to an Authorized Program Analysis Report: http://search400.techtarget.com/definition/authorized-program-analysis-report. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Cole Sent: Wednesday, June 08, 2011 4:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: DCBs and DCBEs - Could IBM have done it any worse? Way back in the '70s, when a colleague tried to file an APAR (remember what that actually stands for?) over some now forgotten issue, IBM refused to do so, saying It doesn't need 'fixing' because [you guessed it] it works as coded... -- 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 -- 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
Re: DCBs and DCBEs - Could IBM have done it any worse?
At 17:09 -0400 on 06/08/2011, Tony Harminc wrote about Re: DCBs and DCBEs - Could IBM have done it any worse?: So OPEN not only zeroed out the DCBE pointer, but it also turned off the flags that show that such a pointer exists? I suppose that's considerate... Considerate Nothing - Since it destroyed the DCBE Pointer (by setting it to Zero) it HAD to reset the flags or the first time something tried to access the DCBE Pointer (since the flags were still set) it would ABEND/0cx. The only way to avoid this is to unset the flags that would cause the pointer to be referenced. -- 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
