What is main difference between C and COBOL
Lianhai Wu
I was asked one question about the difference between C and COBOL. As I
have little knowledge on COBOL, Could you out there please help me on
this problem?
Thanks in advance.
Joe Clune
> I was asked one question about the difference between C and COBOL. As I
> have little knowledge on COBOL, Could you out there please help me on
> this problem?
I have passing knowledge of C, but don't know if I am qualified to
answer, but I will give an answer.
What is the difference between French and Spanish? Each can say the
same thing, get the same point across, but each has different verbs and
different ways those verbs can be used, and where they can be placed in
the sentence. As far as I know ANSI C and COBOL can do the same things,
although sometimes it may take a little more code in one language to do
one thing, but more in the other to do another thing. Also, I think
COBOL makes you define your variables a little more rigidly (the PIC
clause) and I think that is why C can be viewed as more flexible.
Kevin Thompson
On Thu, 13 Mar 1997 17:55:32 -0600, Joe Clune <joec...@netdoor.com>
wrote:
To add my view which has been limited to Cobol in industry but only
C in school, C can easily allow less structure. As a general
statement you can "get away" with more in C which has it's ups and
downs. C is more "powerful" but that can be a flaw in itself.
Cheers,
Kevin
Lee James
On Wed, 12 Mar 1997, Lianhai Wu wrote:
> I was asked one question about the difference between C and COBOL. As I
> have little knowledge on COBOL, Could you out there please help me on
> this problem?
>
> Thanks in advance.
>
>
Well the main difference is that COBOL is easy to understand..
C++ is very difficult to learn especially the graphics side of things.
COBOL as a screen designer and it is easy to do error trapping on the screen
as you can define how long ints and the chars are so they don't go overlap
data on the screen.
C++ you have to build you own screen and you can't do error trapping on
the screen as when you declare an character to have an array of 10 chars
0 - 9 and you type more than 10 chars in.. The program will except it
and it will overlap exisiting data on the screen..
There are loads more differences but I prefer COBOL for database use
and menu use.. And file handling and report making...
But I have to use C++ at Uni
Chris Adams
On Thu, 13 Mar 1997 17:55:32 -0600, Joe Clune <joec...@netdoor.com> wrote:
>> I was asked one question about the difference between C and COBOL. As I
>> have little knowledge on COBOL, Could you out there please help me on
>> this problem?
>answer, but I will give an answer.
>What is the difference between French and Spanish? Each can say the
More like the difference between French and Chinese. There are some
large differences in the 'mindset' of the languages. COBOL trades
flexibility for stability over C. It's also a higher-level language; ever
write a C program that did indexed file operations? You can't just write a
SELECT & FD and start work.
e...@microfocus.com
In <332865db...@news.airmail.net>, kk...@airmail.net (Kevin Thompson) writes:
>On Thu, 13 Mar 1997 17:55:32 -0600, Joe Clune <joec...@netdoor.com>
>wrote:
>
>>> I was asked one question about the difference between C and COBOL. As I
>>> have little knowledge on COBOL, Could you out there please help me on
>>> this problem?
>>
>>I have passing knowledge of C, but don't know if I am qualified to
>>answer, but I will give an answer.
>>What is the difference between French and Spanish? Each can say the
>>different ways those verbs can be used, and where they can be placed in
>>the sentence. As far as I know ANSI C and COBOL can do the same things,
>>although sometimes it may take a little more code in one language to do
>>one thing, but more in the other to do another thing. Also, I think
>>COBOL makes you define your variables a little more rigidly (the PIC
>>clause) and I think that is why C can be viewed as more flexible.
>
>
> To add my view which has been limited to Cobol in industry but only
>C in school, C can easily allow less structure. As a general
>statement you can "get away" with more in C which has it's ups and
>downs. C is more "powerful" but that can be a flaw in itself.
>
>Cheers,
>Kevin
These are, in general, all correct. Certainly both languages offer
all the standard sorts of decision and control flow constructs, and both
do input and output. I'd say the major difference (syntax aside) is that C is
essentially a systems programming language and that COBOL is a business
programming language. COBOL offers a richer set of numeric data types
that are oriented towards business processing and decimal math. C offers
integer and floating point, *neither* of which is appropriate for business.
COBOL also has a much richer set of file capabilities (keyed access, etc.)
You can certainly write business apps in C, by adding decimal math and
keyed file libraries - however, as a developer with extensive C experience
I'd recommend COBOL instead.
On the other hand, C is much more like a
high-level assembler, with all the power and all the opportunities to shoot
yourself in the foot! You *can* write some pretty aggressive systems code
in COBOL, but C is easier...
As a developer, I love C, but I think COBOL is much better for writing
business applications.
John McKellar
LianHai Wu asked:
>I was asked one question about the difference between C and COBOL.
As I
>have little knowledge on COBOL, Could you out there please help me
on
>this problem?
>
>Thanks in advance.
For each of the following points there is probably a dialect
of Cobol where it isn't true (my own experience is mostly with
IBM mainframe Cobol). But in general:
1. In C it is commonplace to allocate chunks of memory
dynamically, stitch them together with pointers, and build
data structures of arbitrary complexity. In Cobol this
technique is either impossible or, if possible, exotic and
little-used. One can still build data structures using
array subscripts in place of pointers, but it's awkward.
2. C allows recursion; i.e. a function can invoke itself,
directly or indirectly. Not in Cobol, though with some
extra work you can simulate recursion if you need a recursive
algorithm.
3. In C you can determine a filename at runtime and open it
as needed. In Cobol the file name (or DD name, etc.) is
specified at compile time.
4. C views a file as a series of bytes; Cobol views it as a
series of records. If your records consists of fixed-length
fields in fixed positions, it's a breeze to read them in
Cobol -- all you need is a single READ statement and every
field is available by name. In C it's a real pain -- one
way or another you have to do it byte by byte. (Yes, I know
you can read or write an entire struct, but the Standard lets
the compiler stick padding bytes between the fields in a
non-portable manner.)
5. Cobol tends to be annoyingly verbose; C tends to be
annoyingly cryptic.
6. In my experience the two languages tend to attract
different kinds of people. Cobol people tend to be less
interested in technical elegance. Maybe this reflects the
difference between the mainframe culture, where Cobol is
King, and the MS-DOS/UNIX culture, with its historical ties
to C.
I don't want to start a holy war -- each language has its
merits. Some things are better done in one and other things
in the other. With a few exceptions either language can do
anything the other can do, but perhaps more awkwardly.
Scott McKellar jm4...@multi.sbc.com
bil...@ibm.net
John,
With MVS COBOL v1.2 on MVS and VisualAge COBOL v1.2 (OS/2, AIX NT...)
which are available since at least one year, I must correct the three
first points of your answer:
1) You CAN dynamically allocate memory with COBOL (Through LE services -
CEECRHP, CEEGTST - on MVS and through arrays with the OCCURS n DEPENDING
ON phrase which now permits to declare variable length arrays in
WORKING-STORAGE You can also use pointers (var USAGE IS POINTER and SET
pointer TO ADDRESS OF var) and SOM methods (somNew, somRenew, somFree)
to allocate memory for COBOL objects and PROCEDURE-POINTER...
2) Those COBOL are recursive (PROGRAM-ID. xxx IS RECURSIVE) and
introduce a LOCAL-STORAGE SECTION that allocate a new area in the heap
for local variables each time a program is called (necessary for
recursivity). They introduce also EXTERNAL (i.e. static) and GLOBAL
variables.
3) You can dynamically open files in VA COBOL with the SELECT ... ASSIGN
USING <var>. You specify at run time the name of the file in <var>. This
is a unique feature of VA COBOL for OS/2. You can also use
SELECT..ASSIGN TO <ext-var> where ext-var is an OS/2 environement
variable that holds the name of the file and can be set just before
running the program...
COBOL is now a much more modern language with the COBOL 1997 standards
and the OO features.
Yours Friendly,
Biloute.
David Sailer
Thanks Scott.
I would add that, because of the differences, COBOL tends to be good at
business oriented problems (banking, insurance, etc) , which also tend
to be record-oriented. COBOL has added features of late that move away
from this paridigm, such as pointer-like abilities (not to the extent of
C), and reference modification, but that doesn't change things much
overall. C tends to be good at technically-oriented problems (CAD/CAM,
desktop apps, embedded systems), where you must drop down to lower
levels of abstraction. IMO, the reason for the cultural differences I
think, is that C programmers like that lower level of abstraction, and
COBOL programmers tend to like the business-level of abstraction more.
IMO, C/C++ does have alot of weaknesses (see
http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3/ ) but it's still out
there and we have to deal with it. I like to encourage people to look at
and consider other options, but unfortunately one of the important
aspects of language selection is the ability to find expertise, so
languages tend to be self-perpetuating.
Dave Sailer
Camp Hill, pa
Richard Plinston
In message <<5gek81$n...@news-c1.gnn.com>> JSMcK...@gnn.com writes:
>
> 1. In C it is commonplace to allocate chunks of memory
> dynamically, stitch them together with pointers, and build
> data structures of arbitrary complexity. In Cobol this
This is the area where many problems occur in C programs. It
is amazingly frquent that memory leaks occur when it is not
deallocated correctly, or 'wild' pointers occur because the
pointer continues to be reused after the memory is deallocated.
Pointers are an area best avoided by inexperienced programmers,
and by those who want to have reliable programs. If they are
to be used then an add-on memory tracker is vital during testing
so the problem areas can be found - they can be very subtle.
> technique is either impossible or, if possible, exotic and
> little-used. One can still build data structures using
> array subscripts in place of pointers, but it's awkward.
In many cases the data structures being built are best held in
a structured file anyway as the data may be shared. Programming
courses tend to focus on single programs but in real usage
several program may be using the data at the same time which is
impossible in dynamic tables within one program.
>
> 2. C allows recursion; i.e. a function can invoke itself,
> directly or indirectly. Not in Cobol, though with some
> extra work you can simulate recursion if you need a recursive
> algorithm.
There are no recursive algorithms which don't have an iterative
equivalent. usually the iteritive one is safer and faster,
though they take slightly more work storing and retrieving
the 'stack'.
>
> 3. In C you can determine a filename at runtime and open it
> as needed. In Cobol the file name (or DD name, etc.) is
> specified at compile time.
I have been specifying filenames dynamically at run time in Cobol
for nearly 20 years with MF Cobol. Most other Cobols on DOS and
Unix can also do this too.
>
> 4. C views a file as a series of bytes; Cobol views it as a
> series of records. If your records consists of fixed-length
> fields in fixed positions, it's a breeze to read them in
> Cobol -- all you need is a single READ statement and every
> field is available by name. In C it's a real pain -- one
> way or another you have to do it byte by byte. (Yes, I know
> you can read or write an entire struct, but the Standard lets
> the compiler stick padding bytes between the fields in a
> non-portable manner.)
>
> 5. Cobol tends to be annoyingly verbose; C tends to be
> annoyingly cryptic.
The crypticness of C is generally countered quite easily by
adding appropriate comments - which then make the program as
bulky as Cobol. I find that comments generally detract from
understanding a program because there is no assurance that
they are true. In general one would tend to believe the
comment rather than understand the code. I tend to write
verbose C with long variable names (no longer limited to 6
characters) and avoiding all the short cuts.
>
> 6. In my experience the two languages tend to attract
> different kinds of people. Cobol people tend to be less
> interested in technical elegance. Maybe this reflects the
> difference between the mainframe culture, where Cobol is
> King, and the MS-DOS/UNIX culture, with its historical ties
> to C.
I have been working exclusively on DOS/Windows/Unix for nearly
20 years primarily in Cobol. There is no 'mainframe culture'
here.
Richard Plinston
In message <<332B13...@ibm.net>> bil...@ibm.net writes:
>
> 3) You can dynamically open files in VA COBOL with the SELECT ... ASSIGN
> USING <var>. You specify at run time the name of the file in <var>. This
> is a unique feature of VA COBOL for OS/2. You can also use
In what way is this a 'unique feature' of VA COBOL ? I have been
using this in MF Cobol for nearly 20 years and MS Cobol has had
a similar feature: VALUE OF FILE-ID IS <var> since version 1.
I am sure that RM and Accu do much the same.
> SELECT..ASSIGN TO <ext-var> where ext-var is an OS/2 environement
> variable that holds the name of the file and can be set just before
> running the program...
This also has been in MF for many years.
Greg Coles
In article <332865db...@news.airmail.net>, kk...@airmail.net (Kevin Thompson) says:
>
>On Thu, 13 Mar 1997 17:55:32 -0600, Joe Clune <joec...@netdoor.com>
>wrote:
>
>>> have little knowledge on COBOL, Could you out there please help me on
>>> this problem?
>>
>>answer, but I will give an answer.
>>What is the difference between French and Spanish? Each can say the
>>same thing, get the same point across, but each has different verbs and
>>different ways those verbs can be used, and where they can be placed in
>>the sentence. As far as I know ANSI C and COBOL can do the same things,
>>although sometimes it may take a little more code in one language to do
>>one thing, but more in the other to do another thing. Also, I think
>>COBOL makes you define your variables a little more rigidly (the PIC
>>clause) and I think that is why C can be viewed as more flexible.
>
>
> To add my view which has been limited to Cobol in industry but only
>C in school, C can easily allow less structure. As a general
>statement you can "get away" with more in C which has it's ups and
>downs. C is more "powerful" but that can be a flaw in itself.
>
>Cheers,
>Kevin
C was created for programmers who can't type.
bil...@ibm.net
Sorry Richard,
The message was not clear enough:
It is a unique feature a IBM VA COBOL for OS/2 compared to IBM COBOL for
MVS.
I do not know any other PC COBOL compiler as the IBM one, so I apologize
for the confusion.
Ross Klate
David Sailer <Dsa...@paonline.com> wrote in article
<332CB4...@paonline.com>...
> John McKellar wrote:
> >
> > LianHai Wu asked:
> >
> > >I was asked one question about the difference between C and COBOL.
snip
> > For each of the following points there is probably a dialect
> > of Cobol where it isn't true (my own experience is mostly with
> > IBM mainframe Cobol). But in general:
> >
snip
> > 2. C allows recursion; i.e. a function can invoke itself,
> > directly or indirectly. Not in Cobol, though with some
> > extra work you can simulate recursion if you need a recursive
> > algorithm.
> >
> > 3. In C you can determine a filename at runtime and open it
> > as needed. In Cobol the file name (or DD name, etc.) is
> > specified at compile time.
> >
2. In Unisys COBOL, a paragraph can perform itself. This can be
recursed until the stack overflows, usually about 50 deep.
3. In Unisys COBOL, you can use run-time task attributes to
change a file-name (or media) at run-time.
John McKellar
In article <332B13...@ibm.net> biloute wrote:
>John,
>
>With MVS COBOL v1.2 on MVS and VisualAge COBOL v1.2 (OS/2, AIX
NT...)
>which are available since at least one year, I must correct the
three
>first points of your answer:
Before claiming to correct me, please do me the courtesy of
reading what I wrote.
I took pains to acknowledge the existence of various
dialects with various special features. I was describing
Cobol as it is commonly and most typically used in practice,
at least in the environment with which I am most familiar.
>
>1) You CAN dynamically allocate memory with COBOL (Through LE
services -
A vendor-specific extension, not generic Cobol.
>CEECRHP, CEEGTST - on MVS and through arrays with the OCCURS n
DEPENDING
>ON phrase which now permits to declare variable length arrays in
>WORKING-STORAGE You can also use pointers (var USAGE IS POINTER
and SET
So far as I know, OCCURS DEPENDING emphatically does not
allocate memory dynamically. It merely applies a upper bound
to a statically allocated array, making the SEARCH verb more
useful. Of course, you may be referring to a variant with
which I am not familiar.
>pointer TO ADDRESS OF var) and SOM methods (somNew, somRenew,
somFree)
>to allocate memory for COBOL objects and PROCEDURE-POINTER...
>
My own Cobol programs have been using dynamically allocated
memory, pointers, and various data structures for years.
I learned these tricks from C, and found ways (and reasons)
to apply them in Cobol. However, I don't know of any other
Cobol programmers in my shop who make any substantial use of
these techniques -- and it's a big shop. I try to evangelize
but no one has shown any interest.
SOM and other trappings of OO Cobol are too new to have
become widely available, much less widely used or even
understood. Likewise for the 97 standard.
>2) Those COBOL are recursive (PROGRAM-ID. xxx IS RECURSIVE) and
>introduce a LOCAL-STORAGE SECTION that allocate a new area in the
heap
>for local variables each time a program is called (necessary for
>recursivity). They introduce also EXTERNAL (i.e. static) and
GLOBAL
>variables.
>
>3) You can dynamically open files in VA COBOL with the SELECT ...
ASSIGN
>USING <var>. You specify at run time the name of the file in
<var>. This
>is a unique feature of VA COBOL for OS/2. You can also use
>SELECT..ASSIGN TO <ext-var> where ext-var is an OS/2 environement
>variable that holds the name of the file and can be set just
before
>running the program...
>
According to your own description, these features are
vendor-specific, and not characteristic of generic Cobol.
>
>COBOL is now a much more modern language with the COBOL 1997
standards
>and the OO features.
>
Agreed -- Cobol is gradually acquiring the capabilities that
were present in C from the beginning, and in some cases C++.
I haven't noticed any tendency for C or C++ to adopt Cobol's
features.
I welcome the new features, and I look forward to using
them. However, if you take a job in a mainframe Cobol
shop, you will probably find your coworkers writing Cobol
much the same way it was written ten years ago, or twenty.
No doubt there are exceptions. In particular, the Cobol
culture may be different outside of the mainframe world;
I can't say.
Believe it or not, I am not a C bigot. Among C bigots I
typically defend Cobol. Nevertheless, Cobol ***as typically
practiced*** has a very different flavor from C. It is that
difference which I tried to convey.
>
>John McKellar wrote:
>>
snip -- the original poster asked about the difference
between C and Cobol. Please note the qualification at
the beginning of my reply, following:
>> For each of the following points there is probably a dialect
>> of Cobol where it isn't true (my own experience is mostly with
>> IBM mainframe Cobol). But in general:
>>
>> 1. In C it is commonplace to allocate chunks of memory
>> dynamically, stitch them together with pointers, and build
>> data structures of arbitrary complexity. In Cobol this
>> technique is either impossible or, if possible, exotic and
>> little-used. One can still build data structures using
>> array subscripts in place of pointers, but it's awkward.
>>
>> 2. C allows recursion; i.e. a function can invoke itself,
>> directly or indirectly. Not in Cobol, though with some
>> extra work you can simulate recursion if you need a recursive
>> algorithm.
>>
>> 3. In C you can determine a filename at runtime and open it
>> as needed. In Cobol the file name (or DD name, etc.) is
>> specified at compile time.
>>
>> 4. C views a file as a series of bytes; Cobol views it as a
>> series of records. If your records consists of fixed-length
>> fields in fixed positions, it's a breeze to read them in
>> Cobol -- all you need is a single READ statement and every
>> field is available by name. In C it's a real pain -- one
>> way or another you have to do it byte by byte. (Yes, I know
>> you can read or write an entire struct, but the Standard lets
>> the compiler stick padding bytes between the fields in a
>> non-portable manner.)
>>
>> 5. Cobol tends to be annoyingly verbose; C tends to be
>> annoyingly cryptic.
>>
>> 6. In my experience the two languages tend to attract
>> different kinds of people. Cobol people tend to be less
>> interested in technical elegance. Maybe this reflects the
>> difference between the mainframe culture, where Cobol is
>> King, and the MS-DOS/UNIX culture, with its historical ties
>> to C.
>>
>> I don't want to start a holy war -- each language has its
>> merits. Some things are better done in one and other things
>> in the other. With a few exceptions either language can do
>> anything the other can do, but perhaps more awkwardly.
>>
>> Scott McKellar jm4...@multi.sbc.com
Scott McKellar jm4...@multi.sbc.com
(John is my first name but I go by my middle name.)
jok...@mailhost.wolfenet.com
The Programmer
I've never had any need to use recursion in COBOL, so I have no idea whether
it's even possible.
In VAX/COBOL, the name of an external data source can be set at run time using
either the $DEFINE before running the executable, or, by setting the data
source name within the program by moving a value to the variable assigned to
the VALUE OF ID clause before opening the file. This has been part of standard
VMS since I first starting using VAX/COBOL back in 1982.
In COBOL/400, either change the library list (EDTLIBL), or issue an OVRDBF
prior to calling the program object. If you want to set the data source from
within the program, issue a call to QCMDEXC containing the OVRDBF command prior
to opening the file -- just don't forget to call QCMDEXC containing the DLTOVR
command after closing the file!
There was also a question about being able to allocate memory dynamically. As
far as I know, in VAX/COBOL this would have to be done using system services,
but I've never done that, so I can't provide any details. With COBOL/400, I've
issued calls to CRTUSRSPC, CHGUSRSPC, and DLTUSRSPC to dynamically allocate RAM
as needed. Unfortunately, under OS/400, this is a very slow and miserable
method. Much better to dynamically create a physical file in the QTEMP area,
and use that as a dynamic array (or table). Since the AS/400 is designed to be
an I/O machine, the resulting access speed can be dramatic.
--
The Programmer Has Spoken -- SO THERE!
Ross Klate <Kl...@spartan.com> wrote in article
<01bc3487$e7ded120$8101...@MIS-RKW95.spartan.com>...
>
>
> David Sailer <Dsa...@paonline.com> wrote in article
> <332CB4...@paonline.com>...
> > John McKellar wrote:
> > >
> > > LianHai Wu asked:
> > >
> > > >I was asked one question about the difference between C and COBOL.
> snip
> > > For each of the following points there is probably a dialect
> > > of Cobol where it isn't true (my own experience is mostly with
> > > IBM mainframe Cobol). But in general:
> > >
> snip
> > > 2. C allows recursion; i.e. a function can invoke itself,
> > > directly or indirectly. Not in Cobol, though with some
> > > extra work you can simulate recursion if you need a recursive
> > > algorithm.
> > >
> > > 3. In C you can determine a filename at runtime and open it
> > > as needed. In Cobol the file name (or DD name, etc.) is
> > > specified at compile time.
> > >
Tim Oxler
hard...@yhc.com (Greg Coles) wrote:
>C was created for programmers who can't type.
That explains why it takes me so long to write a Cobol program!
Wouldn't it be nice if part of the Cobol 97 standard would be to add
PERFROM and ESLE as legal statements.
Or better yet a Cobol spellchecker! :)
Tim Oxler
TEO Computer Technologies Inc.
tro...@i1.net
http://www.i1.net/~troxler
http://users.aol.com/TEOcorp
Willy
Borland's BRIEF editor provides a COBOL template. Just press "P", hit
the spacebar, and out pops
PERFORM [c]
END-PERFORM
or "m" and space give you
MOVE [c]TO
What more could you want?
([c] is the cursor)
John Stevenson
Lianhai Wu wrote:
>
> I was asked one question about the difference between C and COBOL. As I
> have little knowledge on COBOL, Could you out there please help me on
> this problem?
>
Cobol is a procedral language and C is an object language.
John Stevenson
S. Cross
C does not provide built-in support for classes, inheritance and other
object-oriented concepts (C++ is another matter); on the other hand there
are object-oriented COBOL standards and implementations. So I would say
that this statement is the exact opposite of the truth....
John Stevenson <jstv...@toccoafalls.edu> wrote in article
<33421B...@toccoafalls.edu>...
Theo DP
Wrong-O...C is by no means an object language (it's successor, C++, takes
a stab at objects).
C is a somewhat primitive language (perhaps named after a grade its
compiler designer received?) that was kept simple for portability
purposes. It does provide lower level access to operating system
functions via features like pointers and has a more terse syntax than
COBOL.
Unfortunately, its simplicity means that it also lacks many of the COBOL
features that C devotees ridicule, perhaps without realizing how useful
they are can be for "real" systems. Built-in features taken for granted
in COBOL (string data types, decimal numbers and arithmetic, string
compares and moves, sort, search, sequential and keyed I-O) are not part
of the base C implementation and are only available from add-in functions,
class libraries, etc.
As such, you'll find that while "leading edge" companies (e.g.,
PeopleSoft) may use C for the user interface, they turn to COBOL for the
"meat" of their system.
Binyamin Dissen
On Wed, 02 Apr 1997 03:41:46 -0500 John Stevenson <jstv...@toccoafalls.edu>
wrote:
[Posted and mailed]
:>Lianhai Wu wrote:
:>> I was asked one question about the difference between C and COBOL. As I
:>> have little knowledge on COBOL, Could you out there please help me on
:>> this problem?
:>> Thanks in advance.
:>Cobol is a procedral language and C is an object language.
No. C is a procedural language as well. C++ and Object Cobol are OO languages.
Cobol is, in my humble opinion, a better language for file processing or
standard business applications. It is also a little more readable to the
non-programmer. C seems to be better in math and more complex programming.
Cobol has a lot more support in the 370 world. C has a lot more support in the
PC world.
:>John Stevenson
--
Binyami...@theoffice.net
Binyamin Dissen <bdi...@netvision.net.il>
Director, Dissen Software, Bar & Grill - Israel
J. Turincs
Binyamin Dissen wrote:
>
> On Wed, 02 Apr 1997 03:41:46 -0500 John Stevenson <jstv...@toccoafalls.edu>
> wrote:
>
> [Posted and mailed]
>
> :>Lianhai Wu wrote:
>
> :>> I was asked one question about the difference between C and COBOL. As I
> :>> have little knowledge on COBOL, Could you out there please help me on
> :>> this problem?
>
> :>> Thanks in advance.
To the original author ... COBOL (COmmon Business-Oriented Language) was
developed in the late 60's? as a general business programming language.
As some of the other threads mention, the language is based on record
and/or file type processing. The language constructs were originally
very English-like in syntax (e.g. MOVE ZERO TO MYFIELD - the equivalent
in C would be c = 0;). COBOL supports many complex data structures such
as arrays, matrices, etc., and all of the "basic" types (e.g. Character
strings, integers, etc.). The newest versions of the language now
supports additional types such as pointers, but this has been a
relatively recent development (last 2-3 years); and as mentioned, there
are now variants which support object-oriented conventions (although I
have yet to see a good implementation of it). COBOL is also a
"columnar" language in that certain characters in certain columns
(usually columns 1 through 8, and 72 through 80) have special
significance to the compiler. In addition, COBOL programs are broken
down into "divisions" and "sections"; most programs have a
IDENTIFICATION division where variables, I/O, and data structures are
defined.
C on the other hand, was designed for more complex computing. It is a
"terse" language (as opposed to COBOL being a "verbose" language) and
its original keyword set was very small. Again, as mentioned, C is not
an object-oriented language, but C++, which was meant to retrofit object
orientation onto the C language, does maintain many of the traits of an
"object-oriented language". C is also a "free-format" language where
COBOL source code is more rigidly constrained.
Some Additional Examples:
Desc: Loop from 1 to 3
COBOL: PERFORM X100-MYLOOP VARYING MYINDEX FROM 1 BY +1 UNTIL MYINDEX >
3
C: for (myindex=1; myindex > 3; myindex);
> :>Cobol is a procedral language and C is an object language.
>
> No. C is a procedural language as well. C++ and Object Cobol are OO languages.
>
> Cobol is, in my humble opinion, a better language for file processing or
> standard business applications. It is also a little more readable to the
> non-programmer. C seems to be better in math and more complex programming.
>
> Cobol has a lot more support in the 370 world. C has a lot more support in the
> PC world.
>
> :>John Stevenson
>
> --
> Binyami...@theoffice.net
> Binyamin Dissen <bdi...@netvision.net.il>
>
> Director, Dissen Software, Bar & Grill - Israel
--
+-----------------------------------------------------------
| J. Turincs - Database and Operating systems
| Mainframes and PCs
+-----------------------------------------------------------
InstrJCC
Cobol is a procedural language that was designed as a high level language
for use in business application development. It introduced the use of
records (later called structures ) to programming and performs accurate
decimal arithmetic on numbers up to 18 digits in length.
C is a functional, mid-level language developed to facilitate the writing
of portable operating systems; the success of the UNIX O/S is due in part
to this portablility.
By functional I mean that segments of code ( functions ) can be written in
C that return values such that they can be used as part of an expression.
In the example
x = 3 * ( sin(y) + 2 ) the function sin behaves as would its
counter part in math. Complex expression can be built up using
combinations of operators, variables and functions.
C++ is C with Object-oriented extensions and minor modifications in the
syntax rules that provide for stronger type checking otherwise it
resembles C to a great extent.
Regards,
Jim Castro
Bradley Swan
What is the difference. Simple. C is written by people who came
out of Uni after 1989 and Cobol is written by everyone else.
Cobol is written by programmers on Mainframes and C is written by
programmers on mid-range/workstation machines. C programmers
are stupid and think that Cobol programmers are even stupider.
Cobol programmers are older and stupid and think C programmers
and younger and more stupid. And to cap it all off Java
programmers want to know what all this fuss about C and Cobol
is about because Java is the only true programming language.
If it is of any help (which it won't be) C and Cobol and Java all
have one thing in comon with other computer languages, they let
designers and programmers implement business rules incorrectly.
You see you can write a program to pay an invoice in any of the
above languages and still get it wrong.
In other words the language has no impact, if you're dumb in
Cobol then you'll still be dumb in C or C++ or Java.
It's just that C programmers reckon there's more dumb people
doing Cobol than there is doing C.
:-)
Dave Parker
In article <5i4s47$32k...@cpe.Sydney.aone.net.au> b.s...@acslink.aone.net.au (Bradley Swan) writes:
[...text deleted...]
>It's just that C programmers reckon there's more dumb people
>doing Cobol than there is doing C.
Which is probably a pretty safe assumption given the ratio of COBOL
programmers to C programmers.
--
Dave Parker dlpa...@dlpinc00.com
noone
on Sat, 05 Apr 97 06:40:07 GMT, an infinite number of monkeys calling
themselves b.s...@acslink.aone.net.au (Bradley Swan) wrote:
I know that it's probably dumb to jump into a flame war like this, but
>What is the difference. Simple. C is written by people who came
>out of Uni after 1989 and Cobol is written by everyone else.
C has been around since the early 70's.
>Cobol is written by programmers on Mainframes and C is written by
>programmers on mid-range/workstation machines. C programmers
I've seen some nice COBOL compilers for mid-range computers
(ACU-COBOL comes to mind)
>are stupid and think that Cobol programmers are even stupider.
>Cobol programmers are older and stupid and think C programmers
>and younger and more stupid. And to cap it all off Java
>programmers want to know what all this fuss about C and Cobol
>is about because Java is the only true programming language.
>If it is of any help (which it won't be) C and Cobol and Java all
>have one thing in comon with other computer languages, they let
>designers and programmers implement business rules incorrectly.
>You see you can write a program to pay an invoice in any of the
>above languages and still get it wrong.
>In other words the language has no impact, if you're dumb in
>Cobol then you'll still be dumb in C or C++ or Java.
>It's just that C programmers reckon there's more dumb people
>doing Cobol than there is doing C.
>:-)
There is a fairly large fundamental difference in the two languages.
It stems from their origins. Cobol was developed long before my time
for business/financial/data processing applications. C was developed
by Operating Systems programmers to allow them some high level
constructs but still have low level access to their hardware. Both
languages have evolved over the years.
--
/* the word SPAM is added to my email */
/* address to avoid bulk mailers */