Re: "file locked by another user" mystery
- From: briggs@xxxxxxxxxxxxxxxxx
- Date: 30 Jan 2008 06:30:40 -0600
In article <479FB364.4010505@xxxxxxxxx>, Fred Bach <bach@xxxxxxxxx> writes:
Mr Briggs,
Holy crow! You're right. However, it is not explicitly stated
in the DCL Help that if you have an ON SEVERE command that you
cannot have a previous ON WARNING command and expect it to work.
The HELP just implies that, in the absence of the ON WARNING or
and ON ERROR command, execution would simply continue. The DCL
HELP does *not* say that previous ON WARNING or ON ERROR commands
are thereby nullified and rendered useless! Looks like the DCL
HELP needs to be amended to say what it really should!
Perhaps so. I'd actually visited the DCL help before posting to
see if there was a definitive reference that I could point to
describing the actual behavior. No such luck.
The DCL Help says:
ON
Parameters
condition
Specifies either the severity level of an error or a Ctrl/Y
interrupt. Specify one of the following keywords, which may be
abbreviated to one or more characters:
WARNING Return status of warning occurs ($SEVERITY equals
0).
ERROR Return status of error occurs ($SEVERITY
equals 2).
SEVERE_ERROR Return status of error occurs ($SEVERITY
equals 4).
CONTROL_Y Ctrl/Y character occurs on SYS$INPUT.
The default error condition is ON ERROR THEN EXIT.
command
Specifies the DCL command line to be executed. Optionally, you
can precede the command line with a dollar sign ($).
If you specified an error condition as the condition parameter,
the action is taken when errors equal to or greater than the
specified level of error occur.
Examples
1.$ ON SEVERE_ERROR THEN CONTINUE
A command procedure that contains this statement continues
to execute normally when a warning or error occurs during
execution. When a severe error occurs, the ON statement signals
the procedure to execute the next statement anyway. Once
the statement has been executed as a result of the severe
error condition, the default action (ON ERROR THEN EXIT) is
reinstated.
[ snip ]
Note that the help does NOT say that it is illegal to have an
ON WARNING THEN CONTINUE or an ON ERROR THEN GOTO EXIT. The HELP
doesn't even say it's futile.
Neither are futile.
"ON WARNING THEN CONTINUE" means that the first error of severity
WARNING or worse is ignored and the sequential flow of execution
is maintained.
[It is poor practice to depend on this because the ON <severity>
conditions are one-shots. A second error would go unhandled. It
is more appropriate to use "SET NOON" if you want to continue
the normal sequential flow of execution past multiple errors]
"ON ERROR THEN GOTO EXIT" means that the first error of severify
ERROR or worse causes the flow of execution to branch to the EXIT
label. Any errors encountered at or beyond the EXIT label will
get default error handling because the one-shot ON condition has
already been used up.
The above text would seem to say
that the program executes "normally" for warning and error
conditions. The word 'normally' is rather confusing - it would
suggest that you could actually use an ON WARNING or ON ERROR
command and expect its specified action to be taken when only a
warning condition happened. At least that was the way I always
understood the help.
The help is correct as written in this case. If you have "ON SEVERE"
in force then warnings and errors are ignored. The sequential flow
of execution is not interrupted for warnings or errors but continues
"normally". This does not "use up" the one-shot ON <condition>.
When you get the first severe error, the ON SEVERE THEN CONTINUE causes
sequential execution to proceed in that case as well. But this does
use up the one-shot ON <condition>
I did this all the time. FOR YEARS, and it really did seem to
work just fine. I guess the ON command is really forgiving or
maybe I got the order accidentally correct. ;-)
I avoid it like the plague. If I want to take control of error
handling, I go with $ SET NOON together with $ SAVE_STATUS = $STATUS
and $ IF .NOT. SAVE_STATUS ...
[I always want a saved copy of the $STATUS around so that I can exit
with the right condition code or use F$MESSAGE and embed an accurate
copy of the underlying error code in any error message that I generate]
Typically, to handle all possible conditions that might happen toYep. I have a short script here that I used to verify the behavior before
the user, I feel that I need to specify different actions for
the various ON conditions. Such as "ON WARNING THEN CONTINUE"
and "ON ERROR THEN GOTO EXIT" and "ON SEVERE THEN STOP" which
would be the typical set of ON commands I would use. They
all seemed to function just fine together in the same DCL routine.
Over all these years they did not appear to interfere with each
other. Things worked very well and the desired action seemed
to be taken.
I just wrote a short script that would CONFIRM WHAT YOU SAY!
I moved various ON command lines around to test their effects.
posting as well.
It would seem that the LAST "ON" command sets the course of
events.
Yes. That is correct.
Much like I do for $STATUS now, to handle errors in a custom
way I suppose that now I will have to save and test the value
of $SEVERITY if I really want different actions to be taken on
different values! Can a fellow do that? Ya learns something
every day.... Thanks for the correction!
Unless you get fancy, you can only save $SEVERITY or $STATUS. Not both.
Personally, I tend to save $STATUS. If I need $SEVERITY, I can compute
it as $STATUS .AND. 7
If you want to save them both, you could use a construct like:
$ !some-command-that-sets-$STATUS
$ save_status_severity = $status + "," + $severity
$ save_status = f$element ( 0, ",", save_status_severity )
$ save_severity = f$element ( 1, ",", save_status_severity )
My above code did NOT check things in the other direction - that
is: what if I want something special to happen on an ERROR
condition and all I get is a WARNING condition, and the ON WARNING
was specified LAST. I'm not quite sure how a fellow could cleanly
create only an error condition while trying to type a file.
Can you suggest some code to test this case? Thanks!
$ type /output=<non-existent-device:filename>
That'll generate a severe error. Is that what you're asking for?
One thing that IS important to know is that after an "ON"
condition is acted upon, the last pertinent ON statement is
more or less rendered 'cancelled' by its having its specified
action taken. The ON condition executed then returns to its
default condition, so another set of ON ... statements is
frequently needed. Now even though the HELP confirms this,
that IS something that I learned the hard way. And I had
built myself a little DCL test procedure to prove it and in
some of my coding you would find a block of ON conditions
repeated many times. The code looks funny, too. How does
a fellow set the *default* ON conditions themselves??
The default ON is "ON ERROR THEN EXIT"
That continues sequential execution on warnings.
And it exits on errors and severe errors.
.
- Follow-Ups:
- Re: "file locked by another user" mystery
- From: Fred Bach
- Re: "file locked by another user" mystery
- References:
- "file locked by another user" mystery
- From: tadamsmar
- Re: "file locked by another user" mystery
- From: tadamsmar
- Re: "file locked by another user" mystery
- From: Richard B. Gilbert
- Re: "file locked by another user" mystery
- From: tadamsmar
- Re: "file locked by another user" mystery
- From: AEF
- Re: "file locked by another user" mystery
- From: Fred Bach
- Re: "file locked by another user" mystery
- From: briggs
- Re: "file locked by another user" mystery
- From: Fred Bach
- "file locked by another user" mystery
- Prev by Date: Re: PowerTerm 525 & eXcursion
- Next by Date: Re: Restricting Access to TCP/IP and DECnet
- Previous by thread: Re: "file locked by another user" mystery
- Next by thread: Re: "file locked by another user" mystery
- Index(es):
Relevant Pages
|