LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (December 2008, week 5)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
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
Comments: To:
Content-Type: text/plain; charset=us-ascii

i was gonna say 10 years of hash would get you twenty in Pelican


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: > > > >Has it been 10 years already, really? Hard to believe... > >Merry Christmas, Everyone... > >Kind regards >---------------- >Paul M. Dorfman >Jacksonville, FL >----------------

Back to: Top of message | Previous page | Main SAS-L page