Date:         Wed, 17 Sep 2008 00:45:34 +0000
Reply-To:     iw1junk@COMCAST.NET
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Ian Whitlock <iw1junk@COMCAST.NET>
Subject:      Re: why this "DO WHILE NOT" cause infinite loop?

Summary: FIRST. and LAST. variables are initialized to 0 or 1
         based on the presence of a legitimate BY statement.
#iw.-value=1

I have not read the entire thread, but have some observations.

   1          data _null_ ;
   2             put first.x= last.x= ;
   3             put first.y= last.y= ;
   4             retain first.y last.y 8 ;
   5          run ;

   NOTE: Variable first.x is uninitialized.
   NOTE: Variable last.x is uninitialized.
   first.x=0 last.x=0
   first.y=8 last.y=8
   NOTE: DATA statement used (Total process time):
         real time           0.04 seconds
         cpu time            0.02 seconds


   6
   7          data w q ;
   8             do x = 1, 1, 1 ;
   9                output ;
   10            end ;
   11         run ;

   NOTE: The data set WORK.W has 3 observations and 1 variables.
   NOTE: The data set WORK.Q has 3 observations and 1 variables.
   NOTE: DATA statement used (Total process time):
         real time           0.01 seconds
         cpu time            0.01 seconds

   12
   13         data _null_ ;
   14            put _all_ ;
   15            stop ;
   16            set w ;
   17            set q ;
   18            by x ;
   19         run ;

   x=. FIRST.x=1 LAST.x=1 _ERROR_=0 _N_=1
   NOTE: There were 1 observations read from the data set WORK.Q.
   NOTE: DATA statement used (Total process time):
         real time           0.01 seconds
         cpu time            0.01 seconds

In the first step FIRST.X and LAST.X are initialized to 0.  The note
about uninitialized refers to the user's code lacking some explicit
assignment, not to uninitialization.  Note that there is no message
about FIRST.Y and LAST.Y.  You should also note that the RETAIN
initialization must have come after the initialization to 0, since the
value 8 is reported instead of 0. Whether one calls this non-
executable assignment part of the compiling process or part of a
special pre-execution process is rather irrelevant since it cannot be
tested, i.e. the answer has nothing to do with programming in SAS.

The last step is curious, because of the presence of the note about
one observation from Q being read but no note about reading from the
preceding SET statement for W.  I also note that LAST.X is 1 in
contradiction to the fact that the second record is has X = 1.
Moreover, SAS could not know this without looking at the second
record.  That leads me to think that the note about reading the first
record is a by product of messages and does not indicate something
real.

Ian Whitlock