Linux.com

Feature: Linux

Test drive: theKompany's version of COBOL looks promising

By on June 21, 2002 (8:00:00 AM)

Share    Print    Comments   

- By Joe Barr -
Not long after seeing KOBOL mentioned in an online news story, I was visiting theKompany.com to take a look. That's right, KOBOL. As in Common Business Oriented Language. Echos of Amazing Grace, punched cards, and Gene Amdahl. It was strange to see a classical batch offering from the master of object-oriented rock 'n' roll, Shawn Gordon.
Speaking of classical batch, batch processing is about all you can do with KOBOL. Because other than displaying messages at the console, there isn't much interactivity available. At least not yet. But murmurings on the KOBOL mailing list indicate there may be a GUI in KOBOL's future.

KOBOL is pretty bare-bones in its current form, but the price is low. Microfocus, long the acknowledged king of COBOL for personal computing, goes for about five large. It cost me $39.95 for the download version of KOBOL. You can download a free evaluation copy of KOBOL from this page, and the current version is 1.0.2.

Installation in Linux -- Windows 98 through XP are also supported -- is no more involved than decompressing the download file and running the install script. Once that is done, entering KOBOL from the command line brings up the KOBOL IDE seen below.

It's been a few years -- five to be exact -- since I've coded in COBOL. So one of the first things I needed as I played in KOBOL's IDE was a manual. A COBOL language manual. But there isn't one included. The KOBOL "manual" includes some important information, but it is hardly more than a README. And its goal is not to provide a handy reference for writing COBOL code, in any case.

That's OK. I knew I could find some COBOL source code laying around on the Internet, so that's exactly what I did. When I tried to compile the first sample program I found and saved, however, the IDE threw a fit. It wants line numbers in columns 1 through 6, if you please. The sample code had no line numbers at all.

I did manage to tinker with some of the example code, as well as a program sent on the KOBOL mailing list for debugging. I also learned on the mailing list that it takes a little trick to properly read/write lines of text. I created an input file using vi that looks something like this:

1352 06/03/02 017276 ACE PLUMBING
1353 06/03/02 008290 PETS R URS
1354 06/04/02 001355 DAILY TIMES
1355 06/04/02 021912 AUTO REPAIR CENTER
1356 06/04/02 007422 BIG DADDY'S RESTAURANT
1357 06/05/02 042032 ELECTRIC COOP
1358 06/05/02 003872 DEATH STAR PHONE CO

In my KOBOL source code, I defined the file as:

000230 SELECT INFILE ASSIGN TO "input".
...
000305 FD INFILE
000306 RECORD CONTAINS 50 CHARACTERS
000307 LABEL RECORDS ARE STANDARD.
000308 01 IN-REC.
000309 05 FILLER PIC X(50).

The output file was similar. But the point is that because of the way KOBOL currently handles the newline character, the input gradually drifted off -- byte by byte -- from matching up with the input records. Shawn Gordon, founder of theKompany.com and chief architect of KOBOL, posted a workaround for the problem. His suggestion, modified to fit the example above, is to create and export an alias for "input" in your shell as in:

infile=infile.dat,L

It works. Gordon notes that future releases of KOBOL will allow files to be declared as LINE SEQUENTIAL, so the workaround won't be necessary. It is heartening to see Gordon and his developers participating on the KOBOL mailing list to address customer worries, questions, and concerns.

The more I hacked around with the code, the more I found that I needed a programming manual for the tool. It's been years since I've seen my IBM mainframe COBOL books, and although I still have a handy copy of Rodney Zak's tome on Z80 programming, unused now for 20 years, I couldn't find anything at all to help me with COBOL.

It's not so much that I need the manuals in order to learn how to write COBOL code, it's because I don't remember what was an IBM (or other vendor's) extension to COBOL, which KOBOL wouldn't claim to support, and what was part of the ANSI standard, which they do claim to support. I would rank the need for a KOBOL programming manual right up there at the top of the "needs" list, and I hope theKompany responds. It would very definitely make the product more usable.

