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 (July 2004, week 1)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Sun, 4 Jul 2004 12:26:10 -0500
Reply-To:     Kevin Myers <KevinMyers@AUSTIN.RR.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Kevin Myers <KevinMyers@AUSTIN.RR.COM>
Organization: Posted via Supernews, http://www.supernews.com
Subject:      Re: Assign Result of PUT Statement to a Variable

Please see below...

"Paul M. Dorfman" <sashole@bellsouth.net> wrote in message news:20040704165346.GCEF1701.imf20aec.mail.bellsouth.net@sasholewmis4a7... > Kevin, > > Richard has pointed in one right direction with _FILE_, however the > functionality being sought had been available long before _FILE_ emerged in > the form of (_ALL_) (<modifier[s], <formats>>). In this form, _ALL_ > disregards automatic variables and only snatches non-automatic ones in the > PDV order. Thus, if for values

No Paul, using _ALL_, etc. does not replace the functionality of _FILE_. Without using _FILE_ there is no way to assign what would be written by the PUT statement to a variable, which is the functionality that I need.

> > retain ch1 'start' n1 1 ch2 'BB' n2 16256 ch3 'end' ; > format n2 worddate. ; > > we code > > file <fileref> dlm = ',' dsd ; > put (_all_) (:) ; > > what we get is: > > start,1,BB,"July 4, 2004",end > > where the delimited values are quoted only if there exists an ambiguity with > regard to the delimiter - which is why "July 4, 2004" gets quoted. This is a > pretty smart behavior on part of the compiler. Now there are a number of > variations on the theme: > > put (_all_) (~) ; > "start","1","BB","July 4, 2004","end" > > which quotes everything including the formatted values of numeric variables. > > put (_char_ _numeric_) (~) ; > "start","BB","end","1","July 4, 2004" > > where you decide how to group quoted output by type. > > Caution: Note that > > file <fileref> dlm = ',' ; *note the absence of DSD ; > format _char_ $quote. ; > > hides a caveat negating the "smart quoting" behavior highlited above, for > then both > > put (_all_) (:) ; > put (_all_) (~) ; > > AND the _FILE_ technique offered by Richard give > > "start",1,"BB",July 4, 2004,"end"

Yes, but the formatted numeric values that I am working with will fortunately never contain quotes or commas.

> > where thus July 4 and 2004 appear as separated entries to anything reading > it as a CSV list, so one using this form of output must make sure that no > formatted values contain DLM= character. Methinks that specifying DSD and > using the forms > > put (_all_) (:) ; > put (_all_) (~) ; > > depending on whether the formatted numeric values need to be quoted or not > (if not, values containing the delimiter will be quoted still) are the > safest.

Nope, can't use those forms because 1) my numeric values MUST NEVER be quoted (hence ~ modifier won't work), 2) ALL of my chracter values MUST be quoted, regardless of whether there are any embedded quotes or delimiters (hence colon modifier doesn't help), and 3) my variables must be output according to the order created in the data step, hence the following won't work either, as previously mentioned: put (_character_) (~) _numeric_.

Instead, the following suggestion from Roger DeAngelis does what I need, as mentioned in a prior post: format _character_ $quote80.; put (_all_) ($);

I know there are certain restrictions using that approach that could be undesirable in certain situations (e.g. formatted numeric variables with embedded quotes or commas, or formatted character variables), however those problems won't occur with the data that I am working with.

In any case, using a PUT statement alone (of any form) doesn't address my need to get the result that would have been written by the PUT statement into a variable. For that, I need the _FILE_ variable that Richard suggested.

> > Kind regards, > ---------------- > Paul M. Dorfman > Jacksonville, FL > ---------------- > > > > > > > > > > -----Original Message----- > > From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On > > Behalf Of Kevin Myers > > Sent: Sunday, July 04, 2004 5:59 AM > > To: SAS-L@LISTSERV.UGA.EDU > > Subject: Assign Result of PUT Statement to a Variable > > > > In SAS version 8, the ability was added to treat the special > > input buffer variable _INFILE_ as a normal variable in many > > respects. Among other things, that allows the ability to > > parse values from other sources as if DSD input from an > > external file were being used. > > > > I need to do essentially the opposite: I need to create a > > variable whose value is the result that would have been > > produced by using a PUT statement for several variables using > > the DSD option. However, I also have the following > > additional restriction: I must be able to create the desired > > value as a single *expression*, *not* as the result of > > multiple separate data step statements. > > > > For this purpose, I wrote the following macro. It does > > essentially what I need, but writes undesirable messages to > > the log because the unused result arguments (the values that > > don't apply) to the ifc function are evaluated even when they > > aren't used. > > > > I can eliminate most of the messages by setting options > > errors=0, but that still produces one related note and I > > would rather not need to use that option. Also, I like to > > proceed under the rule that well written code should *never* > > produce such potentially worrisome notes in the log. > > > > Can anyone see some way around this predicament? BTW, it > > should be noted that the variables whose values are to be > > included in the resulting expression may be created in the > > current data step. Thus their type, format, etc. cannot be > > obtained by using dictionary.columns or otherwise accessing > > the variable descriptor information from an existing data set. > > > > Thanks, > > s/KAM > > > > P.S. - In the macro below, %loop is simply another macro that > > I often use which loops over a list of values in the first > > argument, substituting each individual value into the code > > that is contained in the second argument via &itemval. %ifc > > is merely a wrapper macro using %sysfunc around the ifc > > function. The real key to this macro (and the source of the > > problems described above) is the regular ifc function and its > > arguments. > > > > %macro DSDOut(columns,delimiter); > > %loop(&columns, > > %nrstr( > > > > trimn(ifc(vtype(&itemval)="N",putn(&itemval,vformat(&itemval)) > > ,quote(trim(pu > > tc(&itemval,vformat(&itemval)))))) > > %ifc(&lastitem,,||"&delimiter"||) > > ) > > ) > > %mend DSDOut; > >


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