Date: Mon, 23 Aug 1999 14:27:49 -0600
Reply-To: Jack Hamilton <JackHamilton@FIRSTHEALTH.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Jack Hamilton <JackHamilton@FIRSTHEALTH.COM>
Subject: Re: DATA _NULL_
Content-Type: text/plain; charset=us-ascii
Don't forget PROC COMPUTAB, also a powerful reporting proc, which has unfortunately been relegated to obscurity because it's part of SAS/STAT, not the base product.
--
JackHamilton@FirstHealth.com
Development Manager, Technical Group
METRICS Department, First Health
West Sacramento, California USA
>>> "William W. Viergever" <wwvierg@IBM.NET> 08/23/1999 1:08 pm >>>
Ditto here (although I went apl - fortran - cobol - ets - then sas).
One thing the youngsters may forget is that Proc Report is a relatively recent proc - at least to those of us who survived disco <g>. In fact, I just recently started playing with it and had to hit up Meister Pass for guidance.
Before that, all we had was Print, then Tabulate and you can scan all the archives for the many Tab-related posts on how to kill the lines and/or export data into some other app for formatting.
I always thought of the "Data _null_"s as sort of a SAS version of a COBOL pgm, very intricate and time consuming,where you have control of *everything*, especially for multi-panel reports, but when you're done and don't have to do anything but look at the output, it seems like a slick and efficient piece of code.
I've done EIS-type reports where the underlying data set would cause an-SQL type to cringe/die at the non-normal structure that fed the _null_ (e.g., tagging group means onto individ records, etc.).
The other beauty of PUTs and Data _Null_'s is in using SAS for processing external data, i.e., data for other apps. I find often thtat its easier (for me) to screw around in SAS and get the data as far along as possible before I send it over to the other app (e.g., mixing data with formulas to be "put", via DDE, into Excel).
Later
At 03:19 PM 8/23/1999 -0400, RHODESD1 wrote:
>John Whittington wrote, in part, in response :
>>>Should I call these 'DATA _NULL_ reports' even though I used
>>>an output data set?
>
>>That's a semantic question, the answer to which is really up to you. Most
>>people would probably call that 'DATA step reporting', I guess.
>
>As a programmer who cut my teeth on SAS and then COBOL, I have come to use the
>term "A Data _Null_" report to mean: a highly customized report that cannot
>easily be produced using an available proc. My philosophy has always been to
>use
>a proc when it will produce what you need. Presumably, SAS has spent more
>time
>testing its proc than you want to spend testing your code. Most reports can be
>generating using PROC Tabulate or PROC Report (or even PROC Print) instead of
>monkeying around in a data step, _NULL_ or otherwise, with PUTS. (But then
>again, you may note the author has held onto her COBOL report layout sheets
>complete with print control column).
>
>Dianne Rhodes
>Westat
>rhodesd1@westat.com
----------------------------------------------------------------------------
William W. Viergever Voice : (916) 483-8398
Viergever & Associates Fax : (916) 486-1488
A SAS Institute Quality Partner (USA) E-mail : wwvierg@ibm.net
Sacramento, CA 95825
"Age is a question of mind over matter. If you don't mind, it don't matter."
- Satchel Paige -
"Reality is merely an illusion, albeit a very persistent one."
- Albert Einstein -
----------------------------------------------------------------------------