The second most needed enhancement to KOBOL, to my way of thinking, is the ability to more gracefully interact with the user. This may be coming down the road as a "plug-in." I asked Gordon if there were plans for a "screen painter" for KOBOL and he replied that they had something in mind that goes far beyond a mere "screen painter." That's fine. But the lack of even rudimentary screen handling is another shortcoming that limits what can be done with KOBOL today.

At this point, KOBOL's strength is its IDE. It's fast, fairly intuitive, and it lets you do editing, compiles, and test runs from within. I'm sure it has other worthwhile attributes as well, but I haven't yet had time to fully explore them. I'm more used to using a chisel to write COBOL than an IDE, anyway.

I don't know where I picked up the idea, but after a few days on the mailing list I was under the impression that KOBOL had started life elsewhere and then had come under theKompany.com's umbrella. This is not the case, however. Open COBOL, another PC COBOL project, is a continuation of Tiny COBOL, and like its predecessor it converts COBOL source to C prior to compiling. KOBOL follows a similar strategy, but uses C++ instead of C. Gordon said he actually began the KOBOL project before founding theKompany.com.

The bottom line is that you can get real work done with KOBOL today, but it isn't a finished, polished, or mature product just yet. It's an important product to Gordon, however, and that bodes well for its future. Gordon told me that he has always wanted KOBOL to be as easy to use as VB (Visual Basic), except with a COBOL syntax. It's not there yet, but the foundation is in place.

Share    Print    Comments   

Comments

on Test drive: theKompany's version of COBOL looks promising

Note: Comments are owned by the poster. We are not responsible for their content.

why is cobol still alive?

Posted by: Anonymous Coward on June 21, 2002 09:15 PM
This, the Fujitsu .NET extension (that's a stupid computer trick if ever there was one); why do people insist on providing any kind of support for the language?

Let's kill COBOL, it's well outlived its usefulness. It sucks, we have better languages now. Concentrate on things that better the world, not perpetuate previous sins.

#

Re:why is cobol still alive?

Posted by: Joe Barr on June 21, 2002 09:36 PM
COBOL is still alive because nothing good enough to replace it has come along. No, it's not the best thing around for PCs, but there is life in those old mainframes yet.

Crunching payrolls, massaging huge databases, creating reams of reports every night. It's the best choice for those tasks, bar none. Period. It's the best. Nothing compares. No competiton.



It would be worse than stupid to try and replace those programs with C, or C++, or (insert your fave language here). It would be criminally negligent.

COBOL will die when mainframe/batch processing dies. PC types have been predicting that was gonna happen RSN for the last 20 years.


See ya,
Joe Barr

#

Because it is still bringing home the bacon!

Posted by: Anonymous Coward on June 21, 2002 10:25 PM
Because it's still making people money! There are a lot of cobol programs out there and it is not cost effective to recode working programs in another language even when the new language is better. It will be very hard to convince the beancounters in any company that a code rewrite is needed when the old software is bringing in millions of dollars every day. Don't get me wrong, I hate cobol just as much as any other sane programmer out there, but the fact is that cobol is here and it's not going anywhere.

#

Re:why is cobol still alive?

Posted by: DCallaghan on June 21, 2002 10:26 PM
I'm not sure how many people will start coding new projects in COBOL, but I'm sure there's enough legacy code on legacy hardware to go to the moon and back.

And no, the easy answer is not to rewrite all that legacy code. COBOL runs a lot of mission-critical banking applications. A rewrite would not be trivial.

#

Re:why is cobol still alive?

Posted by: Anonymous Coward on June 22, 2002 02:36 AM
There's an interesting fact about new development projects and the languages they use that's pretty much stuned everyone who has seen the numbers (at least anyone who doesn't work in the real world). Everyone knows that there are more COBOL programes already ini production than all other languages combined. However, most people don't realize that, for new development projects, COBOL is only out paced by the combination of C & C++. And it's a very close second. Stats on this were published in the magazine Application Development Trends.

COBOL is far from dead and the money is not strictly in maintaining old code.

#

Re:why is cobol still alive?

Posted by: DCallaghan on June 22, 2002 05:40 AM
That is interesting. I have worked in the real world for a very long time and no one has come to me for a new COBOL project in a long while, though I imagine this is not true for you. And to further correct myself*:

There are between 2 and 3 million COBOL programmers in the world, up to 2 million in the US alone

The estimates range up to 200 billion lines of existing COBOL code, which is about 30 million man-years (6000 to 7000 lines of finished, tested and implemented code per year)

A December 1999 report from the Gartner Group says that over 50% of all new mission-critical applications are still being done in COBOL

I'm glad to hear COBOL isn't dead. I was a fan when I used it, it saved me from counting columns in RPG and I have no reason to see it go away.

Out of curiosity ...
Where are the bulk of these new projects coming from? Have you worked with any of the projects that run COBOL in a Java runtime? Have you tried it with .NET? Do you use OO COBOL?

* http://www-106.ibm.com/developerworks/linux/librar y/cobol/?dwzone=linux

#

Re:why is cobol still alive?

Posted by: Anonymous Coward on June 21, 2002 10:59 PM
Business needs to do a lot of:


    1) Fixed point arthmetic (adding money),

    2) Boring, flat (at best heirarchical) data processing, and

    3) Report generation.

