Your points are certainly valid, Peter. However, use of RSECT in a
multiple CSECT assembly allows a temporary override of NORENT, plus it's
one less line (piddling, I know). I've never actually done a mixed
CSECT/RSECT assembly, but I'm sure someone has...and with some of the
new PM3 and 4 split formats, could be theoretically exploited. (Again,
don't ask me why, I have no immediate idea.)
In addition, unless something has changed recently, *PROCESS RENT can't
be generated from inside a macro, but RSECT can.
I've also seen issues in poorly-coded macros (not mine) where use of
&SYSECT in CEESTART rather than the hard-coded CSECT would avoid conflicts.
Later,
Ray
On 2011-07-07 04:36, Peter Relson wrote:
This doesn't really sound like a philosophy question, it sounds like a
need question. Do you need anything that LE can provide (be that functions
or the stack or something else, even something that just makes it easier
to code what you need to code)? If the answer is "yes" (or perhaps even
"maybe" to help with future changes), then you should use LE. If not, then
why would you? The LE stack is of course faster for an individual obtain
than getmain but if all you need is one getmain, then the LE setup that
would enable you to use that stack would be far more costly.
Gripe time: Dear IBM LE, please allow use of RSECT in CEESTART.
Perhaps I'm missing the benefit. RSECT is ignored within z/OS processing
except for modules in IEANUCxx.
So is there some assembler benefit over and above what RENT checking gets
you? Wouldn't
*PROCESS RENT
xxxxxxxx CSECT
(or having RENT in your assembler invocation parameters) basically be
equivalent to
xxxxxxxx RSECT
Peter Relson
z/OS Core Technology Design
