Re: Genuine question...
OK, not my field but I will take a stab at offering some counterpoints ...
1) Sure, the code may be working now, but how much longer can you sustain finding people who know Cobol to come in and fix it the next time there's a Y2K type issue, or even just some small fix?
You do not bring in a random "dime a dozen" programmer to quick fix something in an existential-level business critical system. Even if you were so reckless to do so - would your language-du-jour rent-a-hack fair with a body of code that has been auto-translated from a source with a design based on the precepts of COBOL?
How would they go about re-validating/re-certifying this new system?
2) If it's running on original hardware, how long until a capacitor fails or something else and you can't fix it?
Whilst there is a lively market in legacy hardware for these types of "must have" systems, there is also a strong market for high-fidelity emulation. (At my former employer, the Charon VAX emulator was in use for a number of legacy projects). And, pre-emting 4), the business software issue remains concerns of point 1) remain unchanged and the new software/hardware issues of the virtualization are a new business concern which offsets the concerns of obsolete hardware. These are both unavoidable and need to be dealt with carefully.
3) If it's running on original hardware, how much is it costing you in terms of electricity? Both the machine itself and the necessary cooling, etc.
Insignificant in comparsion to other costs and the business value.
5) If you took all of these programs together they might make up hundreds of thousands of lines of code, but each individual program is probably only a few hundred, maybe a few thousand, lines
The complexity of many such software systems often lies in the emergent behaviours arising from the interactions of its components rather than the inherent complexity of any individual components. Good design typically tries to control and manage these interactions - but shit happens (sometimes for good** reasons at the time).
Having software auto-converted to another language preserving all possibly important behaviours would leave you with a mess of software preserving idiosyncrasies of the COBOL and adding idiosyncrasies from the new language. This would be accompanied by a loss of knowledge about the system as those lifers who previously understood the system would now be faced with something unfamiliar.
6) Not sure what your point was about error handling and testing, since I explicitly covered testing
Whilst side-by-side output comparison might provide some reassurance for commissioning final integration of a replacement system it seems unlikely to replace all the intermediate level testing stages - which would also need to be migrated (along with the software). Quite often such legacy testing environments can be just as convoluted as the design and deployment environment. The whole development process needs to be considered.
7) Same about the dependencies, not sure what your point is, since it's not like you'd just be updating these systems every time there's a new Perl package released, and you do realize you can download and use local copies of any additional libraries you may use, right? ... right? ... ... right? I have to ask, because you seem genuinely confused on that point.
These inherited dependencies also expand your code base - which might add further concerns as you will not have design and test knowledge for this code. Some of this inherited code might give some reassurance based on its wide-spread use - but that might be uncertain if the code has been subject to frequent updates (prior to the point you choose to freeze at). You then have to decide how critical any future updates to this inherited code are - for which you will need expertise that you probably do not have.
8) I rather explicitly said Perl was being used as an example, which you seem to have conveniently ignored. It could be any language you want, I just picked Perl because its strengths lie in text processing, but as I said in my earlier post, you could use Python, Ruby, Rust, whatever.
Or, and just going out on a limb here, COBOL. Its strengths are that it is oriented to your problem domain, you have a great deal of experience with it, and you know it works.
You don't really want the itinerant programmer looking for easy money and something to fluff up their CV. You should be more interested in getting somebody capable of making sound engineering decisions based on a thorough understanding of your needs and who can determine potential problems that might lie in different potential solutions.
COBOL is a dated language with its own peculiarities - but this is likely to pale into insignificance compared with the oddities of the corporate software system. If somebody is only concerned with COBOL not looking good on their CV, rather than being able to set out what they actually did with it, then they are probably not the right person to entrust your business critical system to.
I am not saying that battling the demons of stupidity in the muddy trenches of software maintenance is glamorous good fun - but it can give you an interesting perspective on the complexity of developing large scale systems, and some useful experiences/stories to carry forward.
Biting the hand that feeds IT
