about INFILE option END=

[Peter_C]

as documented for the INFINE option END=

END=variable

specifies a variable that SAS sets to 1 when the current input data record is the last in the input file. Until SAS processes the last data record, the END= variable is set to 0. Like automatic variables, this variable is not written to the data set.

Restriction:

You cannot use the END= option with  the UNBUFFERED option the DATALINES or DATALINES4 statement

Can you explain why this "Restriction" applies to DATALINES? (or it's earlier form CARDS)

(sure the on-line doc offers a work-around using another option, but I'm intrigued why this Restriction applies.)

peterC

[data_null__ · Accepted solution]

I always thought it was because CARDS are UNBUFFERED.  If you want in-stream buffered data lines use PARMCARDS;

filename FT15F001 temp;
data test;
   infile FT15F001 end=eof;
   input;
   list;
   put eof=;
   parmcards;
hello peter.
hello kitty
;;;;
   run;

[Peter_C]

thank you data_null_;

as you demonstrate, PARMCARDS would work!

I guess in the days of the ? interface, code (and card datalines) were processed line by line and the line I would want to flag in the END= var is the line before the semi-colon - so it is unrecognised until too late!

Seems like a long time since anyone used that ? interface Do you think it is still available? If it is no longer available why preserve the analogy?

Alternatively the END=var could be flagged once that ; is recognised. Would that be a valid approach?

peter

[Ksharp]

Null' s code can work, because he used Filename statement.

if you keep cards into a file.

Filename x 'c:\test.txt'.   end= option also can work.

For this case, why not use eof= option to detect the end of cards.

Ksharp

[Peter_C]

thank you ksharp

eof=label is the alternative option I referred to in my original question.

In the example above from data_null_; the PARMCARDS seem no more "buffered" than DATALINES, but if that is all it needs to obtain the effect of END= on the INFILE statement for "instream" data then I shall be adopting that route.

(FT15F001 must be assigned for PARMCARDS to be written, but although there is reference to FT15F001 in the config file, that is not enough:smileyconfused: so I expect to add something to the autoexec to eliminate the need for any further FT15F001 filename statements).

I was reminded of the Restriction when testing demo code in the posting from SASJedi at 18-Oct-2011 19:16 (in response to FriedEgg)
"Re: Reading tab-delimited data using a macro"  http://communities.sas.com/thread/31512

        if last then do;

...

           call symputx('mlen_this',mlen_this);

           call symputx('mlen_that',mlen_that);

    end;

the call symputx() are never executed

Although the code is easily adapted to use the eof= option.

it seemed appropriate to

          Question that Restriction

probably pointless question, because it will probably never change

supplemental question

Would it add value to have either a NOTE: or WARNING: for the setting of an option that cannot take effect (such as this one)?

Would it add enough value to justify a suggestion for the SASware ballot?

peter

[data_null__]

Peter.C wrote:
 supplemental question
Would it add value to have either a NOTE: or WARNING: for the setting of an option that cannot take effect (such as this one)?
Would it add enough value to justify a suggestion for the SASware ballot?
peter

Do you mean this warning?

1    data _null_;
2       infile cards end=eof;
WARNING: The value of the INFILE END= option cannot be set for CARDS or DATALINES input.
3       input;
4       list;
5       cards;

[Ksharp]

Yes. SASJedi should use filename statement.

supplemental question

Would it add value to have either a NOTE: or WARNING: for the setting of an option that cannot take effect (such as this one)?

Would it add enough value to justify a suggestion for the SASware ballot?

peter

I am not sure. Maybe you can check some system option to suppress these message. Just like keep drop statement.

Ksharp

[data_null__]

Peter.C wrote:
Seems like a long time since anyone used that ? interface Do you think it is still available? If it is no longer available why preserve the analogy? 

UNIX SAS 9.2 started with -NODMS.

  1? data _null_;
   infile cards end=eof;
   input;
   list;
   put eof=;
   cards;
hello kitty
;;;
  2? run;
WARNING: The value of the INFILE END= option cannot be set for CARDS or 
         DATALINES input.
  7> 
eof=0
RULE:      ----+----1----+----2----+----3----+----4----+----5----+----6----+--
7          hello kitty
  8> 
NOTE: DATA statement used (Total process time):
      real time           0.09 seconds
      cpu time            0.02 seconds
      
  9? 

[Peter_C]

does the parmcards example work just as well?

[data_null__]

---

@Peter_C wrote:

does the parmcards example work just as well?

---

My response from 2011 is not correct.  You can place PARMCARDS in the same location as  CARDS statement and read from it.  I don't know why I thought that.

Previous response from 2011.
Not exactly the same.  You have to submit PARMCARDS first. While not so intuitive is probably how it should be done anyway.

• create a file
• read a file

filename FT15F001 clear;

filename FT15F001 temp;

   parmcards;

hello peter.

hello kitty

;;;;

data test;

   infile FT15F001 end=eof;

   input;

   list;

   put eof=;

   run;

[Peter_C]

Not exactly the same. You have to submit PARMCARDS first. While not so intuative is probably how it should be done anyway.
create a file 
read a file

thought it might be like that

So - I think that (almost always, being able to place parmcards where datalines would go) demonstrates that,

other than in "line interactive" mode, code is buffered as it is submitted to SAS even when it includes "instream data" i.e. CARDS, PARMCARDS and DATALINES .

Well, until the logic of that  changes the treatment of "instream data" to "buffered", I'll try to respect that WARNING and use EOF= rather than END= when testing the end of an INFILE.

At least EOF= allows code to remain otherwise unaltered when development testing (with instream data) progresses to working with "real data" that is not "instream".

code like

     infile cards truncover END= last;
...
   if last then call symputx('mlen_that',mlen_that);
cards;

will become something like

   infile cards truncover EOF= eof_label ;
...
return;
 eof_label:
   call symputx('mlen_that',mlen_that);
cards;

I might just stop using END= on INFILE statements, completely:smileyshocked:

peter