The CriticalPoint logic command is primarily intended to enable the recovery of report output. However, there is an additional consideration with the use of standard reports.
When a CriticalPoint command is performed, any print-line buffering is unconditionally written to the file.
The inclusion of CriticalPoint logic in direct reports depends on the requirements for recovery of the reports.
If a report fails in which Glb.User is changed after a Release logic command is executed, but before a CriticalPoint command is executed, you may not be able to restart the report. This is due to access to the output file being restricted to the value of Glb.User. In addition, output released by a Release command in a standard report is not visible until database transactions have been committed using a CriticalPoint command.
Including the Sleep Variant
There are several rules that apply when the Sleep variant is included in the CriticalPoint logic command:
In synchronous reports, the sleep is ignored, as it could delay the transaction or commit prematurely.
All outstanding HUB transactions are committed.
Existing database updates are committed and new transactions begun.
If the value of Glb.Close is “CLOSE”, the report terminates.
If a Wake or stop signal is received, the report handles it.
If there is time remaining, the report sleeps before checking for a Wake or stop signal.
If the EndAfter time elapses, it is handled in the same way as a stop signal.