Richard,

Perhaps the GTE difference between writing to nothing and reading from nothing explains the differences: Pitching stuff in a dumpster is one matter, while picking stuff from one is altogether different. The concept of _NULL_ (as well as great many other SAS things) has of course been borrowed from the venerable

//DUMPSTER DD DUMMY

routinely used as a black hole in testing or providing a black hole sink for written-out data without causing /O or the necessity to remove the JCL reference. Indeed, no mainframer worth his dumb terminal needs an explanation what "dummying it out" means. Likewise, _NULL_ causes no /O, which is why I always use it in performance testing. So, from the GTE standpoint,_NULL_ will always work as a sink and can be specified instead of any output data file:

create table _null_ as... data _null_ ; proc sort out = _null_ ; hh.output (dataset: '_null_') ; output out = _null_ ; ....

However, SAS exhibits a much greater degree of discrimination when _NULL_ is indicated as a read source. And indeed there is a good reason for it: When it is not known what is there, the natural assumption is that the content is [computer] garbage, much like an empty buffer. SAS wisely avoids COBOL's Great "Initial Read" Controversy and Endless Philosophical Debate by sagely deciding to NEVER move anything into the PDV from an empty buffer when an attempt is made to read from it; and it is wise to limit the attempts of reading from _NULL_ to the circumstances where it will definitely render no harm. Your examples are an excellent proof.

Kind regards, ---------------- Paul M. Dorfman Jacksonville, FL ----------------

Richard A. DeVenezia wrote:

> The interesting use of _NULL_ sparked me to think that _NULL_ > was the missing piece for SQL -> macro without a table (as I > think Howard or Sig discussed in a separate thread). Alas no. > > 8972 proc sql noprint; > 8973 select 3*3 into :nine from _null_; *<----- from > _NULL_... not; > ERROR: Table WORK._NULL_ doesn't have any columns. PROC SQL > requires each of its tables to have > at least 1 column. > 8974 quit; > NOTE: The SAS System stopped processing this step because of errors. > NOTE: PROCEDURE SQL used (Total process time): > real time 0.14 seconds > cpu time 0.03 seconds > > WARNING: Apparent symbolic reference NINE not resolved. > > > In Help, _NULL_ is documented at section "When Not Creating a > Data Set" on the DATA Statement page. > I could not find mention of _NULL_ in context of SET, yet we > find it is accepted and behaves sensibly. > An experiment shows a procedure accepting OUT=_NULL_ and does > not create output (as would be expected) > ----- > proc transpose data=sashelp.class out=_NULL_; > var age; > run; > ----- > > Procs will also accept DATA=_NULL_, but many (if not all) > will complain for lack of data. > > More experiments show the OPEN function accepts _NULL_, but > does not like to figure out what it's ATTRN's are, nor does > it want to CLOSE it!. > > 14 %let dsid = %sysfunc (open (_NULL_)); > 15 %let msg1 = %sysfunc (sysmsg()); > 16 %let nvars = %sysfunc (attrn (&dsid,NVARS)); > WARNING: Argument 1 to function ATTRN referenced by the > %SYSFUNC or %QSYSFUNC macro function is > out of range. > NOTE: Mathematical operations could not be performed during > %SYSFUNC function execution. The > result of the operations have been set to a missing value. > 17 %let nobs = %sysfunc (attrn (&dsid,NOBS)); > WARNING: Argument 1 to function ATTRN referenced by the > %SYSFUNC or %QSYSFUNC macro function is > out of range. > NOTE: Mathematical operations could not be performed during > %SYSFUNC function execution. The > result of the operations have been set to a missing value. > 18 %let rc = %sysfunc (close (&dsid)); > 19 %let msg2 = %sysfunc (sysmsg()); > 20 > 21 %put dsid=&dsid nvars=&nvars nobs=&nobs rc=&rc > msg1=&msg1 msg2=&msg2; > dsid=1 nvars=. nobs=. rc=70021 msg1= msg2=ERROR: Invalid memptr. > > -- > Richard A. DeVenezia > http://www.devenezia.com/downloads/sas/samples