Charles Mills wrote:
And a corollary would be "why DID IBM make it so darned hard to write
reentrant assembler code?" Some IBM macros can be used in standard form
without a problem. Some simply require MF=E with MF=L in the DSECT. Some
require MF=L in the DSECT and a "model" in CSECT storage that you move to
the DSECT (or home-built initialization code that defeats the purpose of
standard macros). Some have internal address constants that must be
relocated after a move to a DSECT. Some executable forms generate standard
address constants that are incompatible with DSECTs. Often it depends on
which operands you code, so a "simple" change to a macro may create a
totally unexpected problem. And the documentation does not usually bother to
tell you which is which.
You cannot use a single IBM executable macro in a reentrant environment
without examining the assembled code to make certain it will not have a
problem (unless you are already very familiar with the particular macro).
A symptom of a mature operating system. The now decades-old services
allowed parameters to be set along with MF=L and attempted to merge
options in their MF=E expansions. The new services merely reserve space
and declare symbols in their MF=L expansions and their MF=E expansions
zero the parameter list before updating it.
Upward compatibility concerns make it impossible to go back and change
the older services to use the newer approach. The only option is to
replace them the way the new ISGxxxx services have replaced ENQ/DEQ and
GQSCAN. Don't expect such replacements to be commonplace.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
