The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Mainframe, cobol systems not that bad

I work with mainframe/COBOL systems in a financial services company.  Dont write COBOL but use COBOL based programs regularly.  Using these interfaces aren't that bad.  I know COBOL itself gets a bad rep for obvious reasons, but the actual running mainframe environment is really very stable.  Applications run pretty quick and are still functional. (ie, I work with mail, calendar, scheduling, editing programs)

If I could describe the interfaces I use, they resemble an advanced version of ncurses application (VMS maybe?).  All terminal based (no microsoft explorer environment), there are windows and scrolling and stuff.  And it is a true thin-client networked environment.


The J2EE web applications that we develop that interface with these systems are normally buggy, slow (at least compared to the mainframe interfaces), high-maintenance.  The main selling point (of course) is the standard, accesible web GUI.

The point of my post is just to say, mainframe systems arent pretty but they arent as bad people make them out.  You should really consider trying to use one, it will open your mind a little bit.
Bot Berlin
Monday, May 21, 2007
Where can I download one of these mainframe cobol systems to try them out?
Anonymous Fat Guy Send private email
Monday, May 21, 2007
If you are serious, your best bet is to find a developer in your area that actually works with them.  See if you both can remote in and navigate around.  It is different kind of environment, probably better to get the whole experience as opposed to looking at snippets of code on the net.

ie; might want to see how programs get written, how jobs(programs?) are run and how they get queued.  See the user tools.

Imagine it this way.  Web applications take so much effort to create, creating the screens and the layouts.  You may end-up with X number of screens and entrance points.  Mainframe systems grow every fast, and end up with just an infinite amount of screens and data and information.
Bot Berlin
Monday, May 21, 2007
I worked on mainframe PL/1 programs.
Takes about a week to do what nowadays takes 1 hour to accomplish in dotNET. No thanks.
Fritz Send private email
Monday, May 21, 2007
I wrote cobol code for about 10 years in the financial and securities world and enjoyed it.  When I switched to MSFT tools I enjoyed it but thought this stuff is not made for heavy duty OLTP environments.  I was right for a few years and then their products became less toy like and eventually became scalable and industrial strength.  I feel no smugness towards mainframes and the people who still support them.  Do I want to go back to doing it - nope.  :-)
Monday, May 21, 2007
I'm currently working on mainframe C++ programming, and it is pretty bad. It takes many times longer to do things on the mainframe than it would on a Windows or Unix system, if you can do it at all.

I used to think that VMS was the worst possible system to work on, but it is MUCH nicer than IBM MVS/TSO.

Maybe the mainframe isn't so bad if you're not developing on it (or if you have competent operators at your beck and call), but if you are the one invoking the JCL, it's a complete nightmare.
Jeff Dutky Send private email
Monday, May 21, 2007
Somebody give the OP a niche hat.
TravisO Send private email
Monday, May 21, 2007
You are right, I have only seen snippets of working code.  So I havent seen the nuts and bolts behind everything.  I guess I like some aspects of the interface.  It is uniform, quick, functional.
Bot Berlin
Monday, May 21, 2007
I guess I like some aspects of the interface.  It is uniform, quick, functional.

I think you are describing the programmers who wrote the software you are using, and not as much the environment.
I forgot my posting name.
Monday, May 21, 2007
> The point of my post is just to say, mainframe
> systems arent pretty but they arent as bad people
> make them out. 

Isn't that exactly what some of the old farts on this forum have been pointing out for years.

The young guns dismiss the old farts as coders past their prime, unwilling to learn anything new, but in reality most of these new technologies are nothing more than eye candy when compared to the older, more powerful technologies of yester year.
Jussi Jumppanen
Monday, May 21, 2007
Sorry about the length of this, I got a bit carried away :-)

I have used mainframe, unix and Windows extensively and technically I think the mainframe is far superior. There are 2 main reasons:
1) the hardware and software have been developed cooperatively and
2) the systems were designed explicitly for businesses at a time when they were suspicious of computer systems, and intolerant of the types of computer problems we take for granted today.

There are many problems that were solved in the mainframe world decades ago, that PC/unix systems haven't become complex enough to really encounter yet. Like: How do you manage thousands of programs, using hundreds of thousands of files shared between several systems, where some programs can share access to the same file but others cannot?
You need to guarantee that you don't end up with the situation:
- Program 1 opens file A exclusively
- Program 2 opens file B exclusively
- Program 1 needs access to file B to complete
- Program 2 needs access to file A to complete
The mainframe manages this automatically, without any logic to handle it in the programs themselves. This is what JCL is for. Many people hate JCL, but I suspect they haven't tried to do the same thing without it.

Mainframes are very strict about security. Mainframe people look at unix security the same way unix people look at Windows security :-)

Mainframe systems often have strict response time measurements. It is not uncommon to have requirements for subsecond response time, with penalties of $thousands/month or more for missing them. This is one area where web apps have a long way to go to catch up.