COBOL is good for all 3. Bean counters can verify the code because the language is verbose.

COBOL isn't going to die any time soon, and yes, there are new projects started in the language all the time.

#

Re:why is cobol still alive?

Posted by: Anonymous Coward on June 22, 2002 02:20 AM
I don't mind people who have an opinion for or against a subject. I do, however, mind when they assert their opinions without having any clue on the topic they are opining on. The reason COBOL has not gone away is because there is no better language for doing what COBOL does. It is the best at processing data. COBOL is also an evolving language and now has better object orientation extensions than C++. Please, next time you wish to make a statement on a subject take the time to learn a little about it before making your comments.

#

Re:why is cobol still alive?

Posted by: Dave Parker on June 22, 2002 05:16 AM
Yes, COBOL is an evolving language, and mainframes are an evolving platform. I would say that COBOL and the mainframe of 20 years ago are dead, but their are still a TON of applications that were written 20 years ago that are still running, and even some mainframes that are that old. Not only banking, but telecommunications billing, insurance, large payroll and accounting apps - to name only a few - are written in COBOL and running on mainframes. I'm sure practically anyone out there can think of similar applications written in 'modern' languages that reliably process much smaller volumes of data, but I'm talking industrial strength volumes here. COBOL is far from dead, and the mainframe is far from dead. People who make comments to the effect that 'COBOL is dead' or 'COBOL should be replaced', etc. have absolutely no concept of the kind of environments COBOL runs in and the heavy lifting that it does.

To say that a full-size White Freightliner is an excellent vehicle for hauling tons of freight down the highway is not the same thing as saying that the automobile is dead. The right tool for the right job.

#

Re:why is cobol still alive?

Posted by: Anonymous Coward on June 25, 2002 09:58 AM
It is typical to see these comments like COBOL sucks and so forth. Having been developing for many years in C, Fortran, COBOL and others, I would very much like to see a decent COBOL compiler for running batch file processing. It is possible to knock up these programs to run reliably for years in COBOL with very little time. C and Fortran are more processor intensive languages and are just not suited to quickly knocking up, say, an ISAM file.

#

GUI capability

Posted by: Anonymous Coward on June 21, 2002 10:42 PM
Joe's comments are honest. In the next release after the one coming out on Monday we are going to add the "DISPLAY AT coordinates" ability to give basic screen capability. The COBOL standard has something called a SCREENS-SECTION which is essentially a block mode 80x24 screen that you can display and accept. Not all compilers support this section, but we are looking at how best to do it, we will likely do an interface to Qt in 2 phases, the first will be to map the SCREENS-SECTION and the second will be the ability to directly interface to Qt from COBOL, which is another advantage of our OO language translator.

