Rewriting IBM assembler + COBOL in C++

Question

I work as a rental agent / manager for a car rental company that is running on a rental system that was written in 1972. I decided that maybe it was time for an update. For a bit of background, here is a short example of the madness that we have to deal with from this program daily:

A rental agent must remember that printing on one screen uses "MXC" in the ACT field (everything is based on short codes), which perplexingly stands for "MaXimum display on a Contract", while on another it requires PR (for PRint) in the ACTION field, but several screens use a Y in the PT (for PrinT) field, yet another screen uses Y in the PRT (for PRinT) field, yet another screen requires the user to hit enter (but not the enter next to the letters, as that's a new line character, it must be the enter on the number pad) and then F8, a different but related screen requires simply F8, some screens have a field labeled PRT, which should be for PRinT, but the field actually does nothing and printing is done automatically after going through several prompts, and still more screens have a field labeled PRINT Y/N, which insanely defaults to Y for operations in which another location is already delivering paperwork, and to N for operations in which another dealer will need paperwork.

I decided that I could do a better job than this, so I set out to contact the person in the company that would make the decision to update this. I eventually get through to the VP of IT, who is in charge of this program. I get a bit of information out of him, and learn that my car rental company has its rental program written in IBM mainframe assembler with a little bit of COBOL mixed in. He says that there are no positions open right now, but that I should e-mail him my resume anyway (in case something opens up).

This leads me to my questions.

The first is technical. With the idea of improving maintainability in the future, my thought is to re-write it in a higher-level language than assembly language. My area of experience is in C++, so that is the obvious choice for me. The company is in dire need of an easier way to update the program, as I recently read an article where the man I spoke with is quoted as saying the team worked hard, and they are proud to announce that the program now has support for 5-digit location codes (instead of 4) and 8 digit car numbers (instead of 7). My philosophy on updates, even in situations this dire, is in line with Joel's: http://www.joelonsoftware.com/articles/fog0000000069.html in short, re-writes should be incremental, rather than throwing out everything there was before and starting fresh.

Is there an easy way to integrate IBM assembly with C++, and if so, how should I do it? I am vaguely aware of the asm keyword, but I don't know if it's best to use that or do something else. Is such a plan ill-advised? I do most of my work on Linux using g++ and GNU make, so answers specific to that are welcomed, but definitely not required (since I have no idea what sort of build system they have no, but I suspect almost none).

The second question is more political. How should I go about persuading this company that they need to make the switch? The theoretical cost savings are huge (based on my estimates, the company is wasting an extra million or so dollars per year, just on increased training costs to learn how to interact with the program), but my proposed changes would probably put all of the current programmers out of work, should they be enacted, so there is great structural resistance to change.

edit: I should explain why me modifying what the company already has seems like the best solution to me. I am still open to other suggestions, because this is a monster of a program, however. I've never had a programming job before, so please correct me on any incorrect analysis I might give.

First off, there is the off-the-shelf solution.

From my talks with a few mid-level managers about this sort of thing, one of the main concerns with switching to a new system is the large number of loyal employees who have been with the company for decades and are comfortable with the system by now. If I have the ability to modify what we have, I could maintain the current interface in a sort of 'compatibility mode'. Users already have to log in to use the current system, so I could add the ability to activate a setting when users log in for the 'first' time (after I make this change), where they are given the option to use either the 'classic' interface or the 'new' interface. There is no way I'll find an off-the-shelf solution that allows that, and I think that fears of senior employees getting confused by changing technology would be a major reason for upper management to say no.

My company also owns the software we use; we do not license it. This means that the management I am currently talking to are the same people who could actually authorize me to make a change. With a third-party solution, I would have to get approval from my company in addition to securing whatever rights would be necessary from the company that developed the product we use, which adds an additional hurdle. This would also require convincing the company to give up on "their" product and take some other product, which seems like a greater hurdle than attempting to update what we have, but I could very well be wrong on this issue.

Finally, looking into the future, I don't just want to improve the user interface and fix a few bugs. After I update those 'urgent' issues, I was hoping to update fundamental way the company runs as related to technology. After spending 1-2 years on these sorts of issues, my plan was to go back to management and propose more dramatic changes. There are many ways the company runs that could be fundamentally improved by technology that they simply are not using right now. For instance, each region pretty much operates the same way. The local major airport is the central hub to distribute cars. They are primarily sent on an as-needed basis. However, the airport is used as the home base for all operations. They'll send two people in one car to my location to pick up one car from us that we don't need, then return to the airport with the car they came in, plus what they are taking back (we are 32 miles from the airport). Then they will come to the location 5 miles away from us in two cars to drop one of them off, then return in their other car to the airport. They do this even if the car we sent back is the same kind of car they need near us. I've been with the company for about two years now, and I've only seem them deviate from this in the most extreme emergencies of car shortages (so about three times ever). I would replace the 4 people working in every region with an automated scheduling system that determines what cars go where and try and find the path that requires the least amount of time + miles + drivers to deliver all cars where they need to be, as an example of the higher level fixes I hope to some day add.

However, before I would feel comfortable proposing all of this, I feel it would be helpful to get a toehold in the company and the code base by doing the smaller tasks, like updating the interface. Solutions like outsourcing or otherwise would remove this possibility.

Answer 1

Confining myself to the technical front...

I suggest you begin by determining the environment in which the application runs. "Mainframe" could mean a couple of different things, given the application's age it could be CICS or IMS. It's also possible the original authors wrote their own started task.

Depending on where the application runs, it will likely make use of APIs for that environment, CICS now uses an interface markedly different from its early days, I cannot speak for IMS. If the application is its own started task, then it may very well have its own internal API - I spend some seven years supporting such a beast, written in the same era.

Something else to consider, given the age of the application, is that the Assembler with which you wish to integrate C++ predates the existence of Language Environment (LE). As such, unless the Assembler has been updated to be LE-conforming, you will have some difficulty as C and C++ are LE-compliant and require their callers and callees to also conform.

Another point for consideration, if this application is running on a moribund mainframe, you may be looking at trying to integrate with an application that runs on unsupported hardware and software. This would be not unlike trying to integrate with an application written in 1989 that runs on DOS 4.01 on its original hardware.

Answer 2

You're jumping the gun. From your description it looks like you haven't fully understood the current technical environment (what OS exactly, where and how is the data stored, do interfaces to other systems exist etc.). But even more important: a serious plan should consider alternatives to a partial or complete in-house rewrite of the sofware, namely off-the-shelf software, out-sourincing of the rewrite, software as a service etc.

Whatever way the company finally goes, it first need a solid analysis of what the software does today and what the requirements for the new solution are.

So why don't you offer to do this analysis?

Answer 3

I am surprised you got such a polite response!

Lets look at this from their viewpoint.

They successfully managing a thirty year old system with probably hundreds of thousands of lines of code, interfaces to perhaps twenty other systems which embodies a business processes that evolved over forty years.

They are probably/hopefully experts in their field and as such would regard C++ as a step down from IBMs "High Level Assembler Language" to give it its full title. IBMs assembler language is extremely powerful and the "MACRO" language is the best implementation of a pre-processing/template language ever.

There will have been a proposal to replace their system about every five years since it was first implemented. Some would have been rejected after a feasibility study, some would have got as far as the design stage before they lost there budget, some may have even got into the code and perhaps testing stage before they hit performance problems and got canned.

C++ would simply not help. There is no graphics library in the environment where the application runs. (There is a 3270 graphics library but its unlikely to be supported in C++ as nobody uses it, and, there is a full "X" client library but you need to be in a different environment to use it.)

They have a user interface which is far from perfect but which is well known and fast. An experienced operator will fill in a form about three times faster using a green screen rather than an equivalent GUI. Plus they can pay attention to the customer while they touch type.

The screen operators will need training whichever interface they use, retraining all there employees to use a new and unfamiliar GUI would be a massive budget item compared with just training the new employees on the olde worldy system.

Answer 4

I had a similar problem some years ago at BellSouth. I simply wrote COBOL code to scan assembler language programs byte by byte, separate out the opcodes and operands, convert branch instructions to go tos, and convert compare instructions to IFs. This program converted DC instructions to the equivalent COBOL Data Division code, and converted moves, zaps, etc., as appropriate.

Once that was done, I wrote a second program to convert IFs and GOTOs to IF-THENs, with moves and such in the lines between these clusters (this wasn't really all that hard to do - the secret is to insert the IFs and ELSEs as you re-read the 1st-phase "pidgin" cobol from back-to-front).

IF-THEN-ELSER looked for situations where it found a GOTO reference in close proximity to a label, which could safely be deleted (decrementing its number of references by 1). You run this IF-THEN-ELSER program iteratively (that is, you run it again and again, stopping only when your last pass can't find a way to make any more changes). Most of the critical work is done by this if-then-elser, whose COBOL product must be carefully reviewed and vetted by an experienced, competent assembler-language programmer (namely, me). In my experience, my "if-then-elser" was able to eliminate more than 90 percent of the GO TOs resulting from the original branch instructions.

I suppose it's possible to go forward from this point with a straightforward conversion to C (or C++) - languages I am also conversant with. However, at BellSouth, our target language of choice was COBOL/II. There is always a bit of complexity which arises from situations where a remaining label has multiple GO TO references (many times, these situations are handled by COBOL PERFORMs, but can sometimes be simply represented by OR and AND constructs).

I think it's nice to produce code in elegantly block-structured COBOL/II, with EVALUATEs (Case constructs) and 88 level condition-names. Adding these finishing-touches led to another pair of programs, which proved handy on COBOL programs not originating in programs converted from assembler.

I don't know if this helps.

As others above have commented, you have to conduct this process with care. It helps to have 10-12 years of assembler coding experience informing your decision making processes. We who have that experience are hard to find any more.

As a final note: We only wrote in assembler back then because the compilers for the high-level languages produced cumbersome, inefficient object code. Today's "optimizing" COBOL compilers don't have those same bad habits. ----------

Answer 5

Joel's advice is generally sound, but in this case a complete rewrite is overdue. Ideally, a rewrite with a battleaxe, as what you're dealing with here is a monster.

I'm not sure what exactly to add, as you've already made a pretty good argument for this rewrite yourself. My only recommendation would be to skip C++ entirely and go straight to a web interface for the rental system, as that'll probably be even easier to train workers for, and will save you a lot of work on the UI (as well as make it much easier to get new blood in the project, or even just outsource the whole thing).

As for the existing COBOL programmers -- perhaps they can help with documenting the existing system, and with the migration process.

Answer 6

As to the technical aspect, a lot will depend upon the quality - the modularity - of the assembler code. Some programmers understood the importance of creating modules with specific, limited function and a clear, simple parameterized interface, using standard IBM subroutine linkage conventions. The great majority, however, tended to create monolithic monstrosities.

With the former, reuse is possible, and it shouldn't be that hard to work out the "glue" between C++ and assembler, assuming your assembler modules use standard (or at least consistent) calling sequences. In all likelihood, however, the assembler code will be a mess. Although it was possible to write structured assembler, very few people did, and it will be nearly impossible to discern any "design" from which to begin rewriting.

On the other hand, 360/370 assembler is pretty high-level compared to today's microprocessors, and a lot simpler, and C is sometimes considered "high-level assembler". I worked for a DBMS company whose product was entirely 370 assembler, and our principal architect believed it might be possible to machine-translate the assembler code into C (for future portability). I'm skeptical, but the point is that the distance isn't as large as you might think.

DOn't know if any of this is helpful. As I say, I think it's heavily dependent on the quality and size of the original code.

Answer 7

I can't tell whether this is a joke or not -- your company is seriously running code originally written 39 years ago? If it's running on a System/360, you're going to have to compile g++ from source...

Honestly, I wouldn't even think about using any of the old code; you need to take a fresh approach, sit down and think about what needs to go into the design, and do it from the ground up. Yes, it will involve a fair bit of planning, but I don't think even Joel would say this is a case for incremental changes.

As for persuading the company that you need to switch, you need to point to specific reasons that will improve efficiency, lead to lower costs, and/or show that what you're using now is doing some harm to the bottom line right now.

One other comment -- I imagine that other car rental companies have joined the rest of us in the 21st Century; I would do a bit of recon to see how they are doing it (web-based, I imagine), and possibly model it after one of those systems (i.e., don't re-invent the wheel).

Good luck!

Answer 8

In theory it shouldn't be difficult to convince upper management to replace the old system if you can show them it will save them megabucks. And it will. It's going to get more and more difficult to find programmers to maintain this system, and those programmers are going to get more and more expensive. It's not a matter of "if", it's a matter of "when". It really has to be updated.

However the question is whether you can convince them not just that it needs updating (and they probably know that anyway), but that it should be an in-house project. Especially if the team is just you. Quite often such a major replacement is outsourced. There may even be some off-the shelf-software available for consideration. These options need to be investigated and your managers will insist that happens if they're sensible.

As for the task, if you were to do it, I actually believe a bulldoze-rewrite may be appropriate in this case. Joel's argument doesn't apply in every case. However I couldn't really know without seeing it.

Answer 9

1. An incremental change is out of the question.

2. There is likely to be an off-the-shelf solution available. There are many car rental businesses.

3. If, as a last resort, you need to rewrite it, first spend some time thinking about how the new system will work.
   After you've identified the functionality and interfaces, then you can choose the development tools that fit best with the needs (and your skills).

One strategy to minimise the stress to end-users is to start out emulating the old ugly interface that the users know, with a few niceties like drop down lists for ugly mnemonics, then gradually add UI functionality and wean them onto a modern UI.

You probably don't want to keep the same data file format, so there will be no going back once they switch.