Fog Creek Software
Discussion Board




Can Java run on the Mainframe instead of Cobol?

Curious?

KenB
Thursday, April 10, 2003

You mean "in addition to Cobol" right? There are JVMs for several mainframes. They are used by IBM software groups to put a friendly face to those millions of lines of RPG / COBOL / FORTRAN monsters so the $10 per hour  Java Rocks(TM)(C) 2003  co-op students knows how to do reporting or administration.

Li-fan Chen
Thursday, April 10, 2003

Curious to see if Java will ever replace COBOL on the mainframe? I am 29 and I know most of my generation has either never used COBOL or taken like 1 class in college on it.

My professors guided me away from COBOL and puched me in the C++ direction so I never even took a COBOL course.

With so much code out there, in the future, how will this legacy COBOL code be supported - if hardly anyone knows it or wants to code in it at all?

Could Java replace COBOL on the mainframe?

KenB
Thursday, April 10, 2003

Could Java replace COBOL on the mainframe? I guess it depends.

For new development, as long as there is a JVM for your OS/Processor architecture, you should have no problem using Java for new development projects. (BTW, what platforms are still in enterprise use but have no JVMs? Does anybody know?)

However, for legacy apps, it is doubtful that Java will replace the COBOL code anytime soon. If you have had a working app in place for 10 years, and you have no new requirements for the system, then there's usually no good reason to replace the working COBOL code with Java code, just because Java is more cool.

Plus, the JVMs for the more obscure unix OSes get a lot less support from Sun than the JVMs for Linux or Windows or Solaris or HPUX. If you're using some other OS, good luck reliably using the JVM.

Benji Smith
Thursday, April 10, 2003

I've coded COBOL on IBM mainframes.  I worked on code that's older than me (in some cases, by a decade).  If that code hasn't been replaced, it's not likely going to be replaced.

COBOL, however, is absolutely horrible.  In fact, the entire mainframe environment is horrible (give me UNIX anyday).

Wayne Venables
Thursday, April 10, 2003

OS390<Linux<Java<Jython. The four degrees of python. But I'll leave that for someone else to expore. I not a fool *with* python.

Java on the mainframe:

http://www-1.ibm.com/servers/eserver/zseries/software/java/

fool for python
Thursday, April 10, 2003

Linux on the mainframe in general.... yum.

Which is funny, because all of the VMS and Mainframe folks always gripe about how unfriendly Unix is, yet the rest of the world thinks that VMS and Mainframe systems are the annoying ones.

Oh yeah, and HP3000's.

flamebait sr.
Thursday, April 10, 2003

I dunno why all you kids beat up on COBOL.  A lovely language, especially now in these days of multi-line text editors so you need never type ORGANISATION (oops) ORGANIZATION DIVISION again.

After the bureaucracy of the beginning bit all you had to do was tell the computer what to do...

PERFORM SORT-RTN  (always routines in COBOL) UNTIL BORED

It also shared with other systems languages a complete lack of user interface (wimpy versions post  1980 don't count, though Ericssons was quite nice but MS bought that and shot it dead). 

And  all you Java types thinking you disinvented pointers, hah!  COBOL didn't even have any notion of indirection, let alone heaps or stacks.

And if it wasn't for COBOL Michael Jackson would never have made all that money.

No, not that Michael Jackson, a different one that wrote "Structured Programming" to the misery, err illumination of us all.  Hmmm perhaps COBOL wasn't a Good Thing after all.

Now PL/1, there was a language....

Simon Lucy
Thursday, April 10, 2003

The question is not if new development in mainframe is going to be in Java or in Cobol (or in other languages). The answer here -I guess- is "Yes, Java too".

As stated here, I think the point is all about legacy code. Nobody changes without a really good reason a big and critical system if it is working fine.

Add to it that probably the system is running Cobol faster than Java would run (without improving the hardware), and velocity uses to be an important value on those systems.

So let's focus our mind to find those good reasons to change. Anyone had got any experience about a Cobol->Java migration in a mainframe system? And the reasons were?

Ross
Thursday, April 10, 2003

Cobol gives you Cobol fingers (a.k.a. fingers worn down to little nubbins)

It's a dangerous trap in languages to assume that if the language was just a little more verbose, a little more like english, without all of those nasty little {}'s and *'s and &'s and ;'s in weird places, that anybody could code.

Then they realized that the great difficulty of programming is being able to make data structures and deal with pointers and algorythms and everything else and the syntax of the language matters only slightly more than if you code wearing sneakers or hiking boots.

Except that they keep trying to bring this all back under new appearences.  BASIC, COBOL, Visual languages, Visual Studio Wizards, etc.

flamebait sr.
Thursday, April 10, 2003

I really don't know where to start, so forgive the shotgun approach:
- Cobol was not invented to be easy for anyone to write, it was for business people to read.  Big difference.  Visual Basic was invented to allow anyone to code and well, just because you can...
- JAVA replace COBOL - Economics?  Just about anything can provided you are willing to pay the dollars.  Part of the economic downturn in IT is from all those companies that spent millions making their COBOL code Y2k compliant.  Tough to replace it after that effort.
- JAVA replace COBOL - Language - Mayhaps.  I think companies have given up on the language being of any value to anyone. The end result is the end result.  Can it get the job done.  That being said, I have watched as many companies are now shy on introducing new languages as they are dependant on those who introduce it.  Someone brings in Python, uses it on a project and leaves.  Now they have to hire someone who knows Python or teach it to someone.  Too much of that is a big issue.  (OK - - this is probably economics too)
- JAVA on MVS - Works great. 
- Linux on MVS - Works great. 
- JAVA as a part of the MVS toolset - We run IBM with JAVA, Websphere, CICS and MQSeries.  Say what you want about COBOL but it screams in a CICS region if written well.  JAVA however does have a better visual front end. (Remember a few years ago when THAT was the problem with JAVA?)

I am going to step out on a limb and say, I am beginning to see consolidation again.  It is not so much Cobol2Java as it is COBOL and JAVA or Language 1 and Language 2.  They are coexisting because it makes more sense for the business than the infamous "rewrite."  If in doubt - see Netscape.

Mike Gamerland
Thursday, April 10, 2003


COBOL is transactional in nature.

JAVA is not.

Bajillions of lines of code have been written in COBOL.  The best way to integrate with a COBOL is with another COBOL app.  (I've had to write C-To-COBOL access wrappers.  UGH.)

Thus, Heusser's theorm:

COBOL is going to be around in legacy IS shops for a long time.  These shops typically ran AS/400's or OS/360 with DB2 and are now migrating to whatever IBM will give them. 

Java is not going to take that space away - but, potentially, these shops might migrate to Oracle and use Oracle's reporting tools to create reports, instead of COBOL. 

In my book, it's much more likely that Oracle PL/SQL will replace COBOL for business (IS) apps.

just my $0.02 ...

Matt H.
Friday, April 11, 2003

I am also going to agree with Matt H.  Where migration from COBOL in the back-end is happening, I see Oracle/Sun filling the space.  However, IBM sees that too and are fighting back with DB2/2 and to some extent Linux. 

As well they are making the case that the cost of migrating hardware, after a mainframe investment is questionable.  A legitimate case.

I will close on a slight disagreement.  COBOL is as transaction based as JAVA.  People sometimes confuse the front end as being more persistent in JAVA, but looking at a COBOL/CICS/DB2 and JAVA/Oracle the end results are transactions into a database.  Of course YMMV.

Mike Gamerland
Friday, April 11, 2003

*  Recent Topics

*  Fog Creek Home