topic Re: Same principle but different outcomes?! in SAS Programming

Same principle but different outcomes?!

expertyejin — Tue, 17 Sep 2019 22:53:07 GMT

Hi all:

I am exploring some basic SAS statements. Here is my first code:

data _null_;
input a (b c) ($);
put a= b= c=;
datalines;
1 A B
2 C D
;
run;

When I run this I get exactly the result as I expected, and I thought using the same principle I can be a bit more creative. So I tried this:

data _null_;
input a (b c) (date9.);
put a= b= ddmmyy10. c= mmddyy10.;
datalines;
1 13jan1988 21may2000
2 30aug1994 05dec1999
;
run;

To my surprise this time the code isn't working quite. In fact here is the log:

1          OPTIONS NONOTES NOSTIMER NOSOURCE NOSYNTAXCHECK;
 70         
 71         data _null_;
 72         input a (b c) (date9.);
 73         put a= b= ddmmyy10. c= mmddyy10.;
 74         datalines;
 
 NOTE: Invalid data for c in line 75 12-20.
 a=1 b=13/01/1988 c=.
 RULE:      ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0                     
 75         1 13jan1988 21may2000
 a=1 b=10239 c=. _ERROR_=1 _N_=1
 NOTE: Invalid data for c in line 76 12-20.
 a=2 b=30/08/1994 c=.
 76         2 30aug1994 05dec1999
 a=2 b=12660 c=. _ERROR_=1 _N_=2
 NOTE: DATA statement used (Total process time):
       real time           0.00 seconds
       user cpu time       0.00 seconds
       system cpu time     0.00 seconds
       memory              465.56k
       OS Memory           27044.00k
       Timestamp           09/17/2019 10:42:41 PM
       Step Count                        84  Switch Count  0
       Page Faults                       0
       Page Reclaims                     84
       Page Swaps                        0
       Voluntary Context Switches        0
       Involuntary Context Switches      0
       Block Input Operations            0
       Block Output Operations           0
       
 
 77         ;
 78         run;
 79         
 80         
 81         OPTIONS NONOTES NOSTIMER NOSOURCE NOSYNTAXCHECK;
 92

Can anyone tell me why the former is working but not the latter?

Thanks

Re: Same principle but different outcomes?!

data_null__ — Wed, 18 Sep 2019 14:48:58 GMT

You need the : format modifier to use LIST input with explicit in-format.

1    data _null_;
2       input a (b c) (:date9.);
3       put a= (b c) (=ddmmyy10.);
4       datalines;

a=1 b=13/01/1988 c=21/05/2000
a=2 b=30/08/1994 c=05/12/1999

Re: Same principle but different outcomes?!

expertyejin — Tue, 17 Sep 2019 23:48:42 GMT

Wow, great! Thank you so much! I guess I seriously need to improve my SAS skills.

Re: Same principle but different outcomes?! 21may200

ChrisNZ — Wed, 18 Sep 2019 01:43:32 GMT

Read the log:

 NOTE: Invalid data for c in line 75 12-20.
 RULE:      ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0                     
 75         1 13jan1988 21may2000

The pointer is moved by 9 positions to read the first date because of the informat's length, and then reads the next 9 for the second date.

The 9 characters at positions 12-20 are : ' 21may200' .

That's not a valid date9 string.

It's all in the log!

Re: Same principle but different outcomes?!

ballardw — Wed, 18 Sep 2019 14:56:17 GMT

Try running this:

data _null_;
input a (b c) (date9.);
put a= b= ddmmyy10. c= mmddyy10.;
datalines;
1 13jan198821may2000
2 30aug199405dec1999
;
run;

Without the : modifier when using formats on the input statement the next variable starts in the column immediately after the end of the previous variable. Formatted input as you attempted in more appropriate for fixed-column data than for delimited data.

Re: Same principle but different outcomes?!

expertyejin — Sat, 21 Sep 2019 14:44:56 GMT

Thank you all for your help! I guess I run into this problem because just like character variables, numeric variables may also get truncated when they exceed 8 digits and that's the reason SAS requires a colon modifier, right?

Re: Same principle but different outcomes?!

ChrisNZ — Mon, 23 Sep 2019 04:27:50 GMT

> numeric variables may also get truncated when they exceed 8 digits and that's the reason SAS requires a colon modifier, right?

No.

Read the explanations above again.

And read about the colon modifier.