Re: RE : Java on zLinux for batch processing
> *** Reply to note of Thu, 13 Mar 2003 07:05:20 +0100 > *** by [EMAIL PROTECTED] > > The Linux Journal had an article on gcj (Jan 2003): > > http://www.linuxjournal.com/article.php?sid=4860 > > One thing lead to another: PERCobol PERCobolTM Enterprise Edition is a robust COBOL development solution enabling COBOL programs to execute on the Java Virtual Machine (JVM). PERCobol is a fully ANSI 1985 X3.23b standard compliant COBOL compiler which generates Java source code. The resulting Java source code can then be compiled using any JDK 1.1+ compliant Java Compiler and will run on any JDK 1.1+ implementation of the Java Virtual Machine as either an applet or application depending upon how the program is invoked (applets are subject to applet security restrictions). lead to http://www.legacyj.com/lgcyj_perc1.html -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
RE : Java on zLinux for batch processing
*** Reply to note of Thu, 13 Mar 2003 07:05:20 +0100 *** by [EMAIL PROTECTED] The Linux Journal had an article on gcj (Jan 2003): http://www.linuxjournal.com/article.php?sid=4860 sal Herve Bonvin <[EMAIL PROTECTED]> writes: >I had a meeting with the developers and they are not very please with = >the idea to use something else as java. >We place great hopes in the new java.nio package which should improve = >the io operations. It is jdk 1.4. I don't about gcj and jdk 1.4 but we = >will have a look.=20 > >I will let this list know about the result of our tests. We will test = >java versus cobol/delta (delta is a cobol generator used by our = >developers on z/OS). Perl, cobol on CMS are not an option because of = >lack of knowhow, IDE's ...=20 > >Thanks for all the informations I received from this list, >Herve=20 > > > >-Original Message- >From: John Summerfield [mailto:[EMAIL PROTECTED] >Sent: Thursday, March 13, 2003 3:55 AM >To: [EMAIL PROTECTED] >Subject: Re: Java on zLinux for batch processing > > >> >> > Portability is also an important factor for us. Once the batch is=20 >> > running on z/OS, the migration to other plateforms is very=20 >> > difficult. If the batch is running on linux, the choice for future=20 >> > migration is much better. >> >> That's a slightly different problem, however -- batch on Linux vs=20 >> converting to Java. Converting to Java doesn't make applications that=20 >> much more portable -- you're just dealing with a different set of=20 >> porting problems. (try running a application built with the Sun JVM on = > >> a Windows system sometime -- Java isn't *that* portable). Running=20 >> batch on Linux is the same problem as running batch on any other Unix=20 >> system. >> >> As I said, our results with batch Java apps is pretty mixed. Your=20 >> experience might be better, but there are a lot of issues that tend to = > >> make it not worth the effort. > > >For java in batch applications, it's worth considering gcj, part of the = >Gnu Compiler Collection. If that's not up to snuff, consider hiring = >someone to help get it fixed. Bearing in mind the expense of any = >rewriting, I think that that wouldn't be a great additional burden. > > >By using gcj, you will get the performance benefits of compiled code = >with the coding benefits. > >I'm not a great fan of C, especially for anything Cobol and PL/1 can do = >well. >-- >Cheers >John Summerfield > >Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ > >Note: mail delivered to me is deemed to be intended for me, for my = >disposition. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D >If you don't like being told you're wrong, >be right!
RE : Java on zLinux for batch processing
I had a meeting with the developers and they are not very please with the idea to use something else as java. We place great hopes in the new java.nio package which should improve the io operations. It is jdk 1.4. I don't about gcj and jdk 1.4 but we will have a look. I will let this list know about the result of our tests. We will test java versus cobol/delta (delta is a cobol generator used by our developers on z/OS). Perl, cobol on CMS are not an option because of lack of knowhow, IDE's ... Thanks for all the informations I received from this list, Herve -Original Message- From: John Summerfield [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 3:55 AM To: [EMAIL PROTECTED] Subject: Re: Java on zLinux for batch processing > > > 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. For java in batch applications, it's worth considering gcj, part of the Gnu Compiler Collection. If that's not up to snuff, consider hiring someone to help get it fixed. Bearing in mind the expense of any rewriting, I think that that wouldn't be a great additional burden. By using gcj, you will get the performance benefits of compiled code with the coding benefits. I'm not a great fan of C, especially for anything Cobol and PL/1 can do well. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
Re: Java on zLinux for batch processing
> > > 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. For java in batch applications, it's worth considering gcj, part of the Gnu Compiler Collection. If that's not up to snuff, consider hiring someone to help get it fixed. Bearing in mind the expense of any rewriting, I think that that wouldn't be a great additional burden. By using gcj, you will get the performance benefits of compiled code with the coding benefits. I'm not a great fan of C, especially for anything Cobol and PL/1 can do well. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
Re: Java on zLinux for batch processing
> C/C++ is also an option if java performances are really too bad. > Our online transactions run on Websphere/ejb/java, so java > would be ideal for our developers. Plain C is probably more portable at this point. > It is for a billing application which runs on z/OS at the moment. > Access/update will probably be with DB2 or file transfer. This would be a good application for DB/2 Connect. -- db
Re: Java on zLinux for batch processing
> 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
Re: Java on zLinux for batch processing
Why not use C/C++ instead of Java, if your programmers know it? It is "native" and has better performance. Of course, performance is not everything. Ease of coding and maintenance may make the decision for Java. Just out of curiousity, what sort of processing do you plan to do? Will it be for z/OS data? How will you access or update the information on the z/OS side of the house? I've been thinking about this sort of thing as well. -Original Message- From: Herve Bonvin [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 11:46 PM To: [EMAIL PROTECTED] Subject: AW: Java on zLinux for batch processing 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
Re: Java on zLinux for batch processing
On Tue, Mar 11, 2003 at 06:46:24AM +0100, Herve Bonvin wrote: > 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. > Have you considered other options? On unix, perl would probably have been my first option. It is well adapted to unix. It has also been ported to many other platforms. There are a number of other such higher-level languages (most notably python, but some would also point out ruby) Having worked with java and perl, perl is *my* first choice. -- Tzafrir Cohen http://www.technion.ac.il/~tzafrir/ mailto:[EMAIL PROTECTED] sms: mailto:[EMAIL PROTECTED]
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
Re: Java on zLinux for batch processing
On Mon, 10 Mar 2003 15:53:40 +0100, Herve Bonvin wrote: >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. >Has someone tested the use of java for batch applications ? I did look into it while I was with BEA - personally I wouldn't recommend it. Batch is often used to process e.g. millions of rows, and the java overhead, however small, will hit your performance. I understand the desire to have just one language for apps, but java for batch is not the right thing, IMHO. Just as IBMs CSP (anyone remember that one) wasn't all that hot in batch either. >What for job scheduling system (like OPC) are available under zLinux ? I don't know of any. Maybe cron? :-( Unix and Linux were never very batch-oriented. regards, Per Jessen, Zurich http://www.enidan.com - home of the J1 serial console.
