Date: Mon, 10 Jan 2000 19:12:31 -0500
Reply-To: Douglas Dame <dougdame@HPE.UFL.EDU>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Douglas Dame <dougdame@HPE.UFL.EDU>
Subject: Re: Variables used in a program (was "MVS variables..." but the Q
is not O/S specific)
Content-Type: text/plain; charset="us-ascii"
If the "final output" of your program includes one or more "permanent"
datasets that will be used by other programs -- presumably the case,
otherwise, why create them? -- then it will be impossible to tell by looking
at just the internal code which incoming variables are unnecessary.
(Although one could argue that any variable passing through the program
unaltered could just as well be accessed by a subsequent program from the
original "source" data ... but whether that would be optimally efficient in
practice would be dependent on the particulars of your situation.)
Even if that's not the case, for example if the final product is "a report"
of some flavor, it's still difficult. Bearing in mind the many funky &
subtle ways variables to be used can be specified in SAS programs:
MON: (everything starting with MON)
FIRSTVAR--VAR600 (all vars "between" the 2 end-points)
proc print; run; (an implicit _ALL_)
and the possibility of [dataset] variable names being carried around (or
created) through the creative use of SAS macro variables .....
... I would hold out little hope that an "easy [that's the key word] SAS or
other software method" could do the analysis you're hoping for.
If you can positively identify what are your "final report variables" (i.e.,
the design specifications for the final product, although must of us in
SAS-land aren't that formal about calling it that), you have a reasonable
shot at starting from there and reverse engineering the minimum input
dataset that will get to that desired end point. But your quality control
plan is still necessarily going to have to include devising a method of
comparing the values of all the final variables, as created with your
restricted set of inputs, with the values of those same variables as output
by the "old" program, just to make absolutely sure that no computations
along the way have inadvertently been compromised.
All in all, sounds like as if this (writing code to do all this checking of
variable references/usage in another program) could potentially be a LOT of
work. Could you get to a 50% solution fairly easily? Hard to say, maybe.
Quicker than you would by hand? Maybe. Of course, a 50% machine solution is
re-usable against other similar programs, the all-hand approach always
starts at 0%.
Time for cost/benefit questions. How long does this program take to run AS
IS/what's the cost in other resources you care about? How much improvement
do you think might be possible? How often is this puppy run, daily, weekly,
or monthly? (Can the original programmer/s be located/threatened/motivated
by guilt to help?) Is this a "production" program? What's the downside risk
if you "break it", even temporarily? Is there a recognized need to
re-engineer this program anyway, if for no other reason than because it's
barely understandable or supportable in its current non-svelte state?
Just some thoughts, hope this helps.
Charles Darwin (1809-1882) said:
"All SAS programs start small and
evolve to bloated. Except Paul Dorfman's,
his code just gets tighter and tighter,
which proves the general rule."
> -----Original Message-----
> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU]On
> Behalf Of Gary Ross
> Sent: Monday, January 10, 2000 1:03 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Mvs Sas-Variables used in a program
> This may take some explaining so bear with me. I have
> a "large" Sasfile (lets say a 1000 variables) which is
> used in a complex, lengthy program. For efficiency, I
> would like to reduce the 1000 variable Sasfile down to
> only the variables used in the program. If there a easy
> Sas or other software method of doing this?