Date: Mon, 4 Oct 2010 07:20:17 -0500
Reply-To: "Data _null_;" <iebupdte@GMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Data _null_;" <iebupdte@GMAIL.COM>
Subject: UNBUFFERED
Content-Type: text/plain; charset=ISO-8859-1
I don't believe the question, "Why do you have to use EOF= with
CARDS?" was ever answered.
The answer is CARDS data are UNBUFFERED.
UNBUFFERED
tells SAS not to perform a buffered ("look ahead") read.
Alias: UNBUF
Interaction: When you use UNBUFFERED, SAS never sets the END= variable to 1.
Tip: When you read instream data with a DATALINES statement,
UNBUFFERED is in effect.
You can use PARMCARDS to achieve a type of instream data this is BUFFERED.
94 filename FT15F001 temp;
95 data test;
96 infile FT15F001 end=eof;
97 input;
98 put EOF=;
99 parmcards;
103 ;
NOTE: The infile FT15F001 is:
(system-specific pathname),
(system-specific file attributes)
eof=0
eof=0
eof=1
NOTE: 3 records were read from the infile (system-specific pathname).
The minimum record length was 1.
The maximum record length was 1.
NOTE: The data set WORK.TEST has 3 observations and 0 variables.
NOTE: DATA statement used (Total process time):
real time 0.04 seconds
cpu time 0.04 seconds
104 run;
105
106
107 data test;
108 infile FT15F001 end=eof eof=eof unbuf;
WARNING: The value of the INFILE END= option cannot be set when the
UNBUFFERED option is also specified.
109 input;
110 put EOF=;
111 return;
112 eof:
113 put 'NOTE: EOF';
114 parmcards;
118 ;
NOTE: The infile FT15F001 is:
(system-specific pathname),
(system-specific file attributes)
eof=0
eof=0
eof=0
NOTE: EOF
NOTE: 3 records were read from the infile (system-specific pathname).
The minimum record length was 1.
The maximum record length was 1.
NOTE: The data set WORK.TEST has 4 observations and 0 variables.
NOTE: DATA statement used (Total process time):
real time 0.03 seconds
cpu time 0.03 seconds
119 run;
On Wed, 18 Sep 2002 14:06:52
Ian Whitlock wrote:
>Peetie,
>You are lucky, when I did it years ago, I lost many hours debugging a messy
>DATA step because there was no warning.
Not even an uninitialized var note?
>Remember the options do different
>things - the END= variable is set when the last line is touched,
>the jump to EOF= is made when you attempt to read beyond the last record.
Both were designed to signal an end-of-file condition?
- Hide quoted text -
- Show quoted text -
>The END= requires a user code test, while the EOF= jump is automatic from
>any appropriate INPUT statement.
>Here are two ways to get close to your comfortable "homey" code.
>/* method 1: place macro in autocall lib */
>%macro endfile (eof=eof) ;
> return ;
> &eof:
> retain endfile 0 ;
> endfile = 1 ;
> goto endtest ;
>%mend endfile ;
>/* little massage of your DATA step */
>data _null_;
> infile datalines eof=eof;
> input x;
> sx + x;
> endtest:
> if endfile then put _all_;
> %endfile()
>datalines;
>2
>3
>;
Potentially unneeded complexity, here?
- Hide quoted text -
- Show quoted text -
>/* method 2 */
>filename temp catalog "work.temp.datalines.source" ;
>data _null_ ;
> file temp ;
> input ;
> put _infile_ ;
>cards ;
>2
>3
>;
>data _null_;
> infile temp end=endfile;
> input x;
> sx + x;
> if endfile then put _all_;
>run ;
Potentially unnecessary i/o, here?
Oooops. I fear the "hominess" has evaporated. :-)
Still, it's good code. It's just kludgy ...
>Now ask yourself the big question. Since EOF gives you more flexible
>control and works all the time why shouldn't you standardize on it?
Never mind me. Why hasn't sas-l standardized on it? I rarely
see it here.
>Well in
>your example it cost 4 extra lines of code. Now I would ask, is 4 lines of
>code significant in the amount of code you write in a day?
If there weren't many, many other things to test/do, it
would not be very significant.
If, in the alleged real world, everyone had to code four lines
when one would've done for every piddling thing, perhaps many
(myself included) might have considered an exciting and
challenging career in, say, ditch-digging. Or perhaps politics. :-)
>(In truth one
>has to be a little bit careful when using the default OUTPUT statement, but
>once bitten you learn.)
>In practice I found method 2 works quite well when I wrote the code before
>thinking about how to test it and did not want to switch to EOF=. But now I
>tend to ask whenever I write
> infile something end=...
>Is this what I want to do?
It is a fair and advisable question to ask. There can be
many considerations when structuring a data step.
One such consideration for many is parsimony of code.
Why do a branch (transfer-of-control) when one is
potentially unneeded? Don't we need the flexibility
to be able to choose either? Reading from a file -or-
from in-stream data?
The above begs the central question of my query. Is there
any good reason why "infile datalines end=endfile;"
should be dysfunctional given that SAS can detect the
last record of the in-stream data?
If such good reason exists, I seek enlightenment.
I'm at a loss to discover one myself. If noone comes up
with one, I suppose I'll assume that this is a small
instance of "counter-productive engineering" that made
it through the doc's and is likely to remain unchanged
forever.
Thanx,
Peetie
- Hide quoted text -
- Show quoted text -
>-----Original Message-----
>From: Peetie Wheatstraw [mailto:peetie_wheatst...@LYCOS.COM]
>Sent: Wednesday, September 18, 2002 11:32 AM
>To: SA...@LISTSERV.UGA.EDU
>Subject: infile datalines end=endfile
>Greetings,
>This has bothered me for quite some time ...
>I often need to test/control for end-of-file when
>programming data steps using in-stream data.
>If I code:
>data _null_;
> infile datalines eof=endfile;
> input x;
> sx + x;
> return;
> endfile:
> put _all_;
> return;
>datalines;
>2
>3
>;
>run;
>everything works fine.
>But I more commonly need something like:
>data _null_;
> infile datalines end=endfile;
> input x;
> sx + x;
> if endfile then put _all_;
>datalines;
>2
>3
>;
>run;
>Which yields:
>"WARNING: The value of the INFILE END= option cannot
> be set for CARDS or DATALINES input."
>Clearly (from the first data step) SAS has no problem
>identifying the last record. Why won't "end=enfile"
>in the second data step work?
>Note that it states in the doc that it won't work. It
>can't be considered a 'bug'.
>Is it a design error that got nicely doc'd? Or is there
>another reason why it is disfunctional?
> Thanx,
> Peetie
_____________________________________________________________
Play the Elvis® Scratch & Win for your chance to instantly win $10,000 Cash
- a 2003 Harley Davidson® Sportster® - 1 of 25,000 CD's - and more!
http://r.lycos.com/r/sagel_mail_scratch_tl/http://win.ipromotions.com...
