UCLIN. REP MOD(CEEPLPKA) UMID(xxxx). NOTE MOD, NOT LMOD *************************************** . LMOD does not have a UMID sub-entry. . One MOD statement per CSECT zapped by vendor. . ENDUCL.
This will ABSOLUTELY cause a regression message to be produced for any SMP/E attempt to modify "MOD". This will trigger your efforts to: 1) reverse the UCLIN. (UCLIN. DEL MOD(CEEPLPKA) UMID(XXXXXX) ENDUCL.) 2) Install IBM maint as ususal. 3) Copy updated CEEPLPKA to alternate loadlib 4) Re-install UCLIN on smp/e zones. 5) re-apply vendor maint to the copy of CEEPLPKA. (with or without SMP/E). I don't think this can be done in "one step" within a single usermod. Also, using the method abe, only an attempt to replace one of the zapped CSECTS will trigger the regression message. <snip> Would the regressed-usermod message still pop up if one of the 347 other modules in lmod CEEPLPKA besides CEEPLPKA itself was hit by maintenance? Supposedly, an ADD LMOD(CEEPLPKA) UMID(usermod) UCLIN is an option, but since that field doesn't show up in a list of an LMOD, I wonder if it really works. And how do I code the actual usermod to pull in CEEPLPKA, zap it, and stick it in an application-specific library? I'm pretty sure SMP/e will frown upon me trying to use the same name for the mod while sticking it in a different library (without hurting the production CEEPLPKA). I was thinking of setting the usermod element up with a different name and giving it the alias of CEEPLPKA, but wasn't sure how "aware" SMP/e's alias processing was in v3.4. </snip> ---------------------------------------------------------------------- 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
