Admin: 1 revision

2016-11-01T20:29:11Z

1 revision

← Older revision	Revision as of 20:29, 1 November 2016
(No difference)

JAL: /* Two types of refresh */

2016-11-01T18:45:59Z

Two types of refresh

New page

The refresh process checks the usage and growth of file tables, comparing these to threshold values, and it updates the <var class="product">SirFile</var> database.

==Two types of refresh==
You can request a refresh operation to run once or periodically:
<ol>
<li>A one-time refresh runs in the <var class="product">Model 204</var> thread of the user requesting the refresh. It can be specified for a single file or for all files that <var class="product">SirFile</var> can access.
You invoke a one-time refresh using any of these:
<ul>
<li>The [[SirFile main menu]] <var>ADD</var> command, <var>REFRESH</var> command,
or the PF12 key</li>

<li>The PF12 key on the [[SirFile file tables screen|file tables]], [[SirFile#Getting started|system default thresholds]], or [[SirFile single file thresholds|single file thresholds]] screen. </li>

<li>The <var>SIRFILE BATCH</var> command.

The <var>SIRFILE BATCH</var> command is usually invoked only in a [[Using HLI and batch configurations#BATCH204|BATCH204]] jobstream, to be run when files are not open for update by any Online. See [[#Running SirFile under BATCH204|Running SirFile under BATCH204]], below.</li>
</ul></li>

<li>A periodic refresh, which repeats at a specified time interval, is also called the Background Monitor. This can be invoked by:
<ul>
<li>The PF5 key of the [[SirFile Background File Monitor screen|Background File Monitor screen]].
This runs the refresh on an [[Sdaemons|sdaemon]] thread, that is, on a different thread from the requesting user. </li>

<li>The <var>SIRFILE BACKGROUND interval</var> command.
This runs the refresh on an sdaemon thread, and it may be useful in the Online's User 0 stream. </li>

<li>The <var>SIRFILE SDAEMON interval</var> command.
This runs the refresh on the thread of the requesting user. It is most often invoked by a [[BATCH2 (TCP/IP)|BATCH2]] or <var>[[IODEV parameter|IODEV]]</var> 3 thread. </li>
</ul>

[[#Invoking background monitoring|Invoking background monitoring]], below, further discusses considerations of periodic refreshes. </li>
</ol>
Whenever the refresh operation is performed, it can consume considerable resources if it calculates the <var>CFULLP</var> (Table C percentage full) value.
One of the values specified on the system thresholds screen is
whether to allow file-by-file determination of the <var>CFULLP</var> calculation:
<ul>
<li>If file-by-file <var>CFULLP</var> determination is allowed, <var>CFULLP</var> is calculated during any type of refresh, for exactly those files that are specified as having the <var>CFULLP</var> calculation performed. </li>

<li>If <var>CFULLP</var> calculation is not determined on a file-by-file basis, the calculation is performed for all files by the <var>SIRFILE BATCH</var> command, and is not performed by any other type of refresh. </li>
</ul>

Messages to users and to the audit trail are only sent during a periodic refresh.

==The refresh operation details==
The refresh process makes a list of all files already in its database,
then it adds to the list any files that are currently open in the Online.
After this, it runs through the following process for each file on the list:
<ol>
<li>It checks if a file-specific threshold exists. If not, it compares the file to the system default thresholds. </li>

<li>If any value in the file exceeds a threshold value, a record is stored
for the file, and a warning is posted which causes the file to be
highlighted on the SirFile main menu. </li>

<li>If the file has not exceeded any thresholds and at least one sample
record has been stored for the file, <var class="product">SirFile</var> performs a simple linear regression to predict when the file will fill.
If the file-full date falls within the specified number of days of advance warning (as shown on the [[SirFile single file thresholds|single file threshold screen]]), SirFile posts a prediction and a message to the file.
The file will now appear highlighted on the main menu and on the [[SirFile file tables screen|file tables screen]]. </li>

<li>If no prediction or warning is posted to the file, <var class="product">SirFile</var> performs a cleanup of any old warnings, predictions, or messages for the file. </li>

<li>If the refresh process is running Online, and <var class="product">SirFile</var> encounters a file
in its database that it cannot open — because it did not get
added to the <code>SIRFILE</code> subsystem definition, or because the file is not allocated to the region — you are prompted for a password. </li>
</ol>

==Invoking background monitoring==
<var class="product">SirFile</var>'s background monitor runs as a special user in the <code>SIRFILE</code> subsystem to perform a periodic refresh.
Messages to users and the audit trail are sent only during a periodic refresh (that is, by the background task).

Any user ID can be the background monitor, and any <var class="product">SirFile</var> user can initiate the background task.
The most useful way to run the background monitor is in one of the [[Sdaemons|sdaemon]] IODEVs set up in the Online.
If you are going to run the background file monitor in an
sdaemon, you should allocate an extra one explicitly for this task.
Failing to allocate an extra sdaemon can slow down other jobs initiated from other products that require sdaemon servicing.

When the background monitoring task is sent to an sdaemon, the task appears as the sdaemon thread number and the user ID of the submitting user.
The sdaemon sits in a WAIT state until the specified number of minutes has passed, then it wakes up and runs a <var class="product">SirFile</var> database refresh, sends warnings as appropriate, then returns to a "sleep" state.

You can bump the background task just as you bump any user.
To change the time parameter for the background task, it should be bumped and resubmitted.

The PF5 key from the [[SirFile Background File Monitor screen]] runs the monitoring task in an sdaemon. You can also use one of the following commands to initiate the task:
<table class="thJustBold">
<tr class="head"><th>Command</th><th>Description</th></tr>

<tr><th nowrap>SIRFILE BACKGROUND interval</th>
<td>This command, entered at command level or inserted in the User 0 stream, initiates the background task under an sdaemon.

<var class="term">interval</var> specifies the number of minutes the background task should sleep between refresh operations. This required value must be between 1 and 1440 (24 hours). 

If no sdaemon is available or if the background task is already running, the submitting user is warned, and the request is ignored.</td></tr>

<tr><th>SIRFILE SDAEMON interval</th>
<td>This command, entered at command level, causes the session to become the background task.

<var class="term">interval</var> specifies the number of minutes the background task should sleep between refresh operations. This required value must be between 1 and 1440 (24 hours). 

The command may be placed in a BATCH2 or IODEV3 input stream, or it may be typed at command level from any terminal.
Typing this command on a terminal will cause that session to become the background <var class="product">SirFile</var> task:
that is, it will enter a "sleep" state that is not interruptable unless it is bumped.</td></tr>
</table>

Note: You can also use the <var>SIRFILE BATCH</var> command to invoke a single refresh; [[#Running SirFile under BATCH204|Running SirFile under BATCH204]], below, describes the most useful way to do this. 

==Running SirFile under BATCH204==
Running <var class="product">SirFile</var>'s database refresh in batch has two advantages over running it in the Online:
<ol>
<li>It allows the database refresh to be scheduled on a regular basis by a job scheduling system.</li>

<li>It allows the most expensive processing in <var class="product">SirFile</var> to be run in off-hours.</li>
</ol>

In addition, if you have specified <code>N</code> for the following prompt
on the [[SirFile#Getting started|system default thresholds screen]],
the <var>CFULLP</var> statistic is only calculated if the refresh is run via the <var>SIRFILE BATCH</var> command:
Collect CFULLP only on specified files

<var>CFULLP</var> is a more accurate measure of the full status of Table C, but it requires that a <var>TABLEC</var> command be executed, which can be a very resource-intensive operation.

Following is a sample job fragment and CCAIN stream showing the <var class="product">SirFile</var> refresh being run in [[Using HLI and batch configurations#BATCH204|BATCH204]].
<nowiki>//SIRFILE JOB (0) 'Batch Refresh',CLASS=X
//REFRESH EXEC PGM=BATCH204,SYSOPT=187
//...
//CCASYS DD DSN=M204.CCASYS,DISP=SHR
//CCAGRP DD DSN=M204.CCAGRP,DISP=SHR
//SIRFILE DD DSN=M204.SIRFILE,DISP=SHR
//SIRLOCAL DD DSN=M204.SIRLOCAL,DISP=SHR
//PROCFILE DD DSN=M204.PROCFILE,DISP=SHR
//PROCFIL2 DD DSN=M204.PROCFIL2,DISP=SHR
//...
//CCAIN *
NFILES=99,NDIRS=99,NDCBS=99,NUSERS=2,NSERVS=2,...
IODEV=15,POLLNO=1,NOTERM=1
LOGON filemanagr
password
OPEN FILE PROCFILE1
password
OPEN FILE PROCFIL2
password
...
SIRFILE BATCH
EOJ
/*
//
</nowiki>
The job is simply a BATCH204 job that contains CCASYS and CCAGRP, and it
has a DD card for any file <var class="product">SirFile</var> is going to monitor.
The <code>IODEV=15</code> statement is required; change it to <code>IODEV=nn</code> if
you reset the <var>SDAEMDEV</var> parameter to nn.
The <var>[[SYSOPT parameter|SYSOPT]]</var> value for the job must allow for the use of groups and [[Application Subsystem development|application subsystems]].
If any file is not yet in the <var class="product">SirFile</var> database or requires a password to open, it should be opened explicitly in the CCAIN stream.

The command <var>SIRFILE BATCH</var> tells the <code>SIRFILE</code> subsystem to run through the
[[SirFile refresh process|refresh process]], including <var>[[TABLEC command|TABLEC]]</var> calculations for <var>CFULLP</var> (Table C
percentage full) if <var>CFULLP</var> allocation is not determined file-by-file.

Note: A file must be open with File Manager
privileges (<var>PRIVDEF</var> must contain the X'8000' bit) in order for the <var>TABLEC</var> command to operate.
When <var class="product">SirFile</var> adds files to its application subsystem
definition, it adds them with privileges X'0221' to [[SCLASS]] <code>USERS</code> and X'8221' to SCLASS <code>ADMIN</code>.
If a site wants to run the batch job with <var>TABLEC</var> commands for each file, the logged-on user in the batch job must be in the <code>ADMIN</code> SCLASS.


Users may customize their run by manually changing privileges for specific files in the <code>USERS</code> SCLASS to X'8221'.
Then, running <var>SIRFILE BATCH</var> with a user ID from the <code>USERS</code> SCLASS will only calculate <var>TABLEC</var> for the files with high privileges.
Note: The output will show a failure of the <var>TABLEC</var> command for all files that have privileges that are too low.


==See also==
{{Template:SirFile topic list}}

[[Category:SirFile]]

SirFile refresh process - Revision history

Admin: 1 revision

JAL: /* Two types of refresh */