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 (September 2002, week 1)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:   Thu, 5 Sep 2002 00:28:04 -0400
Reply-To:   "John J Genzano, III" <jgenzano@GENZANO.COM>
Sender:   "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:   "John J Genzano, III" <jgenzano@GENZANO.COM>
Subject:   Re: SAS 2 COBOL
In-Reply-To:   <200209041959.g84JxZw10468@listserv.cc.uga.edu>
Content-Type:   text/plain; charset="us-ascii"

You are talking probably a minimum of 10 to 1 programmer productivity advantage for SAS vs. COBOL. It takes a SERIOUS run-time advantage to make that difference up. And that does not include getting COBOL to do the things people want that SAS does and COBOL doesn't (what effort is required to turn your COBOL output into a WEB page?). Anybody who thinks in this day and age that they are going to be saving money by using people at the expense of machine cycles doesn't belong running a shop.

John J Genzano, III Principal Consultant Genzano Software Consulting 610-517-2591 SAS Certified Professional, V6

"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin 1759

-----Original Message----- From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Charles Harbour Sent: Wednesday, September 04, 2002 4:00 PM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: SAS 2 COBOL

I can think of several hundred thousand of them. The high cost of SAS is forcing both large and small mainframe operations to put SAS only on their smallest footprint in order to save licensing costs. This situation is exacerbated by the fact that observed efficiency is getting worse instead of better in moving from v6 to v8. This situation is perfectly acceptable to the SAS Institute, as they expect an increase of 7% - 10% run time for the exact same code.

The reduced development time of SAS needs to be balanced with the generally longer run time (compared with COBOL or PL/I)--how often does the job need to be maintained vs. how often is it run? Of course, all of this can be offset by the statistical functionality of SAS, but for straight data manipulation, other languages do just as good if not better.

If you can create a macro that will convert SAS code to COBOL code, I think you'll be sitting on a gold mine. I'll be first in line to invest... :-) As a bit of advice, if you have PL/I, the syntax is very similar to SAS-- it's much less of a struggle than COBOL if it's available. Good luck!

CH

On Wed, 4 Sep 2002 14:59:21 -0400, John J Genzano, III <jgenzano@GENZANO.COM> wrote:

>Why would you want to?? > >John J Genzano, III >Principal Consultant >Genzano Software Consulting >610-517-2591 >SAS Certified Professional, V6 > >"Living in the past is a dull and lonely business; looking back strains >the neck muscles, causes you to bump into people not going your way." - >Edna Ferber > > >-----Original Message----- >From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of >Abdu Elnagheeb >Sent: Wednesday, September 04, 2002 2:32 PM >To: SAS-L@LISTSERV.UGA.EDU >Subject: SAS 2 COBOL > > >Hello. >Does anyone, please, know if there is available any MACRO or >shareware/software that can translate SAS code into COBOL. Please, email >me. >Your help is appreciated. > >Thanks, >abdu


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