Modernizing legacy stuff

[Wim Van den Wyngaert]

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

[labadie_1]

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]

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]

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

[labadie_1]

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]

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

[Richard J Maher]

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]

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

[Jan van den Ende]

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

[Robert Gezelter]

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

[Hein van den Heuvel]

Wim>> Could you give me more details of what you mean ?

Hi Wim. I think that question is in reference to Richard's note.

I think his reference is a soft referral to two extensive replies he wrote today in:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1095466
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1110572

Be sure to check those out.
Hein.

[Wim Van den Wyngaert]

Hein,

OK but re-read my question. Who really did something important ?

Wim

[Hoff]

And then, who can talk about what they've done in any particular detail?

Put another way, your question isn't one I would or could answer, nor would I expect nor believe anyone else could. Without some idea of the code, it's difficult to predict what might be feasible and reasonable, and how much that effort might cost -- this ranges from zero to infinite, and the use of "billions" and "thirty years old" and other such implies relative values and relative effort rather larger than zero.

The first step here (regardless) is to document what you have in detail, including the current code and your business practices and your current burn rate for maintaining the environment, and -- and this often is the most difficult part of the whole endeavor -- start to nail down the particular project requirements; where you want to be, and particularly where you can get to.

Creeping project requirements or significant unspecified or undocumented or unknown existing capabilities will kill most any software effort.

Once you have some idea of what you have, then you can look at either an incremental upgrade or incremental migration, or if you should be forced into a rather more draconian migration (to a newer application, on or off OpenVMS)... And you'll have a far better idea of the scale of the effort.

The following are related (and high-level) thoughts and considerations:
http://64.223.189.234/node/225
http://64.223.189.234/node/226

DSM (and Cache) are good solutions. There are others. And you can have unmaintainable code in most any language and on most any platform. What you need to do to extricate the business practices and data varies. Widely.

[Richard J Maher]

Hi Wim,

[Wim> 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.]

Adrian was one of the founding fathers of Elan and a nice bloke who stayed a nice bloke after he sold Elan for squillions. Back in the early 90s when VMS was still king, he was the best pimp you could ask for in VMS's European market place. (And pretty technically minded for an agent) Anyway, not important.

[Hein>
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1095466
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1110572

Be sure to check those out.
]

Thanks for that Hein. They're definitely worth a read if I do say so myself.

[Wim>OK but re-read my question. Who really did something important ?]

I'm not sure this is the best place to come for customer testimonials, if that's what you're after Wim. But to answer your question directly, in a broader sense, let me just say "I did!".

I have simply come up with the best, most efficient, and easiest to implement, infrastructure for integrating you latest and greatest GUI front end with your rock-solid, high-performance, and secure VMS servers. Doesn't matter if it's Java, .NET, Browser-based HTML/Javascript, or another VMS box.

I've gone further than just joining up the dots and filling in the paint-color numbers for you; I have handed you the Mona Lisa in a frame and all I'm asking you to do is stick it up on your living-room wall for a while and see if it grows on you.

But here you're looking for previous experience(s) rather than potential solutions so I'll leave you to it. I just wouldn't be too suprised if both you and VMS are still there in 5-10 years time. Let's face it, support costs and staff have been reduced to such a level that it is no longer cost-effective to get rid of these VMS systems.

Cheers Richard Maher

PS. Is Belgacom still VMS?

[Wim Van den Wyngaert]

Yes Belgacom is still VMS. And make it 2-10 years (2=managemenet, 10=the old vms guys).

Wim

[Brad McCusker]

Wim (and others) -

I am aware of a few of these situations from my prior rolw in HP.

Send me mail offline and I can point you at the guy in HP who is very close to a few of these, and continues to work with a few customers doing this sort of effort.

Brad McCusker

Software Concepts International
www.sciinc.com

(mccusker at the domain above)

[Dean McGorrill]

>>>
I have simply come up with the best, most efficient, and easiest to implement, infrastructure for integrating you latest and greatest GUI front end with your rock-solid, high-performance, and secure VMS servers. Doesn't matter if it's Java, .NET, Browser-based HTML/Javascript, or another VMS box.
<<<
Right on. I've only been on the vms streets
a couple years since not working on vms, but
I've seen a few companies trying to leave
vms. On my last contract, they'd spent
millions on a replacement app that wasn't
working. I suggested they just update the gui. dunno what they wound up doing..

[Willem Grooters]

The MBA adagium: New = Better = Cheaper.

It doesn;t have to be.
Since most businesses do not basically change their field of work, it's quite likely that core business logic will not change. The basic rulkes for banking, insurence, shopkeeping - whatever - are basically unchanged in a few hundred years.
Changes do NOT need to be for the better. It's been tried fairly recently (remember boom dot com?).
What's often referred tp as 'modernize' is actually a matter of 'give it a nice, shiny, funky look'. Or its riding the waves of a hype.

Having said that, it doesn't mean it's all worthless. Most ofen, it requires good thinking in advance: what will you loose? If you do transactions, moving from a single straem of controlled access you have now, to a uncontrolled set of activities, probably, with all consequences in tracking, tracing, keeping thins consistent...Not to forget legal requirements, validation, accreditation, and that kind of stuff (SOX at al).

Working on badly documented systems is hard and costly, and it won't be cheaper if you re-develop the application (inclusing all related testing, validation, accreditation...) and put THAT into maintenance. Documentation will, again, be minimal and be outdated before you blink you eyes. And you're back where you once started.

[labadie_1]

[Sorry, this is out of subject]

I do not have a MBA, but I think this book is a very good one
http://www.amazon.com/Managers-Not-MBAs-Management-Development/dp/1576752755/ref=sr_1_6?ie=UTF8&s=books&qid=1217914168&sr=8-6

The company which had the highest percentage of MBA was Enron. A big success, as everybody knows :-)

[Wim Van den Wyngaert]

DSM is expected to finish before the end of the year (Management) or before the end of 2009 (the project team).

In Belgium we also had L&H (speach techno) ...

Wim (no bottles of labadie left)

[Dave Gudewicz]

Saw this product at a recent LUG meeting:

www.seagullsoftware.com

Basically took legacy applications and brought them from one century to another.

[Willem Grooters]

A word of warning?

http://reddevnews.com/devscope/print.aspx?editorialsid=935