Date:         Mon, 5 Jun 2006 09:52:40 -0600
Reply-To:     Alan Churchill <SASL001@SAVIAN.NET>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Alan Churchill <SASL001@SAVIAN.NET>
Subject:      Re: SAS as a programming language (OT: Response)
In-Reply-To:  <4edg42F1efa7eU1@individual.net>
Content-Type: text/plain; charset="us-ascii"

Richard,

Will it run on a different O/S? For example, if my license is for Windows
can I compile the app to run on a unix variant which my client may have?

Alan

Alan Churchill
Savian "Bridging SAS and Microsoft Technologies"
www.savian.net


-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Richard
A. DeVenezia
Sent: Saturday, June 03, 2006 7:12 AM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: SAS as a programming language (OT: Response)

Alan Churchill wrote:
> Joe,
>
> I have no axe to grind with SCL or Macro. I don't like macro myself
> and would probably use SCL if it was part of Base and I could count on
> it being available.
>
> Alan


The AF executor is ever present.  If you compile it, it will run.  Of
course, as developer, you will have to get the SCL compiler/ frame builder
(even here there may be some rounded corners {anecdotal evidence is that the
Data Model _setSource method can compile even if SAS/AF is not licensed} --
if true I could implement my own frame builder and persistor)

The 'use of AF is restricted' mindset is in some ways analagous to 'what-if
I could only run compiled DATA Steps'?  A little change moves the DS dev
camp into the AF dev camp.

We all want to write our own DATA Steps... or do we?  Some perspectives see
SAS pushing the stored procedure concept, which essentially submits
replacement values to boiler plated static code (code with abstraction
tokens having submit time replacement is shh... macro).

--
Richard A. DeVenezia
http://www.devenezia.com/
Use the tools you know well, when your tools wear out, get new ones.