To warmboot a KB snapshot file:
warmbooting afterwards options on the Load KB dialog to restore the snapshot file to its run-time state. G2 loads and automatically resumes running the current KB as if it had merely been paused. This is called warmbooting. Loading a KB snapshot file restores both the stored KB's knowledge and the real-time data that existed at the time when the KB snapshot file was saved.
If you do not select the
warmbooting afterwards check box when loading a KB snapshot file, G2 discards the run-time data that was loaded. The result is the same as if you had loaded a standard KB file.
To warmboot a KB snapshot file:
Select the warmbooting afterwards option in the Load KB dialog.
To warmboot a KB snapshot file programmatically:
Invoke the g2-warmboot-kb system procedure, as described in the G2 System Procedures Reference Manual.
Scheduler-mode attribute in the Timing Parameters system table of the loaded KB snapshot file.After loading a KB snapshot file, G2 runs the current KB somewhat differently from its default behavior, as follows:
initially rules.
warmboot, and executes it, if it exists.
When the KB in a snapshot file contains a procedure whose name is
warmboot, G2 invokes that procedure before beginning execution of the file. This invocation provides a hook that you can use to take whatever action is necessary to restore the needed context. If no procedure named warmboot exists, G2 continues without error. A modularized KB can also contain warmboot procedures that are not named warmboot, as described under Modular Warmboot Procedures.
Non-Modular Warmboot Procedures
When a KB is not modularized, or when one warmboot procedure suffices for all modules, you can provide a procedure named warmboot that does what is needed. This procedure must take no arguments and return no values.warmboot procedure so that it specifies a set of actions that are appropriate to execute after the KB snapshot file is warmbooted. For example, the sample warmboot procedure shown below duplicates some operations performed when the KB starts, but performs other operations that depend on state information saved as part of the KB snapshot file.
warmboot ( )
ND : class node ;
WS : class kb-workspace = the subworkspace of mill-welcome-screen;
begin
{ Notify user that warmbooting has occurred. }
show WS ;
inform the operator that "Warm restart of MILL application" ;
{ Update display for each manufacturing station, based on saved state. }
for ND = each node upon WS do
call reset-graphics ( ND ) ;
if the status of ND is processing then
start process-material ( ND ) after
max ( 0 , the process-end-time of ND - the current time ) ;
end ; { do }
{ Display menu bar and resume "production" of raw material objects. }
hide WS ;
start developer-package-initialization-rules ( ) ;
show the subworkspace of mill-process-diagram-object with its top left
corner 2 units to the right of and 40 units below the top left corner of
the screen ;
start process-material ( warehouse ) ;
end
warmboot that does this, but GFR provides a more general capability: it contains a system-defined procedure named warmboot that automatically executes any other warmboot procedures. When you warmboot a snapshot of a KB that includes GFR, G2 invokes GFR's
warmboot procedure just as it would a user-defined procedure with that name. The GFR procedure scans the KB for items of class GFR-STARTUP-OBJECT, each of which can define a warmboot procedure for a module, and executes the procedures specified by the items in the order defined by the module hierarchy. A warmboot procedure for use with GFR has a different signature than a procedure named
warmboot, but otherwise does the same types of things in the same ways that a non-modular warmboot procedure does, as described under Non-Modular Warmboot Procedures. For further information about modular warmboot procedures, see the chapter on managing modules in the G2 Foundation Resources User's Guide.
Caution: If a KB contains more than one procedure named warmboot, the duplicate names could cause G2 to invoke the wrong one. Therefore, a KB that requires GFR must use GFR to execute any warmboot procedures, and must not contain any procedure named warmboot except the one supplied by GFR.
Warmbooting With Catch-Up
G2's default behavior for initializing a warmbooted KB snapshot file might not be appropriate for a KB that is designed to run continuously. For this reason, you can direct G2 to warmboot a KB so that its processing can catch up from the current time saved in the snapshot file to the current real time.
To catch up to the current real time when warmbooting:
Select the warmboot afterwards with catch-up feature option in the Load KB dialog.
Scheduler-mode attribute in the resulting current KB's Timing Parameters system table to as fast as possible.
Scheduler-mode attribute to the value real time. If your KB does not reset the Scheduler-mode attribute, then G2 continues to run with a setting of as fast as possible.
To reset the scheduler mode to use real time processing after a warmboot:
Scheduler-mode attribute in the KB's Timing system table from as fast as possible to real time when the scheduler's current time is greater than or equal to the current real time.
Scheduler-mode attribute to the value at the time the KB snapshot file was saved. This procedure assumes that the warmbooted KB includes a text parameter named text-parameter-holding-saved-scheduler-mode, whose value is equal to the value of the Scheduler-mode attribute in the Timing Parameters system table at the time the KB was saved to its snapshot file.
change-to-real-time-when-caught-up( )
begin
repeat
wait for the current real time - the current time;
exit if the current time >= the current real time;
end;
change the text of the scheduler-mode of timing-parameters
to the current value of
text-parameter-holding-saved-scheduler-mode;
end
warmboot procedure so that it starts change-to-real-time-when-caught-up.
warmboot when warmbooting the KB. For example:
warmboot( )
begin
. . .
start change-to-real-time-when-caught-up ();
. . .
end
warmboot afterwards with catch-up feature option.
change-to-real-time-when-caught-up procedure restores the value of the Scheduler-mode attribute in the Timing Parameters system table. For a KB that is warmbooted in this manner, if you reset the resulting current KB, G2 resets the
Scheduler-mode attribute to its value that is saved in the KB snapshot file.
warmboot afterwards with catch-up feature option to warmboot KB snapshot files saved under G2 Version 3.0 revision 0 or earlier.