Why doesn't the data step stop?

[ChrisNZ]

This generates an error message. Uncommenting input @ ; doesn't. Why?

Why is A in the 4th record always read?

data _null_;
file 'f:\kk.txt';
put '1'/'2'/'3'/'x';
run;
data _null_;
infile 'f:\kk.txt' end=LASTREC;
*input @ ;
if LASTREC then stop;
input @1 A 1.;
run;

[sbb]

For consideration, when you uncomment the first INPUT statement, that causes SAS to load the input data buffer and it will trigger the end=LASTREC before the other INPUT statement, so your IF test will pass and the DATA step will stop prematurely.

And, the NOTE (not really an ERROR) that you receive is because you are attempting to read a character field from the 2nd (last) record as numeric, and it is alphabetic, causing the SAS diagnostic message.

In the future, it is best to share your SAS log, please, not just to say that an error occurs. For assistance with a post, send a reply with the log pasted in your submission (instream). Also, consider adding a PUTLOG _ALL_; command before the RUN; to provide as much diagnostics output as possible -- it also may help you debug the problem, as well.

Scott Barry
SBBWorks, Inc.

[ChrisNZ]

Mmm, never thought about this; I kind of assumed INFILE was executable, like SET, and I was surprised end= behaves differently for SET and for INFILE.

It probably isn't, so the executable statement required to trigger the end=LASTREC is INPUT. It makes sense now, provided the INFILE stmt is not executable.

[Peter_C]

INFILE is executable, but in other ways (when compared with SET).
A data step can have more than one INFILE. The statement provides a pointer to which infile an INPUT statement should read, as well as initialising infile options which persist for the step. One important dynamic option on an infile statement, is the FILEVAR= option. Almost all of the other options on INFILE remain as defined on the first reference to that INFILE.

at least that is teh way I understand it.

PeterC

[sbb]

Depending on the OS platform, other INFILE parameters will take on conditional values based on input handling conditions (especially unique with concatenations), such as:

EOV= END= JFCB=

Some of these gems are documented in the related "companion" guide, by the way.


Scott Barry
SBBWorks, Inc.