Shawn Gordon
President
theKompany.com

#

Re:GUI capability

Posted by: Anonymous Coward on June 21, 2002 11:32 PM
hehe... you going to add CICS access as well?

#

Re:GUI capability

Posted by: Anonymous Coward on June 22, 2002 02:30 AM
Man, if there was a way to get CICS on Linux it would be the killer app that would totaly wipe Windows off the face of the data center and server world. Right now there is no petter TP than CICS. And this means that Linux has no really good TP. If Linux did have a solid, stable, fast TP like CICS we would truly achieve world domination.

#

Re:GUI capability

Posted by: Anonymous Coward on June 22, 2002 05:34 AM
if there was a way to get CICS on Linux it would be the killer app that would totaly wipe Windows off the face of the data center and server world. Right now there is no petter TP than CICS.

Have you looked at MicroFocus COBOL? Expensive, but, since their bread and butter are (1) allowing mainframe development and (2) migration paths off mainframes, I wouldn't be surprised if they have a CICS emulator.

#

TP capability

Posted by: Anonymous Coward on June 22, 2002 05:46 AM
actually on M/F, either the kernel or the VM ( for IBM) are transactions aware- that would be an unnecessary baggage on the kernel.

M/F exist solely for TP so it works out- they do not deal with video, audio, USB blah blah devices. On linux systems, reliability is better achieved thru clustering such as beowulf ( due to extra points of failure on kernel). With that, TP has to be at the application level.

M/F architecture was OK for that time- it is unnecessary today. Network is the computer so why go back to proprietary buses and protocols ?

#

Re:GUI capability

Posted by: Anonymous Coward on June 22, 2002 08:15 AM
> Have you looked at MicroFocus COBOL?



Yes, they do have a CICS implimentation but, aside from the exorbatent fees they don't have a Linux version.

#

Re:GUI capability

Posted by: Anonymous Coward on June 23, 2002 05:48 PM
MicroFocus has a COBOL for LINUX by now.

#

Re:GUI capability

