× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




Hi Jon,

I've done quite a bit of Java batch programming on and off the AS/400,
things like image indexing, billing monitors and billing, monitoring for
messages from an RPG database trigger to process incoming items for faxes
out, grabbing data, investigating zip files, reprocessing and FTP'ing
multiple files out, generating notification messages as data comes in, and
so on. Almost all of it hit the database, all of it in production
environments. So my answer is that Java is viable.

You do need to have people, or at least someone, who understands Java,
JDBC, SQL and batch processes in general. To repeat an old song, if you get
programmers who just write RPG, COBOL, name-your-language, programs in Java
syntax, you're going to have problems and lose out on a lot of productivity
enhancements.

I agree with David that it is very helpful to think of Java as a server,
although I'd be very surprised if sockets were optimal, for the same reasons
that a type 2 JDBC driver typically outperforms a type 4: TCP/IP ends up
being another Yet Another layer. OTOH, I believe Oracle recommends using
pure Java drivers because of the overhead of JNI context switching. Then
again, it's Oracle. More typical is "messaging" of some description, either
data queues or native messaging, which I normally use.

Knowledge of threading can also be *very* helpful. I've seen someone
here say threads are easy. If you can use all local variables and have no
contention, they can be not too difficult; otherwise, you need someone who
understands the issues very well.

Since you wouldn't be tied to WebSphere, you should also be able to take
advantage of JSE 6, which has continued performance enhancements. For a
serious batch processing system, I'd also look to JVM tuning, probably
something like a shared connection pool, and take advantage of batch updates
as a start.

Of course, what do I know? I still (almost always) use the cycle in RPG batch programs...


Joe Sam

Joe Sam Shirah - http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum: http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International? http://www.jguru.com/faq/I18N
Que Java400? http://www.jguru.com/faq/Java400

----- Original Message ----- From: "Jon Paris" <Jon.Paris@xxxxxxxxxxxxxx>
To: "Java400" <java400-l@xxxxxxxxxxxx>
Sent: Monday, March 17, 2008 3:18 PM
Subject: Java as a batch language on System i ?


Have any of you had much experience using Java in a batch environment
on the System i?

Much of the customer's workload is batch - currently written in
COBOL. They are experiencing problems in getting experienced COBOL
programmers and this situation is likely to be exacerbated as their
in-house pool shrinks when their mainframe applications are replaced
during the 2008 - 2009 timeframe.

Everything else in the shop is Java WebSphere (but not on i). They
want to keep the data on the i but need to address the programmer
problem.

My gut tells me that the Java performance will be an issue - but I
have no experience to back that up one way or the other. COBOL
already outperforms RPG in batch and I've never seen a Java program
beat out RPG performance wise so ... but if somebody has some
experience that suggests that Java is viable as an option in this
arena I'm more that happy to be wrong.

No religious wars please.

Jon Paris

www.Partner400.com
www.SystemiDeveloper.com





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.