RE: QZDASOINIT

>From: Andy Nolen-Parkhouse [mailto:aparkhouse@attbi.com]
>Is it possible that your application has around 800
>database connections open concurrently?  I'm not a
>Java coder so I don't know much about whether a database
>connection needs to be explicitly closed within the application.

As a technical matter you do not have to close connections in java. When the
connection object is no longer referenced it will be eligible for garbage
collection. When it's cleaned up via GC the connection will close. However,
from a practical point of view you do need to close connection. Garbage
Collection runs when Garbage Collection feels like running, so if you finish
with a connection GC may clean it up in 2 seconds, or 2 minutes, or 2 hours
or 2 days, there is no way of knowing. If YOU close the connection YOU
control the release of those resources.

Given that he mentions 40 modems I'd guess it would be reasonable for there
to be 40 connections at any point in time. I'd guess the polling app is a
multi-threaded app and I'd guess one thread per modem. The thread connects
to the AS/400, calls the store, does the updates and moves on. I would
expect the thread to close the connection, but it may just abandon it and
expect GC to clean it up. 800 jobs is probably the result of numerous opens
w/o closes and a periodic GC to clean them up.

Steven, if you end the polling application (and thus the JVM) this should
force a GC on JVM shutdown. If you do this the jobs should all go away, have
a look. I'd suggest one of 3 options:

1) Ignore the problem. GC will get there eventually. (BAD)
2) Change polling app to explicitly close the connections (BETTER)
3) Change polling app to use connection pool. This way the same QZDASOINIT
jobs will service the threads not a new one for each thread. (BEST)

-Walden

------------
Walden H Leverich III
President
Tech Software
(516) 627-3800 x11
(208) 692-3308 eFax
WaldenL@TechSoftInc.com
http://www.TechSoftInc.com



-----Original Message-----
From: Andy Nolen-Parkhouse [mailto:aparkhouse@attbi.com]
Sent: Wednesday, April 03, 2002 08:00
To: midrange-l@midrange.com
Subject: RE: QZDASOINIT


Steven,

Assuming that the polling application is initiating the jobs, QZDASOINIT is
processing a JDBC request against your database and then returning the
results to your program.  I am assuming that your polling application works
against a DB2 database.  Is it possible that your application has around 800
database connections open concurrently?  I'm not a Java coder so I don't
know much about whether a database connection needs to be explicitly closed
within the application.  The QZDASOINIT program will process IP-based
database requests from other sources as well as JDBC.

The maximum number of uses (200) specifies how many times a pre-start job
can be reused before the subsystem ends the job.  You can assume that the
800 jobs did not reach this limit.  If it is reasonable for your application
to have this number of database connections active, then what you are seeing
is reasonable.  You might want to increase the initial number of jobs, the
threshold, and the additional jobs parameter so that more jobs are created
less frequently.

Regards,
Andy

> Subject: QZDASOINIT
>
> Could anybody explain how QZDASOINIT actually works. There is
virtually no
> reference to the procedure in the manuals.
> The reason why I am requesting this info is that we have a server
> connected to the AS400 running some polling software on this (in Java)
> Attached to the server are approximately 40 modems , polling around
5000
> sites each night.
> QSERVER is recycled at 19:30 each night , but I have noticed that each
> morning (after the nightly polls) QSERVER has around 800 QZDASOINIT's
> running underneath the subsystem. I am not sure if these amount of
> jobs should be open ?
>
> So I am after a little bit more understanding on exactly what this job
> does.
>
> The job runs with user profile QUSER (we had to change QUSER max temp
> storage to *NOMAX - as we had a connection problem)
>
> Under QSERVER the prestart job entry detail is as follows
>
> Subsystem description:                QSERVER                 Status:
> ACTIVE
>
> Program  . . . . . . . . . . . . . . . . . . . . :
QZDASOINIT
>
>       Library  . . . . . . . . . . . . . . . . . . . :
QIWS
>
> User profile . . . . . . . . . . . . . . . . . . :            QUSER
>
> Job  . . . . . . . . . . . . . . . . . . . . . . :
QZDASOINIT
>
> Job description  . . . . . . . . . . . . . . . . :            *USRPRF
>
>       Library  . . . . . . . . . . . . . . . . . . . :
>
> Start jobs . . . . . . . . . . . . . . . . . . . :            *NO
>
> Initial number of jobs . . . . . . . . . . . . . :            1
>
> Threshold  . . . . . . . . . . . . . . . . . . . :            1
>
> Additional number of jobs  . . . . . . . . . . . :            3
>
> Maximum number of jobs . . . . . . . . . . . . . :
> *NOMAX
> Maximum number of uses . . . . . . . . . . . . . :            200
>
> Wait for job . . . . . . . . . . . . . . . . . . :            *YES
>
> Pool identifier  . . . . . . . . . . . . . . . . :            1
>
> Class  . . . . . . . . . . . . . . . . . . . . . :
QPWFSERVER
>       Library  . . . . . . . . . . . . . . . . . . . :
QSYS
>
>       Number of jobs to use class  . . . . . . . . . :
> *CALC
> Class  . . . . . . . . . . . . . . . . . . . . . :            *NONE
>       Library  . . . . . . . . . . . . . . . . . . . :
>
>       Number of jobs to use class  . . . . . . . . . :
> *CALC
>
>
> Any help would be appreciated.
>
>
>
> Regards
>
> Steven Gray

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.