> It is not a performance or ressource problem but a cost problem. > On the other hand, the price of running our batch > applications (cobol) on z/OS is very high and difficult to reduce.
If you already have z/VM to support your Linux guests, look into whether IBM will special bid you the CMS COBOL compiler and support libraries. If the concern is to run existing COBOL apps and utilize a underutilized resource, that will be simpler and lower-cost than z/OS COBOL. I agree that z/OS resources tend to be overpriced -- but z/OS and Linux aren't the only operating systems on the platform. This method also avoids the large cost of rewriting existing working code. For new applications, I can sort of see your point, but not all JVMs are created equal, and portability is not what it should be for Java apps. > Portability is also an important factor for us. Once the > batch is running on z/OS, the migration to other plateforms > is very difficult. If the batch is running on linux, the > choice for future migration is much better. That's a slightly different problem, however -- batch on Linux vs converting to Java. Converting to Java doesn't make applications that much more portable -- you're just dealing with a different set of porting problems. (try running a application built with the Sun JVM on a Windows system sometime -- Java isn't *that* portable). Running batch on Linux is the same problem as running batch on any other Unix system. As I said, our results with batch Java apps is pretty mixed. Your experience might be better, but there are a lot of issues that tend to make it not worth the effort. -- db
