Re: Error handling over multiple call levels

Hi Tim,

Am 22.02.2024 um 18:00 schrieb Tim Adair <tadair@xxxxxxxxxxxxxxxx>:

I apologize for my lack of clarity. Here's the scenario...:
<snip>

Well - this really sounds like a good idea for two possible solutions:

1. Submit every "job" as an individual job to a job queue - observe the active and queued jobs with the JOB_INFO table function.

This has the advantage, that you simply utilize the operation systems features and don't have to bother too much.

2. Create a background job (the "worker") which continuously reads thru a table (or uses a data queue) and executes the entries that your front end write to that file (or data queue).

This has the advantage, that it doesn't constantly create new jobs in the system, as this has some overhead and can put some severe stress on the system. With the "worker" you only have one job - which simply runs the programms one after another.

Solution 1 is simpler to scale - if you change the SBS/JOBQ config, you can very easily run 1 or 3 or 70 jobs in parallel. If you want to scale the 2nd solution, you have to write and test some (a lot of) code yourself.

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.

Very easy with individual jobs and a FIFO job quere with only one active job. The MSGW job will prevent the other jobs to start - you can hold them and re-submit the failed job again if you like - and so on.

But also wouldn't be too hard with a "worker" - simply use your "config file" and do not execute the next steps, until the first was executed successfully.

It really depends on your needs and what effort you like to make.

Lately I have written something similar in our shop - a bit more complex with a "dispatcher" job and a variable number of "workers" start are started dynamically depending on the "load" that was dispatched. Every worker then runs until there is no more work to do and then ends itself after a short idle period.

Our decision was made by the facts, that we have sometimes a lot of "tasks" for the "worker" in a short period of time - and some of the tasks a quick and some take more time. So we didn't want to create a new job for each task - therefore the dispatcher/worker pattern. In your case, the user would be the dispatcher - you would only need the "worker(s)".

If you like - we can discuss the further in private - simply send me a PM.

HTH and kind regards,
Daniel