Posted by: Anonymous Coward on June 22, 2002 08:41 AM
Shawn You seem to have a nac for filling real needs. Since it takes 10 years or so for a code base to become mature (don't kick me for it being 9 sometimes ) You have taken on a much needed task. Make Linux (10 years old by the way) capable of handling some of the multitudes of legacy procjects used and needed daily. Congrats on the product. You've touched a real world sweet spot with this one.

James

#

Re:GUI capability

Posted by: Anonymous Coward on June 23, 2002 08:59 PM
I've always found the SCREENS-SECTION to be an extremely poor way of accepting input. If you really want to see a great way painting a screen, you should check out GUI Screen-IO from the Norcom people at www.screenio.com

This product (written in COBOL...) is just amazing. This would be a great port...

#

my response

Posted by: Anonymous Coward on June 22, 2002 01:17 AM
What the hell? Why have you done this?

#

Re:my response

Posted by: Anonymous Coward on June 22, 2002 02:26 AM
Do you mean why has the Kompany released this product? Because there is a very great need for it. Because it's a great program. Because it's time to get the most powerfull language for processing data into the reach of normal programmers of the world (I personally couldn't swing the $2500 to $5000 for a good COBOL devel tool that other companies sell).

That's some of the reasons.

#

Re:my response

Posted by: Anonymous Coward on June 24, 2002 11:06 PM
I suggest you seek mental help.

#

Line numbers?!?

Posted by: Anonymous Coward on June 22, 2002 05:37 AM
> That's OK. I knew I could find some COBOL source code laying around on the Internet, so that's exactly what I did. When I tried to compile the first sample program I found and saved, however, the IDE threw a fit. It wants line numbers in columns 1 through 6, if you please. The sample code had no line numbers at all.

Joe, you sure you were working in KOBOL and not KOBASIC? ;-)

I did some COBOL too, back when (..and it's been a while), and don't remember ever needing line numbers in any environment. Any ideas where Shawn G got that idea?

#

Re:Line numbers?!?

Posted by: Anonymous Coward on June 22, 2002 06:02 AM
COBOL has line numbers in the first 6 chars, some systems and editors display them and some don't, but they are there. We are going to hide it in our new release on Monday

#

Re:Line numbers?!?

Posted by: Anonymous Coward on June 23, 2002 06:27 PM
Re: Line numbers in cobol.
Please make it optional. I have written a few hundred COBOL programs and none of them have line numbers. With Vim as editor I never felt the need.

#

Re:Line numbers?!?

Posted by: Anonymous Coward on June 22, 2002 08:19 AM
> Any ideas where Shawn G got that idea?

It's part of the standard, AFAIK. Most IDE's either hide or automatically put them in.

#

Re:Line numbers?!?

Posted by: Anonymous Coward on June 22, 2002 12:20 PM
I've still got several boxes of sample code.
Have you got a card reader handy :^)

Regards

cww

#

Re:Line numbers?!?

Posted by: Anonymous Coward on June 25, 2002 10:58 PM
Hmm. It's been a while (7 years), and I couldn't remember whether the line numbers in cols 1-6 were required ... they don't seem to be, but then I'm looking at old OS/VS COBOL that's been translated to Microfocus. There are also optional sequence numbers in cols.73-80.

Oh, happy memories of 31T4, back in 1987 ... zone 1... zone 2... sequence numbers ... meanwhile, I'm looking at some 1991 code ... quote "some fairly nasty code, but I'm just back from the sick" unquote ..!

Memories are made of this. Some days you wish you were amnesiac, mind !

- T

#

anti-COBOL prejudice unfounded

Posted by: DCallaghan on June 22, 2002 05:55 AM
After reading the article and remembering doing COBOL a while ago, I though (and commented) that KOBOL would be great for migrating legacy applications. Its been such a while since I've used it, and it gets such a bashing in the press, when it gets mentioned at all, that I started to develop opinions not based on fact.

So I was corrected and redirected, and after doing a little research, I found out how much COBOL has grown since I've used it last and how widespread its popularity and growth are. This isn't due to marketing hype (obviously), but due to the fact that it does what its supposed to do very well.

I code a lot of business applications and I'd be glad to have COBOL back in my toolbox again.

#

Why KOBOL?

Posted by: Serge Wroclawski on June 22, 2002 07:02 PM
Why the heck not just use or contribute to a Free Software COBOL compiler rather than contributing to this non-free thing? <A HREF="http://cobolforgcc.sourceforge.net/">http://cobolforgcc.sourceforge.net/</a sourceforge.net>



- Serge Wroclawski

#

Re:Why KOBOL?

Posted by: DCallaghan on June 23, 2002 02:21 AM
Good point and your concern is understandable. If you only use GNU applications, and many do, the TheKompany's products would not be for you. They are open source but they are not licensed under the GPL. http://www.thekompany.com/products/licensing.php3

In fact, their licensing resulted in the split of the Quanta project. The lead developer stayed on the SourceForge project, which is a licensed under the GPL, while most of his team went to TheKompany to develop QuantaGold. (I use the SourceForge version.)

The GPL COBOL projects include COBOL For GCC and TinyCOBOL. Both aim at producing a compiler which is COBOL 85 standard compliant. Both are pre-alpha.

KOBOL is fully ANSI COBOL compliant and has implemented the full Object Oriented extensions to COBOL that were just recently finalized by the ANSI committee. Its currently shipping a production version.

I am evaluating all of the Linux COBOL alternatives: open source and free software. I would use the software that was most fitting to the task I had at hand, which means at some point I might use one, all or none of these. Even if I used COBOL, it would be sparingly, so I would probably never contribute to the project.

#

Re:Why KOBOL?

Posted by: Anonymous Coward on June 23, 2002 11:42 AM
I need to correct something here about Quanta. The "developer" that didn't work for us is Eric Laffon, who never in fact wrote any code whatsoever for the Quanta+ project, he simply provided direction at times and some small financial support, but at no time and in no way was he ever a developer at any time, he came in to the project after it had been on going for some time. Dimitry and Alex started the project, and wrote the whole project and finally had to start a new source forge project to keep the original Quanta+ up to date because Eric blocked them out of supporting the original code. Despite everything that Eric has promised over the last 18 months, it has resulted in approximatly 8 hours of actual coding on the project.

#

Re:Why KOBOL?

Posted by: DCallaghan on June 25, 2002 07:10 AM
Thank you for your side. I was quoting the press release on Quanta's SourceForge page. I appreciate your clarification.

#

Re:Why KOBOL?

Posted by: Anonymous Coward on June 24, 2002 10:33 AM

> The GPL COBOL projects include COBOL For GCC and

> TinyCOBOL. Both aim at producing a compiler which

> is COBOL 85 standard compliant. Both are pre-alpha.




There's also Open Cobol. It's on freshmeat.



FWIW, I agree that the Software Libre tools have a place. I can see myself using them for some tasks but Kobol really is very good. I need to get a book on the OO additions of COBOL. The last time I really used it was about a decade ago (VS COBOL II under MVS on an IBM 3090). Man, those were some fun days. I was a JCL uber-guru back then. ;-)

