Interesting question. It's tempting to say 'leave well enough alone'.
But in many companies that seems to be frowned upon, and the fashion police will sweep in and propose a 'better' windows/Unix solution whether it is needed or not.
Legacy Cobol applications tend to be large monolithic, with screen IO, application logic, and data access freely intermingled. You may be the happy exception, but all too often....
I think you are right looking at TDMS and Decforms, perhaps not for the product specifically, but for their usage style. These products push you towards a clean separation of form and functions. Clear boundaries and interfaces. I think it would be goodness to go towards that route whether you use the products or not.
It does not have to be an revolution but it could be an evolution.
Perhaps a hard coded, in line, menu interface being replaced by a presentation module and action modules. Perhaps a specific, problematic, file access being taking changed from an in line 'READ NEXT' with meandering EXCEPTION HANDLER to a CALL READ_NEXT_XYZ with simple good/bad status.
That routine is then ready to be replace with more functionality (perhaps the file deserves to become partitioned over multiple files?) or a different implementation call to remote system, database, whatever). But at the same time that routine becomes available as service routine for new tasks maybe tasks through middle ware from a web server.
Personally I have always liked FMS, but that is like setting the wayback machine to the end of the scale and it seems to stay too closely tied to the cobol. But at least it lets you decouple screen design from Cobol.
What was very promising for modernizing was DECforms with the Webconnect options. But that product was retired :-(.
http://h18000.www1.hp.com/products/quickspecs/10720_div/10720_div.HTMLhttp://h71000.www7.hp.com/commercial/decforms/webconnect.htmlI'd say think modules and think middle ware, but you need an excuse to open op working code. Change for change sake does not seem prudent.
>> 2). Database - Currently using RMS file system. Have seen some of the benefits of SQL dbs for transaction logging, rollback,
RMS Journaling deserves more attention than it gets. It can play along in this game.
>> on-line (snapshot) backups,
You can get there from here with RMS + Host or Controller based mirroring, but admittedly not as integrated.
>> and of course, easy column additions/mods,
Right. Those access modules I described earlier can decouple this somewhat and making alread program tolerant to newer fields, and keys but not like an RDBMS
>> etc. From former years I remember RDB and I think Oracle was a player.
Still are. Both available on OpenVMS
>> Of course, we are a small shop and wonder if there are additional products that would enhance RMS, so that the system is not a complete rewrite.
There may be features in RMS that have gone unexploited, like RFA access to make alternative lookup files. Or global buffers for more performance or simple tune-up's
As I said, and Interesting question.
I hope this and other replies will give you some ideas to check out.
The problem as a whole is of course well beyond the scope of a friendly peer advice. If you are serious about this, then you should probably find someone to help you make an inventory of what you have and where you might want to go.
Several folks contributing to the ITRC forum are qualified and happy to take on such assignment.
Regards,
Hein van den Heuvel
HvdH Peformance Consulting
