Date: Wed, 4 Jun 2003 20:25:34 +0200
Reply-To: Lex Jansen
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Lex Jansen
Organization: Posted via Supernews, http://www.supernews.com
Subject: Re: 93 macros and counting
From experience (sasv8.2, WinNT): concatenation of libraries allow use of
more than one compiled macro catalog.
These macro catalogs all have to be named SASMACR.
LIBNAME _mcgen "your first folder with a SASMACR catalog" ACCESS=READONLY;
LIBNAME _mcstat "your second folder with a SASMACR catalog" ACCESS=READONLY;
LIBNAME _mstore (_mcgen, _mcstat) ACCESS=READONLY;
LIBNAME _mcgen CLEAR;
LIBNAME _mcstat CLEAR;
OPTIONS MSTORED SASMSTORE=_mstore ;
"Peter Crawford" <Peter@CrawfordSoftware.demon.co.uk> wrote in message
> Stretch a little
> 1 locking in a macro library is ineffective if you want to be able
> to run macros in stream !
> That includes _all_ autocalling of macros as well as straight code.
> 2 noMautoSource option might be better, (disallow autocall of macros)
> but it needs to be accompanied by sasMstore= the option to indicate
> the libname hosting your sasmacr catalog of pre-compiled macros
> I haven't tested, but concatenation of libraries, might allow use
> of more than one compiled macro catalog.
> 3 option mfile won't give you macro source, but it does give the
> code generated (while option mprint is switched on)
> Any decision on the choice for these issues should surely be separated
> between at least, development and production. (The standard IT rule)
> Surely validation, FDA-style does not relate to code development, but
> only to the production of results.
> I think the SAS System offers support to both.
> It is the _use_ of the system that the FDA appear to wish to regulate,
> and validate, not its capabilities.
> In this way, although very important for satisfactory code development,
> options source2 and mlogic might cease to be necessary in production,
> if these modules and macros are implemented to report to the log
> certain fingerprint information which would validate themselves.
> I may be overstating any potential saving here. If a utility macro is
> called 1000 times, must it report its fingerprint 1000 times ?
> This is not a completed framework of ideas. I just hope I've given some
> more food for thought......
> Peter Crawford
> Roland <firstname.lastname@example.org> writes
> >"mlogic" gives you rather too much. If there were a system option just to
> >give you the macro source then that would be great. Also if there were
> >way to lock in a macro library so the programmer couldn't change it if
> >wanted too then that might come in useful. The logs have to be saved so
> >having a million lines of mlogic in them would waste disk space and make
> >logs hard to read.
> >"Peter Crawford" <Peter@CRAWFORDSOFTWARE.DEMON.CO.UK> wrote in message
> >> But Roland,
> >> the mlogic tells you where (path and file name) the macro came from !
> >> Do they wish to distrust everything, including code already
> >> Roland <email@example.com> writes
> >> >They are going in the direction of having to
> >> >validate everything themselves (including SI-supplied macros) and so
> >> >easier for them and preferable to have all their autocall members in
> >> >place and verified during a production run. They also want to write to
> >> >logs the exact source of any macro called as part of this. It gets
> >> >complicated...
> >> >
> >> How about a second stage job in the production run. It would start a
> >> validate stage to parse the sas log from first stage, verifying
> >> that :
> >> all includes (origin provided by option source2) and
> >> all autocall-ed macros (origin given by option mlogic)
> >> are from trusted sources.
> >> That sounds quite do-able, and much more flexible than just one
> >> sasautos!
> >> --
> Peter Crawford
> available for SAS consultancy contracts