Planned Takeover
In the case of a planned takeover, before you attempt to log into the application on the secondary host, perform the following:
Ensure that the latest system/COMS/CONFIG/FULL file details are contained in the *COMS/CFILE.
If you are unsure, load this file (located on the dictionary pack) via the COMS batch load facility on the Utility window.
If the system has COMS Protected Output and Protected Input enabled, as a precaution, you can disable COMS recovery. To do this:
Go to the DRC window of the COMS Utility.
Set Create New file to Y.
Set RDS pointer to end to Y.
Log into the application. The normal application startup should proceed.
During the takeover, if you log back into the application with a different terminal id, then a new Glb-Dialoginfo record is created. If this occurs, you might want to maintain the same Installation Data across the Configuration files on both hosts. This ensures that when a user logs in to either host, the same privileges are granted by both hosts.
Unplanned Takeover
In the case of an unplanned takeover, before you attempt to log into to the application window on the secondary host, perform the following:
Ensure the latest system/COMS/CONFIG/FULL file details are contained in the *COMS/CFILE.
If you are unsure, load this file (located on the dictionary pack) via the COMS batch load facility on the Utility window.
If the application has COMS Protected Output and Protected Input enabled, as a precaution, you can disable COMS recovery. To do this:
Go to the DRC window of the COMS Utility.
Set Create New file to Y.
Set RDS pointer to end to Y.
Log into the application. At this stage *SYSTEM/DMRECOVERY is started to recover the database. If there are any DMSII recovery issues, refer to your DMSII Utilities manual.
Notes:
Once DMRECOVERY is complete, LSS restarts any Reports that were running at the time of the takeover. Refer to Report Recovery During Unplanned Takeover for more information on this phase of recovery.
The application attribute Glb.Unique value is increased by 2,500 from the value contained on the source host before the takeover.
The LINCLOG will have lost a number of records, depending upon when the log buffer was last flushed. If the LINCLOG is critical to your application, it might be necessary to implement procedures where the LINCLOG is regularly released to minimize the impact of losing any records.
During the takeover, if a user logs back in to the application with a different terminal id, a new Glb-Dialoginfo record is created. If this is the case, it would be good practice to ensure the same Installation Data is maintained across both hosts’ Configuration files. This ensures that when the user logs on to either host, the same privileges are granted.
If the user logs back with a different terminal id, the last screen might not be able to be recalled, and the following error is displayed:
MESSAGE NOT AVAILABLE FOR RECALL; ERROR
This also indicates that the last instance of Glb.Work is no longer available.
Unplanned Takeover during Reorganization or Application Build
If an unplanned takeover occurs during a reorganization or an application build, it is necessary to:
Reload the application from the latest backups.
Start the reorganization or build from the beginning.