We have many reportcaster jobs that contain multiple tasks, and we do not want to send out any of those reports if any of the job’s tasks fail. Yes, they do need to be separate reports rather than a compound report, as one is a machine readable CSV attachment, another is a summary in the email message body, etc. These go out to our external customers, and it can be embarrassing to have the email body describe attachements that aren’t there.

Using &&KILL_RPC works well when the error is something that we can trap in a preprocess, such as a no data condition, but last night for example we had a FOCUS 32026 error and there are other possible problems that can escape a preprocess.

Because we need to append the current date to the report file names, we are using a dynamic distribution list. If there was something that this procedure could reference from within its job, then it could conditionally stop the distribution of reports. It does not appear that the && global variables persist between tasks, or we could set a value in a failing task and read it in the distribution fex. We even tried reading the schedule’s most recent log from the repcast schema, but it seems that reportcaster does not commit current log information during the run.

Is there an approach we could use for inter-task communication of error conditions within a reportcaster job?

Thanks.

This message has been edited. Last edited by: Kerry,

Can you FILEDEF a status file in which you -WRITE a go/no-go indicator after each task? Each task would -READ the status file to determine whether to proceed or not, and then, if appropriate, write a new go/no-go indicator for the next task. The drawback is that you would need a uniquely-named file for each RC job.

That's probably a better idea than what we were considering, which was database entries. It still would be nice if there were a simpler way.

Take a look at the possibilities that ALERT function might give you.
You can build a preprocess that does your controles and only if that proces gives the proper result reportcaster is triggered

We are currently using a preprocess to handle a no data condition. Our issue is with unpredictable errors, like our recent 32026 that killed some tasks of the jobs but allowed others to complete, sending out emails with missing attachments. We'd like a way to know if any of the tasks failed and be able to nix the whole job.

Hi Jim

From our ReportCaster technicals:

Unpredictable errors are by definition, hard to predict, especially as data might change dynamically. You would probably have to create a ‘shadow series of runs’ and check if all those tables/tasks are completed, then if not, you would terminate before the real series of tasks is started, perhaps using &&KILLRPC, else you would continue and run the real series of tasks. There is still a small chance that between your shadow series and the real one, something might change and the real tasks will fail, but that is probably as good as you can get. And you will be trading efficiency (as you will be running everything twice) for security.

Hope this helps.

Cheers,

Kerry

Here’s the approach that we’ve taken. Each task has a step at the beginning of the fex which inserts the &DSTSCHEDID into a row in a table, and a step at the end of the fex that deletes the row if &FOCERRNUM and &RETCODE are equal to 0. (Are there any other variables that we should check?) Because there’s a unique constraint in the table for DSTSCHEDID, any subsequent task attempting to insert into the table after a failed task will also fail, bypassing that processing. The dynamic address fex at the end only returns a distribution list in the absence of the DSTSCHEDID in the table. Unfortunately &DSTSCHEDID is not available to the dynamic address fex, so we have to “figure that out” by querying the repcast schema with parameters available to the dynamic address fex. It’s not very elegant, but does seem to work for us.

Thanks to everyone for your suggestions.

Jim