Sorry for top posting. Yes, you want to zap the MOD (CSECT). SMP/E knows all the LMODs it is relevant to be it one LMOD as in this case or many LMODs.
Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:[email protected] Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html On Wed, 26 Jul 2023 21:19:34 +0000, Pommier, Rex <[email protected]> wrote: >Hello list, > >I'm pretty sure I know what I did wrong and what I must do to fix it, but >would like validation from the SMP/E gurus here. > >DFSMSdss has a module ADRPATCH for activating optional behavior. The DFDSS >manual shows the use of AMASPZAP for turning these flags on/off. Very simple >zap process (sorry for alignment). > >//ZAP EXEC PGM=AMASPZAP,PARM='IGNIDRFULL' >//SYSPRINT DD SYSOUT=* >//SYSLIB DD DISP=SHR,DSN=SYS1.LINKLIB >//SYSIN DD * > NAME ADRDSSU ADRPATCH > VER 0058 00 > REP 0058 F0 > >I didn't want to lose the zap in case of maintenance so I built a usermod to >install it as such: > >//SMPCSI DD DISP=SHR,DSN=SMPE.ZOS24.GLOBAL.CSI >//SMPCNTL DD * > SET BDY(GLOBAL). > RECEIVE SYSMODS SELECT(DSSPT58). > SET BDY (MVST100) . > APPLY SELECT(DSSPT58) CHECK RETRY(YES). >/* >//SMPPTFIN DD * >++USERMOD(DSSPT58) . >++VER (Z038) FMID(HDZ2240) PRE(UJ01310) . >++ZAP ( ADRDSSU ) . > NAME ADRPATCH > VER 0058 00 > REP 0058 F0 >/* >// > >We needed to subsequently remove the usermod to apply maintenance to ADRDSSU >and to our dismay, after the usermod was restored, the flag was still set. We >found this when, after applying the maintenance and adjusting the PRE in the >++VER, and trying to do the reject/receive/apply of the usermod, the apply >failed because the VER failed. Looking at the ADRPATCH CSECT in the load >module confirmed this. Looking at the restore job showed that the job did a >relink of ADRDSSU, pulling the MOD ADRDSSU from the DLIB and the rest of the >LMOD ADRDSSU (which includes ADRPATCH) from the currently running LINKLIB. To >get around the mismatch where the zap was still in place in the loadmod but >SMP/E said it isn't, I manually zapped the flag back off. > >What I'm thinking I should have done initially was, instead of zapping the >ADRDSSU load module, would have been to zap the MOD ADRPATCH like this: > >++ZAP ( ADRPATCH) . > NAME ADRPATCH > VER 0058 00 > REP 0058 F0 > >In doing so, I think SMP/E would have put the zap onto ADRPATCH and relinked >ADRDSSU with the zapped version of ADRPATCH, then when we needed to restore >the usermod, SMP/E would have relinked ADRDSSU with the unzapped version of >ADRPATCH in the DLIB. Am I correct in my assessment? > >TIA, Rex (and apologies for the length of the email but I wanted to >include all pertinent info) > >---------------------------------------------------------------------- >The information contained in this message is confidential, protected from >disclosure and may be legally privileged. If the reader of this message is not >the intended recipient or an employee or agent responsible for delivering this >message to the intended recipient, you are hereby notified that any >disclosure, distribution, copying, or any action taken or action omitted in >reliance on it, is strictly prohibited and may be unlawful. If you have >received this communication in error, please notify us immediately by replying >to this message and destroy the material in its entirety, whether in >electronic or hard copy format. Thank you. > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
