I did very similar things across multiple datacenters with NDM and the JCL
Reader awhile back. And yes, explaining a SyncSort, EasyTrieve, SAS
milkshake to a newbie was an exercise in frustration. Hell, I told them
early on that SyncSort had limited commands (7 at the time?) but would take
them years to master threw them for a loop. Welcome to binary ;-]
That said, I think the details of what I am doing need something else.
The problem with tossing out a problem on SAS-L (and elsewhere) is that the
particular need is generalized to the point of losing what the original
constraints are bound by. After looking at the proposals and the ideas, I am
still faced with what I need to accomplish. Hence, while the %include was
not what I wanted, it worked out the best.
Melding 2 systems together, SAS and .NET, makes me choose alternatives that
aren't as pretty as I would like. Nonetheless, I have something that works
....and I forge ahead.
BTW, this isn't client work but SAS community work for my spare time. I
appreciate everything everyone has contributed and it will be returned.
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
Sent: Wednesday, August 13, 2008 5:23 PM
Subject: Re: Include SAS code w/o including SAS code
What you ask can be done (just about <anything> can be done in sas), but
at what price? The put statement is your friend--think if you were to
generate a whole job, not just a macro. The problem comes if you have any
macro variables that would need to be resolved when the second job runs--
now you have to play with quoting, so that sas doesn't try to interpret
them at compile time. And that can cause horrible headaches, esp if there
are some macro vars that you do want evaluated at compile time.
I have some code that was used on the mainframe to generate dynamically
created jobs that were then submitted either right into the reader or
across the wire to another machine--jcl, including macro resolutions for
pds, member name and ds name, as well as the job logic. It was a real
hassle to maintain, and difficult for a new person to pick up without
doing a lot of hand holding (or try and be patient, and after the 5th
mistake, they figure it out). Trying to coordinate batch processing
across multiple machines, when you have an established production window,
where you can't be waiting indefinitely for a dataset that may never come--
presents its own set of challenges.
If you're still curious, let me know and I'll pass it along.
On Tue, 12 Aug 2008 10:38:11 -0600, Alan Churchill <savian001@GMAIL.COM>
>I actually switched it over to a %include since readability is critical
>here. The only other method I can think of is to use datalines but that is
>not as convenient either.
>The underlying problem behind this exercise was:
>How can I have a set of valid SAS statements be filed into a text file and
>also be available for execution?
>Immediately, I said %include since that is obvious. However, I was hoping
>also be able to see the lines and make quick modifications in the editor.
>Since I have had time to think about it some more, I decided to go ahead
>split it out into 2 programs and simply %include them. That way I retain
>formatting. The only negative is that they are now in 2 tabs but I can
>All of the exploration done by people and pointing out various options has
>been helpful. The formatting though is critical and I don't want to run my
>cleaner on it.
>Sometimes it is best to just KISS.
>From: firstname.lastname@example.org [mailto:email@example.com]
>Sent: Tuesday, August 12, 2008 10:29 AM
>To: SAS(r) Discussion
>Cc: Alan Churchill
>Subject: Re: Include SAS code w/o including SAS code
>Summary: Macro generation of correct SAS code requires SAS execution.
>I do not see how this is possible.
> %macro q ( seed=0 ) ;
> %local cum ;
> data w ( keep = r ) ;
> do i = 1 to 20 ;
> r = ranuni ( &seed ) ;
> output ;
> end ;
> run ;
> data _null_ ;
> set w end = eof ;
> cum + r ;
> if eof then
> call symputx ( "cum" , cum ) ;
> run ;
> title1 "Cum = &cum" ;
> %mend q ;
>This macro ends up generating a TITLE statement. However, that
>title statement depends on the execution of the previous steps.
>Hence it cannot be generated by the macro facility without actually
>executing the previously generated code.
>The problem is similar to that of using CALL EXECUTE to generate
>SAS code via a macro call. In the case of CALL EXECUTE one can work
>around the problem by using %NRSTR to hide the call during the DATA
>step execution, but you have explicitly required the macro to generate
>correct code without executing. Now there is no work around.
>In essence you are asking, "Is the macro facility so weak that there
>is a program that can predict the output of every macro without
>executing it?" Since that output can depend on the execution of SAS
>code, one must first be able to predict the result of executing every
>SAS program without actually doing the executing. It seems highly
>unlikely that the SAS Institute is up to the job.
>Now in the simple situation that you gave, you could use the MFILE
>option with OBS = 0, and one of your "make SAS code pretty" programs
>to achieve a result almost as good as not executing SAS.
>The thing that is interesting about my above code is that no macro
>instructions other than asigning and evaluating macro variables are
>used. So even in this simple setting it might be hard to predict
>whether the resulting SAS code is the same as it would have been had
>the generated code actual executed.
>Date: Tue, 12 Aug 2008 08:41:35 -0600
>Reply-To: Alan Churchill <savian001@GMAIL.COM>
>Sender: "SAS(r) Discussion"
>From: Alan Churchill <savian001@GMAIL.COM>
>Subject: Re: Include SAS code w/o including SAS code
>Comments: To: "Fehd, Ronald J. (CDC/CCHIS/NCPHI)" <rjf2@CDC.GOV>
>Content-Type: text/plain; charset="us-ascii"
>I actually never want to store the macro code. I only want it
>available in a temp file which I then consume. For example:
> data temp.temp4;
> ...do some sas stuff...
>I want to save the contents, formatted, into a text file (i.e.
>c:\temp\program.sas) which I can then consume in another application.
>I also want to execute the code. Hence:
>Save the contents of the macro file to a text file with CRLF included.
>I don't want the run, merely the statements.
>Alan Churchill Savian www.savian.net