Summary of checks - differences and similarities

The following table shows some of the differences between local and remote checks:

Table 1. Summary of local, remote, and REXX checks
Local checks	Remote checks	REXX checks
How do I know which type of check to write?
Write a local check in assembler or Metal C to look at system storage and use assembler services. (You can issue assembler services in either assembler or Metal C.) A local check runs in the IBM® Health Checker for z/OS® address space, so make sure your check can access the data it needs from there, and does not require a potentially disruptive action, such as a wait. (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.) A local check has the advantage of receiving IBM Health Checker for z/OS recovery support.	Write a remote check in assembler or Metal C to look at system storage and use assembler services. (You can issue assembler services in either assembler or Metal C.) A remote check runs in the caller's address space, and is a good choice if: Your check needs to access data that is hard to reach 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.	Write a REXX check to take advantage of the ease in issuing system commands (using the AXRCMD function) and analyzing the output of commands issued. It is easy in a System REXX check to handle I/O. For example, from a REXX check, it is very easy to parse parameters into multiple variables and to read from and write to REXXIN and REXXOUT data sets.
What languages are supported?
Metal C and assembler	Metal C and assembler	REXX exec
Where does the check run?
In the IBM Health Checker for z/OS address space.	In the caller's address space.	In a System REXX address space.
What kind of recovery support does the system provide for my check?
If the check routine abends, the system handles the abend and continues trying to call the check on subsequent iterations.	If the check routine abends, it is up to the application to provide recovery to handle the abend. If the task that issues the HZSADDCK macro defining the check terminates for any reason, including an abend that is not re-tried, the system treats the check as if it is deleted.	If the REXX check abends, the system will mark the check as no longer running for that iteration.
How do I define a check?
Do one of the following: For testing purposes, define the check defaults in HZSPRMxx using `ADD\|ADDREPLACE CHECK`. Create a separate HZSADDCHECK exit routine that issues the HZSADDCK service to describe check defaults. You must then add the check to IBM Health Checker for z/OS by adding the exit routine to the HZSADDCHECK exit.	Check routine defines itself by issuing the HZSADDCK macro describing check defaults.	Do one of the following: Define the check defaults in HZSPRMxx using `ADD\|ADDREPLACE CHECK`. You can also create a separate assembler HZSADDCHECK exit routine that issues the HZSADDCK service to describe check defaults. You must then add the check to IBM Health Checker for z/OS by adding the exit routine to the HZSADDCHECK exit.
Multiple checks per check routine supported?
Yes - Consolidation of multiple checks in one check routine for a product or element supported and recommended.	Yes - Consolidation of multiple checks in one check routine is supported. Since you must manage the storage for remote checks, whether or not there is any benefit to grouping checks into a single routine depends on how you manage the storage. Note that each remote check, even when grouped in one check routine, must run in a separate task.	Yes - Consolidation of multiple checks in one check exec is supported.
What prompts the processing phase for the check routine?
Function codes in the HZSPQE data area for local check routines.	Release codes from the IEAVPSE service for remote check routines.	The check invokes HZSLSTRT to initialize the check environment, and HZSLSTOP to indicate that check processing is complete.
Need to synchronize the check routine and the system?
No - see Writing local check routines	Yes - see Writing remote check routines	No - see Writing REXX checks
Who loads the message table module for the check into storage?
IBM Health Checker for z/OS	The remote check routine	IBM Health Checker for z/OS
Can I read and write persistent data to the HZSPDATA data set?
Yes, all the check types can use the HZSPDATA data set.
How many checks can I run at a time?
The system can process 20 checks at a time. Processing a check can mean either: Running a local check Starting a remote check Once a remote check has been started, it can run on its own and is not subject to the limitation of 20. Thus there is no intrinsic limit to the number of remote checks that can be run at a time.		See System REXX in z/OS MVS Programming: Authorized Assembler Services Guide.
How does delete processing work?
When a check is deleted through either refresh processing or when a user deletes the check, your check will come back to run again whenever ADDNEW or refresh processing occurs, unless you use the DELETE parameter in the active policy.	When a check is deleted, through either refresh processing or when a user deletes the check, the check is marked as deleted and does not come back at subsequent refresh or ADDNEW processing. The delete request is passed to the remote check in a release code and depending on the type of delete release code, the check routine can re-define itself.	A REXX check is not called for delete processing. When a check is deleted through either refresh processing or when a user deletes the check, your check will come back to run again whenever ADDNEW or refresh processing occurs, unless you use the DELETE parameter in the active policy.