#

*wibble*

Posted by: Anonymous Coward on June 22, 2002 12:02 PM
{twitch} Please... make it stop, mommy.

Ye flippin' gods. I took Cobol last semester at uni and I still freak a bit whenever I see code or hear it mentioned. And to think people /like/ this abominable language.

*wibble*

#

Re:*wibble*

Posted by: Anonymous Coward on June 22, 2002 02:16 PM
Ye flippin' gods. I took Cobol last semester at uni and I still freak a bit whenever I see code or hear it mentioned. And to think people /like/ this abominable language.

Totaly agreed. I started out majoring in Cobol in my course 7 years back, and went straight back to C/C++ after just one Cobol module.

But, with that said, I can still appreciate why it is here with us and why people use it. The beauty is that you can focus on data and business rules without having to worry about a GUI, and therefore the development time would most likely be quicker.

Personally I think Cobol apps should reside in a terminal. That's where they work best. No GUI overhead means you can run more users faster. I don't know how much use the Qt interface will be, but then as Cobol is still evolving I guess its just the next step in its evolution.

#

Re:*wibble*

Posted by: eeek on June 25, 2002 02:40 AM
The language is only "abominable" when you try to use it for the wrong things. For the things it was designed for COBOL is still used because it is good at doing them.

#

For those who don't like money...

Posted by: Anonymous Coward on June 24, 2002 07:13 PM
For people who don't understand why COBOL is still hanging around and why companies like Fujitsu are interested in producing stuff like COBOL.Net:



There's a lot (and I mean a *lot*) of banking and business code still clunking away in COBOL in the world. There's a fair to even chance that your very own bank still has its core batch processes written in COBOL.



In short: there's a lot of people with a lot of money still using COBOL.

Like taking candy from a baby. :)

#

Re:For those who don't like money...

Posted by: Anonymous Coward on June 25, 2002 04:42 PM
Except that bankers are stronger, have bigger teeth and cry louder than babies. It is much more dangerous (and taking candy from a baby is VERY dangerous) to take COBOL from a banker

#

Linux finally is getting it.

Posted by: Anonymous Coward on June 24, 2002 11:03 PM
I'm glad someone has finally taken this important step. As of two years ago there was probably more business-related code written in COBOL than any other single language. A lot of money there. This, I feel, will give Linux a stronger push into the business world.

#

Re:Linux finally is getting it.

Posted by: segmentation fault on June 25, 2002 11:19 PM
> This, I feel, will give Linux a stronger push into the business world

Dream on. COBOL people are as bound to the computer (usually something about 2m^3 with an upper case only shell) as they are to the language...

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya