As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
I need to shift the start time of ~300 ReportCaster jobs by a few hours and want to do it in one pass across the backend. This function is controlled by the STARTTIME field, but there is also a NEXTRUNTIME field that is a Epoch value.
I think that the NextRunTime field drives the ReportCaster front end and a small informational message on the job properties screen, but not the actual job schedule itself.
Can anyone validate this or have experience tweaking schedules in this manner?
-ABTThis message has been edited. Last edited by: Kerry,
NEXTRUNTIME will act as a trigger to kick the schedule off..along with ACTIVE column on BOTSCHED ..when ACTIVE = Y and NEXTRUNTIME is <=current time the schedule runs... so NEXTRUNTIME is updated after every run...it is set according to STARTTIME...
If you change the STARTTIME of all the schedules thru a DML on BOTSCHED it shld be fine...schedules will still kick off as per the current NEXTRUNTIME...and then it gets updated with the new STARTTIME value...
thanks SashankaThis message has been edited. Last edited by: Severus.snape,
WF 7.7.03/Windows/HTML,PDF,EXL POC/local Dev Studio 7.7.03 & 7.6.11
NEXTRUNTIME will act as a trigger to kick the schedule off..along with ACTIVE column on BOTSCHED ..when ACTIVE = Y and NEXTRUNTIME is <=current time the schedule runs... so NEXTRUNTIME is updated after every run...it is set according to STARTTIME...
If you change the STARTTIME of all the schedules thru a DML on BOTSCHED it shld be fine...schedules will still kick off as per the current NEXTRUNTIME...and then it gets updated with the new STARTTIME value...
thanks Sashanka
Thanks for the quick reply, but I think that's not what I want to happen. If I move the StartTime out a couple hours later via DML/UPDATE query, it sounds as if the schedule will run once for the current NEXTRUNTIME (that still reflects the old STARTTIME value), update the NEXTRUNTIME value to the new time (a couple of hours later in this example), and then run again. Effectively running twice in the span of a couple hours. Do I understand your comments correctly?
Short of adding the equivalent number of milliseconds to NEXTRUNTIME to compensate for the added number of hours, what other ways are there to resolve this?
I got the NEXTRUNTIME being updated only after execution of schedule wrong.. I just did a test on my RC here...updating the STRTTIME is updating the NEXTRUNTIME immedietly ... so you can make the change...and the schedules would run with the new timestamp.. Please test it in the test environ if you can... But i think it will work OK.
thanks Sashanka
WF 7.7.03/Windows/HTML,PDF,EXL POC/local Dev Studio 7.7.03 & 7.6.11
Yes seems like when you update the STARTTIME field thru a SQL, Nextruntime is not updating itself --which is expected ...when you change the STARTTIME from RC applet NEXTRUNTIME is updating...
since you have a lot of schedules and updating via a SQL is best option...you would have to update NEXTRUNTIME also or let it run with current value and update itself..
thanks Sashanka
WF 7.7.03/Windows/HTML,PDF,EXL POC/local Dev Studio 7.7.03 & 7.6.11
<soapbox>If only updating NEXTRUNTIME were quite that easy... IBI has done their best to take an esoteric date/time format and layer additional complexity on it by storing it as an Alpha field, left padding it with zeros, and then storing the whole thing as milliseconds rather than the epoch standard of seconds. Really IBI? You doing this for sport? I believe the datatype you were looking for that day was INT, not CHAR.
I have dissected these stupid fields before and will do it again, but you win today. I'm going to give it to an intern to do manually. </soapbox>