Deleted SYSMODs

A function SYSMOD can delete another function by naming the function to be deleted as an operand of the ++VER DELETE operand. SMP/E deletes the function and all FUNCTIONs, PTFs, APARs, and USERMODs dependent on the deleted function. The functions specifically named in the DELETE operand list are considered explicitly deleted SYSMODs; all SYSMODs deleted because of their dependency on the explicitly deleted SYSMODs are termed implicitly deleted SYSMODs.

When one function SYSMOD deletes another, SMP/E attempts to remove all information on the deleted SYSMOD from the distribution zone. SMP/E also removes from the distribution libraries all elements that are currently owned by the deleted function SYSMOD. The following processing is done:

SMP/E determines whether there are any function SYSMODs in the hierarchy of the function SYSMOD being deleted, and considers those function SYSMODs also eligible for delete processing.
SMP/E deletes all SYSMODs that have an FMID value equal to one of the function SYSMODs being deleted.
SMP/E identifies all the elements that are currently owned by a function SYSMOD that is to be deleted.
SMP/E deletes from the distribution libraries all the elements of the SYSMODs to be deleted. If the elements have been successfully deleted, SMP/E deletes the entries for them from the distribution zone.
If the distribution zone contains an LMOD entry for a load module composed entirely of modules that are deleted, the LMOD entry is deleted.
If the load module contains modules not being deleted, the LMOD entry is not deleted.
However, for each module deleted from the load module, SMP/E adds a MODDEL subentry for the module to the LMOD entry. MODDEL subentries document the connection between the deleted modules and the load module. If any of these deleted modules are ever reintroduced, an LMOD subentry is added to the MOD entries, and the MODDEL subentries are removed from the LMOD entry.
The distribution zone SYSMOD entries for all implicitly deleted SYSMODs are deleted. A distribution zone SYSMOD entry is created for each explicitly deleted SYSMOD. This entry has a DELBY subentry naming the function causing the deletion. The SYSMOD entries for the explicitly deleted SYSMODs prevent the deleted function SYSMODs from being reprocessed by ACCEPT.
Note: Some functions may both delete and supersede another function. In this case, the SYSMOD entry contains a SUPBY subentry instead a DELBY subentry. This allows SYSMODs naming the deleted function as a requisite to be installed nevertheless.

The result of this process is that all SYSMODs within the hierarchy of the specified function SYSMOD are deleted.

In the example in Figure 1, function SYSMODs HDE1203, HDE1303, and HDE1403, and service SYSMODs UZ00009, UZ00010 and UZ00004 are deleted, because DELETE(HDE1203) is specified on the ++VER statement.

Figure 1. DELETE Hierarchy for DELETE(HDE1203): ACCEPT Processing

CIFREQ subentries in the SYSMOD entry for a function that is deleted (either explicitly or implicitly) are retained in the SYSMOD entry along with the DELBY subentry.

Thus, for the example in Figure 1, when function HDE2000 is applied, CIFREQ subentries in the SYSMOD entry for function HDE1203 are retained, as are any CIFREQ subentries in the SYSMOD entries for functions HDE1303 and HDE1403. Any CIFREQ subentries for conditional requisites specified by the deleted SYSMODs are also retained in the appropriate SYSMOD entries.

Note: SMP/E assumes that when a function is deleted, the deleting function replaces all the required elements of the deleted function. Although you can build a function SYSMOD that does nothing but delete another function, it is your responsibility to make sure you still have a functionally complete system after the product has been deleted. One item commonly overlooked is the IHASUxx macros, which are used to indicate whether an SU has been installed. If you delete a product, thus causing its IHASUxx macro to be deleted, and do not replace that macro with your own version, indicating that the SU is not installed, you may lose the system generation capability for that system, because system generation requires that all IHASUxx macros be present.

During ACCEPT processing, when a function is deleted from a distribution zone by another function, its FMID is not removed from the FMID list in the global zone. This is because the deleted function may still be applied in other target zones or accepted in other distribution zones.