I see what you are saying now. That is sort of the approach we are taking. We want to push it into .Net and use things that are not perfect to get it to work. Then gradually correct the code as we go forward. Similar to pushing it into COBOL with the same issues that we have been discussing here, except that we want to push it into .Net first, add what we need to get it to work, the go back and remove things like the properties solution to data structures as time permits.
The advantage of this is that we can push it into .Net directly, add a few things to make it work... similar to how COBOL for .Net would do it. Our advantage is that we can go ahead and push it directly into .Net and get a LOT of the code working. On average I can get about 90% of the code over into .Net now. That alone is worth a lot more than pushing it into COBOL. I'm not even sure that 90% of the code would be supported in COBOL. And you'd have to have developers that could read and understand the COBOL in order to rewrite it going forward. The advantage of pushing it directly into .Net is that you only need .Net developers... and most of the code already works. Same idea, just not using the COBOL syntax. -----Original Message----- From: Itay Zandbank [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 9:29 AM To: Jon Rothlander Subject: RE: Data Structures in .Net? Obviously that's not what I'm suggesting. I'm suggesting they use a COBOL.NET variant (if a decent one exists) to ease the transition into a full-blown .NET solution (in a non-COBOL language). If the COBOL code is running under .NET OK (obviously this transition will cost money, for testing), you can start translating the system one part at a time. The transition will be easier (you'll be replacing discrete components, which are easier to test) - and throughout the transition period they will have a working system (each time with more .NET and less COBOL). -----Original Message----- From: Jon Rothlander [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 6:24 PM To: Itay Zandbank Subject: RE: Data Structures in .Net? COBOL for .Net? Yeah right. That's a joke. Are you suggesting that a company build their company and future around COBOL? Let me be a little negative here. So what I need to tell them is that they need to take their .Net development staff and retrain them in COBOL.Net? Knowing that no one remembers how to write COBOL anymore and that it will take 10 times as long to maintain in COBOL. At the end of the day, a client isn't going to go with COBOL if the plan on the software having any life at all. Building your company and software based on COBOL is probably not the best way to move forward. -----Original Message----- From: Itay Zandbank [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 1:51 AM To: Jon Rothlander Cc: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: RE: Data Structures in .Net? Well, in that case, if there is indeed a reasonable COBOL.NET, why not use it? They can later, if they feel like it, migrate bit by bit, but they'll get a working .NET solution relatively quickly (and I'm pretty sure it won't cost them $600,000). -----Original Message----- From: Jon Rothlander [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 5:48 PM Subject: Re: 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(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com <html><body><center><hr><b><font face=arial size=2>Visit the Tel Aviv Stock Exchange's Website<a href=http://www.tase.co.il> www.tase.co.il</a></b></body></html> <html><body><center><hr><b><font face=arial size=2>Visit the Tel Aviv Stock Exchange's Website<a href=http://www.tase.co.il> www.tase.co.il</a></b></body></html> =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
