Only the one for which I posted the log information along with the macro, where I used parmbuf (single f as posted). Also tried with 2 f's but still failed to compile.
with apologies to FriedEgg, Tom and Art
I have crossed some wires:smileyshocked: and provided serious miss-guidance
PARMBUFF needs both F
the macro definition with /parmbuff DOES cause errors when a "positional" parameter follows keyword parameters in the definition.
My failing memory should have recalled that is in the invocation that /parmbuff (in the definition) might allow this rule of order to be broken.
As in this (more tested) version
107 %macro trouble() /parmbuff ;
108 %put &syspBuff;
109 %mend ;
110
111 %trouble( ok=1, trouble=999, real_trouble );
( ok=1, trouble=999, real_trouble )
extending the macro a little is instructive
69 %macro trouble() /parmbuff ;
70 %put &syspBuff; %* report the parameter list passed;
71 %put local environment _local_ (thats all !) ;
72 %mend ;
73
74 %trouble( ok=1, trouble=999, real_trouble );
( ok=1, trouble=999, real_trouble )
local environment _local_ (thats all !)
Although the macro appears to be invoked with parameters, none appear in the local environment.
If a parameter is defined in the macro definition, then it would appear in _local_ , but a miss-placed positional parameter will cause syntax ERROR
48 %macro trouble(ok=1, trouble=999) /parmbuff ;
49 %put &syspBuff; %* report the parameter list passed;
50 %put local environment _local_ (thats all !) ;
51 %mend ;
52
53 %trouble( ok=1, trouble=999, real_trouble );
ERROR: All positional parameters must precede keyword parameters.
Art code should be
%trouble( real_trouble ,ok=1, trouble=999);
Just as ERROR said in log.
ERROR: All positional parameters must precede keyword parameters.
BTW. I prefer to use call execute to instead of PARMBUFF, which only can supply one parameter.
Call execute can supply multiple parameters.
Ksharp
K
the idea here was to indicate that "the rule demanding positional parameters appear before keyword parameters" can appear to be broken with a macro defined with option parmbuff and no parameters. I would not recommend this - but it would be valid.
p
P
That would be broken by using parmbuff and &syspbuff. And I do not like &syspbuff any more.
I would use call execute to replace it now.
K
Ksharp
I can understand some of the reasons that make supplying parameters through call execute() more flexible
However, following up your comment
I do not like &syspbuff any more
please would you expand this comment explaining features which cause your dislike?
peter
P
The mainly reason is that parmbuff only can handle a macro variable &syspbuff and also need type some more word , whereas call execute support many macro variable and more brief more readable.
But That is not to say I hate to use &syspbuff, Everyone has oneself taste. I just show myself.
K
thank you for explaining.
I have never had a context where I have needed parmbuff - and hope that continues. However, an interesting paper on parameter validation demonstrated the usefulness of parmbuff to deal with any collection of parameters.
Peter
Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 25. Read more here about why you should contribute and what is in it for you!
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.