COBOL vs SAS
Paul Darlington
Dear All,
Does anyone have a qualified opinion on how SAS fares
in comparison with COBOL as a general programming
language? As a set of tools to perform certain tasks?
As a manager, I have to decide which language to use for
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. SAS is (and will be) licensed by the site,
so it's not a point of concern. All the work will have to be
done on mainframe, OS390.
Apart from seeing a few SAS-generated reports I haven't
had any significant exposure to the software, so I would
appreciate any ideas you may have.
Regards, P.D.
The Goobers
Paul Darlington wrote:
>
> Dear All,
>
> Does anyone have a qualified opinion on how SAS fares
> in comparison with COBOL as a general programming
> language?
Yes, I am sure that someone does.
> As a set of tools to perform certain tasks?
Likewise as above... if you are requesting a professional evaluation of
your needs versus the capabilities of SAS, the capabilities of COBOL and
the ease of generating/maintaining systems written in either then you
are requesting what are commonly called 'Professional Services'... and
*those* cost *money*.
Ya get what ya pays for, yup!
>
> As a manager, I have to decide which language to use for
> 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.
As a manager, then, you realise that your performance is gauged and
reqarded, in part, by the success of your projects. As a manager you
realise that the information you request requires a kind of academic and
technical which is not to be found in you or any of the personnel for
whose allocation, co-ordination and motivation for whom you are
responsible. As a manager, then, you have concluded that you will find
here, on the UseNet, free, anonymous knowledge which will make all of
you look good and get raises.
Bona Fortuna!
DD
Gary Lee
Paul Darlington <pdarl...@pd.yrac.com> wrote in article
<3498685E...@pd.yrac.com>...
> Dear All,
>
> Does anyone have a qualified opinion on how SAS fares
> in comparison with COBOL as a general programming
No doubt many people do, some more than me. Asking that question up front
is almost guaranteed to get anyone who replies to you flamed by someone who
disagrees as to what that means.
>
> As a manager, I have to decide which language to use for
> 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. SAS is (and will be) licensed by the site,
> so it's not a point of concern. All the work will have to be
> done on mainframe, OS390.
>
While not disagreeing with the gist of Goobers' earlier response, I offer
my *opinion* for the edification of the general reader (and because the
thread which might develop will be of interest to me, personally; and
because it fits with the group topic; and...)
You would need to provide a *whole* lot more information for anyone to give
an informed answer to that question. In general, SAS gets what I think is
an unfair rap for two things, difficulty to learn the coding language, and
efficiency.
The basic data manipulation language is actually easier to use, in many
cases, than COBOL, because it makes a bunch of decisions (like internal
storage formats) for you. However, if you don't have any SAS programmers
in house that may be totally useless to you while you wait for training.
Additional down sides are that you probably have no base of SAS code to
cannibalize, SAS programmers have in the past been harder to find (and more
expensive) than COBOL programmers (that may not be true right now, of
course), and if you need *very* specific formatting, it can be more
difficult to do in a 4GL like SAS than in something like COBOL report
writer. SAS does not suffer from the 'you must do it the way the designer
intended' syndrome as much as some 4GL's, but if you want to get the most
out of it's coding simplicity, you have to be willing to let the output
look 'SAS Style'. It's not bad, but some users (as you probably know) are
real jerks about trivial cosmetic differences.
Secondly, I have actually benchmarked, myself, personally, on a real IBM
mainframe, under MVS, programs written in SAS and COBOL to do the same
reporting. On simple hierarchical reports there was very little difference
in the overall wall-clock time. In several cases SAS had to do more I/O to
disk, because the version we were using (Version 5) had to do more things
in it's own proprietary file formats, but other formatting efficiencies
seemed to make up for that. On only slightly more complicated reporting
(say a multi-dimensional table with with a few statistical calculations in
columns, and an unknown number of variable crossings) I found that SAS
executed considerably faster than what we wrote in COBOL (and no, we
weren't beginners). More importantly for getting a project up and running,
we had specific examples where the equivalent routines might be literally
10 lines in SAS, and 50,000 lines in COBOL. This can have a significant
impact both on delivery dates, and maintenance <G>.
Bottom line is that the most significant part of your question is
'sophisticated data manipulation and complex reporting (involving, for
instance, multilevel control breaks)' . Personally I don't think of
multilevel control breaks as sophisticated or complex, and either is easy
in COBOL or SAS. But if you have pieces which need to do more statistical
things, like multi-variate clustering, or chi-square, or goodness of fit,
or a whole bunch of things I don't remember the statistics to understand,
but for which SAS has pre-canned routines (called 'PROCS' in SAS lingo),
then SAS is probably the better choice for those parts (you can mix COBOL
and SAS for different parts, of course).
> Apart from seeing a few SAS-generated reports I haven't
> had any significant exposure to the software, so I would
> appreciate any ideas you may have.
If all you have seen are a few reports, then you are wise to ask the
question, because you don't yet know what SAS is designed to do. Find
yourself a 'SAS Statistics' manual, which covers the basics of the
complicated part, browse through it quickly, and you will get a much better
idea of what SAS was originally designed to help you do.
>
> Regards, P.D.
>
Gary Lee
In this case flames accepted at gl...@millcomm.com (but don't make it a
habit!)
------------------------------------------------
"There's a big difference between mostly dead and all dead. Please, open
his mouth."
Miracle Max in "The Princess Bride"
Mike Rochford
The Goobers wrote a pile of nothing asking for money for advise:
All the man was doing was asking for a little advice, If you don't have
any, or don't know the answer then don't reply.
What do you believe this newsgroup is for ?????
If I knew what SAS was capable of I would gladly have given some help.
mike
The Goobers
Mike Rochford wrote:
>
> The Goobers wrote a pile of nothing asking for money for advise:
>
> All the man was doing was asking for a little advice,
Well, then he got double what he paid for it, neh?
> If you don't have
> any, or don't know the answer then don't reply.
Obviously we see the matter differently.
>
> What do you believe this newsgroup is for ?????
The free interchange of information, ideas and trivia... then again,
nobody guarantees you will find the information, ideas and trivia you
seek.
>
> If I knew what SAS was capable of I would gladly have given some help.
You and I are obviously different people. If someone shows some effort
or thought I am willing to help; if someone shows up only with the
format of 'Will someone out there do my homework for me?' I consider it
to be a target ripe for abuse and will perform the UseNet equivalent of
the T'ai Ch'i form known as 'Repulsing the Vile Brain-Leech'. The
posting in question asked for technical and academic advice which some
of us use to make our livings; if someone asks me to do what I do in
order to make a living for free I tend to get a wee bit... surly.
DD
Jim Burgardt
On Thu, 18 Dec 1997 06:09:51 -0500, The Goobers
<docd...@erols.com> wrote:
"... if someone asks me to do what I do in order to make a
living for free I tend to get a wee bit... surly."
You certainly do, and in such a manner that it may turn him off
using consultants altogether, which is NOT what we want to have
happen. What great PR!
My understanding of his message was that he was asking for a few
general opinions or to be pointed in the right direction, and
was not trying to elicit detailed expert advice or rob you of
your livelihood.
Can't we at least be a little freindlier and cordial toward our
fellow man (and woman), especially at Christmas time? Or you
the original "Bah, humbug" type of guy?
JB
docd...@clark.net
In article <34996b06...@news.value.net>,
Jim Burgardt <in...@philos.com> wrote:
>On Thu, 18 Dec 1997 06:09:51 -0500, The Goobers
><docd...@erols.com> wrote:
>
>"... if someone asks me to do what I do in order to make a
>living for free I tend to get a wee bit... surly."
>
>You certainly do, and in such a manner that it may turn him off
>using consultants altogether, which is NOT what we want to have
>happen. What great PR!
It may... and it may not, many things 'may' happen. As for PR, you got
that right... I crank code and leave the gladhanding to others.
>
>My understanding of his message was that he was asking for a few
>general opinions or to be pointed in the right direction, and
>was not trying to elicit detailed expert advice or rob you of
>your livelihood.
And, obviously, my understanding was otherwise... such is Life, difference
of opinions is what makes for horse-races. I found it to be one of those
horrid 'Say, just for curiousity's sake...' questions, where 'curiousity'
always seems to center around computer-related issues. I've never had
anyone say to me 'You've studied non-Euclidean geometry... just for
curiousity's sake, what happens to Euclid when one ignores the Fifth
Postulate?'... it is always like 'Say, you're a programmer... just for
curiousity's sake, how would *you* go about upgrading from COBOL to
COBOLII?'
(side note: anytime I am asked 'how would *you* (in essence do my job for
me)' I always smile and say 'Oh, I would wait until I am in a position of
appropriate responsibility, authority and remuneration before beginning.'
... and that usually Repulses the Brain-Leech. The more insistent dolts
smile and say 'Well, let's assume that that is a given', getting the
response of 'Well, then, if we're assuming let's Assume Big... let's
assume my solution is a given as well.')
>
>Can't we at least be a little freindlier and cordial toward our
>fellow man (and woman), especially at Christmas time? Or you
>the original "Bah, humbug" type of guy?
Hey, that *was* friendly... I didn't mention habits of hygiene or
grooming, I didn't make any references to consanguinous parentage, I
didn't even indulge in Strong Epithets, like 'poopie-head'... just said,
albeit with a bit of 'surl', that if he wants me to do my work for him
then I want a check or two of his to clear the bank first.
DD
Bill Turner, WB4ALM
Paul Darlington wrote:
> Dear All,
>
> Does anyone have a qualified opinion on how SAS fares
> in comparison with COBOL as a general programming
> language? As a set of tools to perform certain tasks?
>
In my opinion, SAS is a great tool to do data reduction with.
Cobol is a great reporting tool.
The majority of SAS programs that I have seen deal either with
numerical analysis or with processing IBM SMF data.
It has been my observation that you sometimes have to think upside
down to do some "simple" function in SAS, and the majority of users
that I am familiar with use SAS because of its ease in defining input
record formats. Virtually none of the SAS programs that I have seen
do fancy control reporting so I do not know how easy this is or is not.
> As a manager, I have to decide which language to use for
> 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. SAS is (and will be) licensed by the site,
> so it's not a point of concern. All the work will have to be
> done on mainframe, OS390.
>
Number one question: How long will this system be around? Whowill have
to do the maintenance? Most COBOL programmers can
pick up support of a COBOL program written by someone else;
this is not necessarly true for programs written in SAS.
You will find many articles and writings on COBOL coding standards,
some are good, and some are bad. I don't recall seeing any references
to suggested SAS coding standards - but I'm sure that SAS institute
has something on file - especially from the User Group Archives.
> Apart from seeing a few SAS-generated reports I haven't
> had any significant exposure to the software, so I would
> appreciate any ideas you may have.
>
> Regards, P.D.
"Years ago, a friend had to make a purchasing decision for some PC's.
He bought then from IBM, even though there was a machine for less
money that would do he needed for less.
I asked him, "Why did he spend the extra money?"
His reply? (slightly altered) "The project was not defined very well,
and I was afraid that I might have to explain my decisions to the
Board of Directors.
"I figured that I could say "But I bought IBM!" and there would be
less questions than if I said "But I bought Radio Shack!".
---
Sounds to me like you need to consider COBOL for maintainability
and pick an appropiate database manager to use for the Warehousing.
but than again, you might have a "perfect" application for SAS - but
I doubt it, based on the limited information provided.
Um, have you considered hiring a consultant? (I'm not available.)
/s/ Bill Turner, wb4alm
P. Michael Dorfman
Paul,
You must've already talked with SAS guys at your site, and I guess I
know what their standpoint could have been. If you are writing to the
group to seek an unbiased judgment and by "qualified opinion" mean
an opinion of someone who's dealt a lot with _both_ COBOL and SAS
then I can probably add a couple of things to the postings of Gary Lee
and Mark Young. The two gentlemen (not to mention the Goobers, of
course)
have already provided you with a general glimpse and some significant
details, and for the time being, I'd rather skip few things with which
I might disagree.
SAS (or SAS Information Delivery System, as SAS Institute Inc. prefers
to call it without any reference to the "Statistical Analysis System"
which the abbreviation originally stood for) is a very large and multi-
faceted software package consisting of Base SAS Software (the core of
the system) and additional products. Base SAS consists of SAS Language,
SAS Procedures, and SAS Macro Language.
Strictly speaking, it would be "fair" to compare COBOL with SAS Language
only (more precisely - with the language of DATA Step without open code
statements) but it's probably not what you're actually asking about
since very few SAS programs contain no SAS procs or macro statements.
Within the "fair" limit:
- Both are general programming languages (and both are 3GL, procs and
macros make SAS a 4GL) and have similar programming statements and
constructs such as loops, arrays, case structure etc.
- In COBOL, identifiers are long enough to be self-explanatory. In SAS,
they are limited to 8 characters long which will be expanded to 32 in
the upcoming version 7.
- In SAS, character variable (field) length is limited to 200 (again,
in version 7 it will be expanded to 32767), in COBOL it's not.
- Neither language has an internal mechanism of enforcing structured
programming (unlike C or Pascal, for example) but in COBOL, it's
easier to implement (and abuse).
- An important aspect of SAS is a construct called a SAS dataset.
Picture
it as a table similar to a relational database table, the columns
being variables, the rows being observations. Since SAS datasets
don't have to be declared they are used as temporary and permanent
data storage and are very easy to read from, write to and
manipulate.
SAS datasets can be indexed, read and modified sequentially and
randomly
and processed with full-fledged SQL all of which makes them very
convenient for data warehousing.
- SAS variables needn't be declared - they can be created on the fly.
So, SAS doesn't enforce working-storage documentation (variables
still can be declared but it's rarely done). However, if SAS data
set is created it is fully documented in its so-called descriptor,
and descriptor information can be easily accessed programmatically.
Among other things, it means that if data are stored in a SAS data
set the file layout needn't be maintained. If variables are read
from one SAS dataset and written to another one, all the information
about variables is automatically copied to the descriptor being
created. In SAS lingo it's called documentation proliferation.
- In SAS, there is no need to organize a file reading loop (even
though it can be used in the same manner as in COBOL)- it launches
it automatically once a file reading statement is issued. There are
also a myriad of automatic variables one can use. Together with
implied
statements, it is what makes SAS code concise.
- Some constructs like binary search are absent from SAS and have to be
programmed. Also, COBOL is a lot more flexible in creating leveled
data
structures. On the other hand, SAS has a built-in file match ability
(any number of files, any number of keys) and a lot more impressive
array of functions, formats, call routines, etc.
- SAS can read data in virtually any format and from any major database
existing for the operating system under which it's installed. A major
SAS drawback, however, is its inability to work with embedded SQL. I
don't know yet if it is going to be implemented in version 7.
The list could go on and on but within the "fair" approach the sides are
approximately even (depending upon one's tastes and preferences). The
addition of open code statements, procs and macros 'changes everything'.
They, combined with the fact that SAS supervisor compiles and executes
SAS programs at run time step by step, enable one to create flexcode
(code writing and modifying itself) and execute operating system
commands
and/or run external programs (like IBM utilities, SYNCSORT or FILEAID)
from within a program. Thus, for instance, operating system files can
be created on the fly with data driven names, written into, deleted,
etc.
Availability of procs also changes programming style. If you had to
build a house and your only choice were cinderblocks and a set of fine
tools to put them together you would use one strategy; if, in addition
to the bricks, you had a warehouse of panels of different sizes that
could be easily coupled together, you would probably use another method
and, most likely, the house would be erected a lot sooner, even though
it might not look as pretty.
In the case you are going to do a lot of ad hoc work and/or data
analysis
SAS is indispensable because trying to produce output similar to what
SAS procs can perform by writing a comparable COBOL program is probably
possible but practically not feasible. If the warehouse you are talking
about is going to comprise SAS datasets (I know shops like that) then
the choice is obvious. If it is DB2 you are going to rely upon and the
programs under your project will have to update DB2 tables then good old
COBOL will do better.
In your situation, there are too many factors involved to give any solid
advice. Let me just suggest that if you thumb through books listed below
your decision will probably be more competent. Writing a couple of SAS
programs (it's a lot easier than it seems initially) wouldn't hurt,
either. Also, I'd throw the thread into the SAS discussion group, which
is, I believe, comp.soft-sys.sas. Those guys may not be the greatest
COBOL
aficionados (in fact, many of them are COBOL defectors) but they sure
know a lot about SAS. Visiting SAS Institute WEB site may be quite
informative for a novice, too, even though it smells like an ad.
I wish you all the luck.
Books
-----
1. Rick Aster, Rhena Seidman. Professional SAS Programming Secrets.
ISBN 0-8306-7612-0.
The best SAS book ever written.
2. Michael A. Raithel. Tuning SAS Applications in the MVS Environment.
ISBN 1-55544-278-1.
Tons of useful stuff.
3. SAS Language. Reference, Version 6.
ISBN 1-55544-381-8
SAS Institute language reference. Read introduction carefully.
-------------------------
P. Michael Dorfman
Decision Support Systems
AT&T UCS
Jacksonville, Fl
-------------------------
Paul Darlington wrote:
>
> Dear All,
>
> Does anyone have a qualified opinion on how SAS fares
> in comparison with COBOL as a general programming
> language? As a set of tools to perform certain tasks?
>
> As a manager, I have to decide which language to use for
> 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. SAS is (and will be) licensed by the site,
> so it's not a point of concern. All the work will have to be
> done on mainframe, OS390.
>
P. Michael Dorfman
Gary Lee, in particular, wrote:
> Bottom line is that the most significant part of your question is
> 'sophisticated data manipulation and complex reporting (involving, for
> instance, multilevel control breaks)' . Personally I don't think of
> multilevel control breaks as sophisticated or complex, and either is easy
> in COBOL or SAS.
Gary,
I agree that, in principle, a control break process by itself is neither
sophisticated nor complex but as the number of levels grow it becomes
exponentially more tedious and error prone. Talking about COBOL code
vs SAS DATA step only, the availability of automatic variables first.
and
last. helps make SAS code shorter and more clear. The thing is, however,
that in SAS, one is not limited to DATA step alone. Using procs like
SUMMARY of FREQ to perform calculations at all break levels beforehand
(that are guaranteed to work right and don't even require sorting) and
combining their output with either DATA step or other procs to do
further
processing may substantially cut development time . As a matter of fact,
I used to work for a company where for whatever reason SAS was banned
from
production, so I had a COBOL reporting program of this type to fix. The
program had more than 30,000 lines of code and miscalculated something.
It took 10 minutes to concoct SAS code to produce the same report, only
correctly, and having a set of right numbers to compare with it became
easy to find the flaw. As an icing on the cake, the SAS program also ran
three times faster.
The point is that if lots of processing like is intended, SAS might very
well be the language of choice.
Regards, Mike.
P. Michael Dorfman
Mark0Young wrote:
>
> In article <3498685E...@pd.yrac.com>, Paul Darlington> >a project that is going to be heavy on i/o, sophisticated
> >data manipulation and complex reporting (involving, for
> >data warehousing.
>
> for studies and the like uses SAS heavily, and it takes big chunks of time on
> our system. I don't know if that is a problem with SAS or if it is a problem
> with the person who just happens to know enough SAS to be dangerous but he
> doesn't know anything about optimizing applications.
It's probably not wise to do massive data reduction either with SAS or
COBOL (as far as COBOL vs SAS is concerned). Chances are, however, that
the code is written inefficiently. Also true that SAS is easy to abuse,
the result being tremendous degrading in performance. If the person
you've
mentioned is really interested to find out if the code is efficient,
here
is a must reading:
1. SAS Programming Tips: A Guide to Efficient SAS Processing.
ISBN 1-55544-431-8.
2. Michael A. Raithel. Tuning SAS Applications in the MVS Environment.
ISBN 1-55544-278-1.
> SAS seems to be designed for numerical analysis, but so far I am not impressed
> with its performance for simple things like filtering records. (We often see a
> 2:1 improvement in throughput when filtering is done by a different programming
> language, e.g., Easytrieve-Plus, and then just the selected data is passed on
> to the SAS step.)
Agree. I'm not sure that for filtering records, COBOL is faster than SAS
but
even with all efficiency techniques applied, SAS yields to Easytrieve.
However,
SYNCSORT vastly outperforms anything else.
Regards, Mike.
---------------------------------
P. Michael Dorfman
AT&T UCS Decision Support Systems
Jacksonville, Fl
---------------------------------
P. Michael Dorfman
Bill Turner, WB4ALM wrote:
> In my opinion, SAS is a great tool to do data reduction with.
Not really. It's true that with some experience SAS is easier to
code, and often it is used for data reduction just for the sake
of not mixing it with other things - this way it's written
faster. But if one is concerned about performance, SYNCSORT is
the tool.
> Cobol is a great reporting tool.
Agreed. But for reporting SAS is so much better in any conceivable
way, that SAS is used almost exclusively within organizations
specializing in detailed reporting (for instance, in pharmaceutical
industry where FDA to which reports is presented is picky as hell and
approval or disapproval of a drug is at stake).
Charla J. Williams
Paul Darlington (pdarl...@pd.yrac.com) wrote:
: Does anyone have a qualified opinion on how SAS fares
: in comparison with COBOL as a general programming
: language? As a set of tools to perform certain tasks?
I would think it would be a lot easier to hire people to
support COBOL applications than it would to support SAS
applications. Wasn't SAS supposed to be good for statistics,
etc. There are other tools to spit out reports than COBOL.
I personally wouldn't look at new development in SAS in a
business environment. Is it because SAS is supposed to
have multi-platform capability that you are looking at it or is
it just because the software will be available to you?
Regards, Charla
Richard Levy
SAS is a very good language for statistics and simple reporting. It works
with IMS,DB2, and a number of other databases. The advantages are a short
development time, simple coding for record layouts, and relatively simple
coding for databases like IMS. The newer versions ofSAS allows for
paragraph headings and so structured coding can be written (good luck
finding a programmer who can do this). SAS sells packages to do any number
of statistical functions. Like almost all 4GL languages, a sequential read
is assumed and so a basic SAS program can be written without switches and
end-of-file tests. I wrote quite a few quick and dirty SAS programs for
clients although very few were intended for production and I am primarily a
COBOL programmer (Yep, I know COBOL and SAS. I wonder how much THAT's
worth).
The problems with SAS are:
Upward Compatibility
When moving from verision 5.x to 6.x, one of my clients was faced with
completely rewriting the IMS definitions until SAS came out with a patch in
version 6.x.x to make this downward compatible. This is a normal pitfall of
4GL languages. Easytrieve to Easytrieve Plus, Focus 6.x to 7.x, I've seen
downward compatibility problems with them all - which range from setting
override switches to complete rewrites or using a conversion utility,
rewriting the inevitable leftovers, and retesting everything. COBOL has
had some small compatibility issues, but nowhere as bad as the potential in
4GL languages.
Complexity
SAS will maintain a read-next loop automatically. This is great for simple
reporting, but if you need to start coding explicit read statements and do
decision based record handling, you are coming close to writing a COBOL
program. Once you alter the default flow of a SAS program you are
responsible for the result. I would rather debug a COBOL program with 300
lines in the Procedure Division than a SAS program with 100 lines beneath
the record layout.
Testing and Debugging Tools
As of 2 years ago when I last used SAS, I did not see the tools for
debugging SAS that I did for COBOL. If for example, you did write a complex
SAS program and the results seem suspicious, finding out if you have a
problem can be difficult. Difficult in programming terms means expensive in
management terms. On the client/server side, this may have changed. There
might be a "Visual SAS" now available, which means you can develop complex
code faster.
Programming Talent
I have never immersed myself in the SAS market, since I am primarily a COBOL
programmer (14 years) with about 2-3 years of intermittent SAS. SAS can be
written by users and a programmer can pick up enough SAS quickly to do
simple tasks. IF, however, you intend to use IMS and DB2, or code complex
structured SAS, I hope you can find experienced people or have the time,
money and patience to develop in-house.
Summary
SAS is very good at writing reports against many database formats. It can
even perform extracts and field extensions quickly. It is very good for
management reports, especially if complex functions are required. I would
not write a complex system with it. If you remember the story about the
race between the horse and the man, the man won in the short distance race
since he could offset the horse's speed by being able to stop, turn around,
and run back more quickly. COBOL is like the horse, and SAS is like the
man. You need to decide what kind of race you're running.
BTW, this information is provided free and is guaranteed to be worth the
price. These are my opinions and I refuse to make any warranty to them. If
you want me to back them up and feel like paying me $100 an hour for a
consultation, I'd probably have to refuse (my employer requires me to
register all moonlighting and discourages clients from certain industries).
The Goober was right and wrong. This is a community and some information
should be freely given. It's only when you want to make it "official" that
I would demand payment. In a world where everyone wanted money in exchange
for every courtesy, you wouldn't be able to ask for directions without
paying. If anyone finds this information of worth, they can repay me by
helping when someone else asks a question (yes, even Goobers). Of course,
if your company prints a cool tee-shirt.... 8^)
Paul Darlington wrote in message <3498685E...@pd.yrac.com>...
>Dear All,
>
> Does anyone have a qualified opinion on how SAS fares
> in comparison with COBOL as a general programming
> language? As a set of tools to perform certain tasks?
>
> As a manager, I have to decide which language to use for
> 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,
Puter 714
I'm new to this group and I followed this chain to the end.
COBOL vs SAS
This question has been asked in my company for over 10 years now(we have
both)--- SAS has lost.
SAS has gotten the bad rap of being a hog on resources mostly because of poor
coding technique or lack of SAS knowledge.
I have found SAS as difficult to debug and maintain.
SAS reporting is relatively simple if you can live with SAS formatted reports.
If you have client deliverables or users who want neat reports then it can be a
pain.
We also have an AR sytem written entirely in SASAF (G-D only knows why). Noboby
wants to touch it.
I prefer COBOL(FCOBOL, COBOLII, or COBOL LE).
I've been coding cobol for 20 years(SAS for 8).
Using Microfocus COBOL with debugging tools and being able to step thru code is
a poductivity dream.
We recently purchased EASYTRIEVE and we will be using it for most of our
reporting needs. It also can read just about any type of file there is. We also
have the workstation wich gives you the ability to acces PC files and mainframe
files.
PS
In my office SAS stands for "Stupid Ass System"
matt
about it ( It took a team of 120 COBOL programmers 3 years to create a
system in Cobol but X and Y did it in SAS on a Friday afternoon).
It also seems to be the case that those who are SAS zealots never learnt
formally to write code. It really does make a nice toy for Data miners
and the decision support wankers whos salary is in line with their
ego's.
Me I had to learn sas. Pansophic did create a for better product in
Easytreive and Et plus. But I will have Cobol any day. I have designed
and constructed Cobol running on just about every platform including
Automatic teller machines(in this case used Visualage Cobol for OS/2). I
dont know of any other language ( including C & C++) that has got on to
so many platforms.
So stodgy sas although it has some bullshit pc based thing, doesn't
really run properly on the AS/400, I havn't seen it on a Dec of HP
(midrange) box, but it does keep the IBM (and compatable) mainframes
(god bless them) in the dark ages with lots of mistery......
Paul M. Dorfman
Matt, in particular, wrote:
> The thing I like about SAS is the outrageous claims some people make
> about it ( It took a team of 120 COBOL programmers 3 years to create a
> system in Cobol but X and Y did it in SAS on a Friday afternoon).
It's blown out of proportions. In reality, it was 12 COBOL programmers
and 4 months only.
> It also seems to be the case that those who are SAS zealots never learnt
> formally to write code. It really does make a nice toy for Data miners
> and the decision support wankers whos salary is in line with their
> ego's.
Decision support is precisely what systems are created for. If a data
processing system cannot be used for quick decision making, it is
useless.
> Me I had to learn sas. Pansophic did create a for better product in
> Easytreive and Et plus. But I will have Cobol any day. I have designed
> and constructed Cobol running on just about every platform including
> Automatic teller machines(in this case used Visualage Cobol for OS/2). I
> dont know of any other language ( including C & C++) that has got on to
> so many platforms.
Keep learning. This way, you will be able to judge relative merits of
software without claiming that EZ is better than SAS for anything but
primitive data filtering.
> So stodgy sas although it has some bullshit pc based thing, doesn't
> really run properly on the AS/400, I havn't seen it on a Dec of HP
> (midrange) box, but it does keep the IBM (and compatable) mainframes
> (god bless them) in the dark ages with lots of mistery......
I'm not sure that the above mentioned substance is really used to make
PCs or should be used in formal writing... I believe you haven't seen
SAS run on anything except mainframe or the dubious quality PC you
mentioned, but the fact is that it exists on any imaginable platform and
runs properly under any major operating system. You may have heard that
on all those platforms, SAS has a program editor with a built-in spell
checker, so next time you post something, you may want to use it.
Otherwise, an ambiguity may sneak into your text. For instance, did you
actually mean "mystery" or "misery"?
Respectfully,
---Paul M. Dorfman.
P.S. I use COBOL, SAS, Easytrieve, whatever is appropriate at the
moment. All of them are merely programming tools; none of
them is good as a basis for religion or curse.
---------------------------------
Paul M. Dorfman
Gary Lee
Paul M. Dorfman <pdo...@ucs.att.com> wrote in article
<34AD3DCC...@ucs.att.com>...
> Matt, in particular, wrote:
>
> > The thing I like about SAS is the outrageous claims some people make
> > about it ( It took a team of 120 COBOL programmers 3 years to create a
> > system in Cobol but X and Y did it in SAS on a Friday afternoon).
>
> It's blown out of proportions. In reality, it was 12 COBOL programmers
> and 4 months only.
But if you'd like to see some concrete examples, I can supply you the
actual code from real, live, production applications. Some of my favorites
are where a long COBOL development cycle resulted in something which didn't
work right. A SAS routine was developed to test the COBOL system, and
ended up replacing it.
> > It also seems to be the case that those who are SAS zealots never
learnt
> > formally to write code. It really does make a nice toy for Data miners
> > and the decision support wankers whos salary is in line with their
> > ego's.
I certainly thought I, and the other SAS developers I know, all knew how to
code in COBOL. All the best COBOL guys I know also know several other
languages on several platforms. Come to think of it, that applies to all
the best coders or analysts in any language on any platform.
> Decision support is precisely what systems are created for. If a data
> processing system cannot be used for quick decision making, it is
> useless.
>
> > Me I had to learn sas. Pansophic did create a for better product in
> > Easytreive and Et plus. But I will have Cobol any day. I have designed
> > and constructed Cobol running on just about every platform including
> > Automatic teller machines(in this case used Visualage Cobol for OS/2).
I
> > dont know of any other language ( including C & C++) that has got on to
> > so many platforms.
Sleazytrieve is great for some things. So are WordPerfect, JCL,
Postscript, and the Doom Rendering Engine. It all depends on what you are
trying to do.
> Keep learning. This way, you will be able to judge relative merits of
> software without claiming that EZ is better than SAS for anything but
> primitive data filtering.
>
> > So stodgy sas although it has some bullshit pc based thing, doesn't
> > really run properly on the AS/400, I havn't seen it on a Dec of HP
> > (midrange) box, but it does keep the IBM (and compatable) mainframes
> > (god bless them) in the dark ages with lots of mistery......
We have SAS running on MVS, PCs (Windows and OS/2), Solaris, HP-UX and NT
server, and I have seen it on DEC at a previous employer. I haven't used
the Easytrieve versions for UNIX or NT, or PC workstations. Do they work
well?
>
> I'm not sure that the above mentioned substance is really used to make
> PCs or should be used in formal writing... I believe you haven't seen
> SAS run on anything except mainframe or the dubious quality PC you
> mentioned, but the fact is that it exists on any imaginable platform and
> runs properly under any major operating system. You may have heard that
> on all those platforms, SAS has a program editor with a built-in spell
> checker, so next time you post something, you may want to use it.
> Otherwise, an ambiguity may sneak into your text. For instance, did you
> actually mean "mystery" or "misery"?
>
> Respectfully,
>
> ---Paul M. Dorfman.
>
> P.S. I use COBOL, SAS, Easytrieve, whatever is appropriate at the
> moment. All of them are merely programming tools; none of
> them is good as a basis for religion or curse.
Hear, hear!! Use the best tool for the job. Have enough tools in your
belt to know which is best. A good carpenter knows a hammer from a saw,
and when to use each.
> ---------------------------------
> Paul M. Dorfman
> AT&T UCS Decision Support Systems
> Jacksonville, Fl
> ---------------------------------
>
Gary Lee Consultec, Inc.
-----------------
"Twenty years of schoolin' and they put you on the day shift."
Bob Dylan