Date:         Thu, 29 Feb 1996 08:38:00 -0500
Reply-To:     fu.m@PG.COM
Sender:       "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From:         Min Fu <fu.m@PG.COM>
Subject:      Re[2]: SAS MACROS

Message authorized by:
    : /S=karsten@NEWAGE1.STANFORD.EDU/OU=SMTP/O=1.UCN.GO.1/P=PROCTERGAMBLE/A=MCI
Karsten,
 
I usually use SASAUTOS to have my macros called automatically  I don't
think those macros should be related.  I have one directory including whole
bunch of them not related and called by totally different functional
programs. They have been working fine.  Further, when time comes to the
maintenance I feel less difficult to deal with them as I work with
uncompiled macro codes which usually are short pieces stored in the library
 
 
Were you talking about compiled autocall macros?  I may miss your point and
correct me if any.
 
Min Fu
 
Trilogy Consulting at P&G
fu.m@pg.com
 
______________________________ Reply Separator _________________________________
Subject: Re: SAS MACROS
Author:  (INTERNET)SAS-L@UGA.CC.UGA.EDU at external
Date:    2/29/96 1:40 AM
 
 
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Newsgroups:   bit.listserv.sas-l
Comments: To: Mike Harris <mikeh@AMGEN.COM>
 
Agreed on all points with one minor technical correction.
 
You *can* put more than one macro into an autocall file (SI does this
with the macros provided in v6.09/Unix !!) -- but don't let me catch you
doing this or I'll shoot you dead....
 
Because SAS compiles all the autocall macros on invocation, it *will*
compile multiple macros in a single autocall file.  The only reasonable
way to structure this is if the additional macros are functionally
related (or subsidiary) to the primary macro.
 
Putting multiple, unrelated macros in one file makes maintenance....,
well, rhymes with "Leona Helmsley" (a particularly difficult Hotelless,
to the non-Americans on the list).
 
 
On Wed, 28 Feb 1996, Mike Harris wrote:
 
> For the ultimate in macro convenience, use the AUTOCALL facility. First create
> a
> directory (or directories) as dedicated macro libraries. Next, create source
> code
> in your library. Each file must contain one macro, the filename must be the
> same
> as the macro name, and each file must have the .sas extension. (No, you can't
> use
> the pervasive but unsupported .mac extension.) Finally, set the SASAUTOS
option
> to point to all directories you want SAS to search, preferably in
AUTOEXEC.SAS.
> You may now call all your macros like functions, without %including or having
> the
> source code in your programs. Using AUTOCALL facilitates shared macro
libraries
> and streamlines programs. To use it successfully, macros in the library need
to
> be thoroughly tested, debugged and documented before release. One important
> point
> to consider in testing and using autocall macros is that they are compiled the
> first time they are encountered during a session. If the source code changes
> (as
> in testing and debugging), those changes will not be propagated to any macros
> that have already been compiled. You'll need to %include the code or start a
> new
> SAS session to recompile it. AUTOCALL is a great but underutilized feature of
> SAS.
>
> Mike Harris
> mikeh@amgen.com
> *** Disclaimer: These are the opinions of the poster not Amgen Inc.***
>
 
---------------------------------------------
Karsten M. Self -- Sr. SAS Programmer/Analyst
            Sierra Information Services, Inc.
  Contracting for NBER at Stanford University
 
  Karsten@newage1.Stanford.EDU
  KMSelf@ix.netcom.com
 
What part of gestalt don't you understand?