Date:         Wed, 7 Jun 2000 13:11:46 GMT
Reply-To:     Andreas Grueninger <grueninger@IBGRUENINGER.DE>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Andreas Grueninger <grueninger@IBGRUENINGER.DE>
Organization: Customer of UUNET Deutschland GmbH
Subject:      Re: Aggregate Storage/Directory Search under UNIX

This is should be no problem.
Using a script which
- defines environment variables MACRO_A, MACRO_B, MACRO_C, the values
are the directories with the source code (maybe  defined dependent of
username)
- starts sas with the option -SASAUTOS (MACRO_A MACRO_B MACRO_C)

When you use now an undefined macro SAS searches the three directories
for source code for the undefined macros, loads and compiles if found
and produces an error message if not found.


donaldtrevoy@SNIP.NET (Donald Trevoy) wrote:

>I've been asked to move a library of SAS/Graph macros from OpenVMS 6.2 to
>SunOS 5.6; both systems are running SAS 6.12 TS060.  What I'm struggling
>with is how to re-create a aggregate storage location on the new platform
>that references multiple directories and searches them in order.
>
>The original system uses OpenVMS logicals, one for each of the macros
>callable by the users, to define an aggregate storage location in which we
>store the code that macro requires.  This we do in a .COM file executed
>prior to invoking SAS.  In that file you would find code like this:
>
>$  DEFINE    MACRO_A     LIB:[GRAPHICS.MODULES.MACRO_A],
>
>LIB:[GRAPHICS.MODULES.UTILITIES]
>
>$  DEFINE    MACRO_B    LIB:[GRAPHICS.MODULES.MACRO_B],-
>
>LIB:[GRAPHICS.MODULES.UTILITIES]
>
>$  DEFINE    MACRO_C    LIB:[GRAPHICS.MODULES.MACRO_C],-
>
>LIB:[GRAPHICS.MODULES.UTILITIES]
>
>
>These macros are modular by design and in these two directories we store the
>macro-invoked modules (macros as well) that the user-invoked macro requires.
>This code is made available with a series of %INCLUDEs located in the
>user-invoked macro.  This code uses the OpenVMS logical as an aggregate
>storage location. Within macro MACRO_A, for example, you will find code that
>looks like this:
>
> %INCLUDE MACRO_A(MACRO_1);
> %INCLUDE MACRO_A(MACRO_2);
> %INCLUDE MACRO_A(MACRO_3);
>
>In the first of the directories defined by the logical - the one that bears
>the name of the user-called macro (MACRO_A, MACRO_B.) -- we store code used
>only by the named macro.  In the second directory (UTILITIES) we store the
>code that is shared by multiple macros.
>
>In order to find macro MACRO_1, SAS initially searches the first directory
>defined by logical MACRO_A - LIB:[GRAPHICS.MODULES.MACRO_A].  If macro
>MACRO_1 is not there, SAS then looks in the second listed location -
>LIB:[GRAPHICS.MODULES.UTILTIES].
>
>This technique allows us to eliminate the storage of duplicate code, even
>code used by all twelve of the user-callable macros.  It also makes this
>code readily available for browsing from the SAS Display Manager.  Because
>we used operating system logicals, this code is accessible with OpenVMS
>editors such as EDT and EVE as well.
>
>We'd like to preserve as much of this functionality as possible in the new
>environment.  In an effort to minimize the cost of re-validating the
>software, we'd also strongly prefer to leave the SAS code unchanged,
>confining any necessary modifications to the operating specific 'wrapper'
>that creates the environment in which they work.
>
>My UNIX guru tells me I can't duplicate this aggregate storage/directory
>search technique on the new platform.  Any informed second opinions would be
>greatly appreciated.
>
>Once again, many thanks to all!
>
>Don

Ingenieurbuero Grueninger
Uhlbergstr. 15
72631 Aichtal (Germany)
email: grueninger@ibgrueninger.de