Date: Wed, 30 Oct 2002 16:13:25 -0500
Reply-To: "Dorfman, Paul" <Paul.Dorfman@BCBSFL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Dorfman, Paul" <Paul.Dorfman@BCBSFL.COM>
Subject: Re: tricky question
Content-Type: text/plain; charset=iso-8859-1
> -----Original Message-----
> From: Ian Whitlock [mailto:WHITLOI1@WESTAT.com]
>
> Paul,
>
> While I agree that it is a "no-brainer" and may be good
> enough for Philip's purposes, it is not fool proof.
Ian,
Agreed, but I did not make the claim. The intent was not to give a piece
good for all intents and purposes, but merely to give an idea what can be
done in principle leaving
> Any test short of OBS = MAX may produce erroneous results and procedures
like SQL cannot be
> adequately handled. For example, in your example, the program failed to
report the
> input data set for the SQL code.
This is because the log does not report it, either. Parsing the FROM clause
can be easily added, but when selection occurs from _last_, it is not too
informative.
> Try testing
>
> %let name = wrongdsn ;
> data _null_ ;
> input name $char20. ;
> call symput ( "name" , trim(name) ) ;
> cards ;
> w
> ;
>
> data &name ;
> x = 1 ;
> run ;
>
> The code above used a macro variable, but it would be easy to
> use the same theme without macro.
When the name of a future data set is determined at run-time, nothing can be
guaranteed, and OBS=MAX is not remedy, either. What guarantee of data set
name stability will it provide, for instance, in the case of
data w%substr(%sysfunc(ranuni(0),3,10) ;
set w ;
run ;
> It is the fact that in SAS, any iteration of any step
> may determine what future code steps are executed that makes
> limiting the number of observations problematic.
SAS is not unique in this respect. The same can be said about any language
capable of writing flexcode (most of 3GLs are), and even about the
super-rigid JCL - whose structure, hardly accidentally, reminds that of a
multi-step SAS program.
> It is also what makes SAS an interesting language.
Probably not 'it' by itself but rather the fact that 'it' is so easy to
achieve.
> Incidentally the option NEW on PROC PRINTTO clears the file
> so the first step is not needed.
Thanks! I simply forgot about that little sale in the parsimony department.
Kind regards,
--------------------
Paul M. Dorfman
Jacksonville, FL
--------------------
>
> IanWhitlock@westat.com
>
> -----Original Message-----
> From: Dorfman, Paul [mailto:Paul.Dorfman@BCBSFL.COM]
> Sent: Wednesday, October 30, 2002 1:20 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: tricky question
>
>
> Philip,
>
> Instead of writing your own code parser, as was suggested in
> one of the
> replies, why not use the SAS Supervisor with its ability to recognize,
> uncover, and report exactly the stuff you are looking for. I
> think that is
> what Peter Crawford meant. Of course, you need the SAS System
> to run the
> code you are desirous to analyze, but let us assume that this
> predicate is
> met. Then it is a no-brainer to have a SAS data step parse
> what the SAS
> supervisor has already dissected, for example:
>
> filename alg '&altlog' ;
>
> data _null_ ; file alg ; run ; *empty alg ;
>
> option obs = 0 notes nofullstimer source2 nocentre ;
>
> proc printto log = alg ; run ;
>
> %include 'h:\saspgm.txt' ; *program source;
>
> proc printto log = log ; run ;
>
> option obs = max ;
>
> data dsnames ( drop = _: ) ;
> length ref_order 8 libname memname $32 dstype $8 iotype $1 ;
> infile alg ;
> input ;
> _rec = upcase (compbl(_infile_)) ;
> if indexw (_rec, upcase('note:') ) > 0 ;
> if index (_rec, upcase('data set is empty')) = 0 ;
> dstype = 'data set' ; link dsnatch ;
> dstype = 'table' ; link dsnatch ;
> return ;
> dsnatch: _p = indexw (_rec, upcase (dstype)) ;
> if _p then do ;
> libname = scan (substr (_rec, _p +
> length(dstype)), 1, '. ') ;
> memname = scan (substr (_rec, _p +
> length(dstype)), 2, '. ') ;
> if indexw (_rec, upcase('read from')) then iotype = 'i' ;
> else iotype = 'o' ;
> ref_order ++ 1 ;
> output ;
> end ;
> return ;
> run ;
>
> proc print data = dsnames noobs ;
> run ;
>
> To test, I put some sasabracadabra in the file
> 'H:\saspgm.txt', namely,
>
> libname hlib 'H:\' ;
> data a ; do var = 1 to 20 ; output ; end ; run ;
> data ; set a ; run ;
> proc sort ; by _all_ ; run ;
> data c hlib.d ; set a ; run ;
> proc sort data = c ; by _all_ ; run ;
> data hlib._null_ ; merge _last_ hlib.d ; run ;
> proc sql ; create table z as select * from _last_ ; quit ;
> data ; do x = 1 to 10 ; output ; end ; run ;
>
> and ran the parsing program a few times to let the self-named
> data sets
> accumulate subscripts. Here is the output listing:
>
> ref_
> order libname memname dstype iotype
>
> 1 WORK A data set o
> 2 WORK A data set i
> 3 WORK DATA17 data set o
> 4 WORK DATA17 data set o
> 5 WORK A data set i
> 6 WORK C data set o
> 7 HLIB D data set o
> 8 WORK C data set o
> 9 WORK C data set i
> 10 HLIB D data set i
> 11 WORK Z table o
> 12 WORK DATA18 data set o
>
> Surely the same can be done with many more bells and whistles
> if you have
> bought ASAP, but the above has the advantage of costing next
> to nothing, and
> of course it can be easily embellished in more than one way
> depending on the
> needs.
>
> Kind regards,
> --------------------
> Paul M. Dorfman
> Jacksonville, FL
> --------------------
>
> > -----Original Message-----
> > From: Primak, Philip [mailto:Philip.Primak@GENZYME.COM]
> > Sent: Wednesday, October 30, 2002 9:21 AM
> > To: SAS-L@LISTSERV.UGA.EDU
> > Subject: tricky question
> >
> >
> > Dear SAS-L
> >
> >
> > My problem is - is there a way to dynamically create list of
> > all data sets
> > either used or created in some specific SAS code. Foe
> > instance, in that
> > specific code below:
> >
> > data x;
> > set sashelp.class;
> > run;
> >
> > proc sort data=x out=y;
> > by name;
> > run;
> >
> > I want to get WORK.X, SASHELP.CLASS, and WORK.Y
> >
> > Advance thanks,
> > Philip Primak
> > Genzyme Corporation
> >
> >
>
>
> Blue Cross Blue Shield of Florida, Inc., and its subsidiary and
> affiliate companies are not responsible for errors or
> omissions in this
> e-mail message. Any personal comments made in this e-mail do
> not reflect the
> views of Blue Cross Blue Shield of Florida, Inc.
>
>
Blue Cross Blue Shield of Florida, Inc., and its subsidiary and
affiliate companies are not responsible for errors or omissions in this e-mail message. Any personal comments made in this e-mail do not reflect the views of Blue Cross Blue Shield of Florida, Inc.
| 
