o If SMP/E has determined that the binder is available on the system and SMP/E
is processing CSECT deletes, the STORENX link-edit parameter is passed to
the link-edit utility.
Why?
Because without STORENX the binder may not actually replace the load
module, thus it may not actually delete the CSECT. If you told SMP/E to
delete a module, don't you expect the CSECTs to actually be deleted from
the load modules that contain them? I do. SMP/E assumes the packager
knows what they are doing, and if deleting a CSECT makes a load module
non-executable, then presumably you're OK with that, or perhaps you are
also adding some new CSECT that will make it executable (when that CSECT
is in fact added, later during the APPLY operation).
Further it appears that SMP/E overrides the NAME ... RC=4 that I supplied
in the JCLIN for the program object.
When CSECTs are deleted from a load module, it is quite possible, even
likely, conditions causing RC>0 will exist, such as unresolved external
references, missing ENTRY point, target of an ORDER not found, etc.
These kind of conditions are expected during a CSECT delete. As such,
SMP/E considers any RC<12 to be an acceptable completion for the link
edit operation. Hence, for a CSECT delete operation, it overrides your
specified acceptable return code for the subject load module.
Kurt Quackenbush -- IBM, SMP/E Development
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
