Prev: Expand Results Tree
Next: title statement in proc print
From: m1st on 9 Jul 2010 02:29
Hello, people!

I'm quite new to SAS programming, and recently were surprised by some
inconsistency in SAS proc calls. Some of them (like PROC DATASETS or
PROC SQL) seem to require QUIT instead of usual RUN.
Is this the matter of some sense or just an ugly SAS programming
language implementation?
From: John Hendrickx on 9 Jul 2010 07:49
On 9 jul, 08:29, m1st <lex.alt...(a)gmail.com> wrote:
> Hello, people!
>
> I'm quite new to SAS programming, and recently were surprised by some
> inconsistency in SAS proc calls. Some of them (like PROC DATASETS or
> PROC SQL) seem to require QUIT instead of usual RUN.
> Is this the matter of some sense or just an ugly SAS programming
> language implementation?

It's the ugly SAS programming one.

SAS procedures (and the SAS datastep) do not execute until a run
statement is encountered, or the following procedure or datastep is
encountered, which amounts to an implied run statement. So the only
consequence of not using a run statement is that your last datastep of
proc statement won't be executed (and if you run your SAS program in
batch, even that problem is automatically solved). Nonetheless, it's
considered best practise to write a run statement after every datastep
or procedure.

Some procedure, such as proc gplot, proc glm, also have a quit
statement. If you run these procedures without the quit statement, you
can see "proc gplot running" in the title. There are no consequences
to never specifying a quit statement, you'll get your output anyway.

An exception is of course proc sql. Proc sql doesn't use a run
statement and it produces its results immediately. Proc sql keeps
running until it encounters a quit statement. It's a good idea to add
the quit statement but there are no consequences if you don't.

Good luck,
John Hendrickx
From: Ya on 9 Jul 2010 11:39
On Jul 9, 4:49 am, John Hendrickx <john2.hendri...(a)gmail.com> wrote:
> On 9 jul, 08:29, m1st <lex.alt...(a)gmail.com> wrote:
>
> > Hello, people!
>
> > I'm quite new to SAS programming, and recently were surprised by some
> > inconsistency in SAS proc calls. Some of them (like PROC DATASETS or
> > PROC SQL) seem to require QUIT instead of usual RUN.
> > Is this the matter of some sense or just an ugly SAS programming
> > language implementation?
>
> It's the ugly SAS programming one.
>
> SAS procedures (and the SAS datastep) do not execute until a run
> statement is encountered, or the following procedure or datastep is
> encountered, which amounts to an implied run statement. So the only
> consequence of not using a run statement is that your last datastep of
> proc statement won't be executed (and if you run your SAS program in
> batch, even that problem is automatically solved). Nonetheless, it's
> considered best practise to write a run statement after every datastep
> or procedure.
>
> Some procedure, such as proc gplot, proc glm, also have a quit
> statement. If you run these procedures without the quit statement, you
> can see "proc gplot running" in the title.  There are no consequences
> to never specifying a quit statement, you'll get your output anyway.
>
> An exception is of course proc sql. Proc sql doesn't use a run
> statement and it produces its results immediately. Proc sql keeps
> running until it encounters a quit statement. It's a good idea to add
> the quit statement but there are no consequences if you don't.
>
> Good luck,
> John Hendrickx

There is one situation that missing quit from proc sql will cause
problems
for following steps:

proc sql;
.....
;

ods output xx=yy;
proc somestatproc data=...
...
run;

yy will not be generated if quit statement is missing from previous
proc sql.

HTH

Ya
From: Andrew Karp Sierra Info Services on 9 Jul 2010 15:46
Allow me to weigh in on this topic. It comes up alot when I give SAS
training classes.

First, RUN and QUIT are both "explicit step boundaries" in the SAS
Programming Language.

PROC and DATA are "implied step boundaries."

Example1: Two explicit step boundaries.

DATA NEW;
SET OLD:
C = A + B;
RUN;

PROC PRINT DATA=NEW;
RUN;

In this example, both the data and the proc steps are explicitly
"ended" by their respective RUN statements.

Exmaple2: No explicit step boundaries.

DATA NEW;
SET OLD:
C = A + B;

PROC PRINT DATA=NEW;

In this example, the data step is implicitly terminated by the PROC
statement. But, there is no step boundary for the PROC PRINT step/
task, so it will not terminate unless/until the SAS supervisor
"receives" a step boundary.

Some PROCS support what is called RUN group processing. These include
PROCs DATASETS and PLOT in the BASE Module, PROCs REG and GLM in the
STAT module and ARIMA in the ETS module.

Example 4: PROC DATASETS with RUN group processing.

PROC DATASETS LIBRARY = MYLIB;
MODIFY SET1;
FORMAT VAR1 DOLLAR12.2;
LABEL VAR1 "Dollars Paid';
RUN;
DELETE SET2;
RUN;
CHANGE SET3 = SET2;
RUN;
QUIT;

In this example, there separate data mangement tasks are carried out
in the order they were written/coded. First a label and format are
added to the descriptor portion of SET1, then SET 2 is deleted, and
then SET3 is renamed to SET2. The RUN ends each command in the PROC
DATASETS step (MODIFY, DELETE, CHANGE) and QUIT ends the step. If the
explicit step boundary had been omitted, the step would have been
implicity terminated by a subsequent PROC or DATA statement. If there
were no implied step boundary following the last RUN command then the
PROC DATASETS step would not terminate.

The same holds true with oher RUN-group enabled PROCs in SAS
Software. The ARIMA procedure in the ETS module, for example,
implements what is called the Box-Jenkins methodology to analyze a
time series and then generate future forecasted values from the
existing series. There are three parts to this methodology, which are
implmented in PROC ARIMA using (in this order), the IDENTIFY, ESTIMATE
and FORECAST statements. The output from each statement is needed by
PROC ARIMA to move to the next step in the process, and an experienced
forecaster can look at the output generated by the IDENTIFY statement
and then write the appropriate ESTIMATE statement syntax, and then do
the same thing with the output generated by the ESTIMATE statement to
write the proper FORECAST statement syntax. Once the analyst is
satisfied with their model, they can terminate the PROC ARIMA step
with a QUIT statement and move on to the next part of their project.

I hope this has been helpful.

Andrew Karp
Sierra Information Services
http://www.SierraInformation.com



On Jul 9, 8:39 am, Ya <huang8...(a)gmail.com> wrote:
> On Jul 9, 4:49 am, John Hendrickx <john2.hendri...(a)gmail.com> wrote:
>
>
>
>
>
> > On 9 jul, 08:29, m1st <lex.alt...(a)gmail.com> wrote:
>
> > > Hello, people!
>
> > > I'm quite new to SAS programming, and recently were surprised by some
> > > inconsistency in SAS proc calls. Some of them (like PROC DATASETS or
> > > PROC SQL) seem to require QUIT instead of usual RUN.
> > > Is this the matter of some sense or just an ugly SAS programming
> > > language implementation?
>
> > It's the ugly SAS programming one.
>
> > SAS procedures (and the SAS datastep) do not execute until a run
> > statement is encountered, or the following procedure or datastep is
> > encountered, which amounts to an implied run statement. So the only
> > consequence of not using a run statement is that your last datastep of
> > proc statement won't be executed (and if you run your SAS program in
> > batch, even that problem is automatically solved). Nonetheless, it's
> > considered best practise to write a run statement after every datastep
> > or procedure.
>
> > Some procedure, such as proc gplot, proc glm, also have a quit
> > statement. If you run these procedures without the quit statement, you
> > can see "proc gplot running" in the title.  There are no consequences
> > to never specifying a quit statement, you'll get your output anyway.
>
> > An exception is of course proc sql. Proc sql doesn't use a run
> > statement and it produces its results immediately. Proc sql keeps
> > running until it encounters a quit statement. It's a good idea to add
> > the quit statement but there are no consequences if you don't.
>
> > Good luck,
> > John Hendrickx
>
> There is one situation that missing quit from proc sql will cause
> problems
> for following steps:
>
> proc sql;
> ....
> ;
>
> ods output xx=yy;
> proc somestatproc data=...
> ..
> run;
>
> yy will not be generated if quit statement is missing from previous
> proc sql.
>
> HTH
>
> Ya- Hide quoted text -
>
> - Show quoted text -

 | 
Pages: 1
Prev: Expand Results Tree
Next: title statement in proc print