It is not a performance or ressource problem but a cost problem. Our 4 CPU's are more or less sleeping during the night. This cpu ressource is almost "free".
On the other hand, the price of running our batch applications (cobol) on z/OS is very high and difficult to reduce. 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. Best regards, Herve Bonvin -----Urspr�ngliche Nachricht----- Von: David Boyes [mailto:[EMAIL PROTECTED] Gesendet am: lundi, 10. mars 2003 20:06 An: [EMAIL PROTECTED] Betreff: Re: Java on zLinux for batch processing > We have great sucess with java on zLinux at the moment and > after the migration of several application servers, the next > step would be to migrate batch applications (cobol). > The idea would be to use java to replace cobol. This way we > would have only one language and we could use our IFL's > during the night. Not knowing what your applications are, it's hard to say whether they would adapt well to the Java programming model, but not everything does, and moving apps to solve a performance and/or resource problem isn't going to make it any better; it'll just move the problem somewhere else. You could convert your COBOL apps, but I don't see much advantage in it. If you're solving a performance issue, you've just traded one set of maintenance headaches for a different set, and what happens to you when Java is no longer the cool language and you can't get Java programmers either? > Has someone tested the use of java for batch applications ? Yes, with mixed results. For most interactive tasks, there's no significant improvement in performance, and for batch record-processing apps, the JVM overhead imposes a lot more resources to solve the same problem. > What for job scheduling system (like OPC) are available under zLinux ? CA's Autosys, and BMC also has a product that I haven't tried. From the open-source world, there's NQM (used by most of the supercomputing centers), good old cron/at (not usable for production). -- db
