I don't know just when LE decides it has to build an enclave, but if
your routine could be invoked by a non-LE routine (a transaction written
in assembler, for example), perhaps it would cause significant
overhead. If that's impossible, then no worries. Even it were
possible, I don't know how that overhead compares to storage obtain/release.
On 2014-12-15 12:55, John McKown wrote:
I have been seduced by the dark side, in that I now tend to make my HLASM
code be LE compliant. There are some, IMO, decent reasons. The two main
ones being that: (1) is it easier for me to write reentrant code using
CEEENTRY because this relieves me of hard coding the STORAGE OBTAIN and
STORAGE RELEASE macro; (2) it simplifies the interface to call HLL
subroutines. In particular, the C subroutines, of which I have a fondness
for SNPRINTF to format "human readable" messages. Also, for subroutines,
coding a LE compliant routine makes it "more integrated" to the other LE
stuff, such a CEEDUMP. Which is a consideration to me.
Speaking of the second reason (calling subroutines), I have reviewed the
CEEPCALL macro. And I am considering using it in preference to the original
CALL macro. One of the reasons is simply because it uses the BASR
instruction for linkage by default. It also defaults to use the BRC,
relative branch, instructions without the need to use IEABRCX. This is in
support of my "no base register for code" habit. Another, minor, plus is
that it can be used, in especially UNIX code, to call an routine which is
exported from a DLL.
So, does anyone know of a _disadvantage_ to using CEEPCALL instead of CALL?
Oh, I consider being a new facility and so perhaps "confusing" to other
coders to be not that important. But I will promise to put in a comment at
the top of the module to explain that CEEPCALL is "an advanced version of
the normal CALL macro".