You may have tens of thousands of users of the system, so problems are expected to be fixed, rather than the reboot/reinstall etc solution on smaller platforms - and you have the tools to do it.

Many mainframe systems are critical to the businesses that run them. I used to work at an airline, and someone estimated that if the reservations system was down, it cost at least $10,000 per minute. Costs add up quickly when you can't take bookings, check in passengers or board aircraft. That estimate was probably conservative. A couple of years after I left they outsourced, and one day the outsourcer made an error that resulted in the system being down for 2 1/2 hours. I heard on the grapevine that the outage cost the airline $4.5 million.

Mainframe interfaces and development tools could use some updating :-), but its just another computer system, and there's no technical reason it couldn't be done. Most were designed when comms links were slow, and you had to provide subsecond response for multiple users over a link slower than your average modem. They are actually excellent to use over the internet now. If you need anything more than a web browser remotely, I haven't seen anything to beat the mainframe interface. I still think the mainframe interface is better and easier to use than unix/Linux, if you exclude the case of a single user on the unix system console.

Many people don't realize how productive the mainframe interface can be when the computer is just a tool, not your job. You can design Windows interfaces that are as efficient to use as the mainframe interface, but they have to be very good, and they are unusual.

It is interesting to see development moving to web apps, because they use a very similar model to the mainframe. Most of the benefits people promote about web apps apply equally to the mainframe. Mainframes also run web apps, java etc - the apps are probably not so easy to develop, but are likely to be much more secure.

The biggest reason that the mainframe has fallen behind other systems is the cost of software. A system upgrade can result in a bill for millions for the software licenses. This tends to encourage people to move to other platforms - even when the attempts to move end up costing many times what they were supposed to save, for a less productive system.
Andrew Rowley Send private email
Monday, May 21, 2007
One long running assumption I have had is that mainframe business apps result in people being a bunch faster at the kind of data enty that is most common in offices.

Add that in with the lack of access to eBay and no pre-loaded solitaire game and it's a clear winner.

And don't get me started in the value (or lack thereof) of PCs in K-12.
Tuesday, May 22, 2007
"The point of my post is just to say, mainframe systems arent pretty but they arent as bad people make them out.  You should really consider trying to use one, it will open your mind a little bit."

I couldn't disagree with you more.  I've done a bit of mainframe work and I'll never go back.  I'll change careers before I touch COBOL, JCL, or code that is older than me again!

I'll agree that the applications are quick and functional but file management is worse than DOS 1.0.  Software development is the pits in so many ways I can hardly begin to describe it.
Almost H. Anonymous Send private email
Tuesday, May 22, 2007
That's probably another reason why companies move away from mainframe - even if the applications are reliable, productive and easy to use (remember end users shouldn't have to do file management, JCL etc.), people don't want to do the development work.

I would be happy to work on them again - although I was a systems programmer not a software developer.
Andrew Rowley Send private email
Tuesday, May 22, 2007
I think a big problem is that mainframe development tools haven't had enough investment.  The lack of a mass markt for them is probably most of the reason why though.

A lot more could be done with putting an IDE on today's powerful desktops and moving most source control functions off the mainframe as well.  You need more than a code editor of course, you need a good cross compiler and probably a faithful mainframe VM or something on your desktop for debugging against.

A big headache is probably emulation of DMBS and environmental software though.  Only simple batch programs run in a vacuum.

I have noticed that many vendors of Cobol "off the mainframe" have gone to sandboxed interpreters.  Some of those try to provide a mainframe-like application environment.  A few may even work with mainframe-oriented Telnet clients to support multiple users.
Tuesday, May 22, 2007
Yes - although a lot of what you describe already exists. I think there are at least 3 mainframe emulation products, one open source:

The problem is the software licenses, still very expensive or difficult to get. You can run OS/360 which is public domain, but that is 1960s era. I am not sure that IBM has ever actually licensed anyone to run OS/390 or z/OS on Hercules though.

There are a couple of commercial emulators which could run z/OS on a PC or laptop. These have been a good solution for ISVs, but there are some lawsuits going on at the moment and I'm not sure what the results will be.

They don't address the fundamental problem though - the development environment. I think that IBM has really made a mistake by keeping the licensing so strict and expensive - if you could get a non-commercial license, I suspect that there would be a lot more development activity. If you can write an open source emulator for the hardware, surely people would be tempted to write an IDE. I would be tempted to try to get  Subversion working. Lots of open source stuff has actually been ported already, despite the limited access to systems.
Andrew Rowley Send private email
Tuesday, May 22, 2007
I work on and with mainframe applications as well for a couple large automotive companies.

One of the major, major issues with Mainframe (or any green screen terminal application for that matter) is:

1.  The fact that it's very expensive to develop in for both the people and the tools (IBM tools).  Databases (IMS and IMS Connect) too expensive for what they do.

2.  Legacy green-screen applications are hard to marry together without a GUI/Windowing system (X or Microsoft).  IBM is trying to solve this problem with HATS (Host Access Transformation Services).  HATS allows you to transform terminal screens on the fly into HTML and with that you can grab data from multiple screens and re-render the collection into a single screen.  The green screen applications traditionally force end users to open multiple session windows to get their job done and then using macros or screen scraping to retrieve data.  Huge PITA.

3.  Security is another major issuse.  z/OS has, to my konwledge, no way to do SSL over the wire in pure software so all your green screens run in the clear unless you pony up the dollars for a very costly hardware upgrade.  You can encrypt the data but it requires a costly hardware upgrade that smaller companies have a hard time couging up the dough for.  Any company moving financial data round in the clear is in trouble.

4.  Portability.  Where I consult, some applications are using Cobol on Linux (Microfocus Cobol compiler).  The portability is lousy and it sort of reminds me of the days when you had Expanded Memory vs. Extended Memory and the dizzy array of drivers and crummy standards (LIMS makes me shudder).  The reason why portability is important is we can virtualize commodity hardware more cheaply than a mainframe can.  P5 may be IBM's answer to this but we'll see.

... There's more I could say but I think these are the highlights from my persepctive.  This is basically the scene at two automotive giants we consult for.
Tuesday, May 22, 2007
"It is interesting to see development moving to web apps, because they use a very similar model to the mainframe. Most of the benefits people promote about web apps apply equally to the mainframe. Mainframes also run web apps, java etc - the apps are probably not so easy to develop, but are likely to be much more secure."

The big difference is that the Web environment is messy and no-standard.  It seems that every young "script kiddie" and his brother is trying to design the "ultimate website" without realizing that usability and maintainability are more important than flash!  Eighty-percent of the cost of a system is spent on the maintenance phase; hence, it pays to employ the KISS principle up front!
Young developers make foolish design mistakes
Tuesday, May 22, 2007
I think one reason why non-mainframe Cobol vendors move to those "sandboxed interpreters" was to gain easier cross-platform portability.  Sort of like the Java concept.
Jade G.
Tuesday, May 22, 2007
I've been shocked at how lax IBM and its competitors in the mainframe market have been about replaving the "green screen" UI with something more modern.

They could go with something just as stateful as current terminal sessions are.  They could devise a standard UI that did not force regular users to constantly move hands between the keyboard and mouse.

The main things would be to move away from the crude low-res monochrome (or low-color) character displays, and allow parallel open windows within a session.  Perhaps something closer to an "X terminal" in the Unix world.
Tuesday, May 22, 2007
"z/OS has, to my knowledge, no way to do SSL over the wire in pure software"

Not true - SSL can be done in software. Crypto hardware can be used if it is available, but it is not required.
Andrew Rowley Send private email
Tuesday, May 22, 2007
I said:
"z/OS has, to my knowledge, no way to do SSL over the wire in pure software"

I was corrected:
"Not true - SSL can be done in software. Crypto hardware can be used if it is available, but it is not required."

I stand corrected!  The reason, as I found out, we don't use software based is because it taxes the CPU too heavily and CPU tax is more expensive than the associated hardware.  In the mainframe world you are charged by CPU ticks.
Wednesday, May 23, 2007
A single mainframe can replace hundreds of PC based

A few people can manage a mainframe while it takes dozens to manage hundreds of servers.

Mainframes do not accept that software bugs are a fact of life. They know bugs are a result of a defect in design or implementation...and they fix it.
Rob Henry Send private email
Wednesday, May 23, 2007
too bad, cobol programmers dont get a lot of respect out there in the java/.net/asp/php world.  I know some really hardcore mainframers that have to constantly fix serious issues at 4am.
Bot Berlin
Wednesday, May 23, 2007
I don't know for a fact, but I bet 90+% of the core processing that goes on across all industries happens on a mainframe. And I bet 100% of transactions involve a mainframe somewhere, at some stage.

The question is, is this because they are actually good, or because they are too hard to change?
Greg Send private email
Wednesday, May 23, 2007
"CPU tax is more expensive than the associated hardware"

That, unfortunately, is all too true. Hardware is much cheaper than it used to be, but as hardware got cheaper many of the software companies saw unused money in IT budgets and increased software prices to take up the slack.

It's one of the big problems with having everything on one big system - add a workload and all the other work gets more expensive, remove one and everything gets cheaper.

IBM is actually trying to do something about that, and it has got to the point where they ship the machines with a number of different types of processors to get around licensing based on CPU capacity. There is a special processor for Java for example, so that you can do java processing on the mainframe, without paying extra for all your non java software.

On the positive side a well tuned mainframe can use almost all the processor power. Depending on the workload mix, it will run fine at 100% CPU for hours, without response time problems.
Andrew Rowley Send private email
Thursday, May 24, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz