SirFile: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (1 revision)
m (→‎SirFile topics: link repair)
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
'''SirFile''' is a comprehensive facility for monitoring the physical storage utilization of
==Overview==
[[Model 204]] database files and warning users of the need for file reorganizations..
<var class="product">SirFile</var> is a comprehensive facility for monitoring the physical storage
utilization of <var class="product">Model&nbsp;204</var> database files and warning users of the need for file reorganizations.
 
<var class="product">SirFile</var> requires only a single screen of setup information to determine "thresholds," after which it automatically performs a pass
through the Online database files, checking to see if any file has exceeded a threshold.
The process that evaluates files is called the <b>refresh process</b>.
 
The refresh process performs two types of checks:
<ul>
<li>It compares the current state of each file against the threshold
settings to see if any file statistic is above the critical value for
that statistic. </li>
 
<li>It maintains a database of table usage information which it uses
to determine rate of growth and to predict when thresholds will be
exceeded. </li>
</ul>


<var class="product">SirFile</var> is part of the [[ULSPF | UL/SPF]] family of products from [[Sirius Software]].  As with all UL/SPF products, <var class="product">SirFile</var> requires the installation of the [[Sirius Mods]], with a version equal to or higher than the <var class="product">SirFile</var> version.
During the initial database load, all files added to the <var class="product">SirFile</var> database are compared to the system default thresholds.
After the initial load, you can override the system default thresholds with
file-specific thresholds for files that require higher or lower levels of monitoring.


==Overview==
If any file table is above a threshold, <var class="product">SirFile</var> flags the file with a
warning, causing it to be highlighted in <var class="product">SirFile</var>.
Once <var class="product">SirFile</var> has stored at least one sample snapshot of a file, it begins calculating
the date at which each table will fill &mdash; assuming any table is showing growth.
If the predicted fill date falls within a user-settable number
of days, <var class="product">SirFile</var> posts a prediction to the file, and the file is
highlighted in the <var class="product">SirFile</var> screens.
When a prediction or warning is posted using a periodic refresh,
a message can also be sent to the audit trail, as well as to a list of user IDs.


