EOF Technique

[Jack Straw]

I'm an experienced programmer, trying to get up to speed on Cobol.
I've read the source to a few programs from various places, and I have
a methodology question.

When reading a file to it's end, most of the code i'm reading is along
these lines:

1000-read file.
read filename into varname
at end move 'y' into ws-eof-switch
end-read

Then, later on, the programmer is looking at ws-eof-switch.

Why would one do that instead of (what makes more sense to me)
declaring "file status is ws-file-status" in file control, and then
looking at the file status after the read. That will give a return
code telling exactly what happened during the I/O and not a simple
boolean.

Am I missing something, or is it just dumb luck that I have weird code
examples?

The first technique seems very common.

[LX-i]

Post by Jack Straw
I'm an experienced programmer, trying to get up to speed on Cobol.
I've read the source to a few programs from various places, and I have
a methodology question.
When reading a file to it's end, most of the code i'm reading is along
1000-read file.
read filename into varname
at end move 'y' into ws-eof-switch
end-read
Then, later on, the programmer is looking at ws-eof-switch.
Why would one do that instead of (what makes more sense to me)
declaring "file status is ws-file-status" in file control, and then
looking at the file status after the read. That will give a return
code telling exactly what happened during the I/O and not a simple
boolean.

The way you see above is what is in most COBOL books. And, it's been my
experience that unless you're looking for some really weird stuff, this
is acceptable. Many compilers require the "at end" clause on a read
statement (not sure if this can be traced back to the ANSI COBOL
standard or not), so it's convenient to put it there.

However, people who are interested in developing more robust I/O error
handling do exactly what you say - declare a status variable, which they
can check for a host of conditions, and handle accordingly. :)

Post by Jack Straw
The first technique seems very common.

Si, señor...
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ AIM: LXi0007 ~
~ _____ / \ | ~ E-mail: ***@Netscape.net ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please post if you wish to be contacted privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[JerryMouse]

Post by Jack Straw
I'm an experienced programmer, trying to get up to speed on Cobol.
I've read the source to a few programs from various places, and I have
a methodology question.
When reading a file to it's end, most of the code i'm reading is along
1000-read file.
read filename into varname
at end move 'y' into ws-eof-switch
end-read
Then, later on, the programmer is looking at ws-eof-switch.
Why would one do that instead of (what makes more sense to me)
declaring "file status is ws-file-status" in file control, and then
looking at the file status after the read. That will give a return
code telling exactly what happened during the I/O and not a simple
boolean.
Am I missing something, or is it just dumb luck that I have weird code
examples?
The first technique seems very common.

It is common. It was the only technique to use before file status (about
1960 or so) and continues by inertia.

The AT END test is often sufficient but, obviously, the file being absent or
having wrong length records or being fucia instead of teal won't get
detected by the AT END condition.

Another technique you may want to try is a 'priming' read, viz:

Open INPUT IN-FILE.
Read IN-FILE.
Perform until IN-FS not = '00'
Perform INPUT-ROUTINE
Read IN-FILE
end-perform.
Close IN-FILE.

[Michael Mattias]

Post by JerryMouse

Post by Jack Straw
I'm an experienced programmer, trying to get up to speed on Cobol.
I've read the source to a few programs from various places, and I have
a methodology question.

The AT END test is often sufficient but, obviously, the file being absent or
having wrong length records or being fucia instead of teal won't get
detected by the AT END condition.

If the file is not present, the OPEN will fail; the only way to test for
this is FILE STATUS.

PS: If you keep studying, you'll also start to see a lot of
READ filename
INVALID KEY
do something

The conditions under which INVALID KEY is true may also be trapped using
FILE STATUS.


MCM

[Thane Hubbell]

Post by Michael Mattias
If the file is not present, the OPEN will fail; the only way to test for
this is FILE STATUS.

Are you really SURE of this? I think there is another. Bonus points
awarded to those who know.

[Rick Smith]

Post by Thane Hubbell

Post by Michael Mattias
If the file is not present, the OPEN will fail; the only way to test for
this is FILE STATUS.

Are you really SURE of this? I think there is another. Bonus points
awarded to those who know.

Are you referring to OPTIONAL to prevent the failure, or
USE to catch it?

[Michael Mattias]

Post by Rick Smith

Post by Thane Hubbell

Post by Michael Mattias
If the file is not present, the OPEN will fail; the only way to test for
this is FILE STATUS.

Are you really SURE of this? I think there is another. Bonus points
awarded to those who know.

Are you referring to OPTIONAL to prevent the failure, or
USE to catch it?

I knew my statement would be challenged, but I had thought about it in
advance.

USE (DECLARATIVES) can be used to 'catch' an OPEN failure, however, you
really cannot do anything intelligent in the USE procedure without
interrogating the FILE STATUS *in that procedure*. The OPEN can fail for
any number of reasons and direct the flow to the USE procedure; but
programmer action is dependent on the *reason* for the open failure. If the
reason for the open failure is immaterial, I suppose you could skip file
status and just code some generic exit when/if control passes to the USE
procedure, but that is wimp code, and the kind of code up with which I shall
not put.

OPTIONAL will NOT (that's 'not') prevent an OPEN failure on 'file not
present.' It may prevent an immediate ABEND in the IBM batch environment,
but that does not make the OPEN successful!

MCM

[Harley]

"Michael Mattias" <***@gte.net> wrote in message news:CBSPa.16138$***@newssrv26.news.prodigy.com...
|
|
| "Rick Smith" <***@mfi.net> wrote in message
| news:***@corp.supernews.com...
| > Thane Hubbell <***@softwaresimple.com> wrote in message
| > news:***@posting.google.com...
| > > "Michael Mattias" <***@gte.net> wrote in message
| > news:<K9xPa.15411$***@newssrv26.news.prodigy.com>...
| > >
| > > > If the file is not present, the OPEN will fail; the only way to test
| for
| > > > this is FILE STATUS.
| > > Are you really SURE of this? I think there is another. Bonus points
| > > awarded to those who know.
| >
| > Are you referring to OPTIONAL to prevent the failure, or
| > USE to catch it?
|
| I knew my statement would be challenged, but I had thought about it in
| advance.
|
| USE (DECLARATIVES) can be used to 'catch' an OPEN failure, however, you
| really cannot do anything intelligent in the USE procedure without
| interrogating the FILE STATUS *in that procedure*. The OPEN can fail for
| any number of reasons and direct the flow to the USE procedure; but
| programmer action is dependent on the *reason* for the open failure. If
the
| reason for the open failure is immaterial, I suppose you could skip file
| status and just code some generic exit when/if control passes to the USE
| procedure, but that is wimp code, and the kind of code up with which I
shall
| not put.
|
| OPTIONAL will NOT (that's 'not') prevent an OPEN failure on 'file not
| present.' It may prevent an immediate ABEND in the IBM batch environment,
| but that does not make the OPEN successful!
|

Would you then you get a logic error on the first read?

[Michael Mattias]

Post by Harley
| > >
| > > > If the file is not present, the OPEN will fail; the only way to test
| for
| OPTIONAL will NOT (that's 'not') prevent an OPEN failure on 'file not
| present.' It may prevent an immediate ABEND in the IBM batch environment,
| but that does not make the OPEN successful!
|
Would you then you get a logic error on the first read?

NO - because if the OPEN fails, the READ should never be attempted!

But seriously ladies and germs, the read will fail on "file not open" or
whatever the verbage is on the target system.

MCM

[Rick Smith]

Post by Michael Mattias

Post by Harley
| > >
| > > > If the file is not present, the OPEN will fail; the only way to

test

Post by Harley
| for
| OPTIONAL will NOT (that's 'not') prevent an OPEN failure on 'file not
| present.' It may prevent an immediate ABEND in the IBM batch

environment,

Post by Harley
| but that does not make the OPEN successful!
|
Would you then you get a logic error on the first read?

NO - because if the OPEN fails, the READ should never be attempted!
But seriously ladies and germs, the read will fail on "file not open" or
whatever the verbage is on the target system.

These are quotes from GC28-6396-5, IBM OS Full American
National Standard COBOL, which was based on X3.23-1968.

For the SELECT [OPTIONAL] statement,

"The keyword OPTIONAL may be specified only for input
files accessed sequentially. It is required for input files that
are not necessarily present each time the object program
is executed. When a file is not present at object time, the
first READ statement for that file causes control to be
passed to the imperative-statement following the key words
AT END."

This is followed immediately by the "grayed" text,

"However, OPTIONAL need not be specified and will be
treated as a comment, since this function is performed by the
operating system through the DD statement with the DUMMY
or NULLFILE parameter."

For the OPEN statement,

"If a sequential input file is designated with the OPTIONAL
clause in the File Control paragraph of the Environment
Division, the clause is treated as comments. The desired
effect is achieved by specifying the DUMMY or NULLFILE
parameter in the DD statement for the file. If the parameter
is specified, the first READ statement for this file causes
control to be passed to the imperative statement after the
key words AT END."

Mr Mattias, for more than thirty years, the effect of OPTIONAL
has been defined. For the conditions assumed, the OPEN
will be successful and the first read will not fail.

I do wonder whether the use of DUMMY in one environment
caused this information to be lost to some.

[Michael Mattias]

Post by Rick Smith
Mr Mattias, for more than thirty years, the effect of OPTIONAL
has been defined. For the conditions assumed, the OPEN
will be successful and the first read will not fail.

OK, so I'm a tad rusty on specifics. I was trying to be generic, not locked
into what happens specifically in the IBM mainframe environment.

The original question was, "why use "AT END" versus "FILE STATUS?"

Somehow that begat, "what if the file is not present?"

That got me going on the merits of using FILE STATUS to query the OPEN
rather than waiting for a READ or WRITE failure.. what I would consider
superior programming practice.

Besides: when a READ results in the satisfaction of AT END, the READ *DID*
fail!

MCM

[Rick Smith]

Post by Michael Mattias

Post by Rick Smith
Mr Mattias, for more than thirty years, the effect of OPTIONAL
has been defined. For the conditions assumed, the OPEN
will be successful and the first read will not fail.

OK, so I'm a tad rusty on specifics. I was trying to be generic, not locked
into what happens specifically in the IBM mainframe environment.
The original question was, "why use "AT END" versus "FILE STATUS?"
Somehow that begat, "what if the file is not present?"
That got me going on the merits of using FILE STATUS to query the OPEN
rather than waiting for a READ or WRITE failure.. what I would consider
superior programming practice.

Mr Mattias, I agree that the use of file status for creating
robust programs is a superior programming practice and
have used file status on occasion for that purpose. I have
not used file status at all times and relied upon standard
COBOL behavior when robustness was not required.

Post by Michael Mattias
Besides: when a READ results in the satisfaction of AT END, the READ *DID*
fail!

It would seem that we disagree on what 'failure' means.

[Howard Brazee]

Post by Michael Mattias
The original question was, "why use "AT END" versus "FILE STATUS?"

Because it is closer to the original spirit of COBOL. Words that make sense,
as opposed cryptic numbers.

(I generally use FILE STATUS, but I don't care for it on the above grounds).

[Patrick Herring]

Post by Howard Brazee

Post by Michael Mattias
The original question was, "why use "AT END" versus "FILE STATUS?"

Because it is closer to the original spirit of COBOL. Words that make
sense, as opposed cryptic numbers.
(I generally use FILE STATUS, but I don't care for it on the above grounds).

"88" levels.

A technique I used to use was to have every file use the same
file-status field, which had loads of named values. Didn't always work -
sometime you had to keep the knowledge of a particular file reaching its
end before another - but the generic code was usefully portable across
programs.

When the "SET condition-name TO TRUE" came in my code lost almost all
its cryptic numbers.

[Howard Brazee]

Post by Patrick Herring

Post by Howard Brazee
(I generally use FILE STATUS, but I don't care for it on the above grounds).

"88" levels.

Which I use. But we don't have shop and certainly not industry standard 88
levels the way we have IDMS return codes.

[c***@cix.compulink.co.uk]

Post by d***@panix.com
[snip]

Post by Patrick Herring
"88" levels.

Which I use. But we don't have shop and certainly not industry
standard 88 levels the way we have IDMS return codes.

A pity really - as I recall the IDMS 88 levels were /very/ well put
together.

I can't help feeling that there should be some sort of "standard copy
library" (think of stdio.h) at, say, the machine/compiler vendor level for
stuff like this -- the new standards make it easy to use unique names for
each file, something like:

01 WB-File-Control-Stuff.

Copy STDSEQFS with prefix "WB-IP-Master-". *> I know the syntax is off
*> but you get the idea.
Which would yield something like

05 WB-IP-Master-Status Pic X(002).
88 WB-IP-Master-Available Value '00'.
88 WB-IP-Master-EOF Value '10'.
... etc.

Of course, the cogent argument against this (on the mainframe platform at
least - and for sequential files only!) is that a sweeping majority of
cases just don't need anything cleverer than the AT END clause - the IBM
diagnostics are actually preferable for the error cases, because (a) we
all know how careful people tend to be when coding error messages
(i.e. not at all, and they don't test the damned things either) and (b)
they often present more information than is readily available without
trawling through control blocks.

Expanding on that thought, it's a pity we can't tell COBOL which cockups
we want to deal with and which ones we're happy to leave to the runtime to
handle - preferably in some _very_ informative and obvious way (like
ABending after producing a helpful message). Let's face it, 99% of
programs need only know about the cases which are admirably dealt with by
AT END and INVALID KEY (and their mirror images, obviously) - anything
else can (and to my mind _should_) usefully be left to the runtime. Much
easier to deal with those 3am phone calls if the error messages are at
least consistent...

Any thoughts?

Pete.

[***@cix.compulink.co.uk]

[Richard Plinston]

Post by Michael Mattias
OPTIONAL will NOT (that's 'not') prevent an OPEN failure on 'file not
present.' It may prevent an immediate ABEND in the IBM batch environment,
but that does not make the OPEN successful!

Well, one of us completely misunderstands optional files.

Given a file does not exist and is specified as OPTIONAL then an OPEN will
be _successful_ with a file-status of '05' and all READs will take AT END
or INVALID KEY and/or report a status of '10' or '23' as appropriate.

If a file is not present is OPTIONAL and OPENed I-O then it {should} be
created. If it is not OPTIONAL then it will fail to OPEN. (MF has
extension to treat I-O files as OPTIONAL automatically).

What other point would there be to having it OPTIONAL.

[Peter E.C. Dashwood]

Well, ah declare !

And there are still others if you are using certain "environments"...(CICS,
etc.)

MORAL: Avoid saying ANYTHING is the "ONLY way"...

Invariably, when computer people say this, what they mean is: "This is the
only way _I_ can think of..."
(And sometimes they lie because they can't be bothered doing it by another
way, or it is an otherwise unattractive proposition...)

Pete.

Post by Thane Hubbell

Post by Michael Mattias
If the file is not present, the OPEN will fail; the only way to test for
this is FILE STATUS.

Are you really SURE of this? I think there is another. Bonus points
awarded to those who know.

[LX-i]

Post by Thane Hubbell

Post by Michael Mattias
If the file is not present, the OPEN will fail; the only way to test for
this is FILE STATUS.

Are you really SURE of this? I think there is another. Bonus points
awarded to those who know.

The Code Type clause?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ AIM: LXi0007 ~
~ _____ / \ | ~ E-mail: ***@Netscape.net ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please post if you wish to be contacted privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Joe Zitzelberger]

Post by Thane Hubbell

Post by Michael Mattias
If the file is not present, the OPEN will fail; the only way to test for
this is FILE STATUS.

Are you really SURE of this? I think there is another. Bonus points
awarded to those who know.

Depends on environment and open mode. Sometimes the file will be
created for you.

[Chuck Stevens]

Post by JerryMouse
It is common. It was the only technique to use before file status (about
1960 or so) and continues by inertia.

Actually, it looks to me like FILE-STATUS didn't show up in *standard*
COBOL until 1974. See ANSI X3.23-1974 Page XIV-13 Item 7. It was
made available in some implementations of '68 COBOL as an
ANSI-74-compatible extension.

-Chuck Stevens

[Ubiquitous]

Post by JerryMouse
Open INPUT IN-FILE.
Read IN-FILE.
Perform until IN-FS not = '00'
Perform INPUT-ROUTINE
Read IN-FILE
end-perform.
Close IN-FILE.

Ooohhh, I _hate_ those!

[Frederico Fonseca]

Post by Ubiquitous

Post by JerryMouse
Open INPUT IN-FILE.
Read IN-FILE.
Perform until IN-FS not = '00'
Perform INPUT-ROUTINE
Read IN-FILE
end-perform.
Close IN-FILE.

Ooohhh, I _hate_ those!

You're not alone.




Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

[Howard Brazee]

Post by Ubiquitous

Post by JerryMouse
Open INPUT IN-FILE.
Read IN-FILE.
Perform until IN-FS not = '00'
Perform INPUT-ROUTINE
Read IN-FILE
end-perform.
Close IN-FILE.

Ooohhh, I _hate_ those!

I love those.

[Robert Wagner]

It is, in the past it was not uncommon the let the program ABEND rather than
handle the error in the program by not specifying FILE STATUS.
(If you specified FILE STATUS, and you missed the error, the program would
keep chugging along.)

Which is exactly what your example, below, does.

Things are changing, in some shops I've found that if you are missing a "DD"
statement for an output file, the system allocates a temporary file. (The DD
statement specifies the physical file associated with the Logical file in
the SELECT).
Even if you use the file status, you can still use AT END.
PERFORM UNTIL EOF-FILE
READ SomeFile
AT END
SET EOF-FILE to TRUE
NOT AT END
PERFORM 0000-PROCESS-REC
END-READ
END-PERFORM.

What if some other exception occurs, like sector not found or sector corrupted?
You said he could use file status and then provided an example which doesn't
check it. Tsk tsk. The code should read something like this.

05 file-status pic x(02).
88 any-exception value '10' thru high-values.
88 end-of-file value '10' thru '19'.

read SomeFile
perform until any-exception
perform process-record
read SomeFile
end-perform
if not end-of-file
display 'error ' file-status ' on SomeFile'
goback returning (whatever)
end-if

[Michael Mattias]

Even if you use the file status, you can still use AT END.
PERFORM UNTIL EOF-FILE
READ SomeFile
AT END
SET EOF-FILE to TRUE
NOT AT END
PERFORM 0000-PROCESS-REC
END-READ
END-PERFORM.

OR...without setting flags..

PERFORM
READ SomeFile
AT END
EXIT PERFORM
NOT AT END
PERFORM 0000-PROCESS-REC
END-READ
END-PERFORM.

MCM

[Peter E.C. Dashwood]

Post by Michael Mattias
OR...without setting flags..
PERFORM
READ SomeFile
AT END
EXIT PERFORM
NOT AT END
PERFORM 0000-PROCESS-REC
END-READ
END-PERFORM.

Michael,

I really like that. It is very elegant. Wish we'd had it 30 years ago...
Hardly ever write Batch COBOL any more but I promise I'll use this next
chance I get.

Thanks,

Pete.

Post by Michael Mattias
MCM

[Richard Plinston]

Post by Michael Mattias
OR...without setting flags..
PERFORM
READ SomeFile
AT END
EXIT PERFORM
NOT AT END
PERFORM 0000-PROCESS-REC
END-READ
END-PERFORM.

Except that will on do one READ, it needs 'PERFORM UNTIL hell-freezes-over'
or similar.

[Michael Mattias]

Duh.

Post by Richard Plinston

Post by Michael Mattias
OR...without setting flags..
PERFORM
READ SomeFile
AT END
EXIT PERFORM
NOT AT END
PERFORM 0000-PROCESS-REC
END-READ
END-PERFORM.

Except that will on do one READ, it needs 'PERFORM UNTIL

hell-freezes-over'

Post by Richard Plinston
or similar.

[Peter E.C. Dashwood]

Well spotted Richard.

You are right and the rest of us missed it.

It is still an elegant "no-flags" piece of code.

Pete.

Post by Richard Plinston

Post by Michael Mattias
OR...without setting flags..
PERFORM
READ SomeFile
AT END
EXIT PERFORM
NOT AT END
PERFORM 0000-PROCESS-REC
END-READ
END-PERFORM.

Except that will on do one READ, it needs 'PERFORM UNTIL

hell-freezes-over'

Post by Richard Plinston
or similar.

[Harley]

"Robert Wagner" <***@wagner.net> wrote in message news:***@news.optonline.com...
| "Harley" <***@worldnet.att.net> wrote:
|
|
| >On the IBM mainframe:
| >It is, in the past it was not uncommon the let the program ABEND rather
than
| >handle the error in the program by not specifying FILE STATUS.
| >(If you specified FILE STATUS, and you missed the error, the program
would
| >keep chugging along.)
|
| Which is exactly what your example, below, does.

NO it doesn't.
It will abend if file status isn't specified, and I'll get an error message
with the file status from the system. (on the mainframe). It's a freebie!

|
| >Things are changing, in some shops I've found that if you are missing a
"DD"
| >statement for an output file, the system allocates a temporary file. (The
DD
| >statement specifies the physical file associated with the Logical file in
| >the SELECT).
| >
| >Even if you use the file status, you can still use AT END.
| >
| >Here's another sample:
| >PERFORM UNTIL EOF-FILE
| > READ SomeFile
| > AT END
| > SET EOF-FILE to TRUE
| > NOT AT END
| > PERFORM 0000-PROCESS-REC
| > END-READ
| >END-PERFORM.
|
| What if some other exception occurs, like sector not found or sector
corrupted?

On the mainframe, you don't get sector not found?
You should read more carefully.

On the mainframe, the program will abend if you don't specify FILE STATUS.
Remember, it's an input file.
Output files are another story.

| You said he could use file status and then provided an example which
doesn't
| check it. Tsk tsk.

COULD doesn't mean MUST, does it?.

The original post indicated that he had a handle on file status, and he was
asking about AT END. (This guy is NOT a trainee.) I have no doubt that he
could come up with a solution using FILE STATUS without your help.
The original sample had an AT END, and I gave an example with NOT AT END.

When did you start reading minds?
If I did use FILE STATUS, I could have tested it in 0000-PROCESS-REC, and
again, if I didn't the program would ABEND on the mainframe.

|The code should read something like this.

MY example didn't need a priming read, try again.
I know you can do it, if you really try.

What does YOUR code have to do with the AT END condition?

I have an idea, why don't you read the original post, and respond to it.

|
| 05 file-status pic x(02).
| 88 any-exception value '10' thru high-values.
| 88 end-of-file value '10' thru '19'.
|
| read SomeFile
| perform until any-exception
| perform process-record
| read SomeFile
| end-perform
| if not end-of-file
| display 'error ' file-status ' on SomeFile'
| goback returning (whatever)
| end-if
|
|
|

[William M. Klein]

"Harley" <***@worldnet.att.net> wrote in message news:8MSPa.51414$***@bgtnsc05-news.ops.worldnet.att.net...
<snip>

Post by Harley
On the mainframe, the program will abend if you don't specify FILE STATUS.
Remember, it's an input file.
Output files are another story.

(Assuming IBM mainframe) -
True for QSAm
*NOT* true for VSAM (or at least not ALWAYS true for VSAM)

[Harley]

"William M. Klein" <***@ix.netcom.com> wrote in message news:bep3bf$18v$***@slb6.atl.mindspring.net...
|
| "Harley" <***@worldnet.att.net> wrote in message
| news:8MSPa.51414$***@bgtnsc05-news.ops.worldnet.att.net...
| >
| <snip>
| >
| > On the mainframe, the program will abend if you don't specify FILE
STATUS.
| > Remember, it's an input file.
| > Output files are another story.
| >
|
| (Assuming IBM mainframe) -
| True for QSAm
| *NOT* true for VSAM (or at least not ALWAYS true for VSAM)

To be honest, I don't know about the VSAM, because I've always used FILE
STATUS with VSAM for quite some time now.
I should have pointed out that it was for QSAM, thanks for the
correction/clarification.

[Robert Wagner]

Post by Harley
|
|
| >It is, in the past it was not uncommon the let the program ABEND rather
than
| >handle the error in the program by not specifying FILE STATUS.
| >(If you specified FILE STATUS, and you missed the error, the program
would
| >keep chugging along.)
|
| Which is exactly what your example, below, does.
NO it doesn't.
It will abend if file status isn't specified, and I'll get an error message
with the file status from the system. (on the mainframe). It's a freebie!

Don't count on it. WMK pointed out it doesn't always work on VSAM. You know what
they say about assuming.

Post by Harley
| >Even if you use the file status, you can still use AT END.
| >
| >PERFORM UNTIL EOF-FILE
| > READ SomeFile
| > AT END
| > SET EOF-FILE to TRUE
| > NOT AT END
| > PERFORM 0000-PROCESS-REC
| > END-READ
| >END-PERFORM.
|
| What if some other exception occurs, like sector not found or sector
corrupted?
On the mainframe, you don't get sector not found?
You should read more carefully.

I do read carefully. I check for errors before performing 0000-process-rec; you
don't.

Post by Harley
| You said he could use file status and then provided an example which
|doesn't check it. Tsk tsk.
COULD doesn't mean MUST, does it?.

I don't see 'could' in the above quote; I see "if you use the file status".

Post by Harley
When did you start reading minds?

I imagine mind reading would return LOTS of errors. :)

Post by Harley
MY example didn't need a priming read, try again.
I know you can do it, if you really try.

No problem.

05 file-status pic x(02).
88 end-of-file value '10' thru '19'.
88 any-exception value '10' thru high-values.

perform until any-exception
read SomeFile
if not any-exception
perform process-record
end-if
end-perform
if not end-of-file
display 'error ' file-status ' on SomeFile'
goback returning (whatever)
end-if

Do you prefer the duplicated test on any-exception?

Post by Harley
What does YOUR code have to do with the AT END condition?

No change there. It has to do with checking ALL file status exceptions, not just
end of file.

[Harley]

"Robert Wagner" <***@wagner.net> wrote in message news:***@news.optonline.com...
| "Harley" <***@worldnet.att.net> wrote:
|
| >"Robert Wagner" <***@wagner.net> wrote in message
| >news:***@news.optonline.com...
| >| "Harley" <***@worldnet.att.net> wrote:
| >|
| >|
| >| >On the IBM mainframe:
| >| >It is, in the past it was not uncommon the let the program ABEND
rather
| >than
| >| >handle the error in the program by not specifying FILE STATUS.
| >| >(If you specified FILE STATUS, and you missed the error, the program
| >would
| >| >keep chugging along.)
| >|
| >| Which is exactly what your example, below, does.
| >
| >NO it doesn't.
| >It will abend if file status isn't specified, and I'll get an error
message
| >with the file status from the system. (on the mainframe). It's a freebie!
|
| Don't count on it. WMK pointed out it doesn't always work on VSAM. You
know what
| they say about assuming.

I know, that's why alomost everybody, including me, uses FILE STATUS for
VSAM.
I should have specified SEQUENTIAL FILES, I didn't.
It was an error.

|
| >| >Even if you use the file status, you can still use AT END.
| >| >
| >| >Here's another sample:
| >| >PERFORM UNTIL EOF-FILE
| >| > READ SomeFile
| >| > AT END
| >| > SET EOF-FILE to TRUE
| >| > NOT AT END
| >| > PERFORM 0000-PROCESS-REC
| >| > END-READ
| >| >END-PERFORM.
| >|
| >| What if some other exception occurs, like sector not found or sector
| >corrupted?
| >
| >On the mainframe, you don't get sector not found?
| >You should read more carefully.
|
| I do read carefully. I check for errors before performing
0000-process-rec; you
| don't.

Why does it matter where you check?

How does a "sector not found" error occur on the mainframe?

| >| You said he could use file status and then provided an example which
| >|doesn't check it. Tsk tsk.
| >
| >COULD doesn't mean MUST, does it?.
|
| I don't see 'could' in the above quote; I see "if you use the file
status".

Read YOUR comment again.

|
| >When did you start reading minds?
|
| I imagine mind reading would return LOTS of errors. :)
|
| >MY example didn't need a priming read, try again.
| >I know you can do it, if you really try.
|
| No problem.
|
| 05 file-status pic x(02).
| 88 end-of-file value '10' thru '19'.
| 88 any-exception value '10' thru high-values.
|
| perform until any-exception
| read SomeFile
| if not any-exception
| perform process-record
| end-if
| end-perform
| if not end-of-file
| display 'error ' file-status ' on SomeFile'
| goback returning (whatever)
| end-if
|
| Do you prefer the duplicated test on any-exception?

Nope, especially since you don't need any-exception.
This is how *I* would code it. (On the mainframe)

05 file-status pic XX.
88 GOOD-READ VALUE '00'.
88 end-of-file value '10'.

SET GOOD-READ TO TRUE.
PERFORM UNTIL NOT GOOD-READ
READ SomeFile
EVALUATE TRUE
WHEN GOOD-READ
PERFORM 1000-PROCESS-RECORD
WHEN END-OF-FILE
CONTINUE
WHEN OTHER
display 'error ' file-status ' on SomeFile'
GO TO 9999-ABEND-ROUTINE
END-EVALUATE
END-PERFORM.

Seems to be a bit cleaner, and clearer than your example.
Don't you agree?

|
| >What does YOUR code have to do with the AT END condition?
|
| No change there. It has to do with checking ALL file status exceptions,
not just
| end of file.

The original question was about the AT END, what does your example have to
do with that?
Do you understand the question?

[Robert Wagner]

Post by Harley
| >| What if some other exception occurs, like sector not found or sector
| >corrupted?
How does a "sector not found" error occur on the mainframe?

The subject was "some other exception"; sector not found was but one example.

I've seen mainframes get sector not found in the good old days. Especially when
I was writing low level IO drivers and disk optimizers. :)

Post by Harley
This is how *I* would code it. (On the mainframe)
05 file-status pic XX.
88 GOOD-READ VALUE '00'.
88 end-of-file value '10'.
SET GOOD-READ TO TRUE.
PERFORM UNTIL NOT GOOD-READ
READ SomeFile
EVALUATE TRUE
WHEN GOOD-READ
PERFORM 1000-PROCESS-RECORD
WHEN END-OF-FILE
CONTINUE
WHEN OTHER
display 'error ' file-status ' on SomeFile'
GO TO 9999-ABEND-ROUTINE
END-EVALUATE
END-PERFORM.
Seems to be a bit cleaner, and clearer than your example.
Don't you agree?

Yes, except the GO TO. In real life I'd put the read and OTHER handling in a
callable program.

Technically, good-read should be '00' thru '09'. Reading an indexed file on an
alternate (illiterate, should be alternative) index returns '01' for duplicates,
on some platforms.

[Harley]

"Robert Wagner" <***@wagner.net> wrote in message news:***@news.optonline.com...
| "Harley" <***@worldnet.att.net> wrote:
|
| >"Robert Wagner" <***@wagner.net> wrote in message
|
| >| >| What if some other exception occurs, like sector not found or sector
| >| >corrupted?
|
| >How does a "sector not found" error occur on the mainframe?
|
| The subject was "some other exception"; sector not found was but one
example.
|
| I've seen mainframes get sector not found in the good old days. Especially
when
| I was writing low level IO drivers and disk optimizers. :)

It would have been more appropriate to use "bad track", or "unrecoverable
I/O error" as mainframe programmers would be more familiar with that
terminology.

|
| >This is how *I* would code it. (On the mainframe)
| >
| > 05 file-status pic XX.
| > 88 GOOD-READ VALUE '00'.
| > 88 end-of-file value '10'.
| >
| > SET GOOD-READ TO TRUE.
| > PERFORM UNTIL NOT GOOD-READ
| > READ SomeFile
| > EVALUATE TRUE
| > WHEN GOOD-READ
| > PERFORM 1000-PROCESS-RECORD
| > WHEN END-OF-FILE
| > CONTINUE
| > WHEN OTHER
| > display 'error ' file-status ' on SomeFile'
| > GO TO 9999-ABEND-ROUTINE
| > END-EVALUATE
| > END-PERFORM.
| >
| >Seems to be a bit cleaner, and clearer than your example.
| >Don't you agree?
|
| Yes, except the GO TO. In real life I'd put the read and OTHER handling in
a
| callable program.

Normally, when I code an abend routine, I will include things that pertain
to that program, like record counts, totals, and keys.
It doesn't hurt to give the programmer, who has to fix the problem, all the
information that they could use.

That means doing it at the main program level.
So, I will return from a called module, and I will abend in the main
program.

|
| Technically, good-read should be '00' thru '09'. Reading an indexed file
on an
| alternate (illiterate, should be alternative) index returns '01' for
duplicates,
| on some platforms.

That's why I said on the mainframe.
I could get an '04' which is unacceptable, because it indicates a bad record
length. (So, I wouldn't use '00' thru '09'.)

This was for a sequential file which will not get duplicates, since it has
no key.

If I wanted to use '00' thru '09', I would code it this way.

05 file-status.
88 end-of-file value '10'.
10 PIC X.
88 GOOD-READ VALUE '0'.
10 PIC X.

Here is a link to the Status Key Values, on the mainframe.

http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3lr10/6.1.8.9.1?SHE
LF=&DT=20020920180651

[Hugh Candlin]

In real life I'd put the read and OTHER handling in a callable program.
Normally, when I code an abend routine, I will include things that pertain
to that program, like record counts, totals, and keys.
It doesn't hurt to give the programmer, who has to fix the problem, all the
information that they could use.
That means doing it at the main program level.
So, I will return from a called module, and I will abend in the main
program.

You should always do this, as a matter of good programming practice.
Otherwise you run the risk of serious database corruption,
if you happen to be running in an IMS environment.

[Robert Wagner]

Post by Harley
| >This is how *I* would code it. (On the mainframe)
| >
| > 05 file-status pic XX.
| > 88 GOOD-READ VALUE '00'.
| > 88 end-of-file value '10'.
| >
| > SET GOOD-READ TO TRUE.
| > PERFORM UNTIL NOT GOOD-READ
| > READ SomeFile
| > EVALUATE TRUE
| > WHEN GOOD-READ
| > PERFORM 1000-PROCESS-RECORD
| > WHEN END-OF-FILE
| > CONTINUE
| > WHEN OTHER
| > display 'error ' file-status ' on SomeFile'
| > GO TO 9999-ABEND-ROUTINE
| > END-EVALUATE
| > END-PERFORM.
| >
| >Seems to be a bit cleaner, and clearer than your example.
| >Don't you agree?
|
| Yes, except the GO TO. In real life I'd put the read and OTHER handling in
a
| callable program.
Normally, when I code an abend routine, I will include things that pertain
to that program, like record counts, totals, and keys.
It doesn't hurt to give the programmer, who has to fix the problem, all the
information that they could use.
That means doing it at the main program level.
So, I will return from a called module, and I will abend in the main
program.

I agree but I'd do it on three levels: top management, middle management and
file clerk. GO TO is always a symptom of bad structure. Notice how mine
eliminates the GO TO and condition testing inside the middle loop. I too abend
in the main program -- for all errors, not just IO -- while displaying
problem-specific information close to the point where the problem is detected.
The top guy's message may be too generic.

This trivial example doesn't show the advantage of three levels. Imagine a
typical program with multiple middle loops and at least as many files.

main:
01 diagnostic-info.
05 status-code.
10 status-code-1 pic x.
10 status-code-2..
15 status-code-2n comp pic s99.

call 'middle' using diagnostic-info
if return-code > 1
(display diagnostic information)
else
move zero to return-code
end-if
goback returning return-code.

middle:
call 'fileaccess' using diagnostic-info, record-area
perform until return-code not = zero
(process record logic)
call 'fileaccess' using diagnostic-info, record-area
end-perform
goback returning return-code.

fileaccess:
if file-not-open
open input file-name
perform check-status-code
set file-open to true
end-if
read file-name into record-area
perform check-status-code
add 1 to record-count in diagnostic-info
move record-key in record-area to record-key in diagnostic-info
goback returning 0.

check-status-code.
if status-code-1 not = '0'
if status-code-1 not = '1'
display 'IO error ' status-code ' on filename'
if status-code-2 not numeric
display '(' status-code-2n ')'
end-if
move 12 to return-code
else
move 1 to return-code
end-if
if file-open
close file-name
set file-not-open to true
end-if
goback returning return-code
end-if.

[Richard Plinston]

From the infamous "Go To Statement Considered Harmful", Edsger W. Dijkstra

In fact there is nothing wrong with a GO TO at all. It is a very clear
statement that is unambiguous and always does what is required.

Where the _actual_ problem occurs is at the target of a GO TO, a label.

In COBOL, labels may be used for a variety of actions:

PERFORM label
PERFORM xxx thru label
GO TO label
drop thru

If each label is only used for one thing only, eg PERFORM this-label but
never PERFORM .. THRU this-label nor GOTO this-label nor drop thru, then
the process of understanding the program is considerably simplified.

When reading a program it is done small parts at a time while building up
how the whole program fits together. Given a 'PERFORM paragraph-x', for
example', it is quite clear what will happen. When inspecting paragraph-x,
given that only paragraphs will be performed (no THRU or SECTIONs) then it
is equally clear what path is taken.

However, if there are a variety of paths through a label, such as drop thru
_and_ PERFORM, then the complexity increases.

If a program has a termination point in the first paragraph (STOP RUN, EXIT
PROGRAM etc), and has not PERFORM THRU, GO TO, or SECTIONs, then one can be
fairly confident that each label will only be referenced in one way.

Whenever there is a GO TO in the program then it is necessary to increase
the amount of checking that is done at each label to ensure which paths are
actually taken through that point: one must cater for drop thru.

[Donald Tees]

|
|
| >| >This is how *I* would code it. (On the mainframe)
| >| >
| >| > 05 file-status pic XX.
| >| > 88 GOOD-READ VALUE '00'.
| >| > 88 end-of-file value '10'.
| >| >
| >| > SET GOOD-READ TO TRUE.
| >| > PERFORM UNTIL NOT GOOD-READ
| >| > READ SomeFile
| >| > EVALUATE TRUE
| >| > WHEN GOOD-READ
| >| > PERFORM 1000-PROCESS-RECORD
| >| > WHEN END-OF-FILE
| >| > CONTINUE
| >| > WHEN OTHER
| >| > display 'error ' file-status ' on SomeFile'
| >| > GO TO 9999-ABEND-ROUTINE
| >| > END-EVALUATE
| >| > END-PERFORM.
| >| >
| >| >Seems to be a bit cleaner, and clearer than your example.
| >| >Don't you agree?
| >|
| >| Yes, except the GO TO. In real life I'd put the read and OTHER

handling

in
| >a
| >| callable program.
| >
| >Normally, when I code an abend routine, I will include things that
pertain
| >to that program, like record counts, totals, and keys.
| >It doesn't hurt to give the programmer, who has to fix the problem, all
the
| >information that they could use.
| >
| >That means doing it at the main program level.
| >So, I will return from a called module, and I will abend in the main
| >program.
|
| I agree but I'd do it on three levels: top management, middle management
and
| file clerk. GO TO is always a symptom of bad structure.
For *ME*, GO TO is the preferable way to handle the condition of

abandoning

the program.
The other option is to continually test an "abandon" run indicator, which
adds unnecessary complexity to the program, and may unwittingly be

ignored..

From the infamous "Go To Statement Considered Harmful", Edsger W. Dijkstra
"The remark about the undesirability of the go to statement is far from

new.

I remember having read the explicit recommendation to restrict the use of
the go to statement to alarm exits, but I have not been able to trace it;
presumably, it has been made by C. A. R. Hoare."
|Notice how mine
| eliminates the GO TO and condition testing inside the middle loop. I too
abend
| in the main program -- for all errors, not just IO -- while displaying
| problem-specific information close to the point where the problem is
detected.
| The top guy's message may be too generic.
AND, as we both pointed out, lack critical information.
END OF MY COMMENTS.
|
| This trivial example doesn't show the advantage of three levels. Imagine

a

| typical program with multiple middle loops and at least as many files.
|
| 01 diagnostic-info.
| 05 status-code.
| 10 status-code-1 pic x.
| 10 status-code-2..
| 15 status-code-2n comp pic s99.
|
| call 'middle' using diagnostic-info
| if return-code > 1
| (display diagnostic information)
| else
| move zero to return-code
| end-if
| goback returning return-code.
|
| call 'fileaccess' using diagnostic-info, record-area
| perform until return-code not = zero
| (process record logic)
| call 'fileaccess' using diagnostic-info, record-area
| end-perform
| goback returning return-code.
|
| if file-not-open
| open input file-name
| perform check-status-code
| set file-open to true
| end-if
| read file-name into record-area
| perform check-status-code
| add 1 to record-count in diagnostic-info
| move record-key in record-area to record-key in diagnostic-info
| goback returning 0.
|
| check-status-code.
| if status-code-1 not = '0'
| if status-code-1 not = '1'
| display 'IO error ' status-code ' on filename'
| if status-code-2 not numeric
| display '(' status-code-2n ')'
| end-if
| move 12 to return-code
| else
| move 1 to return-code
| end-if
| if file-open
| close file-name
| set file-not-open to true
| end-if
| goback returning return-code
| end-if.

I think you are both missing the boat. I'd use a simple open, and have a
file obect handle everything but the at end in a declaratives section. That
is exactly how a modern compiler works, and what exception handling is
designed for. Why re-write it at the code level?

Donald

[Harley]

"Richard Plinston" <***@Azonic.co.nz> wrote in message news:besd24$veo$***@aklobs.kc.net.nz...
| Robert Wagner wrote:
|
| > Technically, good-read should be '00' thru '09'.
|
| Technically, only the first byte should be used to indicate success, end
of
| file, key error, etc. the 2nd byte may contain additional information, '0'
| indicates no more information applicable.

This is a bit tricky.
The '04' says you have an incorrect record length, so it might not be
advisable to continue processing.
'02' may be acceptable for alternate index processing. (I just know someone
somewhere has written a program that isn't supposed to create duplicate
keys.)

GOOD-READ could be:
"00"
"00" or "04"
"00" or "02"
"00" or "02" or "04"

|
| > Reading an indexed file
| > on an alternate (illiterate, should be alternative) index returns '01'
for
| > duplicates,
|
| '02'.
|
| Note that you should also get an '02' on a WRITE or REWRITE that creates a
| duplicate key on _any_ index (where duplicate keys have been allowed).

I wonder what you get when you satisfy "02" & "04" in the same read.

"02" - For a READ statement the key value for the current key of
reference was equal to the value of the same key in the next record within
the current key of reference.

"04" - A READ statement was successfully executed, but the length of the
record being processed did not conform to the fixed file attributes for
that file.

|
| > on some platforms.
|
| It should be on all conforming '85 or later platforms.

Thanks for the info.
I was assuming that the Status Code values might be vendor/platform
dependent.

[Richard]

Post by Harley
This is a bit tricky.
The '04' says you have an incorrect record length, so it might not be
advisable to continue processing.
'02' may be acceptable for alternate index processing. (I just know someone
somewhere has written a program that isn't supposed to create duplicate
keys.)

Duplicate keys are specified in the SELECT, if they are not allowed
then you will never get an '02'.

Post by Harley
"00"
"00" or "04"
"00" or "02"
"00" or "02" or "04"

You say 'GOOD-READ' but these also apply to WRITE and '05' and '07'
apply to OPEN. Others may be added in future standards.

Post by Harley
I wonder what you get when you satisfy "02" & "04" in the same read.

Good point.

Post by Harley
I was assuming that the Status Code values might be vendor/platform
dependent.

The '9x' codes are vendor and/or platform dependent. The '0x' through
'4x' are defined in the standard. The standard ones should always be
used by the vendor where applicable. However, it may be that the
behaviour can be changed using a compiler directive - MF has
ANS85(syntax).

[Robert Wagner]

Post by Richard

Post by Harley
This is a bit tricky.
The '04' says you have an incorrect record length, so it might not be
advisable to continue processing.
'02' may be acceptable for alternate index processing. (I just know someone
somewhere has written a program that isn't supposed to create duplicate
keys.)

Duplicate keys are specified in the SELECT, if they are not allowed
then you will never get an '02'.

Post by Harley
"00"
"00" or "04"
"00" or "02"
"00" or "02" or "04"

You say 'GOOD-READ' but these also apply to WRITE and '05' and '07'
apply to OPEN. Others may be added in future standards.

Post by Harley
I wonder what you get when you satisfy "02" & "04" in the same read.

Good point.

Post by Harley
I was assuming that the Status Code values might be vendor/platform
dependent.

The '9x' codes are vendor and/or platform dependent. The '0x' through
'4x' are defined in the standard. The standard ones should always be
used by the vendor where applicable. However, it may be that the
behaviour can be changed using a compiler directive - MF has
ANS85(syntax).

In an ideal world, compilers would follow the standard and agree with each
other. This Web page shows what they do in reality.

http://www.adtools.com/support/tip_filestat.htm

It shows they generally do follow the standard, with the notable exception of
IBM OS/VS. This once most common IBM mainframe compiler _frequently_ breaks with
the standard. Others are ambiguous. What does MF return for read on unopened
file? The page shows both 47 and 9-002. I wouldn't be surprised to find it does
one for flat files and the other for indexed.

Not discussed on the page are supplemental return codes provided in various ways
such as FCB, call or extra syntax in the select. FWIW, SQL return codes are very
similar. For instance, Informix returns SQL standard values but in addition can
return an extremely useful English language description of the problem .. if you
know enough to ask for it. Few programmers know the feature exists; I've never
seen it used.

There is a typo on the Web page: 02 is printed as 00.

[Richard]

Post by Robert Wagner
In an ideal world, compilers would follow the standard and agree with each
other. This Web page shows what they do in reality.
It shows they generally do follow the standard, with the notable
exception of IBM OS/VS. This once most common IBM mainframe compiler
_frequently_ breaks with the standard.

The observant amonst us will have noticed that OS/VS has the same
entries as '74' for the standard status values. This is because OSVS
_does_ follow the 'standard', but that happens to be ANS'74 - it is
not an '85 compliant compiler, you need VS Cobol II for ANS'85.

Post by Robert Wagner
Others are ambiguous. What does MF return for read on unopened
file? The page shows both 47 and 9-002. I wouldn't be surprised to find
it does one for flat files and the other for indexed.

MF can return '74 standard codes or '85 standard depending on a
compiler settimg. ANS85(syntax) give '85 syntax but '74 behaviour.
This then only returns those status codes defined in '74 (and thus not
'47') supplemented by vendor codes (and thus '9/002').

This was a feature to ease the transition to '85 while programs
extended their status checking code.

Post by Robert Wagner
Informix returns SQL standard values but in addition can return an
extremely useful English language description of the problem .. if you
know enough to ask for it. Few programmers know the feature exists; I've
never seen it used.

From the Fujitsu Language manual:
------------------------------------------------------------------------
SQLMSG

If an exception event occurs during the execution of an SQL statement,
a message indicating the nature of the event is posted to the
application program. SQLMSG is the area where this message is stored.
The user can print or display the SQLMSG contents by using an output
statement. SQLMSG must always be defined as alphanumeric data item
with level number 01 or 77 in the embedded SQL declarative section.
-------------------------------------------------------------------------

With MF and several embedded SQLs it is sqlerrmc (see SQLCA.CPY or
sqlca.h).

You don't need to 'ask for it'.

I use it.

[Richard]

Good point, but which vendor is MF in 74 mode compatible with? Not IBM.
CIS 74?
Maybe, I don't know. It appears to be compatible with 85 MF with the
addition of
made up values such as 9-002.

The MF ANS'74 error codes are those that were used in the MF ANS'74
Cobol systems which predated ANS'85. These were CIS Cobol (1978) and
Level II Cobol (1983ish).

All '9x' codes are 'made up'.

That's not useful to someone compiling an old 74
mainframe program.

It wasn't supposed to be, it _was_ useful to someone moving earlier MF
ANS'74 code from CIS Cobol and Level II Cobol to the ANS'85 MF Cobol/2
(and later to NetExpress).

Since 9x codes aren't in the 74 standard, I would have used
IBM as the de-facto standard.

Why IBM ? Why not one of the many other Cobol systems, such as RM,
Accu, Burroughs, etc. In any case IBM 9x codes don't cater for things
that MF Level II needed, such as 'record locked'.

MF CIS Cobol and Level II Cobol were not designed for rehosting IBM
systems (which were primarily batch and CICS) but for developing
interactive multiuser small business systems using X/Open facilities.
They were competing with RM, Accu, MS and Data General not mainframes.

Post by Richard
You don't need to 'ask for it'.

You (or the COBOL run-time) needs to provide a pointer to SQLMSG. Sounds
like Fujitsu is doing it for you, under the covers.

And MF, and the C based embedded SQL pre-processors that I have used.

[Chuck Stevens]

Since 9x codes aren't in the 74 standard, ...

Not strictly true. The '74 standard defines 0x (successful completion), 1x
(at end), 2x (invalid key), 3x (permanent error), and 9x
(implementor-defined unsuccessful completion) codes.

ANSI X3.23-1974 page IV-2, 1.3.4.1 Status Key 1: "9 -- Implementor
Defined. The input-output statement was unsuccessfully executed as a result
of a condition that is specified by the implementor. This value is used
only to indicate a condition not indicated by other defined values of status
key 1, or by specified combinations of the values of status key 1 and status
key 2."

The same wording appears also on page V-2 (in the paragraph with the same
number and name for relative I/O) and on page VI-2 (ditto for indexed I/O).
In all three cases paragraph 1.3.4.2 states "When status key 1 contains a
value of '9' indicating an implementor-defined condition, the value of
status key 2 is defined by the implementor." (rule 3 for sequential and
relative I/O, rule 4 for indexed I/O).

What I believe happened here is that implementors provided "9x" status codes
in '74-compliant COBOL for certain circumstances. The '85 standard has a
rather wider set of status codes (and a whole new category -- "logic
error"), and the standard now mandates specific, platform-independent status
codes for some of the circumstances for which '74-compliant programs may
have previously produced "9x" implementor-defined status code values.

Note also that the standard requires that "9x" codes always indicate that
the requested I/O did not complete successfully.

-Chuck Stevens

[Howard Brazee]

Post by Robert Wagner
Technically, good-read should be '00' thru '09'.

Technically, only the first byte should be used to indicate success, end of
file, key error, etc. the 2nd byte may contain additional information, '0'
indicates no more information applicable.

Except if an IBM mainframe gives you a return code of '97', you should know that
the file is opened correctly.

[Howard Brazee]

Post by Robert Wagner
05 file-status pic x(02).
88 any-exception value '10' thru high-values.
88 end-of-file value '10' thru '19'.

With IBM mainframes, '97' is sometimes a successful return code. Ugly.

[Robert Wagner]

Post by Howard Brazee

Post by Robert Wagner
05 file-status pic x(02).
88 any-exception value '10' thru high-values.
88 end-of-file value '10' thru '19'.

With IBM mainframes, '97' is sometimes a successful return code. Ugly.

Before ESA you had to verify VSAM files yourself. Why did you remove the verify
step? Put it back.

I agree it's ugly. Shame on IBM.

[Joe Zitzelberger]

Post by Howard Brazee

Post by Robert Wagner
05 file-status pic x(02).
88 any-exception value '10' thru high-values.
88 end-of-file value '10' thru '19'.

With IBM mainframes, '97' is sometimes a successful return code. Ugly.

97?

Isn't that "other unknow fatal error"?

When is that successful?

[William M. Klein]

File Status "97" indicates a (semi-)successful open of a VSAM file - but
with a VERIFY.

For various 9x file status values (with current IBM OS/390-z/OS compilers)
see:


http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr10/6.1.8.9.1
--
Bill Klein
wmklein <at> ix.netcom.com

Post by Joe Zitzelberger

Post by Howard Brazee

Post by Robert Wagner
05 file-status pic x(02).
88 any-exception value '10' thru high-values.
88 end-of-file value '10' thru '19'.

With IBM mainframes, '97' is sometimes a successful return code. Ugly.

97?
Isn't that "other unknow fatal error"?
When is that successful?

[Joe Zitzelberger]

I think I was confused with a 39. But only because I haven't seen a
verify need since the early 90's. I thought SMS fixed all of that up by
auto-verifying VSAMs on the next open.

Then again, my shop could have customized that. We have a large number
of VSAMs...I could see someone trying to save some time.

Post by William M. Klein
File Status "97" indicates a (semi-)successful open of a VSAM file - but
with a VERIFY.
For various 9x file status values (with current IBM OS/390-z/OS compilers)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr10/6.1.8.9.1
--
Bill Klein
wmklein <at> ix.netcom.com

Post by Joe Zitzelberger

Post by Howard Brazee

Post by Robert Wagner
05 file-status pic x(02).
88 any-exception value '10' thru high-values.
88 end-of-file value '10' thru '19'.

With IBM mainframes, '97' is sometimes a successful return code. Ugly.

97?
Isn't that "other unknow fatal error"?
When is that successful?

[ShadowFox]

Jack,
The read at end is the IO and test.
EG
1000-read file.
Read mastin into work-area at end
perform 300-end-routines
perform 400-close-files
stop run.
Just my own 2 cents.

Post by Jack Straw
I'm an experienced programmer, trying to get up to speed on Cobol.
I've read the source to a few programs from various places, and I have
a methodology question.
When reading a file to it's end, most of the code i'm reading is along
1000-read file.
read filename into varname
at end move 'y' into ws-eof-switch
end-read
Then, later on, the programmer is looking at ws-eof-switch.
Why would one do that instead of (what makes more sense to me)
declaring "file status is ws-file-status" in file control, and then
looking at the file status after the read. That will give a return
code telling exactly what happened during the I/O and not a simple
boolean.
Am I missing something, or is it just dumb luck that I have weird code
examples?
The first technique seems very common.
--
JackStraw
0x3D561045

[Paul Robinson]

Post by Jack Straw
I'm an experienced programmer, trying to get up to speed on Cobol.
I've read the source to a few programs from various places, and I have
a methodology question.
When reading a file to it's end, most of the code i'm reading is along
1000-read file.
read filename into varname
at end move 'y' into ws-eof-switch
end-read
Then, later on, the programmer is looking at ws-eof-switch.
Why would one do that instead of (what makes more sense to me)
declaring "file status is ws-file-status" in file control, and then
looking at the file status after the read.

1. Because the method you describe above was the most common way taught
in most programming books.
2. Testing file status is system dependent, and not something which can
be readily done in a programming book where the writer wants to be
non-system-dependent.

At least it's somewhat better than the way it used to be done:

1000-read file.
read TV-GUIDE into ARMCHAIR
at end go to bathroom
end-read


--
Paul Robinson "Above all else... We shall go on..."
"...And continue!"
"If the lessons of history teach us anything it is
that nobody learns the lessons that history teaches us."

[Joe Zitzelberger]

Post by Jack Straw
I'm an experienced programmer, trying to get up to speed on Cobol.
I've read the source to a few programs from various places, and I have
a methodology question.
When reading a file to it's end, most of the code i'm reading is along
1000-read file.
read filename into varname
at end move 'y' into ws-eof-switch
end-read
Then, later on, the programmer is looking at ws-eof-switch.
Why would one do that instead of (what makes more sense to me)
declaring "file status is ws-file-status" in file control, and then
looking at the file status after the read. That will give a return
code telling exactly what happened during the I/O and not a simple
boolean.
Am I missing something, or is it just dumb luck that I have weird code
examples?
The first technique seems very common.

Comment 1: "Move 'y' to ws-eof-switch" is a very old style. You can
now use the cleaner and less error prone conditional known as the
88-level. I have no idea why people will not let this die...

Comment 2: There are somewhere between 20 and 100 file status codes.
The vast majority of times you really only want to open the file, read
to eof, close the file. Why check for things you otherwise do not want
to handle. Let the system trap those. On keyed reads you also get the
'invalid key' exception handler to make it easier (?IBM extension?).

To further complicate things, many status codes are not relevant to
certain types of files / open modes / read modes. You could do lots of
checking for everything, but 99.9999999% of the time a flat, sequential
file is going to get a '10' (EOF) and nothing else. The 0.00000001%
that you do get something else will likely be in testing when you have
something set up not quite right.

Comment 3: Some environments (z/OS & LE) will provide some very nice
diagnostic messages if you skip the FILE STATUS clause and allow the
system to handle your errors.

[Harley]

"Joe Zitzelberger" <***@nospam.com> wrote in message news:joe_zitzelberger-***@corp.supernews.com...
|
| Comment 3: Some environments (z/OS & LE) will provide some very nice
| diagnostic messages if you skip the FILE STATUS clause and allow the
| system to handle your errors.

Try this, leave out the DD statement for an output file, and run your
program.
I got quite a surprise once when the system created a temp file for the
missing DD.
Unfortunately, I didn't have time to track down the cause.

In general, I agree with your position.
And, I understand you are referring to Sequential (QSAM) files, not VSAM.

[Don Leahy]

Post by Harley
Try this, leave out the DD statement for an output file, and run your
program.
I got quite a surprise once when the system created a temp file for the
missing DD.
Unfortunately, I didn't have time to track down the cause.

<snip>
Check the value of your shop's CBLQDA setting. If CBLQDA(ON) is in effect,
a missing or misspelled DD statement causes Z/OS to dynamically allocate a
file on your behalf. At the end of the job step, it deletes the file.
Helpful, eh? I have seen programmers spend hours, sometimes days, searching
for non-existent logic errors in their code because of this 'feature'.
FWIW, IBM recommends CBLQDA(OFF) for Z/OS systems, because then you get the
system error message you expect when this situation occurs.

[d***@panix.com]

Post by William M. Klein

Post by Harley
Try this, leave out the DD statement for an output file, and run your
program.
I got quite a surprise once when the system created a temp file for the
missing DD.
Unfortunately, I didn't have time to track down the cause.

<snip>
Check the value of your shop's CBLQDA setting. If CBLQDA(ON) is in effect,
a missing or misspelled DD statement causes Z/OS to dynamically allocate a
file on your behalf. At the end of the job step, it deletes the file.
Helpful, eh? I have seen programmers spend hours, sometimes days, searching
for non-existent logic errors in their code because of this 'feature'.

Mr Leahy, this posting is, in my opinion, succinct, technically accurate
and valuable. What is doing in this newsgroup?

DD

[Harley]

"Don Leahy" <***@nospamwhatever.leacom.ca> wrote in message news:enzQa.379$***@news20.bellglobal.com...
| "Harley" <***@worldnet.att.net> wrote in message
| news:SCyQa.53944$***@bgtnsc05-news.ops.worldnet.att.net...
| > Try this, leave out the DD statement for an output file, and run your
| > program.
| > I got quite a surprise once when the system created a temp file for the
| > missing DD.
| > Unfortunately, I didn't have time to track down the cause.
| >
| <snip>
| >
| Check the value of your shop's CBLQDA setting. If CBLQDA(ON) is in
effect,
| a missing or misspelled DD statement causes Z/OS to dynamically allocate a
| file on your behalf. At the end of the job step, it deletes the file.
| Helpful, eh?

In the eyes of some demented soul, maybe.

|I have seen programmers spend hours, sometimes days, searching
| for non-existent logic errors in their code because of this 'feature'.
| FWIW, IBM recommends CBLQDA(OFF) for Z/OS systems, because then you get
the
| system error message you expect when this situation occurs.
|

Thanks VERY MUCH for the info.

[William M. Klein]

A little information on the "dynamic allocation" *requirement* of the '85
ANSI Standard (and what IBM did with QBLQDA).

The '85 ANSI Standard introduced a REQUIREMENT for the COBOL system to
*create* an OUTPUT file - if one is not currently available - in some
(most?) cases. Almost all vendors implemented this in a "useful" way. Even
IBM's VM '85 Standard COBOL system did this in a reasonable way.

UNFORTUNATELY, for IBM's MVS, OS/390, and z/OS systems - rather than
creating a CATALOGED dataset (using some option - with a default such as the
first 7-characters of the job name - to determine the high-level qualifier
*and* using SMS to determine space) IBM created a temporary UNCATALOGED
dataset. In a multi-step JCL job, this is somewhere between useless and
dangerous. With VS COBOL II, there was little one could do about this.

When users started SCREAMING about this (before IBM introduced the CBLQDA
compiler option), IBM decide NOT to fix the fact that such datasets were
"unfindable" and instead introduced a non-Standard, non-portable solution
and allow (even recommend) customers to run with QBLQDA(OFF) to "detect"
missing DDNames when compared to Select/Assign statements.

P.S. If you want to read "obscure" logic, try determining exactly how IBM
has defined "available file" for VSAM files!!!
--
Bill Klein
wmklein <at> ix.netcom.com

Post by Harley
| > Try this, leave out the DD statement for an output file, and run your
| > program.
| > I got quite a surprise once when the system created a temp file for the
| > missing DD.
| > Unfortunately, I didn't have time to track down the cause.
| >
| <snip>
| >
| Check the value of your shop's CBLQDA setting. If CBLQDA(ON) is in
effect,
| a missing or misspelled DD statement causes Z/OS to dynamically allocate a
| file on your behalf. At the end of the job step, it deletes the file.
| Helpful, eh?
In the eyes of some demented soul, maybe.
|I have seen programmers spend hours, sometimes days, searching
| for non-existent logic errors in their code because of this 'feature'.
| FWIW, IBM recommends CBLQDA(OFF) for Z/OS systems, because then you get
the
| system error message you expect when this situation occurs.
|
Thanks VERY MUCH for the info.

[Don Leahy]

Thanks for the history Bill.

Believe it or not, I was just recently able to convince my local sysprogs to
change it to OFF. Their first reaction was that there had been no change,
that the system had always behaved that way, and OFF was the default. Every
Cobol programmer in the shop (well, the 10% who care about such things
anyway) *knew* that this wasn't the case.

The story I heard was that IBM originally delivered CBLQDA(ON) as the
default, with a recommendation to turn it OFF. My local sysprogs accepted
the recommendation and set it to OFF. A few years later, IBM changed the
default to 'OFF'. The local sysprogs knew that in the past they didn't use
the default value, so, by reflex, they switched it to 'ON'. And for a long
time no one complained.

I was finally approached by a desparate colleague who had been banging his
head against the wall for two days, trying to figure out why, no matter what
he did, his output file remained empty. He could see the EXCP counts, so he
knew data was being written *somewhere*. It turned out he had a misspelled
ddname, and Z/OS was writing to output to an uncataloged temporary file.

Post by William M. Klein
A little information on the "dynamic allocation" *requirement* of the '85
ANSI Standard (and what IBM did with QBLQDA).
The '85 ANSI Standard introduced a REQUIREMENT for the COBOL system to
*create* an OUTPUT file - if one is not currently available - in some
(most?) cases. Almost all vendors implemented this in a "useful" way.

Even

Post by William M. Klein
IBM's VM '85 Standard COBOL system did this in a reasonable way.
UNFORTUNATELY, for IBM's MVS, OS/390, and z/OS systems - rather than
creating a CATALOGED dataset (using some option - with a default such as the
first 7-characters of the job name - to determine the high-level qualifier
*and* using SMS to determine space) IBM created a temporary UNCATALOGED
dataset. In a multi-step JCL job, this is somewhere between useless and
dangerous. With VS COBOL II, there was little one could do about this.
When users started SCREAMING about this (before IBM introduced the CBLQDA
compiler option), IBM decide NOT to fix the fact that such datasets were
"unfindable" and instead introduced a non-Standard, non-portable solution
and allow (even recommend) customers to run with QBLQDA(OFF) to "detect"
missing DDNames when compared to Select/Assign statements.
P.S. If you want to read "obscure" logic, try determining exactly how IBM
has defined "available file" for VSAM files!!!
--
Bill Klein
wmklein <at> ix.netcom.com

Post by Harley
| > Try this, leave out the DD statement for an output file, and run your
| > program.
| > I got quite a surprise once when the system created a temp file for

the

Post by Harley
| > missing DD.
| > Unfortunately, I didn't have time to track down the cause.
| >
| <snip>
| >
| Check the value of your shop's CBLQDA setting. If CBLQDA(ON) is in
effect,
| a missing or misspelled DD statement causes Z/OS to dynamically

allocate

Post by William M. Klein
a

Post by Harley
| file on your behalf. At the end of the job step, it deletes the file.
| Helpful, eh?
In the eyes of some demented soul, maybe.
|I have seen programmers spend hours, sometimes days, searching
| for non-existent logic errors in their code because of this 'feature'.
| FWIW, IBM recommends CBLQDA(OFF) for Z/OS systems, because then you get
the
| system error message you expect when this situation occurs.
|
Thanks VERY MUCH for the info.

[Joe Zitzelberger]

That is a different take. I was not happy when it was off. I prefer
CBLQDA(ON) so that SYS(PRINT|PUNCH|OUT) are automatic and do not need to
be explicitly coded.

What I really would love to see is a CBLQIN(ON) option that would allow
SYSIN to be accepted regardless of its existance. Thus one could
specify parms or not and have it function as a SELECT/OPTIONAL file.

Post by Don Leahy
Thanks for the history Bill.
Believe it or not, I was just recently able to convince my local sysprogs to
change it to OFF. Their first reaction was that there had been no change,
that the system had always behaved that way, and OFF was the default. Every
Cobol programmer in the shop (well, the 10% who care about such things
anyway) *knew* that this wasn't the case.
The story I heard was that IBM originally delivered CBLQDA(ON) as the
default, with a recommendation to turn it OFF. My local sysprogs accepted
the recommendation and set it to OFF. A few years later, IBM changed the
default to 'OFF'. The local sysprogs knew that in the past they didn't use
the default value, so, by reflex, they switched it to 'ON'. And for a long
time no one complained.
I was finally approached by a desparate colleague who had been banging his
head against the wall for two days, trying to figure out why, no matter what
he did, his output file remained empty. He could see the EXCP counts, so he
knew data was being written *somewhere*. It turned out he had a misspelled
ddname, and Z/OS was writing to output to an uncataloged temporary file.

[Joe Zitzelberger]

I've never actually been bitten by this, but I see two problems with
your answer.

The first, creating an HLQ with the first 7 bytes of the jobname might,
well, they might not line up with a valid catalog and/or ACF rule to
allow creation.

The second, can't you use JCL referbacks to reference the uncataloged
datasets? I've not been bitten, so I'm not sure of the details, but if
you have a dd in stepA that builds a nameless dataset, can you not reuse
that in another step via *.steA.nmlsdsn?

Post by William M. Klein
A little information on the "dynamic allocation" *requirement* of the '85
ANSI Standard (and what IBM did with QBLQDA).
The '85 ANSI Standard introduced a REQUIREMENT for the COBOL system to
*create* an OUTPUT file - if one is not currently available - in some
(most?) cases. Almost all vendors implemented this in a "useful" way. Even
IBM's VM '85 Standard COBOL system did this in a reasonable way.
UNFORTUNATELY, for IBM's MVS, OS/390, and z/OS systems - rather than
creating a CATALOGED dataset (using some option - with a default such as the
first 7-characters of the job name - to determine the high-level qualifier
*and* using SMS to determine space) IBM created a temporary UNCATALOGED
dataset. In a multi-step JCL job, this is somewhere between useless and
dangerous. With VS COBOL II, there was little one could do about this.
When users started SCREAMING about this (before IBM introduced the CBLQDA
compiler option), IBM decide NOT to fix the fact that such datasets were
"unfindable" and instead introduced a non-Standard, non-portable solution
and allow (even recommend) customers to run with QBLQDA(OFF) to "detect"
missing DDNames when compared to Select/Assign statements.
P.S. If you want to read "obscure" logic, try determining exactly how IBM
has defined "available file" for VSAM files!!!

[Don Leahy]

Post by Joe Zitzelberger
I've never actually been bitten by this, but I see two problems with
your answer.
The second, can't you use JCL referbacks to reference the uncataloged
datasets? I've not been bitten, so I'm not sure of the details, but if
you have a dd in stepA that builds a nameless dataset, can you not reuse
that in another step via *.steA.nmlsdsn?

If it is NEW,PASS you can. In this case the temporary file has a
disposition of NEW,DELETE,DELETE, so you cannot reference it after the step
is completed.

This bizarre behaviour *is* documented:
z/OS consideration--You should use CBLQDA(OFF) under z/OS, because this
prevents a temporary data set from being created in case there is a
misspelling in your JCL. If you specify CBLQDA(ON) and have a misspelling in
your JCL, Language Environment creates a temporary file, writes to it, and
then z/OS deletes it. You receive a return code of 0, but no output.


From CEEA3110 z/OS V1R2.0 Language Environment Programming Reference

[Russell Styles]

Post by Don Leahy

Post by Joe Zitzelberger
I've never actually been bitten by this, but I see two problems with
your answer.
The second, can't you use JCL referbacks to reference the uncataloged
datasets? I've not been bitten, so I'm not sure of the details, but if
you have a dd in stepA that builds a nameless dataset, can you not reuse
that in another step via *.steA.nmlsdsn?

If it is NEW,PASS you can. In this case the temporary file has a
disposition of NEW,DELETE,DELETE, so you cannot reference it after the step
is completed.
z/OS consideration--You should use CBLQDA(OFF) under z/OS, because this
prevents a temporary data set from being created in case there is a
misspelling in your JCL. If you specify CBLQDA(ON) and have a misspelling in
your JCL, Language Environment creates a temporary file, writes to it, and
then z/OS deletes it. You receive a return code of 0, but no output.
From CEEA3110 z/OS V1R2.0 Language Environment Programming Reference

I suppose that this could be usefull when you WANT a temporary file
that is purely internal, and will never be used outside of the job step.

Dynamite can also be usefull. But I don't want any around my house.

[Joe Zitzelberger]

In article

Post by Harley
|
| Comment 3: Some environments (z/OS & LE) will provide some very nice
| diagnostic messages if you skip the FILE STATUS clause and allow the
| system to handle your errors.
Try this, leave out the DD statement for an output file, and run your
program.
I got quite a surprise once when the system created a temp file for the
missing DD.
Unfortunately, I didn't have time to track down the cause.
In general, I agree with your position.
And, I understand you are referring to Sequential (QSAM) files, not VSAM.

It all depends on the CBLQDA compiler option. But yes, you can mess
things up, but it is very nice trying to figure out what went wrong on
an open.

[Howard Brazee]

Post by Joe Zitzelberger
Comment 1: "Move 'y' to ws-eof-switch" is a very old style. You can
now use the cleaner and less error prone conditional known as the
88-level. I have no idea why people will not let this die...

Partially because we can't yet SET SW-EOF-SWITCH to FALSE, in many environments.

While I prefer using 88 level here, I am unconvinced that this is cleaner and
less error prone than the older alternative. It is a style I like though.
But when I am looking for references for a particular switch, I need to catch
all of its 88 levels as well as the switch itself. That's more work, and might
be missed by a maintenance programmer.

[Harley]

"Howard Brazee" <***@brazee.net> wrote in message news:beufrr$i42$***@peabody.colorado.edu...
|
| On 14-Jul-2003, Joe Zitzelberger <***@nospam.com> wrote:
|
| > Comment 1: "Move 'y' to ws-eof-switch" is a very old style. You can
| > now use the cleaner and less error prone conditional known as the
| > 88-level. I have no idea why people will not let this die...
|
| Partially because we can't yet SET SW-EOF-SWITCH to FALSE, in many
environments.

If I need it, I include an 88 to reset the switch.

|
| While I prefer using 88 level here, I am unconvinced that this is cleaner
and
| less error prone than the older alternative. It is a style I like
though.
| But when I am looking for references for a particular switch, I need to
catch
| all of its 88 levels as well as the switch itself. That's more work, and
might
| be missed by a maintenance programmer.

You can specify the switch without a name, and only 88 levels.
This forces use of the 88 levels (until someone names it and moves to it).

i.e.
05 PIC X VALUE LOW-VALUE.
88 sw-color-is-red VALUE 'R'.
88 sw-color-is-blue VALUE 'B'.
88 sw-color-is-unknown VALUE LOW-VALUE.

[Robert Wagner]

Post by Howard Brazee

Post by Joe Zitzelberger
Comment 1: "Move 'y' to ws-eof-switch" is a very old style. You can
now use the cleaner and less error prone conditional known as the
88-level. I have no idea why people will not let this die...

Partially because we can't yet SET SW-EOF-SWITCH to FALSE, in many environments.
While I prefer using 88 level here, I am unconvinced that this is cleaner and
less error prone than the older alternative. It is a style I like though.
But when I am looking for references for a particular switch, I need to catch
all of its 88 levels as well as the switch itself. That's more work, and might
be missed by a maintenance programmer.

I don't name switches, removing the temptation to reference them directly.
(Another reason to avoid initialize) There is no reason to reference them both
ways.

If you can't say FALSE, use the exact same name prefixed by not-.

05 pic x.
88 end-of-file value 'e'.
88 not-end-of-file value low-value.

[Donald Tees]

Post by Howard Brazee

Post by Howard Brazee

Post by Joe Zitzelberger
Comment 1: "Move 'y' to ws-eof-switch" is a very old style. You can
now use the cleaner and less error prone conditional known as the
88-level. I have no idea why people will not let this die...

Partially because we can't yet SET SW-EOF-SWITCH to FALSE, in many

environments.

Post by Howard Brazee
While I prefer using 88 level here, I am unconvinced that this is cleaner and
less error prone than the older alternative. It is a style I like though.
But when I am looking for references for a particular switch, I need to catch
all of its 88 levels as well as the switch itself. That's more work,

and

Post by Howard Brazee
might

Post by Howard Brazee
be missed by a maintenance programmer.

I don't name switches, removing the temptation to reference them directly.
(Another reason to avoid initialize) There is no reason to reference them both
ways.
If you can't say FALSE, use the exact same name prefixed by not-.
05 pic x.
88 end-of-file value 'e'.
88 not-end-of-file value low-value.

I am currently working on a system written in exactly this manner, and I am
adhering to the style. It does have certain advantages. However, for
maintenance, it also has a couple of huge disadvantages.

The biggest disadvantage, to my mind, is that you cannot easily see what a
value *is* when single stepping the code. For example, I have code that says

if end-of-file
blah
if not-end-of-file
blah-blah.

Now, I get to that point, and my debugger tells me that *both* conditions
are false. I know I have some weird file condition, and the status byte
probably tells me what it is. The status byte, however, is completely
invisable ... it does not even have a Cobol data name. If I really want to
find out what the status byte is, I have to go back to source and stick a
display in, or at the very least a dataname reference that I can point to in
my debugger.

Looking at my code, I do not even really know if those conditions are using
the status byte. They may be referencing some value set in the declarative
section.

There are problems with both styles.

Donald

[Joe Zitzelberger]

Which debugger are you using? Which platform?

Post by Donald Tees
I am currently working on a system written in exactly this manner, and I am
adhering to the style. It does have certain advantages. However, for
maintenance, it also has a couple of huge disadvantages.
The biggest disadvantage, to my mind, is that you cannot easily see what a
value *is* when single stepping the code. For example, I have code that says
if end-of-file
blah
if not-end-of-file
blah-blah.
Now, I get to that point, and my debugger tells me that *both* conditions
are false. I know I have some weird file condition, and the status byte
probably tells me what it is. The status byte, however, is completely
invisable ... it does not even have a Cobol data name. If I really want to
find out what the status byte is, I have to go back to source and stick a
display in, or at the very least a dataname reference that I can point to in
my debugger.
Looking at my code, I do not even really know if those conditions are using
the status byte. They may be referencing some value set in the declarative
section.
There are problems with both styles.
Donald

[Donald Tees]

Post by Joe Zitzelberger
Which debugger are you using? Which platform?

At the moment? MF on Win98.

Donald

[d***@panix.com]

In article <FZJQa.3221$***@news20.bellglobal.com>,
Donald Tees <***@sympatico.ca> wrote:

[snip]

Oh, there is always a way. I can page back to my working storage section,
look up the 88 level name and find the data name that it applies to, and
then set up a watch point for that parameter. The point though, is that it
is awkward, and necessitates jumping back and forth in the code to see what
is going on. There is an advantage in being able to reference specific
checkable data areas down at the procedure level.

Now let me get this straight... you have a step-level debugger (not the
classic Batch o' DISPLAYs Debugger) and you are complaining?

In the words of that Wise Philosopher, Bugs Bunny... 'Oooooo, agony,
agony!'

DD

[Donald Tees]

Post by d***@panix.com
[snip]

Oh, there is always a way. I can page back to my working storage section,
look up the 88 level name and find the data name that it applies to, and
then set up a watch point for that parameter. The point though, is that it
is awkward, and necessitates jumping back and forth in the code to see what
is going on. There is an advantage in being able to reference specific
checkable data areas down at the procedure level.

Now let me get this straight... you have a step-level debugger (not the
classic Batch o' DISPLAYs Debugger) and you are complaining?

You cannot do a display either, if you have not given it a data name ...

Donald

Post by d***@panix.com
DD

[d***@panix.com]

Post by Donald Tees

Post by d***@panix.com
[snip]

Oh, there is always a way. I can page back to my working storage section,
look up the 88 level name and find the data name that it applies to, and
then set up a watch point for that parameter. The point though, is that it
is awkward, and necessitates jumping back and forth in the code to see what
is going on. There is an advantage in being able to reference specific
checkable data areas down at the procedure level.

Now let me get this straight... you have a step-level debugger (not the
classic Batch o' DISPLAYs Debugger) and you are complaining?

You cannot do a display either, if you have not given it a data name ...

Mr Tees, I am confused... are you saying that a DISPLAY cannot be done
based on a condition-name?

DD

[Donald Tees]

Post by d***@panix.com

Post by Donald Tees

Post by d***@panix.com
[snip]

Oh, there is always a way. I can page back to my working storage section,
look up the 88 level name and find the data name that it applies to, and
then set up a watch point for that parameter. The point though, is that it
is awkward, and necessitates jumping back and forth in the code to see what
is going on. There is an advantage in being able to reference specific
checkable data areas down at the procedure level.

Now let me get this straight... you have a step-level debugger (not the
classic Batch o' DISPLAYs Debugger) and you are complaining?

You cannot do a display either, if you have not given it a data name ...

Mr Tees, I am confused... are you saying that a DISPLAY cannot be done
based on a condition-name?
DD

Yep. Given:

01 PICTURE X VALUE "A".
88 YES-ANSWER VALUE "Y".
88 NO-ANSWER VALUE "N".

and, somewhere in the code
if yes-answer
blah
else
if no-answer
blahblah
else
display what-the-heck-is-it.
There is nothing to display.

Donald

[d***@panix.com]

Post by Donald Tees

Post by d***@panix.com

Post by Donald Tees

Post by d***@panix.com
[snip]

Oh, there is always a way. I can page back to my working storage section,
look up the 88 level name and find the data name that it applies to, and
then set up a watch point for that parameter. The point though, is that it
is awkward, and necessitates jumping back and forth in the code to see what
is going on. There is an advantage in being able to reference specific
checkable data areas down at the procedure level.

Now let me get this straight... you have a step-level debugger (not the
classic Batch o' DISPLAYs Debugger) and you are complaining?

You cannot do a display either, if you have not given it a data name ...

Mr Tees, I am confused... are you saying that a DISPLAY cannot be done
based on a condition-name?

01 PICTURE X VALUE "A".
88 YES-ANSWER VALUE "Y".
88 NO-ANSWER VALUE "N".
and, somewhere in the code
if yes-answer
blah
else
if no-answer
blahblah
else
display what-the-heck-is-it.
There is nothing to display.

Ahhhhh, I see... it is not that 'a DISPLAY cannot be done based on a
condition-name', it is 'a DISPLAY of an un-named data-area cannot be
done'.

Thanks for the clarification... my thought was along the lines of

if yes-answer
perform a-rtn
else
if no-answer
perform b-rtn

else
display 'garbage in yes-answer/no-answer flag'.

... which, of course, does not display the contents of the field but tells
you that something is big-time wrong.

DD

[Robert Wagner]

Post by Howard Brazee

Post by Howard Brazee

Post by Howard Brazee

Post by Joe Zitzelberger
Comment 1: "Move 'y' to ws-eof-switch" is a very old style. You can
now use the cleaner and less error prone conditional known as the
88-level. I have no idea why people will not let this die...

Partially because we can't yet SET SW-EOF-SWITCH to FALSE, in many

environments.

Post by Howard Brazee
While I prefer using 88 level here, I am unconvinced that this is cleaner

and

Post by Howard Brazee

Post by Howard Brazee
less error prone than the older alternative. It is a style I like

though.

Post by Howard Brazee

Post by Howard Brazee
But when I am looking for references for a particular switch, I need to

catch

Post by Howard Brazee

Post by Howard Brazee
all of its 88 levels as well as the switch itself. That's more work,

and

Post by Howard Brazee
might

Post by Howard Brazee
be missed by a maintenance programmer.

I don't name switches, removing the temptation to reference them directly.
(Another reason to avoid initialize) There is no reason to reference them

both

Post by Howard Brazee
ways.
If you can't say FALSE, use the exact same name prefixed by not-.
05 pic x.
88 end-of-file value 'e'.
88 not-end-of-file value low-value.

I am currently working on a system written in exactly this manner, and I am
adhering to the style. It does have certain advantages. However, for
maintenance, it also has a couple of huge disadvantages.
The biggest disadvantage, to my mind, is that you cannot easily see what a
value *is* when single stepping the code. For example, I have code that says
if end-of-file
blah
if not-end-of-file
blah-blah.
Now, I get to that point, and my debugger tells me that *both* conditions
are false. I know I have some weird file condition, and the status byte
probably tells me what it is. The status byte, however, is completely
invisable ... it does not even have a Cobol data name. If I really want to
find out what the status byte is, I have to go back to source and stick a
display in, or at the very least a dataname reference that I can point to in
my debugger.

Can't you hover the mouse pointer over the (implied) filler to see the value?

The only way it can contain values other than the 88s is a group move, NOT
initialize, or default initialization. I'd look for references to the group
name, especially moving spaces to it. To minimize initialization problems, I
always use low-values for false.

Post by Howard Brazee
Looking at my code, I do not even really know if those conditions are using
the status byte. They may be referencing some value set in the declarative
section.

Huh? Unqualified names must be unique.

[Donald Tees]

Post by Robert Wagner
Can't you hover the mouse pointer over the (implied) filler to see the value?

Possibly ... the real problem though is that I cannot see it at my
breakpoint, in the procedure division. I have to search trhough working
storage, find the 88 level, see what parameter it is based on, and then
chack that value. At the procedure division level, I only have true/false
logic levels available.

Post by Robert Wagner
The only way it can contain values other than the 88s is a group move, NOT
initialize, or default initialization. I'd look for references to the group
name, especially moving spaces to it. To minimize initialization problems, I
always use low-values for false.

Not really ... it could have 7 or 8 other 88 levels assigned to it. In
fact, all 256 states could have 88 levels associated them, and it could be
set to anything at all, even without a data name. You have no way, looking
at the code, to know how exhaustive the list is.

Post by Robert Wagner

Post by Donald Tees
Looking at my code, I do not even really know if those conditions are using
the status byte. They may be referencing some value set in the declarative
section.

Huh? Unqualified names must be unique.

yes, that is true, but it is not what I meant. Take the following code:

open x.
if not no-file
continue
else
perform create-new-file.

I would presume, reading that, that the condition "no-file" was a condition
name based on a file status 29. That may be completely misleading, though
... I could have a declaratives section that filters out sharing errors, and
sets a completely different flag for all but a "new" file. I cannot really
state for sure what parameter is being checked without going back to the
working storage section.

Don't get me wrong ... I use 88 levels quite a bit. The point though, is
that they are not a panacea ... they can hide data at the debugging level
too, and that is not always a good thing.

Donald

[Howard Brazee]

Post by Robert Wagner
If you can't say FALSE, use the exact same name prefixed by not-.
05 pic x.
88 end-of-file value 'e'.
88 not-end-of-file value low-value.

One big advantage - future programmers won't move something into an unnamed
field.

On the other hand:
1. I can't display the value while debugging.
2. I wonder how this works with on-line debuggers (which I don't use) -
especially when "X" is in that value above.
3. There still are two variable names to search for to find when that switch
changes. (your names do help).


Is there any difference between an unnamed field and a FILLER?

[Joe Zitzelberger]

Post by Howard Brazee

Post by Robert Wagner
If you can't say FALSE, use the exact same name prefixed by not-.
05 pic x.
88 end-of-file value 'e'.
88 not-end-of-file value low-value.

One big advantage - future programmers won't move something into an unnamed
field.
1. I can't display the value while debugging.
2. I wonder how this works with on-line debuggers (which I don't use) -
especially when "X" is in that value above.

Using Compuwares XPEDITER I can do a KEEP on an 88-level condition name
and it will show me the byte in question, regardless of name, or lack
thereof

In the above case I could 'K end-of-file' and it will add a byte sans
name (I can't remember if it puts 'filler' there) and the value.

[William M. Klein]

For those working on the PC and who are interested in finding out where data
(under a variety of names - including filler) is modified within an
application, you might want to look at the REVOLVE product from Micro Focus.
See:

http://microfocus.com/products/revolve/datasheet.asp

I certainly wouldn't purchase the product JUST to track "eof switches" - but
it does provide SIGNIFICANT "application understanding" facilities. This
can be a real help to those who are "taking over" the maintenance of an
application that they didn't "build" originally themselves.

On the IBM mainframe, the "old" Viasoft products provided similar
capabilities. (I can't remember - off the top of my head - who bought
Viasoft, but I think the products are still available from another vendor.)
--
Bill Klein
wmklein <at> ix.netcom.com

Post by Joe Zitzelberger

Post by Howard Brazee

Post by Robert Wagner
If you can't say FALSE, use the exact same name prefixed by not-.
05 pic x.
88 end-of-file value 'e'.
88 not-end-of-file value low-value.

One big advantage - future programmers won't move something into an unnamed
field.
1. I can't display the value while debugging.
2. I wonder how this works with on-line debuggers (which I don't use) -
especially when "X" is in that value above.

Using Compuwares XPEDITER I can do a KEEP on an 88-level condition name
and it will show me the byte in question, regardless of name, or lack
thereof
In the above case I could 'K end-of-file' and it will add a byte sans
name (I can't remember if it puts 'filler' there) and the value.

[Robert Wagner]

Post by Howard Brazee

Post by Robert Wagner
If you can't say FALSE, use the exact same name prefixed by not-.
05 pic x.
88 end-of-file value 'e'.
88 not-end-of-file value low-value.

One big advantage - future programmers won't move something into an unnamed
field.
1. I can't display the value while debugging.

Give it a name, temporarily. Use names beginning with 'debug-' so you can search
for and remove them when you're finished.

Put indicators into a group and display the group-name. If you use meaningful
values, rather than 'y' and 'n', it's easy to see which indicators are on.

Post by Howard Brazee
2. I wonder how this works with on-line debuggers (which I don't use) -
especially when "X" is in that value above.

The debuggers I've seen will display any data field, including filler. Group
names are not just blapped like a string, they are formatted with subordinate
names, including fillers, next to values.

Post by Howard Brazee
3. There still are two variable names to search for to find when that switch
changes. (your names do help).

That's the reason for the naming convention. If you don't mind verbosity, you
_could_ give the indicator a name and qualify 88 references with that name.
Perhaps this will answer your concern:

if end-of-file in file-x-indicator

Post by Howard Brazee
Is there any difference between an unnamed field and a FILLER?

No.

[LX-i]

Post by Joe Zitzelberger
to handle. Let the system trap those. On keyed reads you also get the
'invalid key' exception handler to make it easier (?IBM extension?).

Nope - it's been in every COBOL I've ever used. :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ AIM: LXi0007 ~
~ _____ / \ | ~ E-mail: ***@Netscape.net ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please post if you wish to be contacted privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Ubiquitous]

Post by Jack Straw
Why would one do that instead of (what makes more sense to me)
declaring "file status is ws-file-status" in file control, and then
looking at the file status after the read. That will give a return
code telling exactly what happened during the I/O and not a simple
boolean.
Am I missing something, or is it just dumb luck that I have weird code
examples?

Hmm, I do both but never really thought about it until now.
I guess I usually use the status code for output or IO files only.