<snip> For me, the biggest problem in making something reentrant is if I need to
use a DCB. There is no way, that I know of, to generate a DCB in a GETMAIN'd area. </snip> I'm not sure why "DCB" is pointed out specially. In a large number of cases reentrant programming relies on dynamic storage that has been initialized by copying from static storage. DCB is not intrinsically different then the list form of many macros -- you create one initialized in static storage, you allot space in dynamic storage, you copy from static to dynamic, and away you go. Many "execute forms" provide a "complete form" which fully initializes and therefore does not require an initialized static list form. The older the service the less likely it is to support "complete". ESTAE is one such. And if you don't do it right, even thinking that you can just set the area to zeroes, you get what many would not want as the desired value for at least one parameter. I chose not to identify the parameter because you should just do it right and then you won't care. Regarding code below 16M, almost all (maybe all) of the access methods support the invoker being above the 16M line and can identify exit routines that are above 16M. The data might need to be below 16M but that is easy to accomplish (at least in assembler). If you have a need for a mixture of code above 16M and below 16M, see if you have access to using PDSE's and program objects. RMODE=SPLIT is very well suited for exactly this situation. You can't just copy executable code from a CSECT to getmained storage without making sure that the "from" can get to the "to" and vice versa. That can be a pain. V-Cons don't apply between a loaded module and getmained storage. But they do apply across CSECTs in a loadmod or a program object (include the RMODE=24 and RMODE=31 CSECTs in an RMODE=SPLIT program object). Peter Relson z/OS Core Technology Design
