If something like COBOL.NET has been created, it ought to be to solve problems such as these ...
Why not do a first batch conversion of all COBOL code into COBOL.NET assemblies, for example Company.TheSystem.TheComponent.Legacy ? Then you can wrap this ugly converted code into real OO classes so that the idiosyncrasies of COBOL will not contaminate all your system. Then over time, if the legacy code really does cause problem, you can progressively convert it to real OO code. And like Frans Bourma, I would be curious to see the famous generated Java code. It strikes me as something really odd that government and companies want to rewrite their systems in one big doom-to-fail-or-cost-double-project instead of using black boxes and doing it progressively with a much lower risk. There is a reason why most banks still run on mainframes with 30 years old code. Sébastien > -----Original Message----- > From: Discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of Jon Rothlander > Sent: Tuesday, November 14, 2006 11:48 PM > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > Subject: Re: [ADVANCED-DOTNET] Data Structures in .Net? > > I just wanted to point out the reason we are doing this because a > number of post have suggest not try this at all. Here's the basic > reasoning behind attempting to this and not just wanting to rewrite it. > > The options for the client are really pretty simple. If there is no > solution in .Net, the client will simply throw out .Net as a solution, > as .Net doesn't look like it can handle this. They would have the > option of working with other .Net languages such as COBOL for .Net, > which kind of destroy the whole point of moving to .Net in my opinion. > So I find it hard to recommend that to a client. > > The odd thing here is that this is being done in Java without any > issues... > or at least the issues where not big enough to throw out the solution. > So in my opinion the client would simply choose Java over .Net > since .Net cannot handle this. The estimates that we are coming up > with are about $20M to rewrite and about $300K to $600K to migrate the > code in Java. So it would be hard for a $10M company to pick .Net over > Java with the price tag of $20M compared to $600K. No matter how many > points we give them in regards to how .Net compares to Java, the price > tag along will kill it. > > > I don't know how Java is able to do this, but it does. There are > legacy tools to translate this code into Java... and they work. > Whatever solution the Java tools are using would seem to be something I > could use in .Net. > Maybe that's the direction I should go with this. De-engineer a Java > solution. > > =================================== > This list is hosted by DevelopMentor. http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
