Use dynamic statements for ISFPARMS to avoid reassembly
Description
- Assembler macros that you define, assemble, and then link into the SDSF load library. This is the original format for defining ISFPARMS and it continues to be supported for compatibility.
- Dynamic statements, which are in parmlib member ISFPRMxx. Dynamic statements are the recommended format. They are easier to code and are more dynamic than the assembler macros; they can be updated without reassembling or link-editing. The statements are processed by an SDSF server, which is controlled by MVS™ operator commands.
Table 1 provides more details about this migration action. Use this information to plan your changes to the system.
Element or feature: | SDSF. |
---|---|
When change was introduced: | General migration action not tied to a specific release. |
Applies to migration from: | z/OS V2R1 and z/OS V1R13. |
Timing: | Before the first IPL of z/OS V2R2. |
Is the migration action required? | No, but recommended to avoid the migration action of reassembling your customized ISFPARMS for each z/OS® release. (If you do not use dynamic statements for ISFPARMS, reassembly of your customized ISFPARMS is required on each release.) |
Target system hardware requirements: | None. |
Target system software requirements: | None. |
Other system (coexistence or fallback) requirements: | None. |
Restrictions: | None. |
System impacts: | None. |
Related IBM® Health Checker for z/OS check: | Use check SDSF_ISFPARMS_IN_USE to verify that SDSF dynamic statements in ISFPRMxx are being used rather than the assembler macros. If the check determines that the assembler macro ISFPARMS is in use instead, and that it has been modified, the check generates an exception. If the assembler macro ISFPARMS is in use but it has not been modified, so that all defaults are in effect, the check does not generate an exception. SDSF registers this check with the IBM Health Checker for z/OS infrastructure when the SDSF server address space is initialized. However, one of the items this check verifies is that the SDSF server itself is in use, so you have to manually add this check (particularly if you do not use the SDSF server) so that the IBM Health Checker for z/OS infrastructure will invoke the check. To add the check, put the following statement in your PROGxx parmlib member: EXIT ADD EXITNAME(HZSADDCHECK) MODNAME(ISFHCADC). SDSF health checks are distributed in ISF.SISFLOAD for installations running SDSF in the LNKLST. The checks are also distributed in ISF.SISFLINK for installations that do not run SDSF in the LNKLST. For those installations, ISF.SISFLINK must be added to the LNKLST. Note: To avoid a possible ABEND
290 with reason code 02014007 issued by HZSADDCK:
|
Steps to take
If you are already using dynamic statements for ISFPARMS, there is no migration action to perform.
- Convert your existing ISFPARMS to dynamic statements by using a conversion utility that you invoke with the ISFACP command.
- Reassemble your customized ISFPARMS for use
with z/OS V2R2. Reassembly
must be done whenever you change your z/OS release. Before reassembling
ISFPARMS, you might want to update it for new function. The assembler
ISFPARMS cannot be shared with any other release of SDSF. Only use
ISFPARMS for the release on which it is assembled. Note: If you have an SMP/E usermod that specifies modifications to assembler macro ISFPARMS, change the usermod to indicate that module ISFPARMS is now owned by the z/OS base V2R2 SDSF FMID (HQX77A0). The correct SMP/E syntax is ++VER(Z038) FMID(HQX77A0)
Also, in the SMP/E usermod, change the distlib to reference DISTLIB(AISFSRC). The correct SMP/E syntax is ++VER(Z038) FMID(HQX77A0). Your ++SRC or ++SRCUPD statement must specify DISTLIB(AISFSRC).
Reference information
For information about invoking the conversion utility with the ISFACP command, and the ISFPARMS and the ISFPRMxx parmlib members, see z/OS SDSF Operation and Customization.