Thanks for the clarification but I am still not understanding if the
programs B, C etcetera - do you have access or is this a package and you
do not have source.
If you don't have access to those programs then you are really only going
to know that the process stopped on an error, not what the error is.
This still works with data queue option, when the batch jobs gets an
exception error, it can send a message back on the data queue but the
recovery is not going to be entering R=Retry against the CPF message.
This is a lot of work. Are there lots of errors every time ?
I think if one step gets an error you just put up the red reverse image
window saying CALL IT SUPPORT NOW!!!!
Cheers
Don
Don Brown
Director
MSD Information Technology
t: 07 3368 7888
m: 0408 751 644
e: dbrown@xxxxxxxxxx
www.msd.net.au
From: "Tim Adair" <tadair@xxxxxxxxxxxxxxxx>
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Date: 23/02/2024 03:00 AM
Subject: Re: Error handling over multiple call levels
Sent by: "RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx>
I apologize for my lack of clarity. Here's the scenario...:
For years our users have had a paper checklist of the jobs they need to
run for the EOM processes. Well, we all know that users are human
(more-or-less) and that they make mistakes. Sometimes running a job
step more than once, sometime forgetting to run a job step and skipping
it, etc.
Hence, my solution - I created a PF that contains all the information
necessary to run each job step on their checklist, and in the correct
order. I'm writing an RPGLE subfile program that displays all their job
steps on the screen, and allows them to run each one (in sequence) by
simply pressing Enter on each step. The next step to be run is
reverse-image so there's no question as to which job step will be run
next. And all this is done interactively - nothing is submitted to
batch at this point in the program development.
So far, so good.
Here's the problem - data-related errors can occur in the individual job
steps (just like they occasionally do now). Example: someone has a
record lock, target too small, divide by zero, etc.
And I know what you're thinking - just modify the hundreds of job step
programs to allow for every possible error that can occur in every
program. It would be nice if I could do that but, for reasons beyond my
control, I can't.
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've now had suggestions of submitting each job step to batch instead,
and this has piqued my interest. This technique could possibly solve
multiple wrinkles.
Hopefully this helps clarify the situation.
Thanks.
~TA~
On 2/21/2024 7:45 PM, Buck Calabro wrote:
On Wed, 21 Feb 2024 at 17:02, Tim Adair <tadair@xxxxxxxxxxxxxxxx> wrote:
Given the following scenario:
PROGRAM A calls Program B. Program B calls Program C. Program C gets
an error (of any kind).
Is there any way to notify Program A that program C had an error,
without losing my place in program C.
Are the C-level programs running in batch?
Is that why the user needs feedback about what happened?
If you could describe an example of the runtime situation, and one of
the errors you'd like to report back to the user, it might spur more
ideas.
I'm guessing that you're putting some SBMJOB CLs into a menu driver
system, and the 'Job ended abnormally' completion message isn't enough
to help the end user figure out what to do next. If that's the case, I
don't see how to give them better information without changing the
bottom-level RPG code.
--buck
midrange.com
