Yes, this is essentially what I do too.
The problem I have with changing the RMID via UCLIN approach is that you
have to (I believe) undo it via UCLIN at RESTORE time. I prefer not to
have to that.
As an aside, the thing I do in cases like this is to replace the SAMP
with something like this:
++ SAMP(ISRONLY)
*******************************************
* See USERMOD xxxxxxx *
*******************************************
This both updates the RMID so I get MODID error if IBM updates the SAMP
and provides some doc if somebody is looking at the SAMP library.
And it's not my idea. It's something, like so many things I do, that got
posted on this list ???? years ago. I have no shame when it come to
using the ideas of the more knowledgeable people on this list. :-)
--
Jeff
Schwarz, Barry A said the following on 7/6/2009 3:37 PM:
Whenever I have to use an IBM module in a library other than where IBM
put it (++SAMP is just one example), I copy it to a private TXLIB,
modify it if necessary, and then create a USERMOD with both the original
data element type (e.g., ++SAMP) and the desired element type (e.g.,
++EXEC), both using the original name of the module and both referencing
the TXLIB. The desired element type also references the correct SYSLIB
where I want the module to end up. If the original element type is
correct but doesn't support the ++MOVE statement, then I use ++USER1.
The end result is both the original IBM element and my usable copy are
both flagged with the USERMOD which generates the appropriate SMPE
diagnostic if I ever attempt to apply an IBM update.
-----Original Message-----
From: Jeffery Swagger
Sent: Thursday, July 02, 2009 5:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SMPE usermod sample
Yes, but this strikes me as incomplete.
I did try an APPLY CHECK of the proposed USERMOD (minus the JCLIN) and
it appeared to produce the desired result.
In that a ++EXEC element would be created (target library SISPEXEC) with
an ALIAS of ONLY copied from SISPSAMP.
However, here's the problem. The shipped IBM element ++SAMP(ISRONLY) has
no updates associated with it.
This is telling me, and I could be wrong, that IBM could ship a PTF to
ISRONLY, and then my ++EXEC is
out-of-sync because IBM knows nothing of a ++EXEC(ISRONLY). Uh Oh
It seems to me that a complete solution to this problem requires that
the ++SAMP(ISRONLY) must have the RMID updated.
That way, if there is an IBM PTF, then SMP/E will detect a MODID error.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
