Peter Relson wrote:
This is a very bad idea. The interface to services documented by macro is the macro. If you "do it yourself" all bets are off.
In forty-odd years on 360s and later machines, I've had to do a lot of things that weren't pretty, Most notably spending two or three weeks trying to sandwich a few instructions into an SVC overlay so it would still fit into a transient area.
(S.C.) I chose MVI rather than OI because I don't know the initialization status of the DSECT, and it's an input file, so MVI was safe, whereas OI is iffy.
This was hardly "shoehorned". It was a very intentional optimization (which newer macros have largely abandoned because of the complexity) to avoid doing tihngs at runtime that can be determined at assembly time.
Some of those macros support a "COMPLETE" suboption of MF on the execute form which indicates to do complete initialization of the parameter area (and do complete syntax checking for required parameters)..
You're making my point for me. Many 360 and 370 era macros require two expansions, one each in a CSECT and DSECT, with an initialization move. To date some macros still don't support COMPLETE mode or alternative (e.g., the GENACB, etc. facility is no longer suggested). In the case of OPEN, the 31 bit upgrade could have been used to add 370 instructions, a VL option, etc.. While I agree with the philosophy of letting the assembler do as much as possible, some macros are user hostile to writing reentrant code, and the decision of trading execution speed for storage should be the user's.
Gerhard Postpischil Bradford, VT new e-mail address: gerhardp (at) charter (dot) net ---------------------------------------------------------------------- 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
