Date: Sat, 11 Feb 2006 12:23:08 -0500
Reply-To: Peter Crawford <peter.crawford@BLUEYONDER.CO.UK>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Peter Crawford <peter.crawford@BLUEYONDER.CO.UK>
Subject: Re: Identifying macro language elements
In response to : frank_diiorio@YAHOO.COM
On Fri, 10 Feb 2006 01:40:37 +0000, Ian Whitlock <iw1junk@COMCAST.NET>
>Maybe there are other nightmares.
>How do you handle ............
Ian goes on to demonstrate the risks involved in syntax analysis.
For discovering macro cross-calling, I describe below, an
alternative to this syntax analysis.
I hope it is a better alternative.
For a scan of macro hierarchy, nothing beats the macro compiler.
In SAS9 this is revealed in various ways by options like:
mAutoLocDisplay ( where it comes from )
mLogicNest ( macro call hierarchy )
mPrintNest ( generated code comes from all these macros)
Of course these can be switched off, returning the researcher
to the "nightmares". but I expect they will be more revealing
(and perhaps more reliable) than parsing the plain macro source.
The SAS9 option
provides the information underlying the macro-call cross-reference.
In SAS8, there is no substitute for mLogicNest. My team were
able to parse saslogs to reveal this aspect of application
hierarchy by parsing messages like
MLOGIC(METALLOC): Beginning execution
MLOGIC(METALLOC): Ending execution.
The SAS9 mAutoLocDisplay information is provided at the top of a
macro call in SAS8, in the mLogic output, like:
MLOGIC(METALLOC): This macro was compiled from the autocall file ...
The origin of each %include-ed code was determined from the NOTEs
associated with the source2 option.
Of course, making these pieces of information available
required the options mlogic mprint source2, but the pay-back
was very high.
Is this process any better than parsing syntax ? I'm not sure!
Although it captures the macro compiler's complete understanding
of the macro hierarchy, it depends on having a log full of the
mLogic and Source2. It also needs to take care of macros whose
purpose is to switch off/on macro debugging.
For macro crossreference documentation, mLogicNest is excellent!
Crawford Software Consultancy Limited
>Date: Wed, 8 Feb 2006 18:18:42 -0800
>Sender: "SAS(r) Discussion"
>From: Frank DiIorio <frank_diiorio@YAHOO.COM>
>Subject: Identifying macro language elements
>Comments: To: sas-l
>Content-Type: text/plain; charset="iso-8859-1"
>I have a program that reads macros in one or more user-specified
>directories, looks for calls to user-written macros, and constructs a
>cross-reference dataset. The program then creates two reports: "macro
>X uses which macros" and "macro Y is used by which macros"
>It works fine, but was written for V9.1 and thus failed to catch
>references to items new in V9.1.3 (for example, it saw a reference to
>%symexist and thought it was a user-written macro). I have a format
>that maps %IF, %THEN, %SYMDEL, etc. to 'no', which prevents that token
>from being output. I added %symexist, %symlocal, et al. to the format
>definition, but am wondering if there's another way to do this.
>Rephrased: how can I determine if a variable holds the name of a macro
>language statement, function, etc. I'm OK with the user-format
>approach, but if there's a less cumbersome way to do this, I'd like to
>hear about it.