Operating System - OpenVMS
1745857 Members
4623 Online
108723 Solutions
New Discussion юеВ

Re: Modernizing legacy stuff

 
Wim Van den Wyngaert
Honored Contributor

Modernizing legacy stuff

Just curious : did someone already modernize (or webify) old, big, company critical applications ? Or failed doing so ? And how much effort did it cost ?

I'm thinking of 20+ years old stuff (we have a DSM applic of 1974) handling billions a day. Of which the authors are already enjoying their pension and documentation is very inaccurate(if any).

Wim
Wim
21 REPLIES 21
labadie_1
Honored Contributor

Re: Modernizing legacy stuff

JFP has done it in Python (what a surprise !) for a VT only application, that was then used with a Web browser.
He used some Cheetah (on vmspython.dyndns.org, look for "Cheetah - The Python-Powered Template Engine") for templating.
The application accessed a Rdb database (list, update, insert...)

He should talk better than me about it.

Hoff
Honored Contributor

Re: Modernizing legacy stuff

I've written my share of legacy code, and I've hauled my share of legacy code forward.

When you're looking at this, decide what your goals are, and how you will measure them. Decide what your risks are. And decide what's marketeering, and FUD, and what's fashion.

Writing new code is easy, and often faster.

Good old code? Leave it alone. Jacket it. Re-use where you can.

Twisty old code? That's tougher.

I prefer clean-up and incremental migrations forward where I can manage it. Evolving the applications forward. Key here is process improvement, test suite improvement, and bug tracking; find the low-hanging fruit, rinse, repeat.

A large and oft-underestimated effort is digging into the existing code and figuring out what it is actually doing and how, who is using what, what is silently broken, what platform-specific features, what interconnections, etc. The design specs are the toughest, and tend to get thrown out too soon, or the investigation gets slammed with the Gotta Write Code Now problem. Tools like doxygen can be brought into play in the investigation and in the new environment, and scaffolding tools can help with the whole process.

There's a whole second-level discussion around managing out-sourcing, something that some organizations are good and and a surprising number of organizations are horrid at.

For organizations that are on the fence about this whole process, start by documenting your current processes and pieces in increasing detail, your application build and source code processes (completeness, reproducibility test coverage, etc), and particularly start by documenting your current costs. This investigation is low risk, and it provides current benefits, and it provides a basis for a migration. And it provides you with some idea of how much you are spending and what you might spend and might save.

New boxes are cheap.

New custom applications and ports and moderate- and large-scale migrations are not. Business-level outages are expensive. Unexpected regulatory-level outages are off the chart.

But do look at TCO. Current and proposed. If you should end up with only fifteen boxes managed per support staffer and substantial efforts upgrading platform and application software, you are (probably) not going to make your CFO as happy as you could have.

Client-server isn't always popular with the folks selling higher-powered client hardware, but it works.

Arch_Muthiah
Honored Contributor

Re: Modernizing legacy stuff

Wim,

It needs big resources and time. US Dept Education's Student Direct Loan Servicing application and their Guarenteed Loan system have been developed using OpenVMS/COBOL/Rdb/RMS, it is very large application running throughout the US and involve in millons of transaction daily with so many govt. financial institutions, Banks, IRS, many collections agencies.

The Anderson consulting and ACS Inc started moderinize this application in 1998 using Oracle/VB/Java, even after 9 years, they still work on that. Recently I heard that ACS started its branch in India to share the Java related work. But the existing Rdb/COBOL/DECForms based system just works fine.


Archunan
Regards
Archie
labadie_1
Honored Contributor

Re: Modernizing legacy stuff

Wim

Have a look at

http://vmspython.dyndns.org/personnel/

use demo demo as user and password

This shows the "famous" Personnel database, available with any Rdb installation, easier to access than with a VT, issuing SQL commands
(select ... from ... where ...).

Wim Van den Wyngaert
Honored Contributor

Re: Modernizing legacy stuff

Labadie (still 2 bottles left at home),

Great but not the kind of stuff I was thinking of. I think about VT screens filled with info coming from about 50 tables, with complicated interfield validation, description showing on entry of a field, use of the window line, etc ...

On HP3000 I once used "block mode" that resembles your demo applic. But then you had many forms for 1 screen (in fact a form for every group of fields that you had to enter at the same time). That gave complicated screens with at least 10 forms that were difficult to manage.

Wim

Wim
Richard J Maher
Trusted Contributor

Re: Modernizing legacy stuff

Hi Wim,

If you're willing to allocate a ~day of your time then I can get a worthy example up and running on one of your test boxes.

Seeing is believing!

Cheers Richard Maher.

PS. Isn't ElanIT part of Manpower now or is it different on the continent? Ever had anything to do with Adrian Derx?
Wim Van den Wyngaert
Honored Contributor

Re: Modernizing legacy stuff

Elan is the company that pays me. I have no further contacts with them but I think it's part of Manpower. So, no idea who Adrian is.

Could you give me more details of what you mean ?

BTW : I'm just curious, not a soul is thinking of doing it over here. VMS must go out ASAP.

Wim
Wim
Jan van den Ende
Honored Contributor

Re: Modernizing legacy stuff

Wim,

>>>
VMS must go out ASAP.
<<<

I recognise that!

I was contracted for 6 months, with an option for 3 more, and a task description "Maintain the remainibg VMS applications at survival level while the stuff gets ported to Unix or Microsoft"
Well, VAXen were replaced by Alphas ("that is OK, When no longer needed for VMS they can run Tru64").
The cluster still run VMS, recently celebrated 10 year uptime, and has more apps running than there were 12 years ago...

It do not think it will happen overnight.

fwiw,

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Robert Gezelter
Honored Contributor

Re: Modernizing legacy stuff

Wim,

I have a healthy respect of the unknown. I echo many, if not most, of Hoff's comments.

There are several ways to "modernize" applications. Screen scrape middleware of some sort is one solution. Another solution, which admittedly requires some analysis, is the segmentation of the code into screen handling and non-screen handling components. Once this has been accomplished, the screen handling code can be replaced with a web-centric layer.

Importantly, since the underlying code has not been changed, it is possible for BOTH the screen and the web-based versions to co-exist for whatever time is necessary, decoupling the questions of infrastructure change and personnel training from the project plan.

Decoupling is one of the most underrated, yet most important aspects of this type of transition. The opposite, namely coupling of the issues in different areas, is often a reason for overruns, large costs, and project failure.

In technical terms, one of the most important OpenVMS technologies underlying this type of approach is the shareable library facility. I described a technically similar approach in my 2000 Compaq Enterprise Technology Symposium presentation, "OpenVMS Shareable Libraries: An Implementor's Guide"; see http://www.rlgsc.com/cets/2000/460.html

In summary, it can be done, but it is necessary to do it in such a way that it is non-disruptive.

- Bob Gezelter, http://www.rlgsc.com