Re: COBOL to Java conversion



"HansJ" <hjigel@xxxxxx> wrote in message
news:1193659579.442522.126090@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
We are in the business of migrating Unisys COBOL mainframe
applications to Unix.

You are not alone... :-)

There are several COBOL people in this newsgroup with specific Unisys
experience and at least one of them is currently working in Java.

Using the same programming language and keeping the code intact is a
key element, because we think that there are enough issues to deal
with.

You are right. At least initially.

Recently we have seen requests to not only move to a different
platform, but also to change the language to be Java.

This is a change of paradigm. It has risks and benefits. As you have asked
us not to discuss it, I won't.

We don't need to discuss all the issues that come with a language
change, like maintainability, staff competence, etc. as this is a
different topic.
I would be interested in knowing if anyone has seen a successful
project of this type that has a significant size.
A significant size would be more than one million lines of COBOL code.

I have not personally seen or worked on a Unisys conversion to Unix,
although I have been laterally involved in some conversions on other
platforms.

Here is some free advice (definitely worth the price...but bear in mind that
I make a living out of giving advice and helping it get implemented :-)).

1. Ask yourself WHY you need to do this. If the answer is "Because then we
can move to an OO language like Java." then you need to ask yourself WHY you
need to do that. Doing this will establish WHERE you are going and WHY. It
is very important to have a clear vision of what you want.

(It isn't just about technical platforms. If you want the company's IT
systems to be responsive to change and able to deal with fiercely
competitive market places, you might need to consider a much broader
picture. Should you be using in-house developed software at all? What about
web services? Packages? Saas? My point is that it is pretty sad if you
invest considerable time and money in changing a technical platform, only to
find that the whole way in which you currently develop stuff is not
conducive to what the company actually wants/needs, or that the future for
the company lies in web based services and your expensive conversion to Unix
and even to Java fails to achieve this.)

2. If you are looking at converting in the hope of extending the life of the
existing systems, how will running under Unix achieve that?

3. If you are not ready to write off your existing codebase, maybe what you
SHOULD be considering is how best to leverage and re-factor what you have.
(This MIGHT involve a conversion to Java or it might not. Either way, the
tail doesn't wag the dog; hence my point about clarity of vision above. Be
very clear about WHERE you are going and WHY, before you sign any cheques.)

BOTTOM LINE:

Don't let technical staff decide how the company's IT systems should work;
they will see only a technical solution. :-)

Get a steering committee involving senior management to sit down and
formulate what they need, in Business functional terms. (One way to do this
is to get them to look at what is good and bad about the existing systems.
Don't take it personally and don't be defensive; the objective is to find
out what is REALLY needed and wanted, not to castigate IT over past
history). Make sure you elicit what is really important to them.

Explore weaknesses in existing systems and what would be needed to enhance
them, in Business terms only. You are considering major investment; tell
them to make time for it. Make sure that strategic direction for the Company
is included in what emerges.

Take the general directions and goals from the steering committee and relate
them back to existing systems. This will help you decide how much of what
you have is worth re-factoring and how much needs new development, or even a
new approach.

THEN get your technical people to explore options for achieving each of the
stated goals. Make sure that every goal has at least three options, even if
some of them are not very attractive... The objective is to get people
thinking outside the square and not just proceeding with what they've always
done... a "New Deal" for the IT department.

Consider Client/Server solutions as well as mainframe based ones, for
specific systems. (For example, you might find it very cost effective to
re-factor some of your existing COBOL onto a Client/server platform which
you can wrap as a web service and reuse throughout the company... or you
might not. The point is, that options need to be explored, evaluated and
costed, rather than just proceeding with "business as usual".)

You may find that the money you would have spent on a Unix/Java conversion
can be much better spent in other ways. The days when a single corporate
software solution, based around a single corporate platform, was the only
option, are long gone. If you don't HAVE to put all your eggs in one basket;
why would you?

Stay goal oriented and ensure that your people do too.

It is a criminal waste of resource to do something in IT purely because it
is the perceived wisdom, or because "everybody's doing it", or because your
tech people want something "fashionable" on their CVs :-)

Viel Gluck!

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages

  • Re: COBOL to Java conversion
    ... experience and at least one of them is currently working in Java. ... platform, but also to change the language to be Java. ... I have not personally seen or worked on a Unisys conversion to Unix, ... Changing a technical platform might have many reasons, ...
    (comp.lang.cobol)
  • Re: Strange problem when using a class module in VBScript
    ... > problems and is faster than Windows and VB/VBA. ... > which is essentially their version of Java. ... > The Wintel platform has been a series of compromises to preserve backwards ... Unix boxes are often faster, but it has nothing to do with Java. ...
    (microsoft.public.vb.general.discussion)
  • Re: Strange problem when using a class module in VBScript
    ... >> problems and is faster than Windows and VB/VBA. ... >> Even Microsoft is acknowledging this in developing their .NET platform, ... >> which is essentially their version of Java. ... > Unix boxes are often faster, but it has nothing to do with Java. ...
    (microsoft.public.vb.general.discussion)
  • Re: Linux Sys Calls - int 80h
    ... basically ready in time for the first port of UNIX to ... The developer will not pay the cost; ... Then, out of the blue, the manufacturer of the platform your OS ... OSes, you are ignoring the very real, and very large, costs ...
    (alt.lang.asm)
  • Re: Free UNIX for non-commerical use.
    ... but if the person knows a platform well he's MUCH ... very often that person is a sysadmin.. ... sysadmin coz he played around with some unix at home from the beginning. ... I would never had become a sysadmin if I didnt play around with computers ...
    (comp.unix.solaris)