Re:Automated Refactoring of a U.S. Department of Defense Mai...
by le-mark on Monday May 06, 2019 @12:18PM
(#19840817)
The second one immediately lowers the TCO for obvious licensing reasons
How true is that though? They'd still have software licensing, they still need an OS to run on Hercules after all.
Re:Automated Refactoring of a U.S. Department of Defense Mai...
by fork1 on Tuesday May 07, 2019 @03:16AM
(#19847248)
Not just the OS, legacy applications tend to rely on DB2, CICS, IMS, and what not. All of those have expensive licenses and cannot readily run on emulation. Switching to Hercules does not solve the issue, unless your cobol apps are barebone batches.
Re:Automated Refactoring of a U.S. Department of Defense Mai...
by karambahh on Monday May 06, 2019 @02:00PM
(#19842016)
It's been a long while.... At the time, RedHat was still "free".
Linux sysadmins were cheaper than their mainframe colleagues.
Hw was orders of magnitude cheaper.
Floor occupancy was lower.
We did not got as far as watts consumed per functional task performed but I doubt it would have tilted the balance?
Re:Automated Refactoring of a U.S. Department of Defense Mai...
by karambahh on Monday May 06, 2019 @02:02PM
(#19842035)
Sorry I misread your comment!
You're obviously right for licensing inside the emulator! However, the costs are(were?) in hardware & floor occupancy (as in "decomission a whole room"-cheaper)
Re:Automated Refactoring of a U.S. Department of Defense Mai...
by mperham on Monday May 06, 2019 @01:52PM
(#19841953)
No expensive IBM hardware support/services needed.
Recompiling the COBOL codebase on Linux and accessing and loading it as shared objects (via JNI for JVM usage)
Running Hercules ( https://en.wikipedia.org/wiki/Hercules_%28emulator%29 ), an IBM mainframe emulator
The first one has lots of merits, as it allows for a progressive replacement of COBOL functionalities
The second one immediately lowers the TCO for obvious licensing reasons but does not plan for the future, particularly as COBOL developers retire and thus the resources are scarce.
(Anecdotally the customer chose both: recompilation & progressive replacement by Java code for core assets and emulation for "dead", non core, assets dev & staging environments)