>>Why is this project being undertaken, BTW? I mean, why not just do it in >>COBOL? Or for that matter, why not just built an emulator for the old >>hardware, and keep running the old stuff?
The answer to your question should be obvious. The client doesn't want to. Who wants to write COBOL in .Net versus VB or C#? How many people can write COBOL these days? How many people would want to maintain a COBOL app versus a .Net app? COBOL takes 10 times longer to develop and 10 times longer to maintain. Why move it at all of you are just going to end up with the same thing running in .Net? There are emulators, screen scrapers, and modern systems to keep the COBOL running. No one wants that. They have been around for some time and no one wants them. Most that have tried, have failed. At least that's been my experience. If .Net cannot deliver, then Java can. IBM has had the Java tools available to port the code for years now. The clients will choose that solution if they have to, but they would rather go with a .Net solution if possible. What about this? If COBOL can do this, then it creates iLCode that does this and works. That iLCode is the same iLCode that VB and C# outputs. So whatever solution COBOL is using to create the data structure, why can I not do the same thing in VB or C#? Why would I have to write it in COBOL if in the end it's just all iLCode anyway? Maybe I'll download COBOL for .Net and decompile some of the code to see how they accomplish this. My guess is that they are using some unsafe code. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
