LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (August 2001, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Mon, 13 Aug 2001 10:13:46 -0700
Reply-To:     Dale McLerran <dmclerra@MY-DEJA.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Dale McLerran <dmclerra@MY-DEJA.COM>
Subject:      Re: Interesting difference between 6.12 and 8.2
Comments: To: greg.woolridge@tap.com
Content-Type: text/plain

Greg,

One of the big changes between version 6.xx to 8.y was support for long variable names. At the same time that they implemented support for long names, SI also adopted mixed case naming. This support for mixed case naming is not like Unix mixed case naming, where TEST, Test, and test specify different variables. In SAS, there can be only one variable named TesT, no matter how you choose to write it employing upper and lower casing. Moreover, the name is stored with the particular casing as the first occurrence of the variable. So, if you had the statements

data myv8file; length TEST 3; test = 1; output; run;

then the single variable in this dataset would be placed in the descriptor as TEST. However, if you reversed the order of the length and assignment statements in the above code, the variable would be place in the descriptor as test.

What I have described so far is the default behavior in version 8. Now, realizing that this could cause some folks problems, SAS has implemented a system option which allows you more control over the naming conventions. First of all, you can adopt a version 6 convention, in which names have no more than 8 characters and are stored as uppercase. Alternatively, you can allow names to have length up to 32 characters but require that the names be stored in uppercase, regardless of how the name first appears. The system option which controls how SAS names are stored is the option VALIDVARNAME. It can take on values V7 (default), V6 (max 8 bytes uppercased), UPCASE (max 32 bytes, uppercased), or ANY. Note that if you specify ANY, SAS can employ variable names which have any ANSII characters. Thus, you could have variable names which have embedded spaces, names which use parentheses, etc.

I have found this most useful when reading Access tables, where the column names are often not "variable names" but rather "variable descriptions". In order to reference variables with embedded spaces or other characters which are not part of the traditional SAS naming convention, SAS has implemented what are called name literals. Name literals have the variable name surrounded by quotation marks, followed by the letter n. Thus, you could reference a name literal as

"Sodium Chloride"n

I know that this is the long answer to your short question, but understanding the available naming conventions will help you get the most out of version 8.

Dale

>Date: Mon, 13 Aug 2001 10:49:21 -0500 >Reply-To: greg.woolridge@TAP.COM > Greg Woolridge <greg.woolridge@TAP.COM> Interesting difference between 6.12 and 8.2 SAS-L@LISTSERV.UGA.EDU >Hi SAS-Lers, > >We are finally getting round to investigating 8.2 and how converting from >6.12 will affect us. I have noticed something interesting with data sets >in 8.2 vs 6.12 an was wondering if anyone had run into and dealt with this. > >The following bit of code produces identical results in 6.12, but not in >8.2: > >data tester; > input @1 comment $35. @37 comm1 $35.; > cards; >This is a comment to test mixed This is the second comment variable >THIS IS ANOTHER COMMENT and this is lower case >This contains SOME UPPER and lower This one IS ALSO upper and LOWER >let's try one that is all lower AND ONE THAT IS ALL UPPER >This Is The Last One This is the last one >; >run; > >proc contents; run; > >data tester; > input @1 COMMENT $35. @37 comm1 $35.; > cards; >This is a comment to test mixed This is the second comment variable >THIS IS ANOTHER COMMENT and this is lower case >This contains SOME UPPER and lower This one IS ALSO upper and LOWER >let's try one that is all lower AND ONE THAT IS ALL UPPER >This Is The Last One This is the last one >; >run; > >proc contents; run; > >If you look closely, you will notice that the difference between the 2 data >steps is that the input variable comment in the second step is in all caps. >In 6.12 the contents procedure shows all variables in all caps, regardless >of how they're typed in the program code. Hence, the result is the same in >both cases. In 8.2, the contents procedure shows the variable names in the >same case as is used in the program . The 2 steps give different results. >I have discovered that the effect is apparently in the descriptor portion >of the data set, as the differences are also noticed in the options window >of Display Manager and when using other SAS procedures and functions to >compare variable names. > >I can't find any documentation on this change or any option that will allow >me to go back to the old way. The problem is that I have some programs >where I do a PROC CONTENTS and use a statement like if name='CHECK'. Now >it appears that I will need to change all that code to something like if >upcase(name)='CHECK'. > >Has anyone else run into this? Can anyone offer a better solution than >recoding all programs? > >Greg M. Woolridge >Manager, Study Programming >TAP Pharmaceutical Products Inc. >e-mail: greg.woolridge@tap.com >phone: 847-582-2332 >fax: 847-582-2403

--------------------------------------- Dale McLerran Fred Hutchinson Cancer Research Center mailto: dmclerra@fhcrc.org Ph: (206) 667-2926 Fax: (206) 667-5977 ---------------------------------------

------------------------------------------------------------ --== Sent via Deja.com ==-- http://www.deja.com/


Back to: Top of message | Previous page | Main SAS-L page