Ted,
How does a Canadian say tomato...
The CPU cost is the differentiator that you refer to. The additional cost of
interpretive languages is that each line of the source code must be
evaluated and acted on for every iteration of the code. This is classic
CLIST or REXX.
No matter how you label the compile/interpretation phase of SAS, the
execution phase does not result in line by line interpretation of the
source, and thus no interpretive cost. There is a compile and translate
cost, but the difference between compile and interpret is more than mere
semantics.
I don't write REXX or CLIST - I often wonder about that - but from past
tests I know that the CPU cost of the following SAS program compares
favorably with REPRO and beats IEBGENER, and I'd like to compare it with
REXX and CLIST equivalents.
Data _null_;
Infile ifile;
File ofile;
Input @;
Put _infile_;
Return;
Run;
I'm sure your point only pertains to the data step. It would be a hard
argument to convince anyone that PROC SORT parsing into execution DFSORT or
SYNCSORT will have interpretive CPU costs.
Ron
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Ted MacNEIL
> Sent: Wednesday, February 04, 2009 7:03 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] insanity? process SMF with Java on non-z?
>
> >SAS data steps are not interpreted, they are compiled and executed.
>
> Now you are getting semantically involved!
>
> >Would you say that a compile-load-go PL/I job is not compiled? That
seems to
> be what you're saying, but I don't think that falls within the commonly
> accepted meaning of the term.
>
> The difference is that I can keep PL/I object and load code if I want to.
> With SAS, regardless I cannot.
> So, translation/interpretation (or whatever you want to call it) is there
for
> every run, whether I want it or not.
> Therefore, the overhead is there everytime, regardless of what it is
called.
> That was my only point.
>
> You can argue what you want to call it, but it's still there EVERY run.
>
> This argument happened, last year.
> Hit the archives; I'm not going to have it, again.
>
> -
> Too busy driving to stop for gas!
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
