Date: Fri, 5 Dec 2008 11:56:23 +0100
Reply-To: Alexander Konn <alexander.konn@IEA-DPC.DE>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Alexander Konn <alexander.konn@IEA-DPC.DE>
Subject: Re: SAS IDE
In-Reply-To: <200812050002.mB4I5TXv008835@malibu.cc.uga.edu>
Content-Type: text/plain; charset=ISO-8859-1
Hi Chang,
Thank you for your answer. I have printed out that paper and will read
it later today on my way home. I have never really taken the time to
find out what EG really is and can do. I have always taken it for some
kind of ETL tool with very limited use if you have to deal with uncommon
formats and complex data transformation and cleaning requirements.
Probably I was wrong. If I have full access to manipulate and write my
own my STP's, I could probably achieve what I want with EG and benefit
from it's ease of use through the GUI.
Anyhow, for my company the capability of SAS programs to communicate
with the OS is really crucial. E.g., we start SPSS and Python processes
for creating SPSS (.sav) files with formats and labels. So I'd have to
find a way to do this with EG. But judging from some brief research I
just did that should be possible with the ALLOWXMD option.
All the best,
Alex
Chang Chung wrote:
> On Mon, 1 Dec 2008 06:34:11 -0800, Alex <alexander.konn@IEA-DPC.DE> wrote:
> ...
>
>> I can't find something like a SAS plugin for Eclise which is well-suited
>> for developing plain data step and macro code.
>>
> ...
>
> hi, alex,
>
> IMHO, we already have the sas "ide" in sas(r) enterprise guide(r). it is
> just that "development" means different things to different languages/users.
>
> With EG, we are *not* supposed to code(or "develop") in serious languages
> like scl to create an af application. We are supposed to arrange data and
> proc step (and other) icons and interconnect them with arrows in order to
> set up "process flows." With some "solution" products, users' main task is
> (manually) input and edit "meta-data" only -- we are not even supposed to
> mess with data directly any more.
>
> Writing a stored processes (STP's) should really be left to a small number
> of si insiders. Or to highly skilled (and expensive) consultants. As the
> enterprise guide handles more and more choirs like checking and validating
> all kinds of input parameters, macro language skills will become less and
> less important. We users are supposed to click the buttons to run the
> already written/tested/validated STP's and get the output in excel sheets.
>
> You may think this view is extreme and groundless. Then I recommend your
> reading an important sas conference paper by chris hemedinger:
> http://support.sas.com/resources/papers/sgf2008/eguide.pdf
>
> Chris has done an excellent job describing the "benefits" of using EG. But
> the most important insight comes from reading the last section where he is
> talking about things that *cannot* be done with EG (that used to be possible
> with batch sas):
> X statement and Systask
> DDE
> SAS/AF and %WINDOW
> ENDSAS statement
>
> X, systask, and DDE are ways for sas to interact directly with the platform
> it is running on. EG does not allow us to do that any more. SAS/AF and
> %WINDOW are for running/developing sas applications. EG may think that they
> are not good enough. ENDSAS has been the ultimate control of sas sessions
> (i.e. killing it). EG takes it away from sas "developers."
>
> So has sas development been changed and been moved to somewhere else
> already. For ordinary users, the IDE for today's sas is not the next version
> of enhanced editor, not Eclipse with SAS tools plug-in, and never a
> quickly-put-together .net application taking advantage of sas integration
> technology. It is the sas EG and the future is here whether we like it or
> not. IMHO, that is. :-)
>
> cheers,
> chang
>
| 
