Date: Tue, 30 Dec 2008 15:35:17 -0800
Reply-To: "William W. Viergever" <william@VIERGEVER.NET>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "William W. Viergever" <william@VIERGEVER.NET>
Subject: Re: 10 years of hash in SAS
Content-Type: text/plain; charset=us-ascii
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
>----------------
| 
