On Tue, 23 Feb 2016 10:36:16 -0600 Paul Gilmartin wrote:
> Oooh! Neat! Thanks. And I see:
>
> z/OS MVS Program Management: User's Guide and Reference
> SA23-1393-00
>
> STRIPSEC={PRIV|YES | NO}
> STRIPSEC=PRIV
> Specifies that unreferenced unnamed sections are to be removed.
>
> This addresses a misbehavior of SMP/E which secularly piles up private
> sections (Which I think are something programmers should avoid anyway.
> But Pascal reportedly dotes on them.)
>
> Note: For a section to be considered unreferenced, it must:
> ...
> Not be the target of a control statement
> (Such as ORDER?)
>
> Does SMP/E respect STRIPSEC? Does it cause no problems, e.g. with
> RESTORE? How might it interact with the "++MOD(...) CSECT(...)"
> argument?
>
> Thanks again,
> gil
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.
That said I don't think SMP/E could care about unnamed sections, only ones that
it can have been told the names of.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
