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". -- While a transcendent vocabulary is laudable, one must be eternally careful so that the calculated objective of communication does not become ensconced in obscurity. In other words, eschew obfuscation. Maranatha! <>< John McKown
