Re: "file integrity verified" - do I care?

[Howard Brazee]

On 20 Sep 2009 07:24:11 -0700, jcew...@acm.org (Joel C. Ewing) wrote:

>I can conceive of a case where you might want to distinguish between
>"97" and "00", but don't know of any programs in our shop doing that.
>It might make sense if the failure was because of a known ABEND of a
>re-runnable batch process or if there is a need to just record a
>possible exposure to lost updates or failure to update VSAM statistics;
>but, if you know which batch step abended, in all likelihood your
>problem resolution is going to involve a fix and rerun of that to start
>with. 

I've never seen it - in all of the shops I've worked in.   If a shop
suspects some dirty process, it should stick in a bunch of IDCAMS
verifies between jobs and trace down the problem.

--
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: "file integrity verified" - do I care?

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Robert A. Rosenberg
> 
> At 07:56 -0600 on 09/15/2009, Roach, Dennis (N-GHG) wrote about Re:
> "file integrity verified" - do I care?:
> 
> >That depends on how important data integrity is to you.
> >97 indicates that the last user of the file did not close it
properly.
> >The mechanics of the file (index/CI/CA) structure is valid.
> >It does not insure that all of the buffers were written to the file
> >when it was not closed.
> >I.E. - you may be missing data.
> 
> I have a question. If I have a file that gets a 97 when opened, is
> its status/contents at that point the same as if I had first done a
> IDCAMS VERIFY (and thus get a 00 at  open)? IOW: Does letting OPEN
> generate a 97 due to the IMPLICATE VERIFY generate a different end
> result as doing an EXPLICATE VERIFY via IDCAMS?

Best I can recall, the explicit VERIFY resets a "dirty" flag somewhere,
while the implicit VERIFY does not.  That "dirty flag" is what causes
the file status 97 instead of 00.  Neither means can guarantee that
everything that should be in the dataset is actually there; only that
all records in the data component are addressable via the index
component (and possibly that HURBA is correct).

-jc-

--
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: "file integrity verified" - do I care?

[Ted MacNEIL]

>I have a question. If I have a file that gets a 97 when opened, is 
its status/contents at that point the same as if I had first done a 
IDCAMS VERIFY (and thus get a 00 at  open)? IOW: Does letting OPEN 
generate a 97 due to the IMPLICATE VERIFY generate a different end 
result as doing an EXPLICATE VERIFY via IDCAMS?


No.
In both case, if there were unflushed buffers, they still no longer exist.
Only the application people (programmers and end users) can tell if the data is 
safe.
All the (implicite/explicite) verify does is state the the structure of the 
file is 'safe'.

-
Too busy driving to stop for gas!

--
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: "file integrity verified" - do I care?

[Robert A. Rosenberg]

At 07:56 -0600 on 09/15/2009, Roach, Dennis (N-GHG) wrote about Re: 
"file integrity verified" - do I care?:



That depends on how important data integrity is to you.
97 indicates that the last user of the file did not close it properly.
The mechanics of the file (index/CI/CA) structure is valid.
It does not insure that all of the buffers were written to the file 
when it was not closed.

I.E. - you may be missing data.


I have a question. If I have a file that gets a 97 when opened, is 
its status/contents at that point the same as if I had first done a 
IDCAMS VERIFY (and thus get a 00 at  open)? IOW: Does letting OPEN 
generate a 97 due to the IMPLICATE VERIFY generate a different end 
result as doing an EXPLICATE VERIFY via IDCAMS?


--
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: "file integrity verified" - do I care?

[Joel C. Ewing]

On 09/16/2009 05:45 PM, Clark Morris wrote:
> On 16 Sep 2009 10:53:02 -0700, in bit.listserv.ibm-main you wrote:
> 
>> In , on 09/15/2009
>>   at 07:31 AM, Howard Brazee  said:
>>
>>> What am I missing?
>>
>> The possibility that the application that failed to close the file might
>> have had updates it hadn't written out. The fact that "file integrity"
>> doesn't mean what you are assuming it means; it just means that the data
>> structures on disk are consistent with each other.
>>
> While I understand the exposure, I wonder how many shops treated 97
> differently than they did 00.  For that matter, is there any way to
> determine if an IDCAMS verify actually reset the open flag as opposed
> to finding the file was successfully closed?  
> 

I can conceive of a case where you might want to distinguish between
"97" and "00", but don't know of any programs in our shop doing that.
It might make sense if the failure was because of a known ABEND of a
re-runnable batch process or if there is a need to just record a
possible exposure to lost updates or failure to update VSAM statistics;
but, if you know which batch step abended, in all likelihood your
problem resolution is going to involve a fix and rerun of that to start
with.  All the other cases I've seen of "97" was because a online system
had terminated "with prejudice" (or because a batch program response to
a "97" on OPEN was to ABEND without CLOSE). In the case of a CICS ABEND
there is generally no way to regenerate any interactive updates that
might be lost or rollback to a consistent prior data state - unless you
consider the file important enough to use CICS journalling, in which
case CICS can handle some recovery.

-- 
Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org

--
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: "file integrity verified" - do I care?

[Clark Morris]

On 16 Sep 2009 10:53:02 -0700, in bit.listserv.ibm-main you wrote:

>In , on 09/15/2009
>   at 07:31 AM, Howard Brazee  said:
>
>>What am I missing?
>
>The possibility that the application that failed to close the file might
>have had updates it hadn't written out. The fact that "file integrity"
>doesn't mean what you are assuming it means; it just means that the data
>structures on disk are consistent with each other.
> 
While I understand the exposure, I wonder how many shops treated 97
differently than they did 00.  For that matter, is there any way to
determine if an IDCAMS verify actually reset the open flag as opposed
to finding the file was successfully closed?  

--
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: "file integrity verified" - do I care?

[Shmuel Metz (Seymour J.)]

In , on 09/15/2009
   at 07:31 AM, Howard Brazee  said:

>What am I missing?

The possibility that the application that failed to close the file might
have had updates it hadn't written out. The fact that "file integrity"
doesn't mean what you are assuming it means; it just means that the data
structures on disk are consistent with each other.
 
-- 
 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: "file integrity verified" - do I care?

[Frank Swarbrick]

>>> On 9/15/2009 at 9:21 AM, in message
, Erik Janssen
 wrote:
> We also have 'problems' with the filestatus 97, especiallly in DR. I ended up 
> 
> verifying all VSAM datasets with ISMF (it allows for cluster only selection 
> which is nice if you want to fire a verify ds(/) ) The whole idea of giving 
> a 
> filestatus 97 is in my view pointless since any subsequent program gets a 0 
> after the file was succesfully verified. So if you happen to have CICS or 
> some 'I dont care about this sh*t' program opening your dataset first you'll 
> 
> never notice it in the program you specifically wrote to deal with the 
> filestatus 
> 97. I would be very happy to see a runtime option to prevent the 97...

I have written up but not yet submitted a marketting requirement addressing 
this.  I'd like to run it by other people to see if it meets their requirements 
as well.  If you would like to see it please email me.  (I'd post it here but 
I'm afraid that might annoy people.)

Thanks,
Frank




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403

--
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: "file integrity verified" - do I care?

[Binyamin Dissen]

On Tue, 15 Sep 2009 09:08:51 -0600 Steve Comstock 
wrote:

:>Binyamin Dissen wrote:
:>> On Tue, 15 Sep 2009 08:43:31 -0600 Howard Brazee 
:>> wrote:
 
:>> :>On 15 Sep 2009 06:59:56 -0700, dennis.ro...@lmco.com (Roach, Dennis  ,
:>> :>N-GHG) wrote:
 
:>> :>>> Reconstruct what?I thought 97 meant the open statement was
:>> :>>> successful and file integrity was verified.   So the file is OK, the
:>> :>>> open is OK.
  
:>> :>>> What am I missing?
 
:>> :>>That depends on how important data integrity is to you.
:>> :>>97 indicates that the last user of the file did not close it properly.
:>> :>>The mechanics of the file (index/CI/CA) structure is valid.
:>> :>>It does not insure that all of the buffers were written to the file when 
it was not closed.
:>> :>>I.E. - you may be missing data.
 
:>> :>So you're saying I cannot trust that "file integrity is verified". It
:>> :>may be lying.   Have you come across this happening?
 
:>> Lying?
 
:>> For example, file is opened for output, application puts a record and abends
:>> before the data is firmed. Index and data is in synch, but the new data is 
not
:>> there.

:>Wait a minute. "Before the data is firmed"? What do you mean? How
:>does this happen?

There is a delay between logical I/O and physical I/O. If a program abends,
the default action is to not firm the pending buffers, i.e., to not place them
on DASD.

--
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: "file integrity verified" - do I care?

[Ted MacNEIL]

>Wait a minute. "Before the data is firmed"? What do you mean? How
does this happen?

Unflushed buffers?
-
Too busy driving to stop for gas!

--
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: "file integrity verified" - do I care?

[Erik Janssen]

We also have 'problems' with the filestatus 97, especiallly in DR. I ended up 
verifying all VSAM datasets with ISMF (it allows for cluster only selection 
which is nice if you want to fire a verify ds(/) ) The whole idea of giving a 
filestatus 97 is in my view pointless since any subsequent program gets a 0 
after the file was succesfully verified. So if you happen to have CICS or 
some 'I dont care about this sh*t' program opening your dataset first you'll 
never notice it in the program you specifically wrote to deal with the 
filestatus 
97. I would be very happy to see a runtime option to prevent the 97...

Regards,

Erik Janssen. 

--
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: "file integrity verified" - do I care?

[Steve Comstock]

Binyamin Dissen wrote:

On Tue, 15 Sep 2009 08:43:31 -0600 Howard Brazee 
wrote:

:>On 15 Sep 2009 06:59:56 -0700, dennis.ro...@lmco.com (Roach, Dennis  ,
:>N-GHG) wrote:

:>>> Reconstruct what?I thought 97 meant the open statement was
:>>> successful and file integrity was verified.   So the file is OK, the
:>>> open is OK.
 
:>>> What am I missing?


:>>That depends on how important data integrity is to you.
:>>97 indicates that the last user of the file did not close it properly.
:>>The mechanics of the file (index/CI/CA) structure is valid.
:>>It does not insure that all of the buffers were written to the file when it 
was not closed.
:>>I.E. - you may be missing data.

:>So you're saying I cannot trust that "file integrity is verified". It
:>may be lying.   Have you come across this happening?

Lying?

For example, file is opened for output, application puts a record and abends
before the data is firmed. Index and data is in synch, but the new data is not
there.


Wait a minute. "Before the data is firmed"? What do you mean? How
does this happen?

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

==> Ask about being added to our opt-in list:  <==
==>   * Early announcement of new courses  <==
==>   * Early announcement of new techincal papers <==
==>   * Early announcement of new promotions   <==

--
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: "file integrity verified" - do I care?

[Binyamin Dissen]

On Tue, 15 Sep 2009 08:43:31 -0600 Howard Brazee 
wrote:

:>On 15 Sep 2009 06:59:56 -0700, dennis.ro...@lmco.com (Roach, Dennis  ,
:>N-GHG) wrote:

:>>> Reconstruct what?I thought 97 meant the open statement was
:>>> successful and file integrity was verified.   So the file is OK, the
:>>> open is OK.
 
:>>> What am I missing?

:>>That depends on how important data integrity is to you.
:>>97 indicates that the last user of the file did not close it properly.
:>>The mechanics of the file (index/CI/CA) structure is valid.
:>>It does not insure that all of the buffers were written to the file when it 
was not closed.
:>>I.E. - you may be missing data.

:>So you're saying I cannot trust that "file integrity is verified". It
:>may be lying.   Have you come across this happening?

Lying?

For example, file is opened for output, application puts a record and abends
before the data is firmed. Index and data is in synch, but the new data is not
there.

--
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: "file integrity verified" - do I care?

[Howard Brazee]

On 15 Sep 2009 06:59:56 -0700, dennis.ro...@lmco.com (Roach, Dennis  ,
N-GHG) wrote:

>> Reconstruct what?I thought 97 meant the open statement was
>> successful and file integrity was verified.   So the file is OK, the
>> open is OK.
>> 
>> What am I missing?
>
>That depends on how important data integrity is to you.
>97 indicates that the last user of the file did not close it properly.
>The mechanics of the file (index/CI/CA) structure is valid.
>It does not insure that all of the buffers were written to the file when it 
>was not closed.
>I.E. - you may be missing data.

So you're saying I cannot trust that "file integrity is verified". It
may be lying.   Have you come across this happening?

--
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: "file integrity verified" - do I care?

[Roach, Dennis (N-GHG)]

> -Original Message-
> 
> >>So how do you use it?   What do you do differently when you get a 97
> than
> >>when you get a 00?
> >
> >Depending on the application, I might put out a message saying to
> >reconstruct from logs.
> 
> Reconstruct what?I thought 97 meant the open statement was
> successful and file integrity was verified.   So the file is OK, the
> open is OK.
> 
> What am I missing?

That depends on how important data integrity is to you.
97 indicates that the last user of the file did not close it properly.
The mechanics of the file (index/CI/CA) structure is valid.
It does not insure that all of the buffers were written to the file when it was 
not closed.
I.E. - you may be missing data.

 

Dennis Roach
GHG Corporation
Lockheed Martin Mission Services
Facilities Design and Operations Contract
NASA/JSC
Address:
   2100 Space Park Drive 
   LM-15-4BH
   Houston, Texas 77058
Mail:
   P.O. Box 58487
   Mail Code H4C
   Houston, Texas 77258
Phone:
   Voice:  (281)336-5027
   Cell:   (713)591-1059
   Fax:(281)336-5410
E-Mail:  dennis.ro...@lmco.com

All opinions expressed by me are mine and may not agree with my employer or any 
person, company, or thing, living or dead, on or near this or any other planet, 
moon, asteroid, or other spatial object, natural or manufactured, since the 
beginning of time.

--
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: "file integrity verified" - do I care?

[Howard Brazee]

On 14 Sep 2009 15:06:20 -0700, shmuel+ibm-m...@patriot.net (Shmuel
Metz  , Seymour J.) wrote:

>>So how do you use it?   What do you do differently when you get a 97 than
>>when you get a 00?
>
>Depending on the application, I might put out a message saying to
>reconstruct from logs.

Reconstruct what?I thought 97 meant the open statement was
successful and file integrity was verified.   So the file is OK, the
open is OK.

What am I missing?

--
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: "file integrity verified" - do I care?

[Shmuel Metz (Seymour J.)]

In , on 09/11/2009
   at 07:37 AM, Howard Brazee  said:

>So how do you use it?   What do you do differently when you get a 97 than
>when you get a 00?

Depending on the application, I might put out a message saying to
reconstruct from logs.
 
-- 
 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: "file integrity verified" - do I care?

[Howard Brazee]

On 11 Sep 2009 04:50:03 -0700, shmuel+ibm-m...@patriot.net (Shmuel
Metz  , Seymour J.) wrote:

>>So since 97 doesn't seem to be useful
>
>What it seems to you may not be what it seems to others. It certainly
>seems useful to me.

So how do you use it?   What do you do differently when you get a 97
than when you get a 00?

--
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: "file integrity verified" - do I care?

[Shmuel Metz (Seymour J.)]

In <85ce438477b040f1aa47a93d19a78...@wmk>, on 09/04/2009
   at 04:43 PM, Bill Klein  said:

>(Obviously, run-time would have the advantage of "no recompile required"
>while "compile-time" would have the advantage of NOT impacting existing
>programs - without an explicit selection of the feature).

A run-time option would not impact existing programs either. IMHO, the
preferred solution would be to have an installation default, a compile
time option *and* a run-time option to override the compile-time option.

-- 
 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: "file integrity verified" - do I care?

[Shmuel Metz (Seymour J.)]

In <4aa0113f.6f0f.008...@efirstbank.com>, on 09/03/2009
   at 06:55 PM, Frank Swarbrick  said:

>"Certain classes of I-O status values indicate fatal exception
>conditions. These are: any that begin with the digit 3 or 4, and any that
>begin with the digit 9 that the implementor defines as fatal."

That seems to say that IBM complied.

>So in this case IBM has chosen to make status '97' not only "not fatal",
>but in fact absolutely successful.  I am unable to determine of the
>standard actually allows a '9' error to be considered successful, or if
>it should only be a non-fatal or fatal error.

Does the standard define successful? Does it distinguish between
successful and non-fatal?

>Anyway, the point(!) to all of this is I would like to make a
>requirement to IBM Enterprise Cobol to have an option to no longer set a
>file status of 97 when this occurs, but rather to set the file status to
>00.

That sounds reasonable.

>So since 97 doesn't seem to be useful

What it seems to you may not be what it seems to others. It certainly
seems useful to me.

>Yes, I realize we "should" simply change the programs to conform to the
>IBM compiler.  But my feeling is that it's the status 97 that does not
>"conform" to the Cobol standard,

That's reasonable only if you misquoted the text from the standard earlier
in your message; the current behavior certainly conforms to what you
quoted.

>Any thoughts? 

Go through channels to endorse the Share requirement.
 
-- 
 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: "file integrity verified" - do I care?

[Clark Morris]

On 4 Sep 2009 18:08:29 -0700, in bit.listserv.ibm-main you wrote:

>>For any (all) of you who "dislike" the file status "97" - especially
>anyone involved in a >VSE to MVS conversion (where this seems to be a
>medium-high priority problem), >please consider submitting a  "Marketing
>Request"
>>to IBM and reference the existing SHARE requirement:
>
> >SSLNGC0413615  Optional (ISO 2002) "0x" file-status code for current
>"97"
>
>Yes, it was very aggravating when status code of "97" appeared on the
>landscape.
>But, to be honest with you, all of our I/O routines are coded to treat
>"00" and "97" the same. So for IBM to remove "97" as a status code will
>no real effect.

There are many shops that have brain dead application packages that
are unaware of status code 97 and/or old programs that no one is
willing to authorize the testing for the change.  Adding a verify step
adds slightly to the overhead (additional steps, etc.).  Thus fixing
the problem would a lot more shops than just those converting from
VSE.  See Howard Brazee's postings for example.  I also was in a shop
that would have benefited.
>
>If this status code had just appeared, I would say "yes" it would help
>save some needless coding, but since it's been around so long...we
>already have coded around it.
>And management won't spend the money to remove it...no money to get
>gained. 
>
>Thanks,
>Tom Savor
>
>_
>
>The information contained in this message is proprietary and/or confidential. 
>If you are not the intended recipient, please: (i) delete the message and all 
>copies; (ii) do not disclose, distribute or use the message in any manner; and 
>(iii) notify the sender immediately. In addition, please be aware that any 
>message addressed to our domain is subject to archiving and review by persons 
>other than the intended recipient. 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

--
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: "file integrity verified" - do I care?

[Ted MacNEIL]

>Yes, it was very aggravating when status code of "97" appeared on the 
>landscape.
>But, to be honest with you, all of our I/O routines are coded to treat "00" 
>and "97" the same.
>So for IBM to remove "97" as a status code will no real effect.

That's fine for long-time MVS (aka z/OS) shops.
But, the OP's problem is because he's converting from VSE (which doesn't 
violate the standard) to MVS (which doesn't).

-
Too busy driving to stop for gas!

--
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: "file integrity verified" - do I care?

[Frank Swarbrick]

>>> On 9/5/2009 at 7:57 AM, in message
, Mark Zelden
 wrote:
> On Sat, 5 Sep 2009 07:19:56 -0600, Frank Swarbrick
>  wrote:
> 
> On 9/4/2009 at 7:06 PM, in message
>><6ee7eb97db511b45b13630c3361751930141a...@cmbfisltc08.fnfis.com>, "Savor, Tom"
>> wrote:
 For any (all) of you who "dislike" the file status "97" - especially
>>> anyone involved in a >VSE to MVS conversion (where this seems to be a
>>> medium-high priority problem), >please consider submitting a  "Marketing
>>> Request"
to IBM and reference the existing SHARE requirement:
>>>
>>>  >SSLNGC0413615  Optional (ISO 2002) "0x" file-status code for current
>>> "97"
>>>
>>> Yes, it was very aggravating when status code of "97" appeared on the
>>> landscape.
>>> But, to be honest with you, all of our I/O routines are coded to treat
>>> "00" and "97" the same. So for IBM to remove "97" as a status code will
>>> no real effect.
>>>
>>> If this status code had just appeared, I would say "yes" it would help
>>> save some needless coding, but since it's been around so long...we
>>> already have coded around it.
>>> And management won't spend the money to remove it...no money to get
>>> gained.
>>
>>I would agree that there is no gain in removing it if it's already there. 
> But as a shop migrating from VSE where file status 97 does not occur, and
> thus has never been coded for, it will take us "time and money" to make the
> changes to handle status 97 now.
>>
>>Frank
>>
> 
> Since you have to rewrite all your JCL anyway, adding an IDCAMS VERIFY
> step may be the best option and really shouldn't add much to your migration
> costs in terms of time and money.  If you have automated this in some 
> way, it shouldn't be too much trouble to add this step.   You could always
> go back and revisit it later if IBM ever makes a change in this area. 

That is indeed one of the options I am considering.  Thanks!
 
> Just out of curiosity, how many programs are we talking about here?  
> A few hundred?  Thousands?

A few thousand, total, though likely not all that many would have the issue.  
As far as I can tell it only affects KSDS files that are opened for I-O (output 
without REUSE).  So hopefully that will lessen the scope of the issue.

Frank




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403

--
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: "file integrity verified" - do I care?

[Mark Zelden]

On Sat, 5 Sep 2009 07:19:56 -0600, Frank Swarbrick
 wrote:

 On 9/4/2009 at 7:06 PM, in message
><6ee7eb97db511b45b13630c3361751930141a...@cmbfisltc08.fnfis.com>, "Savor, Tom"
> wrote:
>>> For any (all) of you who "dislike" the file status "97" - especially
>> anyone involved in a >VSE to MVS conversion (where this seems to be a
>> medium-high priority problem), >please consider submitting a  "Marketing
>> Request"
>>>to IBM and reference the existing SHARE requirement:
>>
>>  >SSLNGC0413615  Optional (ISO 2002) "0x" file-status code for current
>> "97"
>>
>> Yes, it was very aggravating when status code of "97" appeared on the
>> landscape.
>> But, to be honest with you, all of our I/O routines are coded to treat
>> "00" and "97" the same. So for IBM to remove "97" as a status code will
>> no real effect.
>>
>> If this status code had just appeared, I would say "yes" it would help
>> save some needless coding, but since it's been around so long...we
>> already have coded around it.
>> And management won't spend the money to remove it...no money to get
>> gained.
>
>I would agree that there is no gain in removing it if it's already there. 
But as a shop migrating from VSE where file status 97 does not occur, and
thus has never been coded for, it will take us "time and money" to make the
changes to handle status 97 now.
>
>Frank
>

Since you have to rewrite all your JCL anyway, adding an IDCAMS VERIFY
step may be the best option and really shouldn't add much to your migration
costs in terms of time and money.  If you have automated this in some 
way, it shouldn't be too much trouble to add this step.   You could always
go back and revisit it later if IBM ever makes a change in this area. 

Just out of curiosity, how many programs are we talking about here?  
A few hundred?  Thousands?

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: "file integrity verified" - do I care?

[Frank Swarbrick]

>>> On 9/4/2009 at 7:06 PM, in message
<6ee7eb97db511b45b13630c3361751930141a...@cmbfisltc08.fnfis.com>, "Savor, Tom"
 wrote:
>> For any (all) of you who "dislike" the file status "97" - especially
> anyone involved in a >VSE to MVS conversion (where this seems to be a
> medium-high priority problem), >please consider submitting a  "Marketing
> Request"
>>to IBM and reference the existing SHARE requirement:
> 
>  >SSLNGC0413615  Optional (ISO 2002) "0x" file-status code for current
> "97"
> 
> Yes, it was very aggravating when status code of "97" appeared on the
> landscape.
> But, to be honest with you, all of our I/O routines are coded to treat
> "00" and "97" the same. So for IBM to remove "97" as a status code will
> no real effect.
> 
> If this status code had just appeared, I would say "yes" it would help
> save some needless coding, but since it's been around so long...we
> already have coded around it.
> And management won't spend the money to remove it...no money to get
> gained. 

I would agree that there is no gain in removing it if it's already there.  But 
as a shop migrating from VSE where file status 97 does not occur, and thus has 
never been coded for, it will take us "time and money" to make the changes to 
handle status 97 now.

Frank




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403

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

Status code 97 Re: "file integrity verified" - do I care?

[Frank Swarbrick]

>>> On 9/4/2009 at 6:01 PM, in message
>>
> It would be interesting to see what would happen if someone with their
> management's full backing filed an APAR and a protest to ISO and ANSI
> claiming that the status code 97 in fact makes IBM COBOL
> non-compliant.  I THINK this travesty came in with the implicit verify
> that came with DF/EF.  Unfortunately nobody (including myself) clued
> to the broken as designed violation of the standard and raise a big
> enough stink at the time.  Either a compile or LE option to return 00
> instead of 97 would be an adequate fix.  I can think of a number of
> shops where this would be very useful.
> 
> In terms of lost time and disruption to production, this anomaly has
> probably cost IBM shops collectively millions of dollars in the past
> 20 - 30 years.

I had not considered filing a PMR (APAR, whatever) about this.  I will discuss 
this with my management.  Thanks for the idea!

Frank




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403

--
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: "file integrity verified" - do I care?

[Savor, Tom]

>For any (all) of you who "dislike" the file status "97" - especially
anyone involved in a >VSE to MVS conversion (where this seems to be a
medium-high priority problem), >please consider submitting a  "Marketing
Request"
>to IBM and reference the existing SHARE requirement:

 >SSLNGC0413615  Optional (ISO 2002) "0x" file-status code for current
"97"

Yes, it was very aggravating when status code of "97" appeared on the
landscape.
But, to be honest with you, all of our I/O routines are coded to treat
"00" and "97" the same. So for IBM to remove "97" as a status code will
no real effect.

If this status code had just appeared, I would say "yes" it would help
save some needless coding, but since it's been around so long...we
already have coded around it.
And management won't spend the money to remove it...no money to get
gained. 

Thanks,
Tom Savor

_

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. 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

Status code 97 Re: "file integrity verified" - do I care?

[Clark Morris]

On 4 Sep 2009 14:46:20 -0700, in bit.listserv.ibm-main you wrote:

>
>
>For any (all) of you who "dislike" the file status "97" - especially anyone
>involved in a VSE to MVS conversion (where this seems to be a medium-high
>priority problem), please consider submitting a
> "Marketing Request"
>to IBM and reference the existing SHARE requirement:
>
> SSLNGC0413615  Optional (ISO 2002) "0x" file-status code for current "97" 
>
>(current status of this requirement is "RECOGNIZED")
>
>That requirement asks for an enhancement that could be selected by compiler
>or run-time option to "automatically" turn a "97" into a "0x" file status.
>(Obviously, run-time would have the advantage of "no recompile required"
>while "compile-time" would have the advantage of NOT impacting existing
>programs - without an explicit selection of the feature).
>
>  * * *
>
>To respond to one part of this thread, 
>  YES, the Standard (all past and present one) DOES explicitly state that an
>implementor defined "9x" file status *MUST* be considered "unsuccessful".
>The way that IBM "gets away" with what they do on a 97, is that the standard
>does NOT define what must happen on an "unsuccessful" I/O - when no
>declarative or file status checking is done.
>
>  * * * * 
>
>As always, doing a "marketing requirement" does NOT "guaranteed" to do
>anything more than the existing SHARE requirement does.  However, it does
>tell IBM that this is really impacting existing customers and lets IBM judge
>how "serious" the impact it.
>
It would be interesting to see what would happen if someone with their
management's full backing filed an APAR and a protest to ISO and ANSI
claiming that the status code 97 in fact makes IBM COBOL
non-compliant.  I THINK this travesty came in with the implicit verify
that came with DF/EF.  Unfortunately nobody (including myself) clued
to the broken as designed violation of the standard and raise a big
enough stink at the time.  Either a compile or LE option to return 00
instead of 97 would be an adequate fix.  I can think of a number of
shops where this would be very useful.

In terms of lost time and disruption to production, this anomaly has
probably cost IBM shops collectively millions of dollars in the past
20 - 30 years.

--
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: "file integrity verified" - do I care?

[Frank Swarbrick]

Thanks Bill!!!  I'm going to start typing right now.  :-)

Frank

On 9/4/2009 at 3:43 PM, in message <85ce438477b040f1aa47a93d19a78...@wmk>, Bill
Klein  wrote:
<> previous comments in this thread snipped>
> 
> For any (all) of you who "dislike" the file status "97" - especially anyone
> involved in a VSE to MVS conversion (where this seems to be a medium-high
> priority problem), please consider submitting a
>  "Marketing Request"
> to IBM and reference the existing SHARE requirement:
> 
>  SSLNGC0413615  Optional (ISO 2002) "0x" file-status code for current "97" 
> 
> (current status of this requirement is "RECOGNIZED")
> 
> That requirement asks for an enhancement that could be selected by compiler
> or run-time option to "automatically" turn a "97" into a "0x" file status.
> (Obviously, run-time would have the advantage of "no recompile required"
> while "compile-time" would have the advantage of NOT impacting existing
> programs - without an explicit selection of the feature).
> 
>   * * *
> 
> To respond to one part of this thread, 
>   YES, the Standard (all past and present one) DOES explicitly state that an
> implementor defined "9x" file status *MUST* be considered "unsuccessful".
> The way that IBM "gets away" with what they do on a 97, is that the standard
> does NOT define what must happen on an "unsuccessful" I/O - when no
> declarative or file status checking is done.
> 
>   * * * * 
> 
> As always, doing a "marketing requirement" does NOT "guaranteed" to do
> anything more than the existing SHARE requirement does.  However, it does
> tell IBM that this is really impacting existing customers and lets IBM judge
> how "serious" the impact it.
> 
> --
> 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 electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403

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

"file integrity verified" - do I care?

[Bill Klein]

For any (all) of you who "dislike" the file status "97" - especially anyone
involved in a VSE to MVS conversion (where this seems to be a medium-high
priority problem), please consider submitting a
 "Marketing Request"
to IBM and reference the existing SHARE requirement:

 SSLNGC0413615  Optional (ISO 2002) "0x" file-status code for current "97" 

(current status of this requirement is "RECOGNIZED")

That requirement asks for an enhancement that could be selected by compiler
or run-time option to "automatically" turn a "97" into a "0x" file status.
(Obviously, run-time would have the advantage of "no recompile required"
while "compile-time" would have the advantage of NOT impacting existing
programs - without an explicit selection of the feature).

  * * *

To respond to one part of this thread, 
  YES, the Standard (all past and present one) DOES explicitly state that an
implementor defined "9x" file status *MUST* be considered "unsuccessful".
The way that IBM "gets away" with what they do on a 97, is that the standard
does NOT define what must happen on an "unsuccessful" I/O - when no
declarative or file status checking is done.

  * * * * 

As always, doing a "marketing requirement" does NOT "guaranteed" to do
anything more than the existing SHARE requirement does.  However, it does
tell IBM that this is really impacting existing customers and lets IBM judge
how "serious" the impact it.

--
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: "file integrity verified" - do I care?

[Howard Brazee]

We had a vendor supplied I/O program that was used all over the place
- which did not check for status '97', but when the status returned
was not '0x', returned its own error status.

It was used way too often to go through the costs of tests (this is
before OO changed testing standards), so we lived with it until we
slowly got rid of our VSAM files.

Ugly, ugly, ugly.

--
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: "file integrity verified" - do I care?

[Clark Morris]

On 3 Sep 2009 18:40:03 -0700, in bit.listserv.ibm-main you wrote:

>let's take some possibilities.
>1. the verify succeeds - there are no hanging end of file or paritial
>splits or fatal errors.  wha happened to the blocks that had not been
>written to dasd yet - well, they are gone into the bit bucket in the
>sky.
>2. the verify succeeds - and operations is rerunning the exact same
>job - some of the updates are going double update - some inserts will
>fail as duplicate, totals have wrong values.
>
>status 97 means that a job abended and nothing has been done to
>recover the file.  That is usually not a good thing.

Given that the general action for a successful verify is to continue
as if nothing happened, it would be interesting to see if someone took
the approach of trying to get a PMR against this 20 - 30 year old
problem.  Since 97 is implementer defined unless the standard
specifically states that a 9x status code is unsuccessful, I  doubt
this would work (I will try to remember to look this up).  I also
recall having to this for COBOL 74 so it goes back to at least ICF
VSAM.  It also shows that as a community we are sheep for having put
up with this monstrosity for this length of time.  If I were still
active in SHARE, I would give a requirement to return status 00 for
successful implicit verify a 5 (imperative) and be willing to accept
that this could be governed by a LE option or compiler option.

--
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: "file integrity verified" - do I care?

[Gilbert Saint-Flour]

On Friday 04 September 2009 02:57, Frank Swarbrick wrote:

> ...  this file status of 97 is the "same" as status 00, except that 
> status 97 indicates that not only was the file opened successfully 
> but an implicit VERIFY was also completed successfully.

IIRC, the STATUS 97 problem dates back to the 1990s; it did not exist in OS/VS 
COBOL, but I don't remember if it applied to VS COBOL II.  And, as you said, 
this problem does not apply to VSE either but it can be a real pain, 
particularly when you convert from VSE to z/OS.  

Since 1993, I developed several solutions to fix this problem in dozens of 
VSE/MVS conversion projects; these solutions belong to 3 different types:

1. automatically update MVS COBOL source programs to check SK97

2. CALL a sub-routine to VERIFY VSAM data sets that need it; source-code 
change is optional.

3. add a utility step at the beginning of each job which will VERIFY all the 
VSAM files that need it; no source-code change.

Type 1 is what people generally prefer, but it is costly in terms of effort, 
and wrong results are likely during testing and early production.

Type 2 requires little work (a few hours) and works perfectly.

Type 3 also works perfectly, but it requires that you modify the JCL.  If you 
have an INCLUDE MEMBER=JOBLIB in your jobs, adding an EXEC stmt is probably 
not a problem.

What's the best solution? Well, it depends.   
If you're interested, let me know .

-- 
 Gilbert Saint-Flour
 GSF Software
 http://gsf-soft.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: "file integrity verified" - do I care?

[Mike Bell]

let's take some possibilities.
1. the verify succeeds - there are no hanging end of file or paritial
splits or fatal errors.  wha happened to the blocks that had not been
written to dasd yet - well, they are gone into the bit bucket in the
sky.
2. the verify succeeds - and operations is rerunning the exact same
job - some of the updates are going double update - some inserts will
fail as duplicate, totals have wrong values.

status 97 means that a job abended and nothing has been done to
recover the file.  That is usually not a good thing.

-- 
Mike

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

"file integrity verified" - do I care?

[Frank Swarbrick]

Warning: This is another one of my "bitchy" messages complaining about things 
that people have been "getting along" with for many years.  You have been 
warned, so please don't complain back to me if you think I'm concerned over 
nothing.  Just don't read the rest of the message if this bothers you.


Some Cobol programmers know about the dreaded "status 97" issue.  Essentially, 
if a KSDS is opened for I-O and the job is cancelled before the file is 
successfully closed then the next time the file is opened VSAM will do an 
implicit VERIFY.  If the VERIFY succeeds then a file status of '97' (rather 
than '00') is returned to the Cobol program.  From what I can tell from 
googling, if the file *is in fact damaged* then it will not return '97' but 
will rather return a different file status, one that indicates the file was not 
succesfully opened.  I've not been able to recreate the latter situation, so 
I'm not sure what file status that would be.

All this being said, the point is that this file status of 97 is the "same" as 
status 00, except that status 97 indicates that not only was the file opened 
successfully but an implicit VERIFY was also completed successfully.

The question I have is, "why do I care?"  Of what benefit is it for me, as a 
Cobol programmer, to know this information.  Should I be doing something with 
it?  Already on the syslog do we see messages such as this:
IEC161I 056-084,VSAMIO,STEP00,FILE1,,,FJS.MYKSDS,FJS.MYKSDS.DATA, 744 
IEC161I CATALOG.USERCAT.PPCAT 
IEC161I 056-084,VSAMIO,STEP00,FILE1,,,FJS.MYKSDS,FJS.MYKSDS.INDEX, 745
IEC161I CATALOG.USERCAT.PPCAT 
IEC161I 062-086,VSAMIO,STEP00,FILE1,,,FJS.MYKSDS,FJS.MYKSDS.DATA, 746 
IEC161I CATALOG.USERCAT.PPCAT 

That's fine.  But is there something I should be doing?  I can't think of 
anything.

So my question now is, why should status 97 even exist?  The Cobol standard 
says that any file status with the first of the two characters being the 
character '0' was a successful I/O.  According to the Cobol 2002 standard (I 
don't have the Cobol 85 standard available):
"Certain classes of I-O status values indicate fatal exception conditions. 
These are: any that begin with the digit 3 or 4, and any that begin with the 
digit 9 that the implementor defines as fatal."

So in this case IBM has chosen to make status '97' not only "not fatal", but in 
fact absolutely successful.  I am unable to determine of the standard actually 
allows a '9' error to be considered successful, or if it should only be a 
non-fatal or fatal error.

Anyway, the point(!) to all of this is I would like to make a requirement to 
IBM Enterprise Cobol to have an option to no longer set a file status of 97 
when this occurs, but rather to set the file status to 00.

While it would be nice to say that we simple handle 97 the same as 00, this is 
not the case.  We are a VSE shop migrating to z/OS, and while '97' is 
documented as a possibility, I can't recall a time that we ever actually got 
one.  I have tried doing things to cause it to occur on VSE (such as canceling 
and flushing the job) but it never occurs.  In any case I dare say 90% of our 
programs do not "expect" a file status of 97.

So since 97 doesn't seem to be useful I am trying to make sure it never occurs. 
 Thus the requirement.  In our testing we've already run in to it several times.

Yes, I realize we "should" simply change the programs to conform to the IBM 
compiler.  But my feeling is that it's the status 97 that does not "conform" to 
the Cobol standard, so Enterprise Cobol should, as an option at least, be made 
to conform, and thus eliminate our need to conform to a non-conforming 
implementation.  (And even if status 97 does technically conform, it's still 
annoying.  )

Any thoughts?  It is interesting to note that at the assembler level this 
situation appears to *not* cause the OPEN macro to set R15 to something other 
than 0.  The VSAM feedback code (ACBERFLG?) is set to 118 (X'76'), but that is 
it.  R15 is set to 0.  With Cobol, along with the FILE STATUS code of 97 I also 
get:
VSAM return code   0008
VSAM function code 
VSAM feedback code 0076

This seems to say that VSAM set R15 to 8, but the assembler program I wrote to 
test this shows R15=0.  (I am not an assembler programmer, so I could have 
screwed it up.  I'd be glad to post it if anyone wants to validate it.)  So is 
the Cobol runtime "making up" this VSAM return code of 8?  Hmmm...

What do assembler programs generally do?  Do you assume if the open returned a 
0 that you're good to go?  Do you ever check ACBERFLG if the I/O was successful 
(R15=0)?  I'd be fine with the "VSAM status" codes still being set (if the 
program has specified to receive them) as long as the primary status code is 
00.  (Yes, currently the VSAM status code field is "undefined" if the primary 
status code is set to 00.  I do