SCANTIME parameter
Summary
- Default value
- 0
- Parameter type
- System
- Where set
- User 0 CCAIN parameters
- Related products
- SirScan
- Introduced
- Before Sirius Mods 6.7
Description
This parameter indicates the maximum amount of time between SirScan “heartbeat” messages, and it must have a value between 0 and 3600, inclusive. These heartbeat messages are RK type audit messages, and they contain identifying information about the thread such as userid, terminal ID, and IP address and port number for Janus server threads.
SCANTIME indicates the maximum number of seconds between journal messages for a thread before a heartbeat message is issued. If a message is about to be sent to the journal for a thread, and it has been more than SCANTIME seconds since the last heartbeat message, then the heartbeat message is first sent to the journal. This means that if a journal message is found for a thread, the userid and other identifying information can always be found by looking backwards in the journal no more than SCANTIME seconds.
The default value for SCANTIME of 0 means that heartbeat messages are not logged. If SCANTIME is set to a positive value up to its maximum value of 3600, the SirScan heartbeat messages will be logged to the journal.
If SCANTIME is set to a non-zero value, the SIRSCAN subsystem detects this and, on the scan specification screen, gives users the option of reading an extra SCANTIME seconds on every interval collected from the journal. The extra SCANTIME seconds read are before the start of the requested interval. While the data from the extra SCANTIME seconds worth of journal entries is not formatted, it is scanned for the heartbeat messages, and any information in those messages is saved for each thread. In this way, all messages for all threads after the start of the requested interval can be deterministically associated with a userid, terminal ID, and IP address and Janus port for Janus server requests.
The cost of getting this deterministic behavior is the overhead of scanning an extra SCANTIME seconds worth of journal. If scanning is being done in auto-refresh mode, each refresh (attempt to move past the current bottom) will cause an extra SCANTIME seconds to be scanned. This means that the setting of SCANTIME involves a trade-off between the number of heartbeat messages logged to the journal and the overhead of scanning an extra SCANTIME seconds of journal on every SirScan browse request. The bigger the value of SCANTIME, the fewer heartbeat messages will be logged, but the more journal records would need to be scanned on each SirScan browse request. A small value of SCANTIME will, of course, have the opposite effect.
Since journal messages tend to be bunched (when a thread gets one audit message logged it is likely to get several around the same time), there is probably not a significantly higher cost to a relatively small SCANTIME, like 10 or even 5, than to a much larger one, like 60. On the other hand, the amount of extra work performed by SirScan associated with the extra SCANTIME second scan for each browse request will be roughly proportional to the size of SCANTIME. All this would suggest using a fairly small SCANTIME: a value of 10 might be a good starting point.
If you are setting SCANTIME for the first time in an Online, it is prudent to anticipate a 3% increase in journal usage, though the actual increase will almost undoubtedly be much less than that (probably less than even 1%).
Note: The heartbeat message can even be useful outside of SirScan. Since the heartbeat messages are regular RK type messages, they can be viewed with AUDIT204 as well as SirScan.
This means that if one is using AUDIT204 for a previous run's journal, and you want to find entries for a particular userid in a particular time interval, you can simply request from AUDIT204 all records for all users in the desired interval plus SCANTIME seconds before. By doing so, you can be certain that any messages formatted by AUDIT204 will be preceded by a message identifying the user associated with that message.
If a site is not authorized for SirScan, this parameter will have no effect.