Date:         Sun, 1 Oct 2006 21:38:21 -0400
Reply-To:     "Richard A. DeVenezia" <rdevenezia@WILDBLUE.NET>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "Richard A. DeVenezia" <rdevenezia@WILDBLUE.NET>
Subject:      Re: Help on Macro for Reading Data
Comments: To: sas-l@uga.edu

Ian Whitlock wrote:

> Now if someone, in particular Richard or Randy, is interested in
> teaching me SCL, would he/she expand Richard's example to have
> the flexibility demonstrated above without the use of macro
> variables.  (Please note that the parameters ROOT and PREF could
> be empty.  In this case, %IMPORT could import an arbitrary list
> of CSV files spread across several directories as long as no
> spaces are used in the names of the paths.  %IMPORT could import
> an arbitrary list.)  I am particularly interested in preserving
> the simplicity of Richard's call
>
>    proc display cat=sasuser.import.many.scl ...
>
> while emphasizing the parameters of the problem.

At present the only way to pass parameters on the 'command line' of an SCL
entry invocation is to use the AFA command

DM 'AFA C=SASUSER.IMPORT.MANY.SCL param1name=param1value ...
paramNname=paramNvalue';

When this style of invocation is used, a _CMDLIST_ is available to the SCL
entry, from which named argument values can be retrieved.

Proc DISPLAY does not allow name=value arguments to coded. An improvement
suggested for future releases of SAS is to allow PROC DISPLAY to forgo or
extend formal option checking associated with typical Proc handling
(OPTIONNAME=OPTIONSETTING), and automatically pass unknown name=value pairs
to the _CMDLIST_.

> Finally, Richard's SCL could be directly translated into a DATA
> step.

Good call here.  Functionally, my submit continue block can be mapped to a
call execute.  However, results of Base SAS code submitted via SCL SUBMIT
CONTINUE can be easily checked for error codes and further downstream
invocations can be easily abandoned if the 'business rules' call for such.

>    data _null_
>      do p = 0 to 3;
>      do q = 0 to 3;
>        call execute
>          ( catt('PROC IMPORT
>                    OUT=DATA',p,q,
>                    DATAFILE=
>      '"C:\Documents and Settings\happy\Desktop\OIFORECAST\try'
>                    ,p,q,'..csv" dbms=csv
>                    replace;
>                  getnames=yes;
>                  run;')
>      end;
>      end;
>    run;
>
> So what is the advantage of using SCL for this problem?  The
> disadvantages are that you must have SAS/AF; you must compile
> code; and then manage the code.  What do I gain for the extra
> effort required by SCL in this sort of problem?

For simple single task procedural solutions there is no overarching reason
to use SCL over macro over CALL EXECUTE.  However, when several like
aspected procedural solutions are implemented, each procedural approach can
become a method of an object that brings together the collection wherein
state information is maintained and or communicated to other objects.  A
non-communicating object can be contrasted in some ways to a procedural
macro autocall library. Past conference papers have noted how some aspects
of object orientatedness can be implemented in macro solutions, but macro is
not really the best solution domain for building up objects.

--
Richard A. DeVenezia
http://www.devenezia.com/