What is the correct process when a SYSMOD is discovered post-release to have a corequisite in a FMID other than its own? Is the developer's only recourse to create a dummy PTF to bear the ++IF ... REQ for the SYSMOD in the other function and let that resolve a ++HOLD ERROR?
Yes. <snip>
It appears to me that for ++HOLD ERROR the FMID operand would be more useful if it specified, instead, the FMID to which the corrective SYSMOD must be applied, and the HOLD were enforced only in zones containing that specified FMID.
Hmmm, I think I see your point. But more useful? Not so sure. This doesn't eliminate the need to create the "dummy" PTF containing the ++IFREQ in your hypothetical example, but it could provide a means for a SYSMOD to be "conditionally" held only in those environments that contain the other FMID. How useful is that? I suspect this might be relevant to only a small percentage of HOLDs.
In any case, the purpose of ++HOLD for SMP/E is to identify a SYSMOD that is to be held... it is not used by SMP/E to directly identify the fixing SYSMOD, nor the FMID for which the fixing SYSMOD is applicable (SMRTDATA and the FIX value excepted). The reasonid of the HOLD, the APAR, is indirectly used to identify PTFs to resolve the HOLD.
Kurt Quackenbush -- IBM, SMP/E Development ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
