Skip to main content

LASTRUN Files

When Sigmafine scheduler runs, for each Sigmafine database configured for execution, a “LASTRUN” file is created. The file is created in the same location as the main Scheduler service/executable folder. This file contains the bookmarks of the scheduling execution for the target database specified within the file name itself.

ClosedEXAMPLE: LASTRUN file name

Pimsoft.Sigmafine.Scheduler.exe.\<Sigmafine DB name\>.SF_SchedulerLastRun

Where:

Pimsoft.Sigmafine.Scheduler.exe = Fixed prefix

\<Sigmafine DB Name> = Name of the Sigmafine database

.SF_SchedulerLastRun = File name extension

Example:

Pimsoft.Sigmafine.Scheduler.exe.TestDevelopment.SF_SchedulerLastRun

LASTRUN files are key components for the execution of the Scheduler. The file contains the execution bookmarks for all the analyses configured with automatic execution. Each LASTRUN file is an XML text serialization of a .NET DataSet containing the following information:

  • NAME OF THE ANALYSIS (within the database specified in the LASTRUN file name).
  • LAST CASE OF THE ANALYSIS ELABORATED BY SCHEDULER: It refers the case end time of the latest case managed by Scheduler. Represented in UTC time
  • LAST RUN: It refers to the last execution time of the analysis. Represented in UTC time
  • LAST RUN LOCALE: It refers to the last execution time of the analysis, Represented in LOCAL time

Scheduler automatically creates the LASTRUN file during the initial (first) execution of the target database. The file gets created only when the database has at least 1 analysis to be configured for the automatic scheduler execution. The number of the analyses contained is directly inherited by the main SF_Scheduler table. In this respect, if the SF_Scheduler table has 4 analyses configured for execution, then the corresponding LASTRUN file for the same database will contain 4 records (one for each analysis).

In the case of a file deletion, the file is created automatically by the Scheduler with the following rules:

  • NAME OF THE ANALYSIS: Name of the analysis from SF_Scheduler table.
  • LAST CASE OF THE ANALYSIS ELABORATED BY SCHEDULER: Following the settings for “Skip Check-In”:
  • If 'Skip Check-In' is TRUE, no case is stored. The Scheduler will take the INITIALCASE column value of the corresponding analysis in the SF_SCHEDULER table.
  • If 'Skip Check-In' is FALSE, Cases will be evaluated by calling the GETLASTCASE API from AF-SDK of the corresponding analysis in the SF_SCHEDULER table. Scheduler takes the END TIME of the returned case. If no case is returned, then it takes the INITIALCASE column value of the corresponding analysis in the SF_SCHEDULER table.
  • LAST RUN: Same value of the LAST CASE OF THE ANALYSIS ELABORATED BY SCHEDULER.
  • LAST RUN LOCALE: Same value of the LAST CASE OF THE ANALYSIS ELABORATED BY SCHEDULER but converted in LOCAL time.

The LASTRUN file is read and converted (de-serialized) as a .NET DataSet at the beginning of every target database management or execution process. During the database execution, an internal in-memory image of the LASTRUN DataSet is automatically maintained. When the execution is over the target database is completed. It is at this point that the LASTRUN file is updated in the file system.

This mechanism, with an external file for managing the bookmarks of the execution, was introduced in version 4.6.5 of the Sigmafine Scheduler. It was designed for bypassing the limit of the check-in/check-out architecture of AF. The reasoning behind this change was to alleviate Sigmafine system issues that stemmed from non-standard interactions or abnormal terminations of the scheduler which caused tables to remain locked, affecting the execution of the Scheduler.

Note:

Important Info for LASTRUN file

Along a database execution the LASTRUN file must be writeable and available for Scheduler. A failure writing this file means that Scheduler cannot save the right bookmarks, forcing re-executions and user may experience 2 types of problem:

  • Performance problems due overlapping and unnecessary executions.
  • Analysis may not be running in the proper way (executions are not going forward as expected).

Example 'LASTRUN' File​