Re: Error handling over multiple call levels

On Thu, 22 Feb 2024 at 12:00, Tim Adair <tadair@xxxxxxxxxxxxxxxx> wrote:

If an error occurs in a job step program, I want my cake and eat it too.
I want the user to see a popup on their screen that says, "There's an
error - do not touch the keyboard - pick up your phone and call I.T.
support". Then, when they call me, I want to be able to resolve the
issue (e.g. record lock) and then allow the job step program to continue
from the point of the error.

I'm with Daniel on this: SBMJOB each step. That takes the end user out
of the equation when it comes to self-answering white messages instead
of calling for help.
For a more advanced design, disallow choosing the next step until the
current one has completed, although they should simply queue up in the
JOBQ should they jump ahead.
You might RCVMSG the qualified job name resulting from the SBMJOB, and
keep track of 'current' with JOB_INFO that way.
In theory, they'll know the job is hung up because they'll get a
*STATUS message saying that there's a message in QSYSOPR.
Most end users haven't studied that theory, but I do tend to get calls
like 'Is something stuck in the system? I ran step1 a half hour ago
and my report hasn't printed yet.'
That's when I know to WRKMSG QSYSOPR and take care of things.
--buck