|
My personal opinion is it comes down to skills and platform independence. If this application will run only to the iSeries and you do not have JDBC skills then command call is the way to go. In your case CC will probably be faster and easier to learn. If you need (or will need in a 'short' amount of time) this application to run to multiple types of servers then it is worth the time to do JDBC and use stored procedures. One other thought, be careful if you use connection pooling. Most connection pooling implementations are refined only to the user level. Your application is different because it needs job-level refinement. Suppose you have 10 connections for a specific user in the pool. Each connection probably represents a different job on the server. If you do work on a connection, put the connection back to the pool, then retrieve a connection to do more work, the odds are small that you will get the same connection you retrieve the first time. You have "a" connection for that user, but you don't have "the" connection. You will have a different job so work previously done on the connection does not show up. David Wall Toolbox for Java iSeries ODBC Driver for Linux "David Morris" <David.Morris@plu To: <java400-l@midrange.com> mcreek.com> cc: Sent by: Subject: Re: Server Jobs java400-l-admin@m idrange.com 04/02/2002 10:28 AM Please respond to java400-l David, Not too late at all, I am still experimenting. I am working on a native version of Ant for the iSeries. I really don't know how many or what commands to expect. I have a wrapper that could do setup and cleanup. As far as abnormal ends, etc. I can register a cleanup exit program and/or use a scope message at the job level if necessary. A timeout is reasonable, and could be configurable in the design that I have. Right now, I am concentrating on the tasks necessary to compile from CVS. The CRTRPGMOD command threw a curve because it will not run in a multi-threaded environment. I am having a hard time deciding whether Lo's suggestion to use JDBC is worth pursuing. I already have a server built that can run commands but it is geared toward CL and RPG. I could extend that to integrate better with Java. What would you suggest for running the commands? I can use CommandCall or right now I have the code set up to use a CallableStatement. That is just what I have tried. The command call seems to work well because of the message support, but that doesn't mean that CallableStatement or ? could not do the same thing. Thanks, David Morris >>> dawall@us.ibm.com 04/02/02 08:14 AM >>> One question (sorry this is late but just got back from vacation) -- how far apart are your commands? Each AS400 object represents a connection to a single server job. As long as the connection stays up all commands will be handled by the same job. So, a set of commands run through the same AS400 object will run in the same job as long as the connection does not drop between commands. Using the same AS400 object may not be practical if there is a lot of time between commands, but it should work for commands that are close (especially of the connection is reliable). David Wall Toolbox for Java iSeries ODBC Driver for Linux "David Morris" <David.Morris@plu To: <java400-l@midrange.com> mcreek.com> cc: Sent by: Subject: Server Jobs java400-l-admin@m idrange.com 04/01/2002 11:15 AM Please respond to java400-l Group, I have a Java program that needs a specialized environment to run several CL commands. If I use the CommandCall class, I get a new job for each command. I could submit my own server that processes these commands and then end it when I am done, but this seems like it would be such a common task, I thought I would check to see if I missed it in the toolbox or if anyone else has tackled this. The command call class works very well for what I am doing except that I cannot reconnect to the same server. One solution I am thinking about is a submitting a job that sits on a data queue waiting for commands and returning messages and completion status of each command. Thanks, David Morris _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l. _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l. _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.
As an Amazon Associate we earn from qualifying purchases.
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.