Integrating the DLPAR operation into the application
The DLPAR operation can be integrated into the application in the following ways:
- Using a script-based approach, where the user installs a set of DLPAR scripts into a directory. These scripts are invoked while the DLPAR operation is being run. The scripts are designed to externally reconfigure the application.
- Using the SIGRECONFIG signal, which is used to catch the signal of every process that has registered. The signal method assumes that the application has been coded to catch the signal, and that the signal handler will reconfigure the application. The signal handler invokes an interface to determine the nature of the DLPAR operation.
Both of these methods follow the same high level structure. Either method can be used to provide support for DLPAR, although only the script-based mechanism can be used to manage DLPAR dependencies related to Workload Manager software partitions (processor sets). No APIs are associated with Workload Manager, so the use of a signal handler is not a suitable vehicle for dealing with the Workload Manager-imposed scheduling constraints. The applications themselves are not Workload Manager-aware. In this case, the system administrator might want to provide a script that invokes Workload Manager commands to manage DLPAR interactions with Workload Manager.
The decision of which method to use should be based on how the system or resource-specific logic was introduced into the application. If the application was externally directed to use a specific number of threads or to size its buffers, use the script-based approach. If the application is directly aware of the system configuration and uses this information accordingly, use the signal-based approach.
- check phase
The check phase is invoked first and it enables applications to fail the current DLPAR request before any state in the system is changed. For example, the check phase could be used by a CPU-based license manager to fail the integration of a new processor if that CPU addition makes the number of processors in the system exceed the number of licensed processors. It could also be used to preserve the DLPAR safeness of a program that is not DLPAR-safe. In the latter case, consideration must be given to services provided by the application, because it might be better to stop the program, complete the request, and then restart the program.
- pre phase and post phase
The pre phase and post phase are provided to stop the program, complete the request, and then restart the program.
The system attempts to ensure that all of the check code across the different mediums is executed in its entirety at the system level before the DLPAR event advances to the next phase.