Date: Mon, 30 Jul 2001 10:15:34 -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: in need of multiple output files...
Content-Type: text/plain; charset=iso-8859-1
Jonathan,
Right. From the standpoint of NOTSORTED, any key sequence is OK. What I
meant is, for the process to work as expected, they have to be physically
grouped, all equal keys being together, though not necessarily sorted. In
your test case, it would mean that the sequence [b a a a] will work, but [a
b a a] will not, while as far as NOTSORTED is concerned, they are both
"grouped".
Kind regards,
=====================
Paul M. Dorfman
Jacksonville, Fl
=====================
-----Original Message-----
From: Jonathan Siegel [mailto:Jonathan.Siegel@PFIZER.COM]
Sent: Monday, July 30, 2001 9:49 AM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: in need of multiple output files...
Paul,
Good point about there not having to be a BY statement in the dataset.
It just serves as a check on the data's being sorted.
A disadvantage of the MOD option is that if the files are already there, a
second run of the program will continue to append to previous files,
something a user may not want. One could write a prior pass on the data to
identify and erase all existing files.
I just tried the test code code below, and confirmed that if a BY ...
NOTSORTED statement is used, without a MOD option part of the data still
dissappears from output files. In the test, a.txt ended up with 1 record,
not 3, because (1) when the program encountered a 'b' value of B it closed
a.txt and opened b.txt, and (2) when it encountered the second 'a' value it
closed b.txt and reopened a.txt, and (3) without a MOD option, repening
a.txt erased the 2 records that were there before, so only one record
remained.
data x;
input a b $;
filep = 'c:\c_data\'||left(trim(b))||'.txt';
cards;
1 a
2 a
3 b
4 a
;
run;
data _null_;
set x;
by b notsorted;
file dummy filevar=filep;
put a;
run;
Jonathan Siegel
On Fri, 27 Jul 2001 16:24:46 -0400, Dorfman, Paul <Paul.Dorfman@BCBSFL.COM>
wrote:
>Jonathan,
>
>Correct: Without MOD, you do need grouped data. But my point was, the BY
>statement does not make your data either sorted or grouped. It only causes
>first.-last. automatics to be created and triggers the mechanism of
>validating the specified sequence. If the data are physically grouped,
>FILEVAR uses this fact to produce expected output, but the BY statement
make
>no use of it since there are no first.-last. references. The only thing it
>can do here is abend the step if it is grouped (and hence would produce the
>expected output) but not sorted. If you added NOTSORTED, it would be more
>useful in the no-MOD situation, for that would force the step to abend when
>it runs fine but does not produce what is actually needed.
>
>Kind regards,
>=======================
>Paul M. Dorfman
>Jacksonville, Fl
>=======================
>
>-----Original Message-----
>From: Jonathan Siegel [mailto:Jonathan.Siegel@PFIZER.COM]
>Sent: Friday, July 27, 2001 3:57 PM
>To: SAS-L@LISTSERV.UGA.EDU
>Subject: Re: in need of multiple output files...
>
>
>Paul,
>
>The FILEVAR= option is available in V6, and you don't have to sort the data
>if you use the mod option. The code would look like:
>
>data _null_;
> set your_data;
> by center;
> centerfile = trim(left(put(center, 3.)))||'.txt';
> file dummy filevar=centerfile mod;
> put
> ....
> ;
>run;
>
>Without either sorted data or the mod option, only the most recent
>consecutive data will show up in the output file. In the example below,
>a.txt would end up with only one record with the value 4, because opening
>b.txt (at obs 3) closes b.txt, and then opening a.txt again (at obs 4)
>erases everything that was there before.
>
> input a b $;
> filep = 'c:\c_data\'||left(trim(b))||'.txt';
> cards;
>1 a
>2 a
>3 b
>4 a
>;
>run;
>
>data _null_;
> set x;
> file dummy filevar=filep;
> put a;
>run;
>
>Jonathan
>
>On Fri, 27 Jul 2001 15:12:15 -0400, Dorfman, Paul <Paul.Dorfman@BCBSFL.COM>
>wrote:
>
>>Jonathan,
>>
>>I do agree with the technique, but am pretty sure FILEVAR was a useful
>>option back in v6 as well, I do recall that Howard Shreier once greatly
>>impressed me with its innovative use. On a different note, why would you
>>need the BY here? Your code should work fine without it, plus it does not
>>look like the code makes a lot of use of it, anyway...
>>
>>Kind regards,
>>==================
>>Paul M. Dorfman
>>Jacksonville, Fl
>>==================
>>
>>-----Original Message-----
>>From: Jonathan Siegel [mailto:Jonathan.Siegel@PFIZER.COM]
>>Sent: Friday, July 27, 2001 2:38 PM
>>To: SAS-L@LISTSERV.UGA.EDU
>>Subject: Re: in need of multiple output files...
>>
>>
>>If you have V8+, the FILEVAR=<var> option will handle this with no need
for
>>a macro. The option puts data to a file whose name is the value of <var>.
>>You should use it with a BY statement.
>>
>>This code will do it:
>>
>>data _null_;
>> set your_data;
>> by center;
>> centerfile = trim(left(put(center, 3.)))||'.txt';
>> file dummy filevar=centerfile;
>> put
>> ....
>> ;
>>run;
>>
>>HTH,
>>
>>Jonathan Siegel
>>Pfizer Clinical Research and Development
>>Ann Arbor Laboratories
>>Jonathan.Siegel@pfizer.com
>>734.622.3982
>>
>>
>>
>>
>>On Thu, 26 Jul 2001 15:58:51 -0400, Jim Agnew <Agnew@HSC.VCU.EDU> wrote:
>>
>>>i have a budding program that will need to find out the center number,
>>>then dump a report of patients into
>>>different files, depending on center number. so the put statements
>>>will need to write a series of files such as:
>>>
>>>110.txt for center # 110
>>>
>>>200.txt for center # 200
>>>
>>>and with appropiate formatting, etc...
>>>
>>>now, i'd love to have pointers for doing the multiple opens.. if it can
>>>be done in one data step, great, otherwise i'll just code a macro and
>>>hand-feed it all possible centers...???
>>>
>>>Jim
>>
>>
>>
>>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.
>
>
>
>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.
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.
| 
