|
Seems like you probably have the rpg program written as RPG ILE programs and that they were created with *NEW as the activation group, instead of *CALLER or a defined activation group. I do not know enough information about your systems but this is a good guess. Atul Ghanekar <atul.ghanekar@mphasis.com> on 06/23/2000 12:20:45 AM Please respond to JAVA400-L@midrange.com To: JAVA400-L@midrange.com cc: Larry Loen <lwloen@vnet.ibm.com>, dawall@us.ibm.com (bcc: Robert Arce/Whittman-Hart LP) Subject: Re: How many active Jobs ? Thanks for the input. Since, I am new to JAVA toolbox on AS/400 let me explain in more detail: We will be writing a Servelt which will include HTML for the Workstation part of the program being called and after accepting the input from the screen, I will pass them as a Parameter and CALL corresponding *PGM Object. Now, my problem is : Since we are Web enabling the legacy application on AS/400 every time I call this Servlet it will either call a Interactive program or a non-interactive program. So, in both the cases, If I do WRKACTJOB on AS/400 will I get those many entries as many times a program is being called ? Regards, Atul ----- Original Message ----- From: <dawall@us.ibm.com> To: <JAVA400-L@midrange.com> Sent: Thursday, June 22, 2000 10:58 PM Subject: Re: How many active Jobs ? > The number of jobs depends on how you call the program. > > One choice is to have a central / single Java job that catches the > requests then call the COBOL program via JNI. When you use JNI all > processing stays on the same thread. If you have a thread for each user > then you have only one job, just a lot of threads. If you use this > model you have two important considerations. (1) Identity -- by > default, each call to the COBOL program will run under the user profile > of the java job. If you need to preserved the identity of the user then > you have to swap the identity of the thread before calling the program. > (2) Thread safety -- your COBOL program will be called multiple times in > the same job. Is it thread and object safe? For example, if the COBOL > program creates an object in QTEMP, the QTEMP will be the same for each > thread (there is only one QTEMP per job). You could easily have object > collisions. > > Another choice is to have the central Java job use the Toolbox > ProgramCall object to call the COBOL program. ProgramCall is performed > via an OS/400 server. There is one server job per Toolbox AS400 object > so you can control the number of jobs. For example, through connection > pooling you can put a limit on the number of connections (jobs). If > your threshold is reached, new reqeusts would wait until an active one > completes. If you don't use connection pooling there will be one active > job for each concurrent program call. The good news is since each > server is in its own job, you have thread safety. Also, since the > Toolbox preserves identity, each program can run as a different user. > The bad news is there will be more jobs. > > Another choice is one Java job for each user. With this case you can > preserve identity and it will be thread safe. Besides having more jobs, > another thing to watch for here is the performance of starting the Java > job. It can take measurable time to start the JVM. > > Hope this helps, > > David Wall > AS/400 Toolbox for Java > > > "Atul Ghanekar" <atul.ghanekar@mphasis.com> on 06/21/2000 11:48:07 PM > > Please respond to JAVA400-L@midrange.com > > To: JAVA400-L@midrange.com > cc: > Subject: How many active Jobs ? > > > > > Hi > > I am posed with a problem : > I am supposed to make one As/400 based legacy system Web enabled but by > making use of existing COBOL programs logic. > So only choice is to call Cobol program from a JAVA program (Wrapper). > Our problem is there are 100's of users who will be making calls to this > cobol program > so does that mean that many active jobs are there on AS/400. Like in JAVA > single thread > will take care of such situation. What happens on AS/400 ? > > Regards, > > Atul > > +--- > | This is the JAVA/400 Mailing List! > | To submit a new message, send your mail to JAVA400-L@midrange.com. > | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. > | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. > | Questions should be directed to the list owner: joe@zappie.net > +--- > > > > +--- > | This is the JAVA/400 Mailing List! > | To submit a new message, send your mail to JAVA400-L@midrange.com. > | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. > | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. > | Questions should be directed to the list owner: joe@zappie.net > +--- +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +--- +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
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.