CALL SYMPUTX and uninitialized variables

[Quentin]

Thanks @Tom.  I guess I can accept it as an accident of history / laziness. And since it's documented, it's not a bug it's a feature. But I don't have to like it. : )

[yabwon]

Hi Tom,

I think you've got it. Following log seems to confirm your theory (both y and t are uninitialised but SAS says nothing):

51   data _null_;
52   x = -1;
53   y = t;
54   z = 17;
55   call sortn(t, x, y, z);
56   put t= x= y= z=;
57   run;

t=. x=. y=-1 z=17
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              300.84k

I searched SAS help documentation and unfortunately only following was confirmed: 

A CALL routine alters variable values or performs other system functions.

all the best

Bart J.

[hashman]

A short answer is that you don't get an "uninitialized" note because this variable is set to the standard numeric missing value - i.e., initialized - unconditionally at compile time. 

A longer answer is that you get an "uninitialized" note for a variable if both of the following are true:

1. The variable is not initialized by the compiler unconditionally at compile time.

2. The compiler sees no program statement that will initialize the variable at run time, either.

A still longer answer is that the "uninitialized" note is somewhat misleading. To wit, it does not mean that the variable remains uninitialized - there are no uninitialized variables in the PDV when the compiled step starts running. Instead, it is meant, on part of the compiler, to say:

1. This is not one of the variables I initialize at compile time unconditionally (in particular, regardless of #2 below).

2. I see nothing in the program that will assign it a value (missing or not-missing) at run time.

3. I'm setting it to a standard numeric missing value, unless it's defined otherwise (e.g. via LENGTH, ATTR, FORMAT, etc.).

4. Have at it, but here's a log note that because of this action on my part, you may get results you may not expect.   

As to whether or not the compiler, instead of doing #3, should fail to compile, I don't think so. Whether, instead of generating a note in #4, it should produce a warning, I'm inclined to agree, as a warning is more eminent. At any rate, the latter doesn't mean much to me personally since I never leave a program alone till all "uninitialized" notes have been weeded out.  

Paul D.  

[John6]

Thank you all for all the replies. I'm glad to see at least one person agrees with me that this should be issuing a note to the log (if not a warning!)

I see that I need to do some reading up of CALL routines, as this appears to be the reason for the lack of a note. I confess I've never really understood what they are (compared to regular functions) but I daresay a quick Google will sort that out.

I haven't accepted an answer as the answer yet as I don't think I understand the situation well enough to make that call! (Although naturally I'm inclined to the post that agreed SAS should issue a note 😉

[Quentin · Accepted solution]

Since you're new here @John6 (welcome!) just wanted to point out that there is a community for SAS ballot ideas, i.e. proposals for changes to SAS behavior / new functionality.

https://communities.sas.com/t5/SASware-Ballot-Ideas/idb-p/sas_ideas

Since this is documented behavior that CALL routines don't generate the uninitialized note, it's not really a bug.  And SAS isn't likely to change the default behavior to make it a note (or warning).  But SAS has been adding system options over time, that make it possible to turn on more and more notes/warnings/errors to the log.

I could imagine proposing an option like CALLVARINITCHK=NONOTE|NOTE|WARN|ERROR, which would control whether CALL routines throw a log message when a CALL routine initializes a variable (i.e. creates a variable was not defined elsewhere in the DATA step).  Might not have much likelihood of getting implemented, but I'd vote for it. : )

[John6]

Thanks all for the replies, and I'm pleased to see my post sparked a good discussion. Although I've used SAS for 16 years, I realise that I am still scraping the surface in many aspects.

I agree with your conclusion Quentin. About why CALL routines don't generate uninitialized notes. I've also started reading your paper that you linked to and found myself agreeing with it. I already follow some of what you advise. (I don't know if you go on to suggest it as I haven't finished it but I use a piece of code to check my log - especially for these pesky notes that should - arguably - be warnings. Such as missing values were generated, Division by zero detected, or repeats of BY values, to name a few!)

For that reason I've nominated your last reply as the answer although I think anyone who stumbles across this thread should read the whole thing.

And I'm going to add a suggestion to that other community as you suggest. Cheers!