|Date: ||Fri, 31 Aug 2001 20:29:51 -0400|
|Reply-To: ||"Dorfman, Paul" <Paul.Dorfman@BCBSFL.COM>|
|Sender: ||"SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>|
|From: ||"Dorfman, Paul" <Paul.Dorfman@BCBSFL.COM>|
|Subject: ||Re: Testing for empty file.|
|Content-Type: ||text/plain; charset=iso-8859-1|
While Paul has pointed out to the list several times that programs which use
_N_ and other automatic variable names work correctly, I'd issue a mild
warning. The SAS Version 8 documentation says explicitly:
"SAS reserves a few names for automatic variables and variable lists, SAS
data sets, and librefs.
When creating variables, do not use the names of special SAS automatic
variables (for example, _N_ and _ERROR_) or special variable list names (for
example, _CHARACTER_, _NUMERIC_, and _ALL_)." Ref: SAS Language Reference:
Precisely: It does not recommend "*creating* variables" with the same names
as automatic ones (I am not talking about the list names - they should not
be used as user names, period). Since they already exist, the hazy phrase
above can only really be about creating SAS data sets with columns named the
"automatic" way. That would be imprudent, indeed, since they would either be
dropped by default or, if forced there anyway, dropped when one least
expects it. Consider the famous Bob Virgile's example:
18 data a (rename=(N=_n_ E=_error_ I=_iorc_));
19 retain N 1 E 0 ;
20 do I=1 to 3 ; output ; end ;
21 run ;
NOTE: The data set WORK.A has 3 observations and 3 variables.
22 data b ; set a ; run ;
NOTE: There were 3 observations read from the data set WORK.A.
NOTE: The data set WORK.B has 3 observations and 0 variables.
Try to guess, without knowing what the previous step was, how come B ended
up without variables! And that, IMO, is what the doc is attempting to tell.
But nowhere does it say that you cannot *reuse* automatic variables, that
is, modify them, programmatically. In fact, elsewhere in the same SAS doc it
is *recommended* that _error_ be reset to zero as needed! If the doc piece
you are citing means more than "do not stick these variables in the
descriptor", how must I understand this _error_ business? "Yeah, but"? And I
also recall a certain DB2 processing application where it was useful to
reset _iorc_ to 0.
I suppose that it might be considered a bug if the compiler allows
assignment to an automatic variable name.
Were they really concerned or serious about possible harm caused by
modifying the automatics, it would be a simple matter to kill such usage at
the compiler level.
At the very least I'd consider adopting the practice of a colleague of mine
from many years ago who commented sections of code which were tricky in some
way with the warning /* SKULL AND CROSSBONES */. Just as some substances
are beneficial when used in one manner but are poisonous when used in
another, I'd suggest that the practice of overloading a variable with
multiple uses while it can have benefits can also be a source of error.
Overloading an automatic variable could be a smidgen more dicey.
Quite on the contrary! Of course using a variable X as an array subscript,
array element (we have seen it here recently), and to store a transaction
balance would be, to put it mildly, stupid. But using the self-refreshing
_N_ or idle _IORC_ (in the absence of SET KEY=) as a subscript or some
temporary storage location makes perfect sense: Precisely because they are
sitting there doing nothing and clean themselves after the step is done.
I have seen more one colleague struggling with step B using I as an index
because I had been inadvertently kept in the previous step. But you do nto
place S&C everywhere I is used as a subscript, even though is it far more
dangerous than using automatics as indices, in fact making the program more,
not less, robust, because one simply cannot *forget* to drop _n_.
This is the way I see it. Show me a program (aside from something plainly
dumb) harmed by manipulating, modifying, reusing, assigning to, _N_, and I
will gladly change my mind!
Paul M. Dorfman
Blue Cross Blue Shield of Florida, Inc., and its subsidiary and
affiliate companies are not responsible for errors or omissions in this e-mail message. Any personal comments made in this e-mail do not reflect the views of Blue Cross Blue Shield of Florida, Inc.