Choosing between assembler and COBOL

Question

I have to rewrite and greatly modify parts of a legacy COBOL application. The COBOL source-code is available (around 100.000 lines of copy & pasted code mixed with GOTOs).

Some more details on the system: It is a general management system controlling transactions, bank management, customer data and employees of the company I work for. The COBOL-powered database is about 4 Terabytes distributed over 50 old HDDs. (But messing around with them is the sysadmins job)

They are using COBOL85 only.

Now I have two options: Rewrite and refactor 50% of the old COBOL system, or use X86 assembly.

• Should I use X86 assembler or COBOL?

Answer 1

I'm having trouble seeing any kind of business case for making this an either-or, leaving out .Net, Java, and about a dozen alternatives; it really needs pushback. Despite its hold in big business, the number of skilled COBOL programmers is dropping fast, never mind the number of skilled X86 assembly programmers. Any significant rewrite has to take maintenance (and that includes staffing) into account.

Now, answering the actual question: If it's really an either-or, stick with COBOL. (I'm assuming the compiler is still supported, etc., although if it's COBOL-85...) Why trade a high-level, expressive, business-oriented language for a low-level, architecture-specific, one if you don't need to? Particularly when the existing codebase is already in that language.

Answer 2

I would say that COBOL is more likely to be your option. COBOL is written in order to perform such business oriented tasks. In fact, as you might already know, COBOL means COmmon Business-Oriented Language.

I doubt it will be either easier or funnier to write your code in assembler. You'd better, in my point of view, take what works and refactor it, just like the Agile Development proposes. I see no gain by rewriting the code, but refactoring it. This is my humble point of view. Better to take the time to familiarize with the code instead of trying to rewrite it. In either cases, you will have to familiarize with it anyway, as you'll probably want to reproduce what it already does.

Hope this helps!

Answer 3

I really cannot see why x86 assembler is an option at all let alone the only option.

The x86 instruction set was designed for an 8 bit processor with a very limited number of transistors. Over the years this has grown up into a 64 bit capable piece of hardware with millions of transistors but upward compatibily has left it lumered with much of the original instruction set and many of its constaints. Its probably the worse instruction set you could ever work with - compare either to the beautiful simplicity of ARM or the "third generation langauge implemented in op codes" that is the IBM mainframe instruction set.

You could re-write your system in perl,python, java, C++, c# without spending a penny on development tools.

However it would probably make more sense to buy a more modern COBOL compiler/enviroment and just plain upgrade what you have.

Answer 4

This is a trick question isn't?

Personally I would go with x86 assembler. I have limited experience with COBOL and COBOL maintainers are hard to find.

Of course, I wouldn't hand code my x86 assembler, I'd use a higher level language to specify what I wanted the assembler to do and use a tool to generate the assembler. Say C++ and gcc.

If management really didn't want me to keep the high level language code in source control I'd probably still code a tool that code insert the high level language code as a comment into the generated assembler and a tool to extract it again. Then at least the intent of the code would be reasonably commented.

Answer 5

I'm not sure this is a real question either.

Refactoring 100,000 lines of Cobol-85 and adding new features is not a huge deal. Converting the whole thing to assembly is a HUGE deal.

Why do the headache of going to x86 -- start simple:

• remove any period (.) terminators and replace with the proper END-* construct(s)
• convert your gotos into performed paragraphs
• convert common chunks into nested programs
• add new features

There are a number of automated tools that will convert Cobol-74 (goto laden crap) into Cobol-85. Get one and see how well it works.

Otherwise, kick the contract to me and I'll have the refactoring done in a few weeks (firmer estimates once I've seen the code).