Summary of checks—differences and similarities
The following table shows some of the differences between local and remote 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:
|
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:
|
Check routine defines itself by issuing the HZSADDCK macro describing check defaults. | Do one of the following:
|
| Are 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 a 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. |
| Is there a 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:
|
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. |