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>
wrote:

>Frank,
>
>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
 -mLogicNest
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!

Peter Crawford
Crawford Software Consultancy Limited
UK



>Date:         Wed, 8 Feb 2006 18:18:42 -0800
>Reply-To:     frank_diiorio@YAHOO.COM
>Sender:       "SAS(r) Discussion"
>From:         Frank DiIorio <frank_diiorio@YAHOO.COM>
>Organization: http://groups.google.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.
>Thanks.
>Frank DiIorio