Date: Mon, 22 Nov 2010 11:50:23 -0800
Reply-To: "Nordlund, Dan (DSHS/RDA)" <NordlDJ@DSHS.WA.GOV>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Nordlund, Dan (DSHS/RDA)" <NordlDJ@DSHS.WA.GOV>
Subject: Re: funny code, formatted input or list input or neither
Content-Type: text/plain; charset=utf-8
> -----Original Message-----
> From: bbser2009 [mailto:email@example.com]
> Sent: Monday, November 22, 2010 11:19 AM
> To: Nordlund, Dan (DSHS/RDA); SAS-L@LISTSERV.UGA.EDU
> Subject: RE: [SAS-L] funny code, formatted input or list input or
> Thanks a lot for your reply.
> Regarding the code below.
> You mentioned that
> the input method for name was list input,
> and the blank between Smith and the date value was just a delimiter.
> If this understanding is right, then adding more blanks between Smith
> and the date value should not make any difference, right?
> But if we do so, the new code will give missing value to the variable
> * old code, only one blank after Smith. ;
> data a;
> input name $ date date9.;
> Smith 01JAN2010
> proc print;
> format date date9.;
> Regards, Max
No, adding more blanks will make a difference. Think of input as following a pointer into the line of data. Given the input statement above, SAS starts reading at column 1 and continues until it reads a column containing a blank. Each time it reads a column, it increments the pointer, so after reading the blank, the pointer is pointing at column 7 (which is where your date begins). Next, using formatted input, you tell SAS to read the next 9 columns and interpret it as a date. This works if there is only a single blank, as in the original example.
However, if you add a second blank, then it will still read the next 9 characters beginning at column 7. The characters read would be ' 01JAN201' (which is actually the value that was read in your second example). This is an invalid date value. If you added a third space between the name value and the date value, then the "date" value read would be ' 01JAN20' and SAS would interpret that as a valid date, but it would not be the value you intended (on my computer it was 01JAN1920, because of the date cut-off setting).
Remember, unless you use a specific pointer control, reading of each "variable" begins where it ended up after reading the previous value.
Hope this is helpful,
Daniel J. Nordlund
Washington State Department of Social and Health Services
Planning, Performance, and Accountability
Research and Data Analysis Division
Olympia, WA 98504-5204