At 09:45 AM 5/5/98 +0000, Scott wrote (and pointed out the proximate problem
with the scenario proposed by John Korb):
>IMO, I don't think the :SHOWVAR @;JOB= "enhancement" will help debug
>this type of error.
>
>Why? Most customers use a logon UDC like the following:
>
>logon
>option logon
>setvar ...
>setvar ...
>setvar ...
>file ...
>file ...
>...
>run a.b.c ...
>bye
>
>So the user logs on and then the application aborts. They call the
>"system administrator" type with the problem stagement "My program
>aborted with DBOPEN error...why?"

The solution (obviously?) is a slight modification to the UDC in much the
same way that we do with jobs, to trap the abort within the UDC, and to put
up a message saying (effectively, DON'T CLEAR THE SCREEN, CALL FOR HELP,(you
get the idea)) and then to hang on a read (preferably of a message file, so
that the sysadmin can be the person who controls the clearing of the screen
etc).

This preserves the state of the abort, and prevents "helpful" continuing
with work at a time when diagnosis should be the #1 priority.

Some secondary thoughts - you probably want to have you program set its own
JCW/variable so that program aborts that don't mean anything serious (sort
of like some of the SF numbers ;-) could be bypassed.
<Set ProfressorMode On>

I've always tried to teach students that the most important thing a program
can do is to start when I ask it to, and the second most important thing is
to stop when I need it to. Stopping in a controlled manner is one of the
hallmarks of a well-written program.
<Set ProfessorMode Off>
Tony