<var class="product">SirFile</var> requires only a single screen of setup information to determine "thresholds," after
The file parameters and thresholds that are evaluated for table-full status are
which it automatically performs a pass through the online database files, checking to see
described below in [[#Getting started|Getting started]].
if any file has exceeded a threshold. The process that evaluates files is called the
refresh process. The refresh process performs two types of checks:


Although the database refresh portion of <var class="product">SirFile</var> is quite efficient, it is the most expensive operation in <var class="product">SirFile</var>.
Therefore, several options are provided for determining when to:
<ul>
<ul>
<li>Perform a refresh. </li>
<li>Calculate <var>CFULLP</var>, the percentage full of Table C, which is generally the most expensive of the refresh calculations. </li>
</ul>
For more information, see [[SirFile refresh process]], for a complete description of the refresh process, including a method that can be useful for calculating CFULLP.


<li>It compares the current state of each file against the threshold settings to see if any
The <var class="product">SirFile</var> refresh process is always in "learn" mode.
file statistic is above the critical value for that statistic.</li>
Any file that is open when a <var class="product">SirFile</var> refresh is run is automatically added to the <var class="product">SirFile</var> database, using the default thresholds for comparison.


<li>It maintains a database of table usage information which it uses to determine rate of
==Setting up==
growth and to predict when thresholds will be exceeded.</li>


===Make files available for SirFile monitoring===
For <var class="product">SirFile</var> to collect information on a file, it must be open in the
region by some user or subsystem.
To guarantee that certain files are included in the initial load, those files can be opened manually before
initiating the refresh process.
Because storing user-entered passwords would violate most sites' security, <var class="product">SirFile</var> uses a variety of methods
to make files available to itself without needing to store passwords:
<ul>
<li>If a file is open in the region, or <var class="product">SirFile</var> manages to open the
file with default privileges, the file is added to the database and no
user intervention is required.
<p>
If a file requires a password, you receive a [[#File password screen|prompting screen]].
</p></li>
<li>The first time <var class="product">SirFile</var> collects data for a file, it adds the file to
its [[Application Subsystem development|Application Subsystem]] definition (with low privileges in the
"Users" [[Application Subsystem development#User class|SCLASS]] and high privileges in the "Admin" SCLASS).
Thereafter, no password is required for <var class="product">SirFile</var> to open the file.
Files that are prefixed "CCA" are exempted from this operation, as these files cause problems in [[System requirements for Application Subsystems#Overview of the SUBSYSMGMT interface|SUBSYSMGMT]]. </li>
<li>If <var class="product">SirFile</var> has a file in its database that requires a password, and
a non-periodic refresh is running (other than <var>[[SirFile refresh process#Running SirFile under BATCH204|SIRFILE BATCH]]</var>),
you are prompted for the password.
<p>
If <var>SIRFILE BATCH</var> or a periodic refresh is running,
<var class="product">SirFile</var> skips any file it cannot open. </p></li>
</ul>
</ul>


During the initial database load, all files added to the <var class="product">SirFile</var> database are compared to
====File password screen====
the system default thresholds. After the initial load, the user may override the system
When <var class="product">SirFile</var> needs to open a file, it first tries to do it without a password.
default thresholds with file-specific thresholds for files that require higher or lower levels
If that fails you are prompted for a password with the following screen:
of monitoring.
 
<p class="caption" style="width:475px">File open screen</p>
<p class="figure">[[File:SfileOpenPwd.png|475px]]</p>
 
<var class="product">SirFile</var> requires only read privileges in files being monitored.
 
If you are being prompted for passwords in the middle of a refresh
operation, the PF key choices are as shown in the figure, and have the
following actions:
<table class="thJustBold">
<tr><th>PF3</th>
<td>Cancel the refresh and return to the previous screen.</td></tr>
 
<tr><th>PF6</th>
<td>Skip the current file in the refresh.</td></tr>
 
<tr><th>PF9</th>
<td>Skip the this and the rest of the files in the refresh that require manual entry of passwords.</td></tr>
</table>
 
Otherwise, for example if you are prompted for a password due to
an <var>OPEN</var> command, the only PF key choice is:
<table class="thJustBold">
<tr><th>PF3</th>
<td>Cancel the open and return to the previous screen.</td></tr>
</table>
 
===Ensure file update access===
Besides its subsystem procedure file and the <var class="product">RKTools</var> file <code>SIRLOCAL</code>, <var class="product">SirFile</var> requires update access to [[System requirements for Application Subsystems#Overview of CCASYS|CCASYS]].
 
All other files, even if they are defined to <var class="product">SirFile</var> as optional subsystem files, are closed and freed from
the subsystem at the end of each user's <var class="product">SirFile</var> session.
This is done to reduce enqueuing problems.
 
==Getting started==
<ol>
<li><var class="product">SirFile</var> is installed as a private application subsystem, as described in [[RKTools installation]].
To access the system, you enter <code>SIRFILE</code> on the
<var class="product">Model&nbsp;204</var> command line of the Online containing the software. </li>
 
<li>You are presented with an initial system default thresholds screen. You may accept the defaults or change any of the supplied settings. The table below explains each of the threshold entities.
<p>
<var class="product">SirFile</var> records are fairly small and you shouldn't be too concerned about minimizing the amount of stored data:  A year's worth of data for
a single file will occupy only about one <var class="product">Model&nbsp;204</var> page if a record is kept per week. </p>
<p class="noteN">
Before you press the PF12 key to save the settings and initiate the <var class="product">SirFile</var> database refresh process, consider opening additional files (see [[#openfile|step 3]], below). </p>
 
<p class="caption" style="width:475px">System default thresholds</p>
<p class="figure">[[File:SfileThresholds.png|475px]]</p>
<p>
This screen is also accessible by the PF11 key from the [[SirFile main menu|File Monitor]] screen or from the [[SirFile file tables screen]] screen, if the cursor is not on a file name or file statistics line, respectively. </p>
<p>
The default thresholds screen is initially populated with a set of defaults that are adequate for most file monitoring needs.
The thresholds are: </p>
 
<table class="thJustBold">
<tr><th>ARETRIES</th>
<td>[[Table A (File architecture)|Table A]] retries indicate a failure of the Table A hashing algorithm to find a slot on a Table A page to store field information.
Table A is usually the smallest table in a <var class="product">Model&nbsp;204</var> database file, but it is accessed every time a field name is referred to in SOUL or IFAM code,
so it is important that Table A operate as efficiently as possible.
In most cases, <i>any</i> <var>ARETRIES</var> are too many, and for this reason, the <var>ARETRIES</var> default is very small.</td></tr>
 
<tr><th>BFULLP</th>
<td>Percentage full of [[Table B (File architecture)|Table B]]. This is the percentage of record slots currently used, calculated as <var>[[BHIGHPG parameter|BHIGHPG]]</var>/<var>[[BSIZE parameter|BSIZE]]</var>.
Table B holds the actual data in a <var class="product">Model&nbsp;204</var> file and is usually the largest table.</td></tr>
 
<tr><th>CRETRIES</th>
<td>[[Table C (File architecture)|Table C]] hashing algorithm retries. This statistic indicates that Table C, a hashed data structure, is becoming full, so the algorithm which determines placement of new pointers in the table must run repeatedly in order to find an empty slot. There is no fixed measure of how many retries indicate a critical condition for Table C.</td></tr>
 
<tr id="cfullp"><th>CFULLP</th>
<td>Percentage full of Table C. Like Table A, Table C begins to exhibit hash retries when the data in it reaches a certain density.
There is no strict formula for the maximum fullness of Table C for a given file, but a rule of thumb is that retries will begin to appear when Table C is 70 to 80% full.
<var>CFULLP</var> is a more accurate measure of Table C full status than <var>CRETRIES</var>, but it is very expensive to calculate.
<i>For this reason, unless you determine <var>CFULLP</var> calculation file-by-file, it is only calculated by the [[SirFile refresh process#Running SirFile under BATCH204|SIRFILE BATCH]] command.</i></td></tr>
 
<tr><th>DFULLP</th>
<td>[[Table D (File architecture)|Table D]] percentage full. Table D can fill either as a result of index information or SOUL procedures. Percentage full in Table D is calculated as the number of D pages used (<var>[[DPGSUSED parameter|DPGUSED]]</var>) divided by <var>[[DSIZE parameter|DSIZE]]</var>.</td></tr>
 
<tr><th>EXTNADD</th>
<td>Number of extension records. Extension records occur when the information added to an existing record exceeds the usable space left on a Table B page.
Extension records are not a sign of a file full condition pending, and in some record structures they may be unavoidable.
For this reason, the <var>EXTNADD</var> threshold may be set very high.
However, extension records cause inefficiencies in storage and retrieval, and for some file designs should be taken as a sign that Table B parameters are out of balance.</td></tr>
 
<tr><th>OVFLADD</th>
<td>Addition of records to overflow areas. Overflow records may occur in either sorted or hash files.</td></tr>
 
<tr><th>EOVFLADD</th>
<td>Addition of records to extra overflow areas. Records may be added to Extra Overflow areas in sorted files when the Overflow area is full.</td></tr>
 
<tr><th>SPILLADD</th>
<td>Number of records that have "spilled" from the preferred overflow area into secondary overflow areas or the overflow area prior to the appropriate sort group. Spilled records are stored and retrieved less efficiently than other records.</td></tr>
 
<tr><th>Number of historical records to keep per file</th>
<td>Number of sample records to keep for each file. <var class="product">SirFile</var> requires at least one sample to be stored for any given file in order to make predictions about file-full conditions.
The default value of 99999 records means that <var class="product">SirFile</var> does not throw away old data, as long as the file <var>[[CREATE command: File|CREATE]]</var> date does not change.</td></tr>
 
<tr><th>Minimum number of days between stored samples</th>
<td>Minimum number of days that must pass between samples being stored for any particular file.
This setting allows users to run the refresh as often as they like without <var class="product">SirFile</var> storing excessive amounts of data.
The default of 7 ensures that no more than one record a week is maintained for any file unless that file breaks a threshold.</td></tr>
 
<tr><th># of days advance warning on threshold exceeded</th>
<td>Number of days prior to a predicted "threshold exceeded" condition <var class="product">SirFile</var> should post a warning.
During a refresh, <var class="product">SirFile</var> uses the current file table values and the historical file information to calculate when the file will exceed each threshold (if positive growth is detected in a threshold value).
If the number of days predicted falls within this value, a prediction and message are posted to the file, and the file appears highlighted on the SirFile main menu.</td></tr>
 
<tr><th>Collect CFULLP only on specified files?</th>
<td>Specifying <code>Y</code> to this prompt allows <var class="product">SirFile</var> to collect the <var>CFULLP</var> statistic only on files specified by the user. Collecting <var>CFULLP</var> requires a <var>[[TABLEC command|TABLEC]]</var> command, which can be very I/O intensive.
<ul>
<li>When <code>Y</code> is specified at this prompt, you must specifically request each file the <var>TABLEC</var> command is to be run against, entering <code>Y</code> at the following prompt in the [[SirFile single file thresholds]] screen:
<p class="code"><nowiki>Collect CFULLP for this file
</nowiki></p></li>
 
<li>When <code>N</code> is specified at this prompt, <var>CFULLP</var> calculations are performed only by the <var>SIRFIELD BATCH</var> command.</li>
</ul></td></tr>
</table> </li>
 
<li id="openfile">Open or close additional files.
<p>
Use the following commands: </p>
<table class="thJustBold">
<tr><th>OPEN <i>filename</i></th>
<td>Opens a file. As data can only be collected for files that <var class="product">SirFile</var> already knows about, or files that are currently open by any user, you may want to manually open a file before running a refresh to guarantee the file is included in the sample.</td></tr>
 
<tr><th nowrap>CLOSE <i>filename</i></th>
<td>Closes a file. Any file that the <var class="product">SirFile</var> user has open can be closed, except SIRFILE, SIRLOCAL and CCASYS (the required application subsystem files for <var class="product">SirFile</var>).</td></tr>
</table>
<p>
PF keys: </p>
<table class="thJustBold">
<tr><th>PF1</th>
<td>Accesses full-screen help.</td></tr>
 
<tr><th>PF3</th>
<td>Return to command level or previous screen.</td></tr>
 
<tr><th>PF9</th>
<td>Repeats the last command-line command.</td></tr>
 
<tr><th>PF12</th>
<td>Saves the file threshold defaults and invokes a <var class="product">SirFile</var> [[SirFile refresh process#Two types of refresh|one-time database refresh]].</td></tr>
</table>
</li>
</ol>
 
==SirFile topics==
The <var class="product">SirFile</var> documentation consists of the pages listed below.
This list is also available as a "See also" link from each of the pages.
 
For information about product changes and Model&nbsp;204 feature
support per <var class="product">SirFile</var> version, see
the [[M204wiki main page#rktools_notes|RKTools release notes]].


If any file table is above a threshold, <var class="product">SirFile</var> flags the file with a warning, causing it to be
For information about product error messages, see [[List of Model 204 messages#msir|MSIR. messages]].
highlighted in <var class="product">SirFile</var>. Once <var class="product">SirFile</var> has stored at least one sample snapshot of a file, it
begins calculating the date at which each table will fill — assuming any table is showing
growth. If the predicted fill date falls within a user-settable number of days, <var class="product">SirFile</var> posts
a prediction to the file, and the file is highlighted in the <var class="product">SirFile</var> screens. When a
prediction or warning is posted using a periodic refresh, a message can also be sent to
the audit trail, as well as to a list of user IDs.


The file parameters that are evaluated for table-full status are ARETRIES, BFULLP,
{{Template: SirFile topic list}}
CRETRIES, CFULLP, DFULLP, EXTNADD, OVFLADD, EOVFLADD, and SPILLADD.
The database refresh portion of <var class="product">SirFile</var> is quite efficient, however it is the most expensive
operation in <var class="product">SirFile</var>. Therefore, several options are provided for determining when to
perform a refresh, and for determining when to calculate CFULLP, generally the most
expensive of the refresh calculations.


==See also==
[[Category:SirFile]]
All Sirius <var class="product">UL/SPF</var> documentation is a available for download in PDF format at http://sirius-software.com/maint/manlist

Latest revision as of 21:55, 3 March 2017

Overview

SirFile is a comprehensive facility for monitoring the physical storage utilization of Model 204 database files and warning users of the need for file reorganizations.

SirFile requires only a single screen of setup information to determine "thresholds," after which it automatically performs a pass through the Online database files, checking to see if any file has exceeded a threshold. The process that evaluates files is called the refresh process.

The refresh process performs two types of checks:

  • It compares the current state of each file against the threshold settings to see if any file statistic is above the critical value for that statistic.
  • It maintains a database of table usage information which it uses to determine rate of growth and to predict when thresholds will be exceeded.

During the initial database load, all files added to the SirFile database are compared to the system default thresholds. After the initial load, you can override the system default thresholds with file-specific thresholds for files that require higher or lower levels of monitoring.

If any file table is above a threshold, SirFile flags the file with a warning, causing it to be highlighted in SirFile. Once SirFile has stored at least one sample snapshot of a file, it begins calculating the date at which each table will fill — assuming any table is showing growth. If the predicted fill date falls within a user-settable number of days, SirFile posts a prediction to the file, and the file is highlighted in the SirFile screens. When a prediction or warning is posted using a periodic refresh, a message can also be sent to the audit trail, as well as to a list of user IDs.

The file parameters and thresholds that are evaluated for table-full status are described below in Getting started.

Although the database refresh portion of SirFile is quite efficient, it is the most expensive operation in SirFile. Therefore, several options are provided for determining when to:

  • Perform a refresh.
  • Calculate CFULLP, the percentage full of Table C, which is generally the most expensive of the refresh calculations.

For more information, see SirFile refresh process, for a complete description of the refresh process, including a method that can be useful for calculating CFULLP.

The SirFile refresh process is always in "learn" mode. Any file that is open when a SirFile refresh is run is automatically added to the SirFile database, using the default thresholds for comparison.

Setting up

Make files available for SirFile monitoring

For SirFile to collect information on a file, it must be open in the region by some user or subsystem. To guarantee that certain files are included in the initial load, those files can be opened manually before initiating the refresh process. Because storing user-entered passwords would violate most sites' security, SirFile uses a variety of methods to make files available to itself without needing to store passwords:

  • If a file is open in the region, or SirFile manages to open the file with default privileges, the file is added to the database and no user intervention is required.

    If a file requires a password, you receive a prompting screen.

  • The first time SirFile collects data for a file, it adds the file to its Application Subsystem definition (with low privileges in the "Users" SCLASS and high privileges in the "Admin" SCLASS). Thereafter, no password is required for SirFile to open the file. Files that are prefixed "CCA" are exempted from this operation, as these files cause problems in SUBSYSMGMT.
  • If SirFile has a file in its database that requires a password, and a non-periodic refresh is running (other than SIRFILE BATCH), you are prompted for the password.

    If SIRFILE BATCH or a periodic refresh is running, SirFile skips any file it cannot open.

File password screen

When SirFile needs to open a file, it first tries to do it without a password. If that fails you are prompted for a password with the following screen:

File open screen

SirFile requires only read privileges in files being monitored.

If you are being prompted for passwords in the middle of a refresh operation, the PF key choices are as shown in the figure, and have the following actions:

PF3 Cancel the refresh and return to the previous screen.
PF6 Skip the current file in the refresh.
PF9 Skip the this and the rest of the files in the refresh that require manual entry of passwords.

Otherwise, for example if you are prompted for a password due to an OPEN command, the only PF key choice is:

PF3 Cancel the open and return to the previous screen.

Ensure file update access

Besides its subsystem procedure file and the RKTools file SIRLOCAL, SirFile requires update access to CCASYS.

All other files, even if they are defined to SirFile as optional subsystem files, are closed and freed from the subsystem at the end of each user's SirFile session. This is done to reduce enqueuing problems.

Getting started

  1. SirFile is installed as a private application subsystem, as described in RKTools installation. To access the system, you enter SIRFILE on the Model 204 command line of the Online containing the software.
  2. You are presented with an initial system default thresholds screen. You may accept the defaults or change any of the supplied settings. The table below explains each of the threshold entities.

    SirFile records are fairly small and you shouldn't be too concerned about minimizing the amount of stored data: A year's worth of data for a single file will occupy only about one Model 204 page if a record is kept per week.

    Before you press the PF12 key to save the settings and initiate the SirFile database refresh process, consider opening additional files (see step 3, below).

    System default thresholds

    This screen is also accessible by the PF11 key from the File Monitor screen or from the SirFile file tables screen screen, if the cursor is not on a file name or file statistics line, respectively.

    The default thresholds screen is initially populated with a set of defaults that are adequate for most file monitoring needs. The thresholds are:

    ARETRIES Table A retries indicate a failure of the Table A hashing algorithm to find a slot on a Table A page to store field information.

    Table A is usually the smallest table in a Model 204 database file, but it is accessed every time a field name is referred to in SOUL or IFAM code, so it is important that Table A operate as efficiently as possible.

    In most cases, any ARETRIES are too many, and for this reason, the ARETRIES default is very small.
    BFULLP Percentage full of Table B. This is the percentage of record slots currently used, calculated as BHIGHPG/BSIZE. Table B holds the actual data in a Model 204 file and is usually the largest table.
    CRETRIES Table C hashing algorithm retries. This statistic indicates that Table C, a hashed data structure, is becoming full, so the algorithm which determines placement of new pointers in the table must run repeatedly in order to find an empty slot. There is no fixed measure of how many retries indicate a critical condition for Table C.
    CFULLP Percentage full of Table C. Like Table A, Table C begins to exhibit hash retries when the data in it reaches a certain density.

    There is no strict formula for the maximum fullness of Table C for a given file, but a rule of thumb is that retries will begin to appear when Table C is 70 to 80% full. CFULLP is a more accurate measure of Table C full status than CRETRIES, but it is very expensive to calculate.

    For this reason, unless you determine CFULLP calculation file-by-file, it is only calculated by the SIRFILE BATCH command.
    DFULLP Table D percentage full. Table D can fill either as a result of index information or SOUL procedures. Percentage full in Table D is calculated as the number of D pages used (DPGUSED) divided by DSIZE.
    EXTNADD Number of extension records. Extension records occur when the information added to an existing record exceeds the usable space left on a Table B page.

    Extension records are not a sign of a file full condition pending, and in some record structures they may be unavoidable. For this reason, the EXTNADD threshold may be set very high.

    However, extension records cause inefficiencies in storage and retrieval, and for some file designs should be taken as a sign that Table B parameters are out of balance.
    OVFLADD Addition of records to overflow areas. Overflow records may occur in either sorted or hash files.
    EOVFLADD Addition of records to extra overflow areas. Records may be added to Extra Overflow areas in sorted files when the Overflow area is full.
    SPILLADD Number of records that have "spilled" from the preferred overflow area into secondary overflow areas or the overflow area prior to the appropriate sort group. Spilled records are stored and retrieved less efficiently than other records.
    Number of historical records to keep per file Number of sample records to keep for each file. SirFile requires at least one sample to be stored for any given file in order to make predictions about file-full conditions. The default value of 99999 records means that SirFile does not throw away old data, as long as the file CREATE date does not change.
    Minimum number of days between stored samples Minimum number of days that must pass between samples being stored for any particular file.

    This setting allows users to run the refresh as often as they like without SirFile storing excessive amounts of data.

    The default of 7 ensures that no more than one record a week is maintained for any file unless that file breaks a threshold.
    # of days advance warning on threshold exceeded Number of days prior to a predicted "threshold exceeded" condition SirFile should post a warning.

    During a refresh, SirFile uses the current file table values and the historical file information to calculate when the file will exceed each threshold (if positive growth is detected in a threshold value).

    If the number of days predicted falls within this value, a prediction and message are posted to the file, and the file appears highlighted on the SirFile main menu.
    Collect CFULLP only on specified files? Specifying Y to this prompt allows SirFile to collect the CFULLP statistic only on files specified by the user. Collecting CFULLP requires a TABLEC command, which can be very I/O intensive.
    • When Y is specified at this prompt, you must specifically request each file the TABLEC command is to be run against, entering Y at the following prompt in the SirFile single file thresholds screen:

      Collect CFULLP for this file

    • When N is specified at this prompt, CFULLP calculations are performed only by the SIRFIELD BATCH command.
  3. Open or close additional files.

    Use the following commands:

    OPEN filename Opens a file. As data can only be collected for files that SirFile already knows about, or files that are currently open by any user, you may want to manually open a file before running a refresh to guarantee the file is included in the sample.
    CLOSE filename Closes a file. Any file that the SirFile user has open can be closed, except SIRFILE, SIRLOCAL and CCASYS (the required application subsystem files for SirFile).

    PF keys:

    PF1 Accesses full-screen help.
    PF3 Return to command level or previous screen.
    PF9 Repeats the last command-line command.
    PF12 Saves the file threshold defaults and invokes a SirFile one-time database refresh.

SirFile topics

The SirFile documentation consists of the pages listed below. This list is also available as a "See also" link from each of the pages.

For information about product changes and Model 204 feature support per SirFile version, see the RKTools release notes.

For information about product error messages, see MSIR. messages.