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 (December 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, 10 Dec 2001 21:38:26 +0100
Reply-To:   Peter Crawford <peter.crawford@DB.COM>
Sender:   "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:   Peter Crawford <peter.crawford@DB.COM>
Subject:   Re: upper(trim(left(myvar)))
Comments:   To: mark.k.moran@CENSUS.GOV
Content-type:   text/plain; charset=iso-8859-1

I know that Paul has already answered this, but here is another $0.02 With the trantab system option and procedure, you can control and customize the translations behind lowcase() and upcase() as well as between ascii and non-ascii systems. This allows you to adopt your own application conventions. If you want mono-case data, why not read all your text with the $upcase. informat .... once again the sas system provides defaults for flexibility and controls for those who don't want that flexibility !! .... * trim() when you want - other wise don't * upcase() or $upcase. when _you_ want * use data step "call symput()" if you must, but recognise proc sql noprint; select valu into :mvar1-:mvar9999 from your.table; quit; might read better for some people (=easier support) than data _null_; set your.data; call symput('mvar'||left(put(_n_,4.)), trim(left(put(valu,best12.)))); run; * use validvarname =upcase if _you_ want - don't force us * the data you process belongs to you, so don't blame the sas system when you find your data difficult to handle * SI owns the sas syntax, but listens to customers, maybe they hear your pain (at ballot and customer support !)

... /$0.02-rant-off

Datum: 10.12.2001 20:48 An: SAS-L@LISTSERV.UGA.EDU

Antwort an: mark.k.moran@CENSUS.GOV

Betreff: Re: upper(trim(left(myvar))) Nachrichtentext:

>>>>

Absolutely, plus there is a good deal of terminological confusion here. SAS allows identifiers to be case-insensitive, thus SAS cannot be called a case-sensitive language. Now, the notion that the software ought, by default, to convert all letters in data to the same case (which one?) is short-sighted, to put it mildly. Why would not demand, then, that all non-printable characters be mapped to the same hex? Different characters must be treated differently. If a certain business situation calls for treating some characters the same way, fine: SAS supplies the TRANSLATE function, and moreover, its functionality is duplicated by the UP/LOWCASE pair specifically for the letters.

>>>>

The question is what should the default be, the norm.

--

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


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