On Feb 11, 2013, at 12:52, Walt Farrell wrote: >>>> >>> Dismayingly, when there are multiple options, the multiplicity >>> grows exponentially. >> >> The MF=M form of RACROUTE is sooo nice for situations like this. I wish all >> macros had that! > > Drat. I was just about to mention that, but you beat me to it. :) > > We discovered gil's issue back during the design for MVS 3.1.3, with some of > the new RACROUTE options and some exploiters (particularly JES) who needed > to be able to issue the macro with a wide variety of different options > depending on the exact circumstances, and did not want to write multiple > code paths. We found it was easier overall to provide MF=M so they could > modify individual parameters, before finally issuing MF=E to actually > execute it. They might have one MF=L form with the common set of parameters, > and then code with several different MF=M invocations to set unique > parameters as needed, and finally one MF=E. That made it much easier to add > the RACROUTE requests into their code. > At some point a callable system service with options passed as separate parameters becomes preferable to an in-line macro expansion with all the parameters stuffed into a single parameter block.
I have a colleague who has complained that UNIX callable services exist in too many variants and should likewise be pameterized. I imagine he thinks of such as strcpy(1), strncpy(1), and memcpy(1). And the S/360 hardware design suffered similar shortcomings, partially addressed by using EX to modify, e.g., the count field in SS instuctions. (There's also the non-reentrant approach.) Wisely, MVCL/CLCL moved these parameters to registers. -- gil
