Re: DCBs and DCBEs - Could IBM have done it any worse?

[Paul Gilmartin]

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?

[Shmuel Metz (Seymour J.)]

In , on 06/12/2011
   at 05:00 PM, Paul Gilmartin  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  
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?

[Shmuel Metz (Seymour J.)]

In , on 06/12/2011
   at 10:01 AM, Binyamin Dissen  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  
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?

[Shmuel Metz (Seymour J.)]

In , on 06/11/2011
   at 09:33 PM, Paul Gilmartin  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  
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?

[Edward Jaffe]

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?

[David Cole]

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?

[Peter Relson]

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?

[Robert A. Rosenberg]

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?

[Ken Brick]

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?

[Edward Jaffe]

On 6/12/2011 3:00 PM, Paul Gilmartin wrote:

That just shows it's inconsistent.  Sometimes RC<>0; 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?

[Paul Gilmartin]

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 RC<>0; 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?

[Edward Jaffe]

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?

[Paul Gilmartin]

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?

[Binyamin Dissen]

On Sat, 11 Jun 2011 20:42:22 -0400 "Robert A. Rosenberg" 
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 
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?

[Edward Jaffe]

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?

[Jim Mulder]

> :>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?

[Ed Gould]

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 
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?

[Paul Gilmartin]

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?

[Robert A. Rosenberg]

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?

[Edward Jaffe]

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?

[Binyamin Dissen]

On Sat, 11 Jun 2011 10:42:58 -0500 Paul Gilmartin 
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 
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?

[Paul Gilmartin]

On Sat, 11 Jun 2011 12:50:35 -0500, Mike Schwab wrote:

>On Sat, Jun 11, 2011 at 10:42 AM, Paul Gilmartin wrote:
>
>> 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?

[Mike Schwab]

On Sat, Jun 11, 2011 at 10:42 AM, Paul Gilmartin  wrote:

> 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?

[Paul Gilmartin]

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?

[David Cole]

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?

[Jim Mulder]

IBM Mainframe Discussion List  wrote on 06/10/2011 
08:25:43 AM:

> Ed,
> Can you provide a link, of post the text?
> 
> TIA,
> 
> 
> 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).
> 

  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?

[Shmuel Metz (Seymour J.)]

In , on 06/09/2011
   at 09:08 PM, Clark Morris  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  
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?

[Staller, Allan]

Ed,
Can you provide a link, of post the text?

TIA,


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).


--
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?

[David Cole]

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?

[Edward Jaffe]

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?

[Binyamin Dissen]

On Thu, 9 Jun 2011 21:37:44 -0700 Edward Jaffe 
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 
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?

[Edward Jaffe]

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

Re: DCBs and DCBEs - Could IBM have done it any worse?

[Robert A. Rosenberg]

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  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.



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?

[Clark Morris]

On 9 Jun 2011 08:07:21 -0700, in bit.listserv.ibm-main you wrote:

>On 8 June 2011 23:56, Robert A. Rosenberg  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?

[Tony Harminc]

On 8 June 2011 23:56, Robert A. Rosenberg  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?

[John P Kalinich]

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  
   

   
  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  wrote:

> 
>
> 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. 
>
>
> 
>
> 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 f

Re: DCBs and DCBEs - Could IBM have done it any worse?

[Robert A. Rosenberg]

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

Re: DCBs and DCBEs - Could IBM have done it any worse?

[Bill Fairchild]

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?

[David Cole]

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?

[Ed Finnell]

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?

[Pommier, Rex R.]

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?

[Tony Harminc]

On 8 June 2011 16:14, David Cole  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?

[David Cole]

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?

[Scott Rowe]

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  wrote:

> 
>
> 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. 
>
>
> 
>
> 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
> 
>
> 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 t

DCBs and DCBEs - Could IBM have done it any worse?

[David Cole]

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. 





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


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