Are there any best practices to alert if ReportCaster jobs stay in queue for long time other than the use of a 'System Scheduler', such as OpCon, which kicks of the RC Job and can track Max Run Times ?

I'm looking for a solution which is a total WebFOCUS solution, preferably something within RC.

This is for WebFOCUS 8.1.

Thanks in Advance,
Doug

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

We have several RCaster jobs that report about the RCaster status on a daily basis.

The RCaster schedules, jobs and logs are all in an MS SQL database in our case (that's one of the install options).

One of the issues with that database is that all the timestamps are at some unusual time-zone offset; we found no way to translate those to local time with just WebFOCUS code, but passthru SQL does the trick.

Wep,

There was an article written many years ago that gives some insights into conversion of that time value - link.

There are other articles at that location which are very useful.

T

Thanks Guys, and Susannah,

I do like those solutions. But, they don't, as far as I can see, address my question.

I know that a System Scheduler which kicks off the RC Job can be set to see how long a job runs (Max Run Time = ## Minutes). But, is there a way for a RC job to monitor itself as far as max run time? Or will this be a NFR?

Thanks, Doug

Doug, I'm not sure that RCaster supports such a feature. In fact, I think it just passes its jobs on to the Reporting Server. You can set certain limits on the agents for each service, so some control is possible.
In WF7.7 we used to have separate services in the WFRS for user-initiated jobs and for RCaster initiated jobs. RCaster jobs had wider limits to prevent them from aborting too early. We haven't been able to set WF8.1 up like that, but apparently that's back in 8.2, or at least planned for a future release.

The big problem with limiting time on RCaster jobs is what you do once a job exceeds the time limit. Do you gain anything by aborting it? Perhaps it's just a regular job on a growing set of data that takes longer and longer each day until it hits the limit and will be aborted. Which means that the files it normally creates are either unusable or outdated, depending on how you handle exceeding the time limit. You probably don't want to abort those accidentally.

Instead, what you can do from RCaster is run a daily job that measures how long a job took, or if it's still running, how long it's been running. Exceptionally long run-times could then be reported back as the result-report of that job.

That raises one question that I do not know the answer to: What happens if an RCaster job is still running when RCaster reaches that jobs next runtime? Does it still start the job? Does it wait for the running one to complete? Does it log an error?


@Tony: I read that article and the solution looked far too complicated to me. And complicated code tends to contain bugs. In our experience it's better to rely on well-tested code from larger 3rd parties, for example by leveraging the built-in date/time handling in MS SQL.

It's not hard to obtain the time-zone difference between local time and UTC (or GMT or Zulu-time). For the logtime fields in RCaster's BOTLOG, we simply put a D32 as usage in our master (or is that default?), so that we get it back as a number. That number is relative to 1-1-1970 UTC, which isn't too hard to convert to a datetime in UTC.

In fact, what we did was a little smarter; we used the time zone offset to UTC to create a local time based epoch:

SQL SQLMSS PREPARE SQLOUT FOR
SELECT GETDATE() - GETUTCDATE() AS DIFF_UTC, ' ' AS DUMMY;
END

DEFINE FILE SQLOUT
	EPOCH_AT_TZ/HYYMDs = HADD(DIFF_UTC, 'yy', 70, 8, EPOCH_AT_TZ);
END
TABLE FILE SQLOUT
PRINT EPOCH_AT_TZ
BY DUMMY
ON TABLE HOLD AS TZINFO FORMAT FOCUS INDEX DUMMY
END

Use that table in a Carthesian product with your BOTLOG timestamps and conversion is a relative piece of cake.

Hi Doug

I pinged the product manager about this. If you are licensed for the Web Services Enablement feature of WebFOCUS you could make a RESTful Web Service call to get the number of jobs in the queue or to query the status of a particular job to see if it is in the queue, running or finished.

Not sure if that is an option for you..

Thanks Guys,

Chuck: I'll check that out. I really like RC and have so many NFRs for it to make it even better. This is just one: a self-contained RC monitor. I'll check out other options and close this for now.