I have an issue which I may open a case for, if need be. But, I'm checking Our FocalPoint First.

The issue is that ReportCaster Does Not fail when it should.

Some insight:
1) This RC JOB contains multiple TASKS.
2) A "Task error:Error connecting to the Managed Reporting Repository:" error is produced sometimes, during some of the tasks.
3) Despite that error, the RC Job continues.
* Should the RC Job fail, and produce an send the "On Error" message when a TASK fails, providing that it's set up that way, which it is?

 ReportCaster Log Report Schedule ID: S17bbheal123, Job Description: ReportOne
 
                  Process:    J17h5djb12ab
              Schedule ID:    S17bbheal123
               Start Time:    2013-01-17 17:30:45
                 End Time:    2013-01-17 17:33:58

    Message Code    Message Text

    BTP1010         Schedule Executed On Demand
    BTP1020         Starting task: ReportOne - Report Number One
    BTP1020         Task type: MR Standard Report
    BTP1020         Task domain: domain1/domain1.htm
    BTP1020         Retrieving MR report: app/this_application_name
    BTP1020         Connecting to server THISSVR1 with execution id DougLee
    BTP1020         Executing focexec.
    BTP1020         ====================================================================================
    BTP1020         ==== StopWatch Started at 17.31.00 on Jan 17, 2013
    BTP1020         ====================================================================================
    BTP1020         . . . trace lines from &ECHO . . .
    BTP1020         ====================================================================================
    BTP1020         ==== StopWatch Started at 17.31.00 / Ended at 17.32.11 on Jan 17, 2013
    BTP1020         ==== It took 71 seconds to get to this point in this procedure.
    BTP1020         ====================================================================================
    BTP1020         Task finished.
    BTP1020         Starting task: ReportOne - MSR Sample Division ALL
    BTP1020         Task type: MR Standard Report
    BTP1020         Task domain: domain1/domain1.htm
    BTP1020         Retrieving MR report: app/this_application_name
    BTP1010         <font color=red>Task error:Error connecting to the Managed Reporting Repository:</font> 
    BTP1020         Starting task: ReportOne - MSR Sample Division CLOSED
    BTP1020         Task type: MR Standard Report
    BTP1020         Task domain: domain1/domain1.htm
    BTP1020         Retrieving MR report: app/this_application_name
    BTP1010         <font color=red>Task error:Error connecting to the Managed Reporting Repository:</font> 
    BTP1020         Starting task: ReportOne - MSR Sample Division COMP
    BTP1020         Task type: MR Standard Report
    BTP1020         Task domain: domain1/domain1.htm
    BTP1020         Retrieving MR report: app/this_application_name
    BTP1010         <font color=red>Task error:Error connecting to the Managed Reporting Repository:</font> 
    BTP1020         Starting task: ReportOne - MSR Sample Division NONCOMP
    BTP1020         Task type: MR Standard Report
    BTP1020         Task domain: domain1/domain1.htm
    BTP1020         Retrieving MR report: app/this_application_name
. . .
    BTP1010         Dynamically creating distribution information
    BTP1010         <font color=red>No report for User1@DomainA.com with a burst value of r1010413dv10all.pdf.</font> 
    BTP1010         <font color=red>No report for User2@DomainA.com with a burst value of r1010413dv10all.pdf.</font> 
    BTP1010         <font color=red>No report for User3@DomainA.com with a burst value of r1010413dv10all.pdf.</font> 
    BTP1010         <font color=red>No report for User1@DomainA.com with a burst value of r1010413dv10closed.pdf.</font> 
    BTP1010         <font color=red>No report for User2@DomainA.com with a burst value of r1010413dv10closed.pdf.</font> 
    BTP1010         <font color=red>No report for User3@DomainA.com with a burst value of r1010413dv10closed.pdf.</font> 
    BTP1010         <font color=red>No report for User1@DomainA.com with a burst value of r1010413dv10comp.pdf.</font> 
    BTP1010         <font color=red>No report for User2@DomainA.com with a burst value of r1010413dv10comp.pdf.</font> 
. . .
    BTP1010         r1010413chall.pdf distributed to User1@DomainA.com
    BTP1010         r1010413chclosed.pdf distributed to User1@DomainA.com
    BTP1010         r1010413chcomp.pdf distributed to User1@DomainA.com
    BTP1010         r1010413chnoncomp.pdf distributed to User1@DomainA.com
    BTP1010         r1010413chall.pdf distributed to User2@DomainA.com
    BTP1010         r1010413chclosed.pdf distributed to User2@DomainA.com
    BTP1010         r1010413chcomp.pdf distributed to User2@DomainA.com
    BTP1010         r1010413chnoncomp.pdf distributed to User2@DomainA.com
    BTP1010         r1010413chall.pdf distributed to User3@DomainA.com
    BTP1010         r1010413chclosed.pdf distributed to User3@DomainA.com
    BTP1010         r1010413chcomp.pdf distributed to User3@DomainA.com
    BTP1010         r1010413chnoncomp.pdf distributed to User3@DomainA.com

So, the question is: What needs to be done to get the RC JOB to fail when there's a failure in the execution, or connection, of one of its TASKS?

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

So you are saying - you think the behavior should be if one task fails, the entire thing should stop and have a failure for the Reportcaster Job?

Hi Prarie,

Yep, that's what I think. Consider this:
Task 1, which does stuff which is required by task 2, fails.
Task 2 should not even run. imho

I know that some error checking in task 2 should be, and is, done. However, shouldn't the RC JOB fail if a task fails?

Hi Doug,

I think in that case you would put TASK 1 in PRE-PROCESSING.

I see your point, but then on the other hand if the Tasks are independent of each other, you would not necessarly want the entire thing to fail if one fex did.

New Feature Request?

I agree to "I think in that case you would put TASK 1 in PRE-PROCESSING.". However, this one RC jobs has 41 tasks.

I agree to "...on the other hand if the Tasks are independent of each other, you would not necessarily want the entire thing to fail if one fex did."

But, on the other hand if the Tasks ARE dependent on each other, you would want the entire thing to fail if one fex did.

Fortunately, our scheduler, OpCon, executes a script which kicks off the RC job and checks for errors. Thus, Opcon, sees a task failure as a job failure and notifies the powers to be accordingly. But, that stills leaves the situation for those who depend only on RC and its "On Error" messages.

The bottom line: Ya Gotta read those Full Notification regardless of what you may see at the top of them...

Yes we have Control-m that kicks of Reportcaster jobs and thinks things like that are errors and we get Tickets opened.

Have to be careful what you put out there.

Yes you have to read the entire thing.

Hope all is well with you..

Thanks Prarie,

I'm being careful what I'm putting out there and reading all the notifications. I'm doing fine, as I hope you are too.

Doug

PS: was your "out there" referring to something I posted on FocalPoint? Or ReportCaster? Or someplace else?

Control-M or other 3rd party scheduler.

So, RC continue to process all the remaining jobs even after one ends in error...

Back to more error handling

The Report Caster "Error" condition is not what it seems. It only has an error if no report is distributed.

What I have done to get around this is create a single wrapper program that executes all of the tasks that I want to run. At the end of the wrapper I generate a one line dummy report, which RC then gets to distribute.

At the end of each of the tasks (read focexecs) I add
-QUIT FOCUS
with a check for &FOCERRNUM to cause the quit to execute. If the focexec works ok, I do not do the quit. If there is an error, the quit will execute.

This will terminate the focexec and the wrapper, so no additional tasks are run. It will also cause ReportCaster to display an error on the status, as the dummy report is not sent.

I hope this helps.

That's Very Interesting. You're definitely thinking outside the box (which is a good thing). I'll keep this in mind for the next re-write of the associated app and for future RC apps.
♦