COBOL on Wheelchair
azac.pl
azac.pl
In case anyone is wondering if something like this could ever be the "killer app" of COBOL that launches it into modern fame and glory, the answer is "oh god, no."
COBOL isn't a modern language by any stretch of the imagination. For example, advanced math is something that it's particularly bad at. Or do you want to sort some data? Yeah, COBOL will let you sort some data, only if you specify the damned file containing the unsorted data, the file that will hold the data while it's being sorted, the file that will contain the sorted data (http://www.tutorialspoint.com/cobol/cobol_internal_sort.htm). Want to sort an array into another array? Screw you.
However, there's one thing that COBOL is very bad at: unstructured text. Guess what 99% of the Web is?
For example, in their sample code they show this in the working storage section:
01 the-values.
05 COW-query-values occurs 10 times.
10 COW-query-value-name pic x(90).
10 COW-query-value pic x(90).
Thus, when someone else declares color as "pic x(80)" (note the 80 versus 90), even if the color submitted is "blue" for each, one might be 80 characters long and the other might be 90 characters long and if you don't like it, too bad. Have fun comparing them.
COBOL is still the world's most popular programming language, though, if you look at it in terms of lines of code. Sadly, COBOL programmers are aging and there are fewer devs to maintain their programs (I started hacking on COBOL when I was 30 and I was the youngest developer in my department!).
The core transaction processing system has 1.3 million lines of HP3000 COBOL that is pre-compiled to 13 million lines of Micro Focus COBOL, so that code can be compiled to run on UNIX hardware (using a mainframe emulator framework).
So although I'm not a COBOL dev myself, I deal with the issue you describe constantly. Want to give an inventory item an identifier that's longer than 36 characters? Too bad! That field in the legacy system is PIC X(36) so it will get truncated to that length if it's longer (and of course, padded with spaces if it's shorter, so there are lots of String.trim() calls in our Java code).
Trying to get away from COBOL is actually a three-way problem: technological (as we've alluded to), business (hey, we gotta stop using this shit!), and social (hey, I don't want to touch this shit!). Unfortunately, virtually every solution I've seen focuses on the business or technical issue in isolation, but ignores the others.
I've actually found a solution that solves all of the issues and would make new developers excited to work in COBOL shops, but it's on hold until some technical challenges are surmounted. Frustrating as hell!
But yes, no one wants to touch the 30 year-old COBOL codebase with a ten foot pole. It's career kryptonite.
I'd be curious to learn about the solution you're describing for this problem, is it something you can disclose in any detail?
The project itself hasn't been updated since its initial commit. Would've been funny to go on with it for at least a little while.
I don't really want to participate in all the ceremony that goes into writing COBOL, but the end product is often more intelligible than code in some other languages I don't know.
Not to say that you should be quick to build your startup on COBOL, but the present language is pretty tolerable. Most of the COBOL that actually runs, I think, is 74-era code, however. That is certainly painful.
It could always be worse, however. It could be MUMPS.