-------------------- 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: Concepts --------------------

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!

Kind regards, ===================== Paul M. Dorfman Jacksonville, FL =====================

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.