On Thu, 25 Feb 2016 15:19:59 -0600, Barry Lichtenstein wrote: >> >> Does SMP/E respect STRIPSEC? Does it cause no problems, e.g. with >> RESTORE? How might it interact with the "++MOD(...) CSECT(...)" >> argument? > >Can't really blame SMP/E for accumulating them, that's the binders fault. For >a given section name, it quietly deletes same-named duplicates it finds (if >any), so for an unnamed section it has no handle. > >Since SMP/E does not document recognizing STRIPSEC on the JCLIN PARM, I expect >it would be ignored (you might get away with using SETOPT if you really had >some need for this). > >I would hope however that modules are not shipped which contain unnecessary >unnamed sections! Though sometimes unreferenced sections, named or not, are >there for a reason and should not be removed. > ISTR Pascal makes them. Hardly relevant nowadays.
>That said I don't think SMP/E could care about unnamed sections, only ones >that it can have been told the names of. > And, now that I think about it, STRIPSEC is probably pernicious for SMP/E. SMP/E sometimes includes MOD elements from the target zone, and if they have been stripped desired results will not occur. In fact, for some searches the target zone is first in the search order. I consider this a bad design. SMP/E should search the DLIB zone and the GLOBAL zone and fail if the element is not found there; never search the target zone. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
