Date: Tue, 30 Dec 2008 19:16:09 -0500
Reply-To: Arthur Tabachneck <art297@NETSCAPE.NET>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Arthur Tabachneck <art297@NETSCAPE.NET>
Subject: Re: 10 years of hash in SAS
Bill,
Not to take away from the benefits of hash, I never did see Paul's
original message or, more importantly (for me), his closing comment:
Suum cuique
Talk about parsimony: http://xrl.us/bea4bj
A savings of 4 whole characters minus how much time it took for others to
figure out what Paul was saying.
Is there a shorter way of wishing everyone on the list the best of new
years then "I do so wish"?
Art
-------
On Tue, 30 Dec 2008 15:35:17 -0800, William W. Viergever
<william@VIERGEVER.NET> wrote:
>i was gonna say 10 years of hash would get you twenty in Pelican
>
>but
>
>be that as it may be
>
>according to my dedicated "folder", the
>single-malt-drinking/mad-pianist/hash-man/ukranian started posting
>over a year earlier
>
>we often wondered who this "dude" working for AT&T credit cards was
>
>all this DB2 and/or MVS and/or COBOL talk definitely had piqued our
>collective interest ...
>
>to wit
>
>here's his little reply, on the night-before-the-night-befoe christmas
>'97
>
>to a fellow, old-school, SAS code-dog (doggette?):
>
>
>
>>Date: Tue, 23 Dec 1997 14:42:07 -0500
>>Reply-To: "Paul M. Dorfman" <pdorfma@PD.YRAC.COM>
>>Sender: "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
>>From: "Paul M. Dorfman" <pdorfma@PD.YRAC.COM>
>>Organization: AT&T UCS
>>Subject: Re: COBOL vs SAS
>>To: SAS-L@UGA.CC.UGA.EDU
>>
>>Dianne Rhodes, in particular, wrote:
>>
>>> Paul,
>>>
>>> I am responding to your question posted to SAS-L. I am both a COBOL
and
>>> SAS professional. If you are going to be managing "a project that is
going
>>> to be heavy on i/o, sophisticated data manipulation and complex
reporting
>>> (involving, for instance, multilevel control breaks) and, to some
degree,
>>> data warehousing"
>>> in a time sharing, charge back environment, you should be alerted to
the
>>> fact that COBOL will out perform SAS by a factor of 517 percent. I
have
>>> done some benchmarks of the exact same code processing exactly the same
>>> data. That is to say that a simple report job that costs $3.00 to run
in
>>> COBOL will cost you $15.51 in SAS.
>>
>>If you were talking about filtering data, I would tend to agree that a
>>well
>>written COBOL program will outperform a poorly written SAS program, but
>>even
>>in this kind of processing (which is better off left to SYNCSORT anyway)
>>the
>>difference is not as staggering as you stated, if any. That's number
>>one.
>>Number two: you are actually talking about report writing where writing
>>SAS
>>code exactly same way as COBOL code is exactly the last thing one should
>>try to do. For instance, if DATA step were used every time when PROC
>>MEANS,
>>PROC FREQ or PROC TABULATE where warranted (and I've come across folks
>>who
>>maintained this is the way to go!), then you may end up with figures you
>>indicated, even though I've never seen a factor like that. I used to
>>work
>>in a shop where SAS was not allowed in production, test only, and I was
>>asked
>>to help fix a COBOL program (60,000+ lines) to produce a hierarchical
>>report
>>with 8 categorical variables. The manager was frantic since the report
>>was due
>>'before yesterday' and figures were obviously wrong. In around 15
>>minutes, by
>>combining a couple of DATA steps, proc SUMMARY and proc PRINT, I
>>concocted a
>>printed report with correct numbers with which the COBOL report was
>>eventually
>>fixed. It ran TWO TIMES slower than the SAS program. The report took an
>>expert
>>COBOL programmer three weeks to come up with. Number three: doesn't
>>development
>>time cost anything? In the story above, assuming the shop's salary
>>expense of,
>>say, $60/h, pure loss would be $7,200 which would account for two years
>>of
>>cpu cost difference if COBOL ran 5 times faster. But it was 2 times
>>slower.
>>Besides, the COBOL report was late (which defies its purpose) and not
>>even done.
>>
>>> I would also expect that EASYTRIEV would be a better candidate than
SAS for
>>> report writing and data extraction.
>>
>>Agreed that for data reduction, EASYTRIEVE is faster than SAS, but
>>SYNCSORT
>>runs faster than both. As to report writing, EASYTRIEVE enjoyed some
>>advantage
>>before the advent of PROC REPORT. Now, SAS has become a lot more
>>flexible
>>and powerful.
>>
>>> Although many SAS aficionados will argue that maintenance of COBOL is
more
>>> expensive than maintenance of SAS, I would dispute that. My own
experience
>>> is quite the contrary. There are only so many ways to write COBOL
code.
>>> SAS can be written in as many ways as there are SAS programmers.
>>
>>Are you trying to convince the man that maintaining 20 lines of, say,
>>SAS
>>code in the example above is more expensive than maintaining 60,000
>>lines
>>of COBOL? What do you mean by maintenance, then? Change control? What if
>>a customer - marketing, credit policy, whatever - would like to merely
>>alter
>>the order of categorical variables? It would take a SAS guy 5 minutes or
>>30 minutes to rewrite the whole thing? It takes no time at all to change
>>CENTER to NOCENTER. Do you realize what it means to do something like
>>that
>>in COBOL?
>>
>>> My advise to you would be to mirror what we have done in our shop. The
>>> daily production system that is most I/O intensive handles the incoming
>>> data, processes the complicated edit checks for data validity and
>>> integrity, and does routine reporting is all done in COBOL. Our
production
>>> data bases maintain about 12 million records of health insurance
medical
>>> bills, compensation payments, and master case management records.
>>>
>>> We use SAS when we want to match files and create claim level
information.
>>> We use SAS for complex reporting, as well as univariate statistics
(means
>>> and medians). For our policy researchers doing regression analysis,
we use
>>> SAS. We are using SAS to build a data warehouse, a snap shot of our
>>> production database for each fiscal year. Eventually, I hope to build
a
>>> GUI front end with Delphi or SAS EIS to let the policy wonks at the
data
>>> themselves. This will either be on a terabyte server, or using SAS
Connect
>>> with the mainframe acting as the server.
>>
>>Why would you do 'complex reporting' in SAS if COBOL outperforms SAS 5
>>to 1
>>and EASYTRIEVE is better than SAS for reporting, anyway? I think because
>>it
>>was understood that it would be ludicrous to even attempt to reproduce
>>mere
>>10 lines of PROC TABULATE in either COBOL or EZT. It would mean exactly
>>what
>>you claimed above SAS is about: wasting development, maintenance and CPU
>>resources.
>>
>>As far as data warehousing is concerned, I'd advise Paul (Darlington)
>>(and already did in the COBOL news group) to take a closer look at SI
>>data warehousing products. Maybe, it is all he needs...
>>
>>> Please don't let anyone try to convince you that COBOL is a dead
language
>>> or that you can't find good COBOL programmers. Good technical folks
are
>>> just plain hard to come by right now, regardless of their skill set. I
>>> personally haven't written a line of COBOL code in 4 years, but I look
at
>>> COBOL record layouts every day.
>>
>>Of course, there are a lot of decent COBOL programmers (I even have the
>>audacity to think I'm one of them!), and sure COBOL will not die before
>>we do. Please don't let anyone try to convince you that it is because
>>COBOL is somehow better or more functional than other languages in
>>existence.
>>With the exception of not being able to handle embedded SQL, SAS is
>>infinitely more flexible, easier to write, faster to develop and better
>>to
>>support.
>>
>>Suum cuique.
>>
>>Regards, PMD.
>>
>>---------------------------------
>>Paul M. Dorfman
>>AT&T UCS Decision Support Systems
>>Jacksonville , Fl
>>---------------------------------
>On Thu, 25 Dec 2008 01:09:54 -0500, sashole@BELLSOUTH.NET (Paul
>Dorfman) wrote:
>
>>It has just dawned on me that on 1998-12-15, this raw hash concoction was
>>posted to SAS-L:
>>
>>http://www.listserv.uga.edu/cgi-bin/wa?A2=ind9812C&L=sas-l&P=R985
>>
>>Has it been 10 years already, really? Hard to believe...
>>
>>Merry Christmas, Everyone...
>>
>>Kind regards
>>----------------
>>Paul M. Dorfman
>>Jacksonville, FL
| 
