I'm also surprised that a  * comment in a macro definition can comment out a macro invocation: options mlogic ; %macro abc(); %put I do not execute ; %mend; %macro doit() ; * %abc() ; %mend; %doit() I think you're right that officially a macro invocation is not a macro language statement.  So perhaps this behavior is undefined by the documentation.     But I don't think the macro call should go to the word queue.  I would expect when the above macro executes the * would go to the word queue, the macro call %abc would execute, and then the semicolon would go to the word queue.  But obviously that's not what happens.   My guess is it has something to do with the macro language compiler.  Clearly when the macro is compiled, the compiler is looking inside of * comments.  This is because the * has no meaning to the macro compiler.  And it is why macro statements inside of a * comment will be compiled (and later executed).  I suppose it's possible that a macro invocation is not compiled in the same way as a macro statement is compiled.     Okay, here's another oddity.  With this code: options mlogic ; %macro abc(); Hello world %mend; %macro doit() ; * %abc() ; %mend; If I code: %doit() the macro ABC is not invoked.  But if I code: %put %doit() ; the macro ABC is invoked.   So I'm not sure what to conclude, except that the * is not a comment in the macro language, and when you use * comments inside a macro definition, behavior can be odd.   I'm away from my bookcase.  Does Art not explain this behavior? ... View more

Thanks Tom. Combining with the reply from ballardw, I finally got what is going on: The unmasked comma in &final_class is regarded as one parameter separator by IFC in the macro facility, then only the first segment is returned since the condition evaluation is positive.   ... View more

There is a limit to how much SAS can do to read your mind.     In general SAS will default to length of 8 if there is no information available to make a different guess. In general SAS will default to length of 200 when the only extra information is that the variable is being assigned the result of a character function.  200 used to be the maximum length of a character variable and I suspect that when they changed it with the short lived version 7 release they did not want to break existing code by changing from 200 to the new 32,767 maximum length. There are some special cases, like the SUBSTR() function where SAS is able to make a (potentially) better guess.  But TRANWRD() is not one of them.  What length should it use? You could not just use the length of the first argument since the result of replacing some of the substrings with other substrings could result in a much longer string than the original first argument had.   If you know what you want the maximum length to be then actual DEFINE the variable and don't let SAS guess.   If you know what you are changing will not increase the length then you could just add an extra assignment statement first so SAS will know to guess to make the new the variable the same length as the old one. newcode = all; newcode = tranwrd(all,'ONE','TWO') ;   And forget trying to make any sense of SQL code.  You have to type so much extra junk to get SQL syntax correct just get used to typing the desired length also.       ... View more