Date:         Fri, 18 May 2007 13:13:26 -0400
Reply-To:     Lorne Klassen <lk1@ROGERS.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Lorne Klassen <lk1@ROGERS.COM>
Subject:      Re: Generating %LET statements using PUT statements

At the very highest level:

-This is a code generator. The user fills in SAS tables containing
instructions for what code to generate. I interpret the info in these
tables.
-I generate a SAS program *file* instead of submitting the code directly as
it is generated. As I see it, this "2 phase" technique has 3 advantages:

1) I can check for errors in the input specs (input tables) WHILE the
program file is being generated. If errors are found then, no harm, the
code generator ends gracefully BEFORE any generated SAS code has even been
submitted. I only actually submit the generated program file if no errors
were detected during generation and generation is fully completed.

2) By creating a text file version of the program, this file is actually a
type of documentation or audit trail that the user can look back on in a
year and answer the question "What exactly did last year's processing
program look like?". Or if there is a problem, I as a developer can review
the generated program file.

3) By creating a text file version of the program, the user can opt to JUST
create the program file today (there's an option to "only generate, don't
submit"), and then submit the generated program at a later date. Why?,
maybe they don't have all of their data ready to be processed yet. It's
also useful for testing their input specs tables because of all of the
validation that is done during the generation phase. Maybe other reasons.

It's funny when people try to imply that I'm using the wrong approach or
that don't know what I'm doing. I've written two other SAS code generator
systems recently that are very similar to this one. They work
*FANTASTICALLY* well and have saved users tons of work in trying to write
code themselves. Instead, they only have to fill in the input (specs)
tables. Users have generated programs with millions of lines of code. And
they always have that generated program file to look back at in the future.

This little problem is the only roadblock I've run into after working on
these systems for several years.