RDF System Management Manual for J-series and H-series RVUs (RDF Update 13)

Exceeding the UPDATERFOPENTHRESHOLD Value
The UPDATERFOPENTHRESHOLD attribute enables RDF users to set a threshold value on the number
of files that can be opened by a RDF Updater process. The default value for this attribute is 80%
of the value of the Maximum Number of Concurrent File Opens for a RDF Updater process. The
value of Maximum Number of Concurrent File Opens is 3000. Therefore, the default threshold
value of UPDATERFOPENTHRESHOLD is 2400.
Set this value by using SET RDF command, when RDF is initialized. You can modify this value by
using ALTER RDF only when RDF is not running. When a RDF Updater exceeds this value, EMS
event 933 is generated. This event is generated, when the Updater has exceeded the threshold
value for the number of open files and wants to open a new file. This EMS event has no effect on
the Updater processing or its performance. The EMS event 933 is generated and Updater continues
normal processing.
When this situation occurs, you must stop RDF immediately and then rebalance the number of
audited files on the primary and backup volume of the affected updater so that you do not exceed
the specified threshold number of audit files on that volume. When you have rebalanced the audit
files, then reinitialize and reconfigure RDF using the INITTIME option. For more information, see
“Initializing RDF Without Stopping TMF (Using INITTIME Option)” (page 69).
Exceeding the Maximum Number of Concurrent File Opens
The maximum number of audited files a single updater can have concurrently open is 3,000. If
you have more than 3,000 audit files being replicated by a single updater, then it is possible that
the updater associated with the volume may report RDF event 813 - "Concurrent file opens exceeds
capacity". This happens if the updater has 3,000 files open and it must open a new file. Should
this occur, the updater immediately generates the RDF event 813, commits its current transaction,
closes all files, and restarts, which generates RDF event 837. When it restarts, it resumes processing
image audit at the audit record for the file that caused the problem. In this sense, the problem is
self-correcting, it does not impact updater performance, and it is safe for you to have more than
3,000 audited files on the volume. The danger comes when you have more than 3,000 audited
files on the volume and all of them need to be updated every 6-10 minutes on a regular basis. If
this happens regularly over a period of time, then it could cause the purger to stop purging files.
When this situation occurs, you must stop RDF as soon as possible and rebalance the number of
audited files on the primary and backup volume of the affected updater so that you have no more
than 3,000 audit files on that volume. When RDF has been stopped and you have rebalanced the
audit files, then reinitialize and reconfigure RDF using the INITTIME option. See “Initializing RDF
Without Stopping TMF (Using INITTIME Option)” (page 69).
If the problem occurs, the purger has stopped purging files, and you are unable to stop RDF to
rebalance the number of audited files on the volume, you can try lowering the duration of the
updater's transaction to the minimum value of 10 seconds as a short term workaround. If this does
not correct the problem, then the easiest way to correct the problem is to suspend the extractor on
the primary system for 10 minutes. If you have RDF/ZLT protection, then you are not at risk of
losing any data if your primary system should fail while the extractor is suspended. If you do not
have RDF/ZLT protection, then you are vulnerable to loss of data to an unplanned outage of your
primary system from the point where you suspend the extractor to the point where the extractor
has caught up after you have activated it, but this workaround will allow the purger to purge files.
If suspending the extractor is not acceptable, then use the following steps to resolve the problem
for the short term:
1. Do status RDF to get the name of the latest image file on the image trail of the updater
generating the 813 events.
2. Stop RDF
3. Restart RDF with UPDATE OFF; this causes the receiver to rollover to a new image file on each
image trail.
114 Critical Operations, Special Situations, and Error Conditions