Home > Archive > Cobol > February 2006 > Re: Declarative USE AFTER question
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Declarative USE AFTER question
|
|
| apple.time@yahoo.com 2006-02-08, 8:52 am |
|
I agree that adding commands is the ideal... specifying exactly what
should happend if you get some wild error. But my question goes back
to what does the system do when you get a strange error, if the USE
statement has NO commands following it when you get a fatal error?
-Does the system stop and notify you of a fatal error?
-Does the program terminate?
-Or, does the system just return back to the line following the actual
file I/O that it failed on, subsequently continues on with processing
as if nothing happened?
| |
| James J. Gavan 2006-02-08, 8:52 am |
| apple.time@yahoo.com wrote:
> I agree that adding commands is the ideal... specifying exactly what
> should happend if you get some wild error. But my question goes back
> to what does the system do when you get a strange error, if the USE
> statement has NO commands following it when you get a fatal error?
> -Does the system stop and notify you of a fatal error?
> -Does the program terminate?
> -Or, does the system just return back to the line following the actual
> file I/O that it failed on, subsequently continues on with processing
> as if nothing happened?
>
The program does your "- Or" and if you have a fatal error then it goes
belly up.
So far I've restrained from commenting on your various messages. How can
you *possibly* claim to have 20 years COBOL EXPERIENCE ? In Your 'Code
Assessment' you are way in over your head !
Jimmy, Calgary AB
| |
| HeyBub 2006-02-08, 8:52 am |
| apple.time@yahoo.com wrote:
> I agree that adding commands is the ideal... specifying exactly what
> should happend if you get some wild error.
What on God's earth would compel you to the conclusion that specifying
exactly what should happen if you get some wild error is ideal? You're
trying to solve the wrong problem.
I believe the original programmer did not CARE what would happen if he got a
wild error - he just didn't want the program to abort.
> But my question goes back
> to what does the system do when you get a strange error, if the USE
> statement has NO commands following it when you get a fatal error?
> -Does the system stop and notify you of a fatal error?
Already answered. Usually NO. This is the desired result. Remember, I don't
give a shit whether the CPU is on fire, the tape girl has a wardrobe
malfunction, somewhere in the world, a kid's Yo-Yo malfunctioned, or if he
carried the merely palatable bits on his shoulder or in his handkerchief.
> -Does the program terminate?
Already answered. Usually NO. This is the desired result.
> -Or, does the system just return back to the line following the actual
> file I/O that it failed on, subsequently continues on with processing
> as if nothing happened?
Already answered. Usually YES. This is the desired result. In fact, "denial"
is a philosophy generally leading to a happier and more productive life.
| |
| Peter Lacey 2006-02-08, 8:52 am |
| HeyBub wrote:
>
> apple.time@yahoo.com wrote:
>
> What on God's earth would compel you to the conclusion that specifying
> exactly what should happen if you get some wild error is ideal? You're
> trying to solve the wrong problem.
>
It makes perfect sense to display file, error code, what the program was
trying to do at the time (I used to use WS items primed before the I/O
operation but now there are reserved words for the purpose).
ESPECIALLY if it's some off-brand error that couldn't be planned for.
If I have to figure out what happened if a program crashes for I/O
reasons I expect the programmer - if he knows what he's doing - to give
me as much help as possible.
One guy I know used to display something like 'I/O error on file used
for update'. Great if there happened to be only one such file in the
program. Usually we weren't so lucky. I wasn't in charge so I couldn't
make him change.
Why get so het up?
PL
| |
|
| In article <11uae44gp14hjb0@news.supernews.com>,
HeyBub <heybubNOSPAM@gmail.com> wrote:
[snip]
>In fact, "denial"
>is a philosophy generally leading to a happier and more productive life.
Oh, I *cannot* resist...
.... it is not, is Not IS NOT!
DD
| |
| Michael Mattias 2006-02-08, 8:52 am |
| "Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1139150473.187064.6820@g43g2000cwa.googlegroups.com...
> I once worked at a site where a new-whizzkid programmer was brought in...
> he admitted to not being knowledgable in assemble[r], as he was more of a
cobol programmer.
>...
> He was subsequently sent on a CICS course and left to go to a bank in
> Edinburgh as their 'CICS expert'!
This is the kind of thing I've spent about twenty years trying to correct:
non-professional behavior by a few misguided and/or 'ethically-challenged'
individuals.
If we don't do a better job of policing ourselves, we'll some day wake up to
discover "programmer/analyst" and "information technology consultant" jokes
are as common as jokes about laywers, Congressmen and used-car salesmen.
--
Michael Mattias
Tal Systems Inc.
Racine WI USA
| |
| HeyBub 2006-02-08, 8:52 am |
| Peter Lacey wrote:
> HeyBub wrote:
>
>
> It makes perfect sense to display file, error code, what the program
> was trying to do at the time (I used to use WS items primed before
> the I/O operation but now there are reserved words for the purpose).
> ESPECIALLY if it's some off-brand error that couldn't be planned for.
Bah! I can imagine a program that awakens every ten minutes to check whether
the Yak-Fat Manifest File has been uploaded from Bangladesh. Unfortunately,
it's the monsoon season, all the yaks are dead, and, in fact, the entire
cottage industry involved with harvesting yak fat has decamped, enmasse, for
whale-hunting school.
To be sensible, as you suggest, this semi-somnolent program will commence to
XXXXX like the third monkey on Noah's gangplank six times an hour. In fact,
it may not even finish bitching about the first instance before it's time to
re-XXXXX !
Point is, in this - admittedly rare - state, the programmer does not want
the OS to intervene with a core dump, alarm bells, and complete blood count.
It's sufficient that the program know whether the file exists and the
programmer can test that condition directly - IF he can get the OS to shut
up ( which is what a no-op DECLARATIVES will do).
|
|
|
|
|