× 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.





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 thread ...


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.