I thought that two below codes should work the same. However the second data step generates 0.175 and 0.1101 for the Grade variable while I assumed it had to generate 17.50 and 11.01 as the first data step does. Any idea why?
input StudentName $
George Math 19Dec05 1750 P
Susan Geography 01Feb05 1101 F
infile datalines dlm='.';
input StudentName $
The results for the first data step:
George Math 16789 17.5 P
Susan Geograph 16468 11.01 F
The results for the second data step:
George Math 16789 0.175 P
Susan Geograph 16468 0.1101 F
This is yet another anomaly with the "date" related INFORMAT handling. The fact that there is mixed INPUT processing is a contributing factor. My recommendation is to open a SAS support track, to let SAS Institute know that this unexpected input handling occurs when there is a date input field, and where the delimiter DOES NOT occur in the input record.
For illustration purposes, the two different input record types are processed, one containing a date field within the record and a second type without a date. SAS seems to handle the record not containing the date with no problem. See the code below:
infile datalines dlm='\';
format numdtvar1 date9.;
input type $ @;
if type ne ' ' then do;
if type = '1' then input charvar1 $ numdtvar1 anydtdte. numvar1 4.2 charvar2 $;
if type = '2' then input charvar1 $ numvar1 4.2 charvar2 $;
Like I suggested, open a support track and stand your ground. Good luck.
This will read the variable content up to the next delimeter and then move the pointer to the next position after the delimeter. For some reason in your code SAS appears to be reading the '.' delimeter that separates values as part of the grade value.
In any event the following code works to read in the grade correctly. Be aware that you need to set your informats wide enough to accomodate the largest possible input to be read.
In this statement [pre] input StudentName :$8.
Result :$; [/pre] remove the explicit/implied decimal 2 from the grade informat. Then it would be like[pre] Grade :5. [/pre]
Much safer I feel,is to predefine stored variable lengths (and then informats) before the INPUT statement, which won't then need informats defined at all.