-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
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
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 al5va59bn9hkub0dhg8n0sdds61le2j...@4ax.com, on 09/15/2009
at 07:31 AM, Howard Brazee howard.bra...@cusys.edu said:
What am I missing?
The possibility that the application
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
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
In al5va59bn9hkub0dhg8n0sdds61le2j...@4ax.com, on 09/15/2009
at 07:31 AM, Howard Brazee howard.bra...@cusys.edu 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
On 16 Sep 2009 10:53:02 -0700, in bit.listserv.ibm-main you wrote:
In al5va59bn9hkub0dhg8n0sdds61le2j...@4ax.com, on 09/15/2009
at 07:31 AM, Howard Brazee howard.bra...@cusys.edu said:
What am I missing?
The possibility that the application that failed to close the file might
have had
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?
-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
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
On Tue, 15 Sep 2009 08:43:31 -0600 Howard Brazee howard.bra...@cusys.edu
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
Binyamin Dissen wrote:
On Tue, 15 Sep 2009 08:43:31 -0600 Howard Brazee howard.bra...@cusys.edu
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
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
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
On Tue, 15 Sep 2009 09:08:51 -0600 Steve Comstock st...@trainersfriend.com
wrote:
:Binyamin Dissen wrote:
: On Tue, 15 Sep 2009 08:43:31 -0600 Howard Brazee howard.bra...@cusys.edu
: wrote:
: :On 15 Sep 2009 06:59:56 -0700, dennis.ro...@lmco.com (Roach, Dennis ,
: :N-GHG) wrote:
: :
On 9/15/2009 at 9:21 AM, in message
listserv%200909151021029017.0...@bama.ua.edu, Erik Janssen
erik.jans...@ing.nl 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
In jhkka59q0bavje123mfp9mp5cgdnmhm...@4ax.com, on 09/11/2009
at 07:37 AM, Howard Brazee howard.bra...@cusys.edu 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
In 4aa0113f.6f0f.008...@efirstbank.com, on 09/03/2009
at 06:55 PM, Frank Swarbrick frank.swarbr...@efirstbank.com 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
In 85ce438477b040f1aa47a93d19a78...@wmk, on 09/04/2009
at 04:43 PM, Bill Klein wmkl...@ix.netcom.com 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
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
On Sat, 5 Sep 2009 07:19:56 -0600, Frank Swarbrick
frank.swarbr...@efirstbank.com wrote:
On 9/4/2009 at 7:06 PM, in message
6ee7eb97db511b45b13630c3361751930141a...@cmbfisltc08.fnfis.com, Savor, Tom
tom.sa...@fnis.com wrote:
For any (all) of you who dislike the file status 97 - especially
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
On 9/4/2009 at 7:06 PM, in message
6ee7eb97db511b45b13630c3361751930141a...@cmbfisltc08.fnfis.com, Savor, Tom
tom.sa...@fnis.com 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
On 9/5/2009 at 7:57 AM, in message
listserv%200909050857588007.0...@bama.ua.edu, Mark Zelden
mark.zel...@zurichna.com wrote:
On Sat, 5 Sep 2009 07:19:56 -0600, Frank Swarbrick
frank.swarbr...@efirstbank.com wrote:
On 9/4/2009 at 7:06 PM, in message
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
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
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
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
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
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
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 wmkl...@ix.netcom.com wrote:
previous comments in this thread snipped
For any (all) of you who dislike the file status 97 - especially anyone
On 4 Sep 2009 14:46:20 -0700, in bit.listserv.ibm-main you 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
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
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.
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
35 matches
Mail list logo
