Cobol sucks
Arnold Sommerfeld
>
> Bad? As opposed to what?
>
> Claw-Mark wrote in message <35EBDFD0...@hotmail.com>...
> >cobol is very bad language
> >
Not bad. Rather inferior.
As a general programming language in ANY area of data processing, business
included, infinitely inferior to PL/I. Just a couple of reasons (there are
many more):
1. Virtual absence of intrinsic functions. If one thinks COBOL has got some
in 370, take a peek at the array of functions available from PL/I.
2. Total absence of anything even reminding PL/I ability to work with the
operating system.
3. Absence of a macro processor. Makes elementary operations like working
with files whose names are data driven a chore, if implementable at all.
4. Efficient string manipulation cannot be had from a language using
statements instead of functions to handle character variables.
In some specific areas, such as statistics, ad hoc reporting, and data
mining, COBOL is absolutely worthless compared to SAS.
In the rest of the fields not mentioned above, it is a great programming
language with a hairy heritage.
Arnold
sba...@my-dejanews.com
And BETA is better than VHS, and OS/2 is better than Windows
so what. Eleventy billion lines of code can't be wrong.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Tim Oxler
>Chris Osborne wrote:
>>
>> Bad? As opposed to what?
>>
>> Claw-Mark wrote in message <35EBDFD0...@hotmail.com>...
>> >cobol is very bad language
>> >
>
>Not bad. Rather inferior.
>
>As a general programming language in ANY area of data processing, business
>included, infinitely inferior to PL/I. Just a couple of reasons (there are
>many more):
>
Oh...language wars.
Arnold, who cares. COBOL isn't a general purpose language. It's
specifically designed for business data processing, and at that it is
vastly superior.
PL/I is a really good language, but the fact is, nobody uses it.
Working in ComputerWorld's pick as the 12th best computer industry
market for the past 18yrs, and trained in PL/I, I can tell you that I
can count the number of shops that use PL/I on one hand. OTOH, I'd
need a 55 gallon barrel and a couple hundred pound sacks of beans to
count all of the COBOL shops.
Tim Oxler
TEO Computer Technologies Inc.
http://www.teo-computer.com
Take the Y2k Quiz
http://www.teo-computer.com/dev/quiz.html
Chris Osborne
On a point by point basis of weaknesses versuses strengths, I have to agree
to most of what you say.
However, I've been working with SAS for a while now (6.0.8). The
documentation from SAS is effectively worthless (to me, at least). All the
manuals talk like the reader already knows the paradigm behind SAS data
manipulation, SAS dataset storage in SAS libraries, and just how SAS works
in general. The companion book for my operating system reads like the
author(s) weren't sure what they were talking about (I'm sure they did, but
what they wrote down didn't communicate what I need to know)
Most commercial SAS books are about the same.
This is difficult, because SAS has weird naming conventions (an eight letter
variable name limit!), weird error and runtime reporting, and doesn't
operate on data like COBOL (obviously), or C, C++, or Visual Basic. The way
I see it, SAS doesn't work like any other language, and this is bad when it
comes to matching what I already know against what SAS can do.
If COBOL is useless for Ad Hoc reporting (I wholeheartedly agree), then I
must point out that SAS is less than useless for batch processing of any
kind without jumping through hoops. This because SAS must take data and
fully read it into a SAS dataset before the SAS software engine can operate
on the data. Before anything else can operate on data processed by SAS, SAS
must write the data out of the SAS dataset into a normal OS (whichever OS is
being used) dataset. This is a massive waste of time. SAS is also an
enormous CPU hog (at least on MVS, it is).
I think, if SAS could get around the SAS dataset problem (I'm pretty sure
SAS personnel and other SAS devotees don't see it as a problem), SAS would
be more widely accepted that it already is.
As for Ad Hoc reporting in general, and the usefulness of 4GLs in getting at
data for such requests . . .
I've been doing some Ad Hoc reporting for about seven months now, and a lot
of this stuff is repeating itself, over and over. Since most 4GLs use more
CPU power for the tradeoff of easier programibility, a program quickly run
and data quickly produced is often valuable. But when you use the same 4GL
over and over for exactly the same question, that tradeoff starts to look
less attractive. If the program had been written in a more efficient batch
language, all that extra CPU time wouldn't have been wasted.
Of course, a great deal of this has to do with business people knowing about
what they want. They ask for something as Ad Hoc, decide they like it, and
continue asking for it the same way, generating no justication to assign
enough time to do the job right. With one Ad Hoc report doing a good thing,
more do better, and so an avalanche of Ad Hoc report requests begin.
As for me personally, some of the requests require moderate programming
levels, and I don't know enough about SAS (and thus my gripe about their
documentation), so I use COBOL.
If the people who requested this sort of thing could only figure out either
a)that they'd need this sort of information more than once, or b)that it's
okay to ask for more development if something is going to be done
permanently.
Permanent Ad Hoc reporting.
Arnold Sommerfeld wrote in message <35EC0EB3...@earthlink.net>...
>Chris Osborne wrote:
>>
>> Bad? As opposed to what?
>>
>> Claw-Mark wrote in message <35EBDFD0...@hotmail.com>...
>> >cobol is very bad language
>> >
>
>Not bad. Rather inferior.
>
>As a general programming language in ANY area of data processing, business
>included, infinitely inferior to PL/I. Just a couple of reasons (there are
>many more):
>
Thane Hubbell
<arnoldso...@earthlink.net> wrote:
> 1. Virtual absence of intrinsic functions. If one thinks COBOL has got some
> in 370, take a peek at the array of functions available from PL/I.
Not true since 1989 - however only recently has the IBM mainframe
world received these.
> 4. Efficient string manipulation cannot be had from a language using
> statements instead of functions to handle character variables.
This is simply ludicrous. COBOL has SUPERIOR string handling. I'm
still waiting for someone to show me where it doesn't. Even WITHOUT
intrinsic functions to handle strings (and there are some cool ones
now), string handling in COBOL is easy, simple and fast.
Give me specific examples of string handling where you feel COBOL
falls down on the job and I'll attempt to educate you about how to
perform these tasks simply and quickly using COBOL.
Jeff Farkas
Chris Osborne wrote:
> Arnold,
>
> On a point by point basis of weaknesses versuses strengths, I have to agree
> to most of what you say.
>
> However, I've been working with SAS for a while now (6.0.8).
<SNIP>
I started using SAS from version 5.x.x and I agree that the
manuals are not the best. As for the language it self
I have found that it is a very good utility to solve problems
and generate various reports very quickly.
If you are still trying to use SAS try out the following
book:
Professional SAS programming Secrets
by Rick Aster & Rhena Seidman.
It seems to be the best of the bunch.
--
Jeff Farkas
Jeffrey...@gte.net
"I calculated the odds of this thing succeeding versus the odds of
it doing something incredibly stupid. . and. . I went ahead anyway"
{Crow from MST3K}
Chris Osborne
I'll scan through it at the local bookstore and see if it provides a more
detailed explanation of SAS low-level basics without assuming I already
understand SAS itself.
If I can get a hold of the internals of the system, there is a bigger chance
that examples in the docs will snap into context.
Thanks,
Chris
Jeff Farkas wrote in message <6smilu$21h$1...@news-1.news.gte.net>...
>
>
>Chris Osborne wrote:
>
>> Arnold,
>>
>> On a point by point basis of weaknesses versuses strengths, I have to
agree
>> to most of what you say.
>>
>> However, I've been working with SAS for a while now (6.0.8).
>
Judson McClendon
dropping a single inflammatory remark is always a troll. Claw-Mark
probably wouldn't recognize COBOL if it came up and bit him. He must
have heard about it on the news regarding Y2k and thought he would
pull our chain. Claw-Mark likely has never bothered to look back, or
is rolling in the floor laughing at what a rise he got out of us. :-S
P.S. - Daja News shows this as the ONLY thread anywhere associated
with "Claw-Mark".
--
Judson McClendon judm...@bellsouth.net (remove numbers)
Sun Valley Systems http://personal.bhm.bellsouth.net/~judmc
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
Jeff Farkas
Chris Osborne wrote:
> Jeff,
>
> I'll scan through it at the local bookstore and see if it provides a more
> detailed explanation of SAS low-level basics without assuming I already
> understand SAS itself.
>
> If I can get a hold of the internals of the system, there is a bigger chance
> that examples in the docs will snap into context.
>
> Thanks,
> Chris
Chris,
I am not sure if you will find it in a book store. The copy I have
came from SAS but it is printed by Windcresst/McGraw-HIll so
you may find it. Also I just checked and the latest edition is
available from Amazon.com.
I think you will find it useful. Once I got my hands on it I was able
to understand the language a lot better and I could skip the
manuals in many cases.
If you have any question feel free to email them to me and
I will try to explain what is going on.
Just be thankful that SAS has some books. Have you ever
tried FOCUS? That is a real dog.
>
>
> Jeff Farkas wrote in message <6smilu$21h$1...@news-1.news.gte.net>...
> >
> >
> >Chris Osborne wrote:
> >
> >> Arnold,
> >>
> >> On a point by point basis of weaknesses versuses strengths, I have to
> agree
> >> to most of what you say.
> >>
> >> However, I've been working with SAS for a while now (6.0.8).
> >
Rodger Whitlock
>...Claw-Mark
>probably wouldn't recognize COBOL if it came up and bit him.
Please, if you use one of the canonical online insults, use it correctly.
The correct wording of this insult would be:
"Claw-Mark probably wouldn't recognize COBOL if it *jumped* up and bit him
*on* *the* *ass*."
<mutters to self about sinking literary standards>
----
Rodger Whitlock
Chris Osborne
Your offer of SAS aid is greatly appreciated, I'd pretty much abandon it
locally (despite its obvious, if difficult to access, power) because of lack
of support (all of our original SAS developers are gone).
My local bookstore is a Borders, so they might have it. However, I've got
to say, that when I talk about local bookstore, I mean anything I can get to
easily, and Amazon.com qualifies. But that's hardly obvious.
However, Bookpool is often cheaper than anyone else (if they carry the book
at all; (www.bookpool.com)), and I have a corporate discount at Computer
Literacy, which can make that cheaper than even Bookpool, and they have a
much better selection, maybe almost as good as Amazon.com, though they don't
have the large consumer review base (www.clbooks.com).
Thanks,
Chris
Jeff Farkas wrote in message <6smofs$dal$1...@news-1.news.gte.net>...
>
>
>Chris Osborne wrote:
>
>> Jeff,
>>
>> I'll scan through it at the local bookstore and see if it provides a more
>> detailed explanation of SAS low-level basics without assuming I already
>> understand SAS itself.
>>
>> If I can get a hold of the internals of the system, there is a bigger
chance
>> that examples in the docs will snap into context.
>>
>> Thanks,
>> Chris
>
>Chris,
>
> I am not sure if you will find it in a book store. The copy I have
>came from SAS but it is printed by Windcresst/McGraw-HIll so
>you may find it. Also I just checked and the latest edition is
>available from Amazon.com.
>
>I think you will find it useful. Once I got my hands on it I was able
>to understand the language a lot better and I could skip the
>manuals in many cases.
>
> If you have any question feel free to email them to me and
>I will try to explain what is going on.
>
>Just be thankful that SAS has some books. Have you ever
>tried FOCUS? That is a real dog.
>
<<snip of many previous messages>>
Chris Osborne
Judson McClendon wrote in message ...
Paul M. Dorfman
An interesting post! Let me stop at some points. But first, as it is a serious
professional talk now, let us change the name of the thread to 'COBOL & SAS'.
>
> However, I've been working with SAS for a while now (6.0.8). The
> documentation from SAS is effectively worthless (to me, at least). All the
> manuals talk like the reader already knows the paradigm behind SAS data
> manipulation, SAS dataset storage in SAS libraries, and just how SAS works
> in general. The companion book for my operating system reads like the
> author(s) weren't sure what they were talking about (I'm sure they did, but
> what they wrote down didn't communicate what I need to know)
> Most commercial SAS books are about the same.
True, but not nearly as bad as IBM documentation. In reality, nobody begins to
learn COBOL using it; the same with SAS. There are several superb books written
by users. For instance "SAS: A Gentle Introduction" by Frank Dilorio and, at a
higher level, "Professional SAS Programming Secrets" by Rick Aster and Rhena
Seidman.
> This is difficult, because SAS has weird naming conventions (an eight letter
> variable name limit!), weird error and runtime reporting, and doesn't
> operate on data like COBOL (obviously), or C, C++, or Visual Basic. The way
> I see it, SAS doesn't work like any other language, and this is bad when it
> comes to matching what I already know against what SAS can do.
Eight letter limit is a serious shortcoming but it will become history at the
end of 1998 with the release of version 7. It is going to be 32. Also, the
maximum length of a character variable, currently 200, will be expanded to
32760. Error and runtime reporting is not 'weird', it is simply different from
COBOL. I find it really informative and easy to rely upon. As a general
programming language, SAS operates on external data (i.e. not SAS datasets or
views) the same way other languages do. For instance, when it reads or
writes/updates a flat file, VSAM file, DB2 table. Let us say, we need to read
16-digit account number (signed packed decimal, columns 1-9) and 50 bytes
address (columns 10-49) from a flat file whose DD name is FILEIN. We need to
squeeze all multiple blanks in ADDRESS to a single one, convert ACCOUNT into a
16-digit string, and swap the fields places as we write them into FILEOUT. Is
there anything a COBOL programmer cannot understand just by looking at the
program:
DATA _NULL_; * do not create any SAS
datasets;
INFILE FILEIN END=EOF; * identify input file, set eof
field;
FILE FILEOUT; * identify output file;
DO UNTIL(EOF); * loop until eof;
INPUT ACCOUNT PD9. ADDRESS $CHAR50.; * read record;
ADDRESS = COMPBL (ADDRESS); * process record;
PUT ADDRESS $CHAR50. ACCOUNT 16.; * write record out;
END; * pair DO with END;
RUN; * close files, etc.;
Looks pretty much like a regular COBOL, PL/I, etc. program with understandable
syntax distinctions. Maybe there is anything convoluted or unclear in the
messages sent to the SAS log? Let us see:
NOTE: The infile FILEIN is:
Dsname=USERIDZ.INPUT,
Unit=3390,Volume=TST903,Disp=SHR,Blksize=27880,
Lrecl=136,Recfm=FB
NOTE: The file FILEOUT is:
Dsname=USERIDZ.OUTPUT,
Unit=3390,Volume=TST913,Disp=NEW,Blksize=27920,
Lrecl=80,Recfm=FB
NOTE: 10000 records were read from the infile FILEIN.
NOTE: 10000 records were written to the file FILEOUT.
NOTE: The DATA statement used 0.09 CPU seconds and 3718K.
I do not think so! And surely SAS is not much different from C/C++ in working
with data considering the fact that C/C++ is its underlying software.
>................... SAS is less than useless for batch processing of any
> kind without jumping through hoops. This because SAS must take data and
> fully read it into a SAS dataset before the SAS software engine can operate
> on the data. Before anything else can operate on data processed by SAS, SAS
> must write the data out of the SAS dataset into a normal OS (whichever OS is
> being used) dataset. This is a massive waste of time. SAS is also an
> enormous CPU hog (at least on MVS, it is).
Not SAS but programs written based on the concept you just described. That SAS
must create a SAS dataset before doing anything, is the most widely spread
illusion about this software. In the program above, did you see SAS create a
single bit of a SAS dataset? No: it just reads a file, processes it, writes it
out. In other situations, when SAS datasets may really come in very handy, they
can be replaced with SAS views; thus only a few bytes of a view definition goes
to a disk.
SAS is a CPU hog? Granted, its i/o engines are not as fast as those of COBOL and
PL/I. However, it is not the main reason. The real reason is that many SAS users
are not programmers, and they simply do not know what the hell they are doing.
SAS is easy to use; but it is also immensely easy to abuse. Here in UCS, 90% of
SAS CPU time is consumed by 5% of the SAS programs. They are written and run by
SAS 'gurus' from marketing, credit policy, CFO, and so on. Imagine a COBOL
program reading a 60M-record file, creating a backup both on DASD and tape,
erasing the original, and ... that's all! Will it not waste resources? Yet this
nonsense is a vital part of those programs, and does it have anything to do with
SAS per se?
> I think, if SAS could get around the SAS dataset problem (I'm pretty sure
> SAS personnel and other SAS devotees don't see it as a problem), SAS would
> be more widely accepted that it already is.
Now you know that SAS affiliation or even being a SAS bigot does not apply here,
since this problem simply does not exist. First, some manager decides that
someone who cannot ride a bicycle is good for driving a multifunctional powerful
bulldozer; inspired, the latter uses the bulldozer to pick up a six-pack; and
then the former, wondering why the fuel is gone along with the neighborhood,
blames the bulldozer for inefficiency and waste.
> As for Ad Hoc reporting in general, and the usefulness of 4GLs in getting at
> data for such requests . . .
> I've been doing some Ad Hoc reporting for about seven months now, and a lot
> of this stuff is repeating itself, over and over. Since most 4GLs use more
> CPU power for the tradeoff of easier programibility, a program quickly run
> and data quickly produced is often valuable. But when you use the same 4GL
> over and over for exactly the same question, that tradeoff starts to look
> less attractive. If the program had been written in a more efficient batch
> language, all that extra CPU time wouldn't have been wasted.
> Of course, a great deal of this has to do with business people knowing about
> what they want. They ask for something as Ad Hoc, decide they like it, and
> continue asking for it the same way, generating no justication to assign
> enough time to do the job right. With one Ad Hoc report doing a good thing,
> more do better, and so an avalanche of Ad Hoc report requests begin.
> As for me personally, some of the requests require moderate programming
> levels, and I don't know enough about SAS (and thus my gripe about their
> documentation), so I use COBOL.
> If the people who requested this sort of thing could only figure out either
> a)that they'd need this sort of information more than once, or b)that it's
> okay to ask for more development if something is going to be done
> permanently.
>
Agreed. However, more often than seldom, customers request minor changes to the
reports that run almost the same way all the time. A sophisticated
multidimensional report coded with PROC TABULATE may take maybe 50 lines of
code. Now, if another statistic is requested, or the customer wants to transpose
the report making its columns rows and vice versa and readjust the formatting
accordingly, it may take, grossly exaggerating, a couple of hours from pulling
it from production to moving it back in. On the other hand, completely rewriting
a 50,000 lines of COBOL... Lately, CPU time has been a lot cheaper than a COBOL
programmer's time. That is why, unless a report is absolutely static, we keep it
in production as SAS - in the long run, it is cheaper. Even though a well
written COBOL program runs faster that a well written SAS program,
anyway.
Best regards, Paul.
Paul M. Dorfman
Your best bet is to call SAS Institute at (919)677-8000 and ask for book
department. You can request a free Publications Catalog. Or go to www.sas.com;
it is there, too. They sell both their own manuals and BBU (books by users). The
last time I checked it was cheaper than Borders.
Regards, Paul.
docd...@clark.net
Paul M. Dorfman <pdo...@ucs.att.com> wrote:
[snippemente]
>True, but not nearly as bad as IBM documentation.
As I was taught: 'An IBM manual contains 25 chapters, each of which
assumes intimate familiarity with the other 24.'
DD
Chris Osborne
I had no idea that SAS dataset creation could be stopped. The MVS companion
doesn't mentions this up front. Neither does Mastering The SAS System, or
SAS Application Programming. They all start out by explaining that SAS
_must_ create its own internally formatted datasets. They might not use the
word "must", but it is presented in that context over and over again. What
I've read so far insists that SAS datasets must be created. Now that I know
I can bypass them, I will probably experience a change of heart about its
use.
I've saved you're examples out, and will be studying them.
I have never seen an example of SAS code done the way you have it, here.
Not in any book.
Typically, they have you doing the INFILE and INPUT as single lines, without
a loop, with iteration through the file records automatically provided by
the DATA step. Honestly, I've never seen it done another way; and the
various books do not suggest otherwise.
As for IBM documentation, the latest manuals for OS/390 are superior to what
they once were, but could still use improvement. In the old stuff, though,
the most valuable book I've found is MVS/XA Architecture Overview. A clear
and readable explanation of how the MVS operating system works, even now the
book can still serve as an excellent introduction (it's short) to MVS in
general.
Jeff Farkas
Thanks for the tip on the book stores. Here is some SAS code
you may like.
USE: My customers would use an application and
one of the byproducts was several data sets. The
end result would be a lot of data sets that
were no longer needed and needed to be cleaned
up. The following code did it very nicely.
DATA _NULL_;
INFILE DSNLIST;
FILE DSNOUT;
LENGTH DSN $45.;
INPUT @003 DSN_NAME $45.;
IF INDEX(DSN_NAME,'SS5470.CG5470.P')
THEN
DO;
DSN = "'"||TRIM(DSN_NAME)||"'";
PUT @02 "DELETE "
@09 DNS $45.;
END;
RETURN;
RUN;
This is the first step the second is an IDCAMS
which executes the delete commands created by
the SAS step. Use this correctly and you can get
rid of hundreds of data sets in a few seconds.
Chris Osborne wrote:
> Jeff,
>
> Your offer of SAS aid is greatly appreciated, I'd pretty much abandon it
> locally (despite its obvious, if difficult to access, power) because of lack
> of support (all of our original SAS developers are gone).
>
> My local bookstore is a Borders, so they might have it. However, I've got
> to say, that when I talk about local bookstore, I mean anything I can get to
> easily, and Amazon.com qualifies. But that's hardly obvious.
> However, Bookpool is often cheaper than anyone else (if they carry the book
> at all; (www.bookpool.com)), and I have a corporate discount at Computer
> Literacy, which can make that cheaper than even Bookpool, and they have a
> much better selection, maybe almost as good as Amazon.com, though they don't
> have the large consumer review base (www.clbooks.com).
>
--
Paul M. Dorfman
Due to SAS's brevity, using it for writing SYSINs for some subsequent JCL step
is a common practice. It's less widely known, however, that if the JCL step
executes an IBM utility or any other external (not SAS) program, it's not even
needed. This is because external programs, notably those in SYS1.LINKLIB and
whatever concatenated to it, can be executed straight from a SAS program as a
SAS proc step. This is how. Since normally the DD name SYSIN is occupied by SAS
program itself, first it needs to be freed up. The cards expected by the utility
(in the case of IDCAMS - SYSPRINT only) have to be provided either in JCL or
FILENAME statements.
// EXEC SAS,OPTIONS='SYSIN=SOURCE<,...more options if needed...>'
//DSNLIST DD DSN=<...dsnlist's real name...>,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSIN DD <same attributes as your DSNOUT>
//SOURCE DD *,DLM='$$'
DATA _NULL_;
INFILE DSNLIST;
FILE SYSIN;
LENGTH DSN $45.;
INPUT @003 DSN_NAME $45.;
IF INDEX(DSN_NAME,'SS5470.CG5470.P') THEN DO;
DSN = ''''||TRIM(DSN_NAME)||'''';
PUT @02 'DELETE ' @09 DSN $45.;
END;
RUN;
PROC IDCAMS; RUN;
$$
RETURN statement is not needed - it is implicit. And double quotes should be
used ONLY when a macro reference is to be resolved inside; otherwise, it causes
the macro processor to scan the program looking for macro references without any
need.
Just my $.02.
Regards, Paul.
Chris Osborne
Paul,
I hadn't realized you could execute programs in SAS; we'll, I knew there
must be a way to link to other programs, but I didn't mentally include IBM
utilities or other sys1 stuff in that.
Thank you. :)
Paul M. Dorfman wrote in message <35F0384A...@ucs.att.com>...
Jeff Farkas
Paul M. Dorfman wrote:
> Jeff Farkas, in part, wrote:
>
<SNIP>
Paul,
That was something I did not know. But thanks to you I now
know. Thank you.
PS, throw you two cents in as often as you like, it is
definitely worth it.