In the case of positionals: it is the writer’s problem to determine how many positional entries they need to handle.
I have forgotten the macro, but it was back in the old F Asm days (IIRC) that used &SYSLST(n) to handle all of its positionals. That is, it did not define them individually on or with the model statement. This makes it impossible for the assembler to know there is a problem. So, in that case, the writer had to detect and report the excess. And as I recall, they did. I can’t remember if it was an “O/S” macro or product (back in those days there was not the siloing that there is today, based on component). But, when a system macro is user indifferent, that leads to problems. And ESPIE is a system|RTM macro. Indifference here can cause problems. In fact it did. RENT and self modifying do not go together well. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Oct 18, 2018, at 7:22 PM, Charles Mills <[email protected]> wrote: > > +1 > > Charles > > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:[email protected]] > On Behalf Of Steve Smith > Sent: Thursday, October 18, 2018 3:27 PM > To: [email protected] > Subject: Re: Macro Behavior > > I think in this case, ESPIE, it should check for extraneous operands. It > evidently has a maximum of 3 positional operands, and it would certainly > complain if MF(E(1)) was one of them. > > Re allowing a trailing comma: I wouldn't, and I think Jonathan's > justification is off the mark. The check for too many positionals would > include optional operands. Regular processing should normally treat an > optional operand as unspecified if null anyway. So > AIF (n'&SYSLIST GT max).error > is sufficient. But if you insist, then > AIF (n'&SYSLIST EQ max+1 AND '&SYSLIST(max+1)' EQ '').ok > first. > > I've seen too many macros that are overzealous in checking things that > don't matter, and things the assembler could catch just as well. This > example is sort of a gray area (albeit dark gray) where the macro could > process with what it got, but on the other hand could likely save some > trouble by doing this extra check. > > A logical case could be made the macro processor could/should catch this > itself. Undeclared positionals could be an automatic warning, like > undeclared keywords are. But you'd need some way for macros to specify > they will accept an arbitrary number of undeclared positional operands > (because many do so). However, this is pretty much hypothetical, as I > can't see it's worth the effort or incompatibility. > > sas > > On Thu, Oct 18, 2018 at 11:49 AM Jonathan Scott <[email protected]> > wrote: > >> Ref: Your note of Thu, 18 Oct 2018 11:30:09 -0400 >> >> Steve Thompson writes: >>> I have a question. If one passes too many positional arguments to >>> a macro, should one not issue an MNOTE about this? >>> >>> Please try the following, and let me know what you think about this: >>> >>> ESPIE SET,MYRTN,(1,3,7),PARAM=(3),MF(E,(1)) >> >> It is obviously possible for a macro to check for too many positional >> arguments. There are also many other ways in which macros could >> typically perform intelligent extra validation on operands. >> >> However, on the other side, it is not normally the responsibility of the >> macro writer to check for incorrect usage. Such checks could be >> considered some "extra value" which the macro writer could add, if it is >> considered worth while and does not add too much complexity. >> >> The usual principle in most product macros is only to check for errors >> which mean that the macro is unable to continue, for example because a >> required operand is missing or a keyword has an unsupported value. >> >> Personally, I include the "too many positional parameters" check in >> most of the macros which I create. >> >> I check for ('&SYSLIST(n)' EQ '') where n is one more than the valid >> number of positional parameters. I do this rather than checking >> N'&SYSLIST so that it will tolerate a trailing comma, for example when >> a macro has one positional parameter which is optional, so the user has >> coded a dummy comma operand, which causes N'&SYSLIST to be set to 2 even >> though only one positional operand is allowed. >> >> Of course, my check will not pick up a case where a spurious extra >> positional parameter is preceded by two or more consecutive commas, >> but it doesn't seem worth coding multiple checks to cover even more >> obscure possibilities. >> >> Jonathan Scott, HLASM >> IBM Hursley, UK >> > > > -- > sas
