Remote checks
Remote checks run as tasks in the address space of the caller. For example, a remote check might run in a server address space so that it can more easily obtain the necessary data about the server space and also more easily read data from data sets.
You can write remote checks in either Metal C or assembler. See Writing local and remote checks in Metal C.
- You need a check to run in a specific address space, or you cannot access the data you need for your check from the IBM® Health Checker for z/OS® address space
- Your check requires potentially disruptive actions, such as I/O intensive operations, serialization, or waits. This is important because if your check hangs in the hzsproc address space, it can affect the performance of IBM Health Checker for z/OS and all the other checks.
Local and remote check routines share a basic structure, but there are enough differences between them that you'll need to know before you start writing whether you are writing a local or a remote check. A remote check requires synchronization and communication between the remote check routine and IBM Health Checker for z/OS.
IBM Health Checker for z/OS tracks remote checks for you. If the caller's address space where the remote check is running goes down, IBM Health Checker for z/OS treats the check as if it had been deleted. If the IBM Health Checker for z/OS address space terminates, upon restart it restarts any remote checks that were defined to the system when the address space terminated, unless they have been explicitly deleted.
A remote check need not be APF authorized, but, if not, must be permitted by RACF® or other security product.
The following figure shows the parts of a remote check. The shaded items show the parts that a check developer must provide:
