Date:         Wed, 4 Jun 2003 20:25:34 +0200
Reply-To:     Lex Jansen
              <lexDOTjansenATlex-jansenDOTdemonDOTnl@CRONKITE.CC.UGA.EDU>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Lex Jansen
              <lexDOTjansenATlex-jansenDOTdemonDOTnl@CRONKITE.CC.UGA.EDU>
Organization: Posted via Supernews, http://www.supernews.com
Subject:      Re: 93 macros and counting

Peter,

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 ;

Lex Jansen

"Peter Crawford" <Peter@CrawfordSoftware.demon.co.uk> wrote in message
news:ZJoumDA$6a3+Ewa9@crawfordsoftware.demon.co.uk...
> 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......
>
> Regards
> Peter Crawford
>
>
>
> Roland <roland@rashleigh-berry.fsnet.co.uk> 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
some
> >way to lock in a macro library so the programmer couldn't change it if
they
> >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
the
> >logs hard to read.
> >
> >"Peter Crawford" <Peter@CRAWFORDSOFTWARE.DEMON.CO.UK> wrote in message
> >news:ob7CSDAzLI3+Ewdt@crawfordsoftware.demon.co.uk...
> >> But Roland,
> >>
> >> the mlogic tells you where (path and file name) the macro came from !
> >> Do they wish to distrust everything, including code already
"validated"?
> >>
> >> Roland <roland@rashleigh-berry.fsnet.co.uk> writes
> >> >They are going in the direction of having to
> >> >validate everything themselves (including SI-supplied macros) and so
it
> >is
> >> >easier for them and preferable to have all their autocall members in
one
> >> >place and verified during a production run. They also want to write to
> >the
> >> >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
>