Wow, many thanks to you all!  (didn't I hear that SAS was closed for the holidays? : ) Really appreciate the alternate solutions. Sanjay and Dan, I have your Statistical Graphics Procedures by Example book out on my desk today, it has been a great introduction to SG procs.  So thanks for that as well.  (And Sanjay's SGRENDER solution might encourage me to get back into Warren Kuhfeld's GTL book, which I figured I'd dive into after spending more time with basic SGPLOT...  ) --Q. ... View more

Thanks so much Cynthia, that's definitely what I'm seeing. Where were you last night, when I was banging my ahead against the keyboard.:smileygrin: This morning, I started debugging from scratch with a simpler example, and started commenting out code, thinking "Well, it couldn't be the footnote statement", and there it was....   Which is a lesson it feels like I re-learn every 3 months.  When faced with odd results, debug calmly and methodically....  Last night I had 100 different theories for what could have been wrong (my ods PATH is being reset somewhere, there is a problem with my PROC TEMPLATE code, the .jpg file is corrupted, I should restart the SAS session, etc etc), but was too tired and frustrated to just debug. --Q. ... View more

Hi, This is just a guess.  A quick google search revealed that Autosys is scheduling software. From the second message, I'm guessing that maybe the job is trying to write a log file to /folder1/folder2/folder3/xyz.saslog So I would check the permissions to that folder and the file (if the file already exists), to make sure you have the appropriate permissions. --Q. ... View more

FYI Varun, I posted my last reply before seeing your note that after you read the other thread, we are now in agreement as to the rules for handling multiple ampersands.  Glad it makes sense. ... View more

Hi Varun, Well, I cranked up an old PC with SAS on it, and with SYMBOLGEN on, I do see messages that SAS tried to resolve both VARUN and VARUNYZ, as I had expected: 8    options symbolgen; 9    %let m2=y; 10   %let m3=z; 11   %put &&&&&varun&m2&m3; SYMBOLGEN:  && resolves to &. SYMBOLGEN:  && resolves to &. SYMBOLGEN:  Unable to resolve the macro variable reference &varun SYMBOLGEN:  && resolves to &. SYMBOLGEN:  Unable to resolve the macro variable reference &varun SYMBOLGEN:  && resolves to &. SYMBOLGEN:  Macro variable M2 resolves to y SYMBOLGEN:  Macro variable M3 resolves to z WARNING: Apparent symbolic reference VARUNYZ not resolved. &varunyz I was surprised that the order of the symbolgen lines suggests that SAS tried to resolve &varun twice before &m2 and &m3.  And I don't think I would trust symbolgen enough to believe it.  If it's true, to me its an oddity of the word scanner/tokenizer/macro processor/whatever construct you choose, but one which does not impact the final outcome, of &varunyz being returned.  And, if you define &varun, then the symbolgen messages are consistent with my belief that &m2 and &m3 are resolved in the first pass.  In my mental map of how the macro languages work, below I think of symbolgen lines 1-5 as coming from a first pass which resolved to &&QYZ, line 6 from a second pass which resolved to &QYZ, and the warning message coming from a third pass which could not find a macro variable named QYZ. 12   options symbolgen; 13   %let varun=Q; 14   %let m2=y; 15   %let m3=z; 16   %put &&&&&varun&m2&m3; SYMBOLGEN:  && resolves to &. SYMBOLGEN:  && resolves to &. SYMBOLGEN:  Macro variable VARUN resolves to Q SYMBOLGEN:  Macro variable M2 resolves to y SYMBOLGEN:  Macro variable M3 resolves to z SYMBOLGEN:  && resolves to &. WARNING: Apparent symbolic reference QYZ not resolved. &Qyz ... View more

Hi, I think the rule is actually simpler than you think.  I think the rule is: "When building tokens, two consecutive ampersands resolve to a single ampersand, and trigger the string to be rescanned in an additional pass." You don't need your part about "until it reaches n ampersands in front of a text..." So in your last example. %let m2=y; %let m3=z; * (no other macro variables defined); %put &&&&&varun&m2&m3; Pass #1 resolves to &&&varunyz Explanation: Ampsersands #1 and #2 resolve to one.  Ampersands #3 and #4 resolve to one.  Ampserand #5 begins a macro variable reference, because it is an ampersand followed by  character (v) which is valid as the start of a macro variable name.  The macro processor tries to resolve &varun and it cannot (because it is not defined, I assume, in your example). So it returns &varun.  &m2 resolves to y.  &m3 resolves to z. Pass #2. resolves to &&varunyz. Explanation: Ampersands #1 and #2 resolve to one ampersand.  Ampersand #3 begins a macro variables reference, and SAS tries to resolved &varunyz.  It cannot, so returns &varunyz. Pass #3 resolves to &varunyz Explanation: Ampersands #1 and #2 resolve to one ampersand. There is no macro variables reference. Pass #4 resolves to &varunyz Explanation: SAS sees &varunyz as a macro variable reference, tries to resolve it.  When it cannot, it returns &varunyz. So I would expect your %put statement to to return: &varunyz I would also expect one message that &varun could not be resolved (from pass 1) , and two messages that &varunyz could not be resolved (from passes 2 and 4). Is that consistent with what you are seeing?   If not, could you post the log? Regards, --Q. ... View more

You are correct that two ampersands resolve to one, and trigger the value to be rescanned.  But there is no bracketing, as described in your first post. Here are some notes on the resolution of your two examples, showing each pass of the scanning %let m1=x; %let m2=y; %let m3=z; %let m1yz=foo; %let xyz=foo2; &&&&m1&m2&m3  <- original value &&m1yz  <- && became & | && became & | m1 is just text | &m2 resolved to y | &m3 resolved to z &m1yz  <- && became & | m1yz is just text foo <- &m1yz resolved to foo &&&&&m1&m2&m3 &&xyz <- && became & | && became & | &m1 resolved to x | &m2 resolved to y | &m3 resolved to z &xyz  <-&& became & | xyz is just text foo2 <- &xyz becomes foo2 So as shown above, the two values do resolve differently.  If you are seeing the same result, I would guess that maybe you do not have macro variables &m1 &m2 &m3 defined.  In that case, you will get something like below. I'm less confident that I got this part right, without having SAS on hand to double check....: &&&&m1&m2&m3 &&m1&m2&m3 <- with note that &m2 and &m3 couldn't be resolved &m1&m2&m3 <- (cant remember if another note about &m2 and &m3 not resolving will be generated) &m1&m2&m3 <- with note that &m1 didn't resolve. &&&&&m1&m2&m3 &&&m1&m2&m3 <-with note that &m1 &m2 &m3 couldn't be resolved &&m1&m2&m3 &m1&m2&m3 &m1&m2&m3 <-final value Hope I got that right, as I don't have SAS in front of me.  If you want to learn more about this and other complexities of macro processing, I suggest you get a copy of Art's macro book ("Carpenter's Complete Guide to SAS Macro Language"), it's excellent. ... View more