On Wed, 10 Feb 2010 00:25:24 -0600, Chris Craddock wrote: >On Tue, Feb 9, 2010 at 8:29 PM, Brian Peterson wrote: > >> I'm thinking that had the packaging been originally designed using the >> ++MOD >> entry's CSECT parameter, removing a CSECT from a ++MOD would have been >> straightforward. >> Of course, that could be done after the fact by redelivering the MOD.
What, then, would be the MCS to remove the superfluous CSECT? >> Given the packaging you've described - a reasonable way to structure the >> module - the solution is likely to be something like this: >> >> ++PTF(newptf) . >> ++VER (some value). >> ++DELETE(FOO) SYSLIB(name) . >> ++JCLIN . >> (new structure for load module FOO) >> ++MOD(FOO) . /*presumably FOO is a CSECT in lmod FOO */ >> object deck for current version of FOO >> ++MOD(FRED). >> object deck for current version of FRED I believe the ++MODs are superfluous. >Brian's right. If you DON'T want the old element references don't creep back >in, then you have to ++DELETE the element and also provide it with new >JCLIN so the system knows how to build it correctly. It isn't rocket science >but there are an amazing number of packaging tools out there that don't >understand SMP/E arcana. > I'm familiar with the technique; I've known others who had to resort to it because of another SMP/E deficiency. It's repugnant because it's irreversible; I was hoping for a gentler alternative in this case. Thanks, gil ---------------------------------------------------------------------- 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
