Syntax
CRITICALPOINT [ SLEEP expression ] [ NORELEASE ]Parameters
CriticalPoint can be abbreviated as CP.
SLEEP expression
Suspends the report for the specified time. The time can be specified as number of seconds, as an attribute with numeric value (0 through 9999), or any numeric expression.
If the Sleep command option is not specified, or the specified period of time is 0, the report continues immediately after end-of-transaction processing is complete.
NORELEASE
NORELEASE can be abbreviated as NR. Prevents the release of printed output for ROC direct reports and non-ROC reports when a CriticalPoint logic command is executed, which would otherwise be the default behavior. It has no effect in ROC standard reports. All output is written for all print files when the CriticalPoint logic command is executed.
Description
The CriticalPoint logic command is used in reports to force end-of-transaction, defining a synchronization point for recovery. This enables easy and rapid recovery following a system failure.
The CriticalPoint logic command should be used at important points in the processing cycle of the report, such as after a record is read, but before it is written. This ensures data stored for recovery is the data about to be processed.
For an MCP-based system, regular CriticalPoints should be included to avoid delays at sync points and control points, when other programs using the database might be suspended waiting for this Report.
For a Windows-based system, regular CriticalPoint logic statements should be included to avoid delays in committing locked records, when other programs using this user database might be suspended waiting for this report.
During normal operation, the following processes occur when a CriticalPoint logic statement is executed:
Recovery data is moved from memory to the database.
In ROC direct reports, all print files are released, and completed parts of direct reports are printed. For output directed to a file, a new output file is created for each release. Use the CriticalPoint NoRelease logic command variant to prevent release of print files.
Profile information is reset, so data must subsequently be retrieved from the database before Flag logic statements can be used successfully. Automatic entries will function correctly without additional retrieval.
Ensure reference variables are brought into memory using Determine or LookUp logic statements before executing the CriticalPoint logic command.
For Windows and MCP-based systems, an end-of-transaction is forced. For an MCP-based system, in a Report (including a Report generated as a Coroutine), the CriticalPoint command performs an end transaction and then waits for any specified sleep time.
If your Report has commenced an OLTP Global Transaction, the CriticalPoint command commits and completes the transaction, and commences a new Global Transaction. This ensures that the required recovery information is stored in the appropriate databases.
Extract files open for output are closed.
Note: The CriticalPoint logic command is for use in Reports only. The use of this command in Ispecs and Messengers is invalid or is ignored.
CriticalPoint Sleep
The CriticalPoint Sleep logic command variant is not the same as the Sleep logic command, which is invalid in reports that contain CriticalPoint logic statements.
Suspension occurs immediately when the CriticalPoint logic command is executed, freeing access to the database. The report is activated after the specified number of seconds, and proceeds to complete any activities that it might have accumulated. The report can also be is explicitly activated by a Wake logic statement.
Recovery
Refer to CriticalPoint Recovery.
ROC reports
When a CriticalPoint logic statement is executed, all output for a report is written to the database so that it might be recovered. On resumption of the report, output continues to the same database files. The current files are not released.
For Windows-based systems
ROC standard reports write output to a flat file. Interaction with ROC tables is minimal, and achieved indirectly through an independent process. This separates the transaction activities performed by the report on the ROC database from the user database. For applications deployed to Windows, a single LINC16RR.exe process is used.
The user database remains in transaction state until a CriticalPoint logic statement, whereupon it commits the result before resuming transaction state.
For MCP-based systems
Standard ROC Reports write output to the ROC tables in the database.
If the database is not in transaction state when data has to be written to a ROC data structure, a transaction state will be started for the database update, and then immediately end.
ROC database activity does not affect user database activity, and so CriticalPoint commands (or Sleep 0 commands) are not required to avoid long database transactions due to ROC database activity.
OLTP
If your report has started an OLTP global transaction, the CriticalPoint logic command commits and completes the transaction, and commences a new global transaction. This ensures the required recovery information is stored in the appropriate databases.
Restrictions
The following restrictions while using the CriticalPoint logic command:
The CriticalPoint logic command can only be used in the Main method of a report, or in the Main method of an insertable class that is inserted (using the Insert logic command) into the Main method of a report.
For an MCP-based system, CriticalPoint commands are not allowed with Reports being output to Video.
There is a maximum limit of 99 CriticalPoint logic statements in one report.
CriticalPoint logic statements can be inserted anywhere within the Main method of a report, except within Determine or LookUp logic statements loops. Specify logic to exit these loops before invoking a CriticalPoint logic statements.
For performance reasons, ensure that the number of CriticalPoint logic statements used is not excessive.
Examples
Example 1
This example executes a CriticalPoint logic statement after every 500 records.
Suppose a failure occurs after record 4438 has completed. The system is restored to its condition at record 4000, and processing restarts from record 4001.
SD_Recover is a group variable, with members SD_Total, SD_Key, and SD_Comp.
Message Attention "Enter Company name"
Accept Comp_Name : Get a value for company.
LookUp Comp_Name Corec : Read company name from
: database for header.
SD_Recover.SD_Comp := Comp_Name : Move key to group variable.
Loop
Determine From Cust.Cust_Prof (SD_Recover.SD_Key1) : Read database.
SD_Counter := SD_Counter + 1 : Increment counter.
If SD_Counter > 500 : Test for record 500.
SD_Recover.SD_Key1 := Cust.Number : Assign key to group variable.
JumpTo Finis : Exit to CriticalPoint.
End
: Assign value to SD_Recover.
SD_Recover.SD_Total := \
SD_Recover.SD_Total + Cust.Balance
Frame10.Print() : Process report: Step 1.
Advance 2 : Process report: Step 2.
End
Break All : End report processing.
Label Finis
CriticalPoint Sleep 2 : Perform CriticalPoint.
If Glb.Recover = 1 : Test the need for a
: reinitialization.
Comp_Name := SD_Recover.SD_Comp : Retrieve company name.
LookUp Comp_Name Corec : Read company name.
Glb.Recover := 0 : Set indicator.
End
SD_Counter := Glb.Zeros : Set counter to zero.
End
Example 2
This example executes a CriticalPoint logic statement after every SD_Limit customer.
If a failure occurs, the system is restored to its condition just prior to the most recent critical point and processing continues with the next customer.
Loop
Determine From Event.Recevable (SD_Cust, SD_ActMth, Glb.Spaces, Glb.Zeros)
If Event.Customer <> SD_Cust
If SD_Cust <> Glb.Spaces
SD_Count := SD_Count + 1
If SD_Count > SD_Limit
SD_Count := Glb.Zeros
Break
End
End
SD_Cust := Event.Customer
End
If Event.ActMth = SD_ActMth
Extract Event As FileA RetainAs "CustEvents"
If Event.Ispec = "Cash"
Purge Event
End
End
End
If Glb.Status = "*****"
Break All
End
CriticalPoint Sleep MyNum
End