The Arguement for COBOL
Mark A. Framness
> OK! I have opened up so many cans of worms that its not funny anymore. I
> have been laughed at by people that know and people that are derelicts in
> the programming field. The question!
>
> What is the absolute language to program in to simply push data?
Ahhhh the makings of a "religious war". Break out of that mode of
thinking. Choose a language according to the task and available libraries
rather than a fondness or familiarity of one language.
>
> Simple question for me. I think COBOL! COBOL was built for one purpose -
> process mass amount of data. By mass amount I mean from 500,000 records and
> up. Can anyone else shed some more light on this issue? What other reason
> is there. Can any other modern language come close?
Your contention that COBOL is well suited for processing of mass data is
slightly off of the mark. What platform are you talking about? Processing
500,000 records on a PC in any language is going to take a real long time
no matter what language you are using. That same task will be quicker on a
OS/390 system again, no matter the language.
Programming isn't a matter of language as much as logic and process. All
languages must do the same things. Get input, process data and output.
I like COBOL for its readability and hate it for its universal data
visibility.
From: Mark A. Framness
http://netnet.net/~farmer/
fram...@athenet.net
Go Pack Go!
Oh balsam tree oh balsam tree I see you when I deer hunt!
Brian Framness
Howard Brazee
>
> What is the absolute language to program in to simply push data?
The best language to simply push data may be ICEGENER. It copies files
quite quickly and simply and does have some extensions. It runs on IBM
compatible mainframes.
Of course once you get beyond selecting, sorting, and copying, other
languages have advantages. But you did say "simply". If you get
complex business rules which need to be maintained, you probably want to
pick a more English language language such as Cobol. But that is adding
to your question. If the data you want to push are designed to be read
by a variety of personal computers around the world, HTML works better.
If you want to PULL data, instead of pushing it, SQL may be the choice.
There is a good reason why there are tens of thousands of programming
languages out there.
Michael Baumli
or it was, now with the E-commerce revolution, and demand for OLTP, will
COBOL and it's Legacy disappear with Batch processing, or are they all to
stay around even after ebusiness?
oh, and language does make a difference, COBOL was made for Record I/O,
where most of the others or made for Stream I/O, is only one of the few
thing that makes COBOL great for processing your records, no matter the
system
Mark A. Framness <mfra...@NOSPAM.athenet.net> wrote in message
news:8Sd1uPikEGru-p...@www.framnett.net...
> On Sun, 11 Jun 3900 06:06:30, "Mark Muniz" <wht...@flash.net> wrote:
>
> > OK! I have opened up so many cans of worms that its not funny anymore.
I
> > have been laughed at by people that know and people that are derelicts
in
> > the programming field. The question!
> >
> > What is the absolute language to program in to simply push data?
>
Mark A. Framness
> "Mark A. Framness" wrote:
> >
> > What is the absolute language to program in to simply push data?
>
> The best language to simply push data may be ICEGENER. It copies files
> quite quickly and simply and does have some extensions. It runs on IBM
> compatible mainframes.
Well to set the record straight, I did not write the portion you are
replying to.
>
> Of course once you get beyond selecting, sorting, and copying, other
> languages have advantages. But you did say "simply". If you get
> complex business rules which need to be maintained, you probably want to
> pick a more English language language such as Cobol. But that is adding
C++ has come a long way. The industry was moving towards the obfuscation
of C (for applications ill suited to the language) and along comes Bjarne
addresses that issue.
The point of the original message was that COBOL is the best for processing
large amounts of data, a proposition most would not agree with.
Mark A. Framness
> COBOL is no doubt the best langauge when it comes to business applications,
> or it was, now with the E-commerce revolution, and demand for OLTP, will
> COBOL and it's Legacy disappear with Batch processing, or are they all to
> stay around even after ebusiness?
> oh, and language does make a difference, COBOL was made for Record I/O,
> where most of the others or made for Stream I/O, is only one of the few
> thing that makes COBOL great for processing your records, no matter the
> system
Why is COBOL a record oriented I/O? Because the hardware it was spawned
from is oriented towards record I/o, no?
What is stopping one from developing libaries in other languages that
simulate COBOLS reocrd oriented I/O? Nothing really, so I say that COBOLS
orientation to record oriented I/O is flows from the environment.
Batch processing? I don't see it entirely disappearing, human factors will
dictate it. It doesn't pay to spit out orders for filling as soon as they
come in. COBOL will not disappear because the mainframe will not. Where I
am currently working they are trying to convert major poritions of their
business (a large outboard, I/O boat motor mfger) to Oracle & AIX. They
gave up in MFG and the Oracle people talk of server crashes from time to
time. The servers that we use to connect to the mainframe are down from
time to time, but I have yet to see my client's legacy system come down.
As far as "e-business" goes, the jury is definitely out on that.
donald tees
Mark A. Framness wrote in message
<8Sd1uPikEGru-p...@www.framnett.net>...
>On Sun, 12 Jul 3900 18:41:24, "Michael Baumli" <mba...@asde.com> wrote:
>
>> COBOL is no doubt the best langauge when it comes to business
applications,
>> or it was, now with the E-commerce revolution, and demand for OLTP, will
>> COBOL and it's Legacy disappear with Batch processing, or are they all to
>> stay around even after ebusiness?
>> oh, and language does make a difference, COBOL was made for Record I/O,
>> where most of the others or made for Stream I/O, is only one of the few
>> thing that makes COBOL great for processing your records, no matter the
>> system
>
>Why is COBOL a record oriented I/O? Because the hardware it was spawned
>from is oriented towards record I/o, no?
>
No. In fact, it was designed to run on the exact same hardware as all
the other languages. It stems from the fact that it was designed for
business, while C was designed to write an OS, and to replace assembler.
(which it does very well). Cobol was designed to handle data bases, which
it also does really well.
Languages tend to be particularly suited to either a top down approach
or to a bottom up approach. Cobol is best used with a top down approach,
which, while suited to business systems, has drawbacks. C is best used
with a bottom up approach, which is ideal for developing programming tools,
but not very good for business systems.
OOP Cobol fills that gap. OOP is particularly suited to designing bottom up
tools for an application. For example, I can take an entire old system, and
very simply convert each Cobol program to a method in one big DLL called
"oldsystem". A completely new system can start off by being able to execute
all parts of the old system as a method. If all my records are COPIES, and
I
add the conversion routines to the new system as methods, then I can run
both old and new on the same software, in parallel, and have the system
test and convert itself dynamically.
I shudder to even think about such an approach with C, for example. The
code
would simply be too complex, and take far too long to write. I could do it,
maybe,
with ten programmers and a year or two. I can do it *alone* in Cobol in
five or
six months. As I sell my software for a fixed price, a cost difference of
several
magnitudes affects my income significantly. Like/dislike has nothing to do
with it, and the fact that students hate having to type 35 letter data names
is
their problem, not mine. If they want to get rich as a programmer, they have
to get over their laziness and deal with reality.
BTW, I have not written for anything but micro's since 1975, and have not
written
a batch program in thirty years. Everything I do is on-line, real time.
Even stuff
like year end programs. Batch/on-line has nothing to do with it.
Pete Wirfs
arguments would not be so volatile.
Every language can claim "best" at something, but this is actually a
moot argument in my opinion. You have to match the language to the
task and the environment that is at hand. And sometimes "best" is not
the correct solution because shop standards may dictate a language
that is more common to that shop. (Common languages are easier to
maintain because you have more staff that are fluent in that
language.)
Pete
On Wed, 12 Jul 2000 18:41:24 GMT, "Michael Baumli" <mba...@asde.com>
wrote:
>COBOL is no doubt the best langauge when it comes to business applications,
>or it was, now with the E-commerce revolution, and demand for OLTP, will
>COBOL and it's Legacy disappear with Batch processing, or are they all to
>stay around even after ebusiness?
>oh, and language does make a difference, COBOL was made for Record I/O,
>where most of the others or made for Stream I/O, is only one of the few
>thing that makes COBOL great for processing your records, no matter the
>system
>
>Mark A. Framness <mfra...@NOSPAM.athenet.net> wrote in message
>news:8Sd1uPikEGru-p...@www.framnett.net...
>> On Sun, 11 Jun 3900 06:06:30, "Mark Muniz" <wht...@flash.net> wrote:
>>
>> > OK! I have opened up so many cans of worms that its not funny anymore.
>I
>> > have been laughed at by people that know and people that are derelicts
>in
>> > the programming field. The question!
>> >
>> > What is the absolute language to program in to simply push data?
>>
>> Ahhhh the makings of a "religious war". Break out of that mode of
>> thinking. Choose a language according to the task and available libraries
>> rather than a fondness or familiarity of one language.
>>
>>
>> >
>> > Simple question for me. I think COBOL! COBOL was built for one
>purpose -
>> > process mass amount of data. By mass amount I mean from 500,000 records
>and
>> > up. Can anyone else shed some more light on this issue? What other
>reason
>> > is there. Can any other modern language come close?
>>
>> Your contention that COBOL is well suited for processing of mass data is
>> slightly off of the mark. What platform are you talking about?
>Processing
>> 500,000 records on a PC in any language is going to take a real long time
>> no matter what language you are using. That same task will be quicker on
>a
>> OS/390 system again, no matter the language.
>>
>> Programming isn't a matter of language as much as logic and process. All
>> languages must do the same things. Get input, process data and output.
>>
>> I like COBOL for its readability and hate it for its universal data
>> visibility.
>>
>>
>>
>>
Howard Brazee
Pete Wirfs wrote:
>
> If we would stop using the statement "best language" then the
> arguments would not be so volatile.
>
> Every language can claim "best" at something, but this is actually a
> moot argument in my opinion. You have to match the language to the
> task and the environment that is at hand. And sometimes "best" is not
> the correct solution because shop standards may dictate a language
> that is more common to that shop. (Common languages are easier to
> maintain because you have more staff that are fluent in that
> language.)
In other words, "best language" is the one which best when evaluated
against various criteria, some which are task related, and some which
are environment related. (Environment can be technical, economical, or
political)
Mark A. Framness
>
> Mark A. Framness wrote in message
> <8Sd1uPikEGru-p...@www.framnett.net>...
> >On Sun, 12 Jul 3900 18:41:24, "Michael Baumli" <mba...@asde.com> wrote:
> >
> >> COBOL is no doubt the best langauge when it comes to business
> applications,
> >> or it was, now with the E-commerce revolution, and demand for OLTP, will
> >> COBOL and it's Legacy disappear with Batch processing, or are they all to
> >> stay around even after ebusiness?
> >> oh, and language does make a difference, COBOL was made for Record I/O,
> >> where most of the others or made for Stream I/O, is only one of the few
> >> thing that makes COBOL great for processing your records, no matter the
> >> system
> >
> >Why is COBOL a record oriented I/O? Because the hardware it was spawned
> >from is oriented towards record I/o, no?
> >
>
> No. In fact, it was designed to run on the exact same hardware as all
> the other languages. It stems from the fact that it was designed for
> business, while C was designed to write an OS, and to replace assembler.
> (which it does very well). Cobol was designed to handle data bases, which
> it also does really well.
COBOL grew up in the IBM mainframe environment. On mainframe systems the
concept of a record is much more concrete than it is on micros (as well as
other largish systems), especially when one is dealing with systems that
IBM provides. You create a dataset you must define a "record length" to
the system. The system does I/O in blocks of records (i.e. a set number)
that you can specify or the system defaults to a value. Now other
languages, e.g. C grew up in a completely different world. The world of
UNIX, the hardware may have been similar but the system is different. You
don't have to pre-allocate datasets (ie files) and one does not specify
record lengths in the UNIX world (at the system level).
>
> Languages tend to be particularly suited to either a top down approach
> or to a bottom up approach. Cobol is best used with a top down approach,
> which, while suited to business systems, has drawbacks. C is best used
> with a bottom up approach, which is ideal for developing programming tools,
> but not very good for business systems.
As far as C being a bottoms up language I would dispute. C++ is definitely
a bottoms up language but C is not.
> I shudder to even think about such an approach with C, for example. The
> code
> would simply be too complex, and take far too long to write. I could do it,
> maybe,
Armed with appropriate libraries or ones created it could be done in C++.
I too would shudder doing such things in C. Funny how everyone was headed
towards C and its terseness and then things are now headed the other way
with C++.
> magnitudes affects my income significantly. Like/dislike has nothing to do
> with it, and the fact that students hate having to type 35 letter data names
Nothing anywhere says COBOL symbols have to be long. It is a matter of
style. I've seen long descriptive symbol names used in C and in C++ and
short cryptic ones in COBOL. Though the fashion in C is often towards
terseness & cypticness.
William M. Klein
news:8Sd1uPikEGru-p...@www.framnett.net...
>
> COBOL grew up in the IBM mainframe environment.
Interesting "statement". I know that IBM tendened to "dominate" the
mainframe world in the early days of COBOL (when "BUNCH" referred to everyone
else). HOWEVER, IBM wasn't the first implementation of COBOL - and never
was the only/primary place that it "grew up".
P.S. I have added comp.lang.cobol to this "thread" - as it is the preferred
NG for COBOL issues.
--
Bill Klein
wmklein <at> ix dot netcom dot com
donald tees
William M. Klein wrote in message <8kofm6$r6b$1...@nntp9.atl.mindspring.net>...
>"Mark A. Framness" <mfra...@NOSPAM.athenet.net> wrote in message
>news:8Sd1uPikEGru-p...@www.framnett.net...
>> On Sun, 13 Jul 3900 12:26:22, "donald tees" <don...@willmack.com> wrote:
>>
> <much snippage>
>>
>> COBOL grew up in the IBM mainframe environment.
>
>Interesting "statement". I know that IBM tendened to "dominate" the
>mainframe world in the early days of COBOL (when "BUNCH" referred to
everyone
>else). HOWEVER, IBM wasn't the first implementation of COBOL - and never
>was the only/primary place that it "grew up".
>
To add to that, I have never programmed on IBM equipment, with the
exception of a contract on a series 1 that I did in PL1. I started Cobol
on a DecSystem10, then a Cyber64, then an H200, then under GCOS.
The first Micro I used it on was an Alto's, running MPM-86, and using
MF Cobol.