For us, they appear to be tied directly to whatever IP address is connecting via ODBC. We have about 9 or so PCs running programs that connect, and we have 9 or so QZDASOINIT jobs. I believe they just remain idle until called upon to perform some ODBC job.

How many do you mean by “large number of jobs”?

On our JD Ewards EnterpriseOne machine each connection uses about 6 ODBC connections so there are upwards of over 500 connections at anytime and sometimes as high as 2000 ODBC conections but they are mostly in a wait state waiting for the connection to send data so no harm on the system. We have an equal amount of memory and processors to balance that many connections across.

Generally, these are pre-start jobs. The system starts a number of these when the subsystem starts, and adds more as needed. For example, it may start 10 jobs at startup They sit around waiting for a job to need them, then attach as needed. When and 11th is needed, the system starts 10 more (actual number is configuration setting). This allows these jobs to start & run much quicker than it a job had to be initiated for each request. The TIMW is normal when the job is waiting for somrthing to do.

Connections are closed properly on each page.

How do you know that?

But job QZDASOINIT is not ending and remain in TIMW status.

That’s what QZDASOINIT jobs are supposed to do. Instead of having new jobs start for every connection, the jobs are intended to handle multiple connections one after the other. The jobs wait for the next connection that needs to be serviced.

This is creating large number of jobs on server.How can i close this job when connection is closed?

We need to know what you consider to be a large number of jobs. I know of systems with thousands of QZDASOINIT jobs. Others might only have one. What you think is large might be normal.

There’s a good chance it isn’t optimal for your site, but it’s probably not bad enough to cause problems.

To review the pre-start settings, run DSPSBSD QUSRWRK and take option 10, Prestart job entries. Display the entry for QZDASOINIT. The attributes that might be relevant are:

1. Initial number of jobs
2. Threshold
3. Additional number of jobs
4. Maximum number of jobs
5. Maximum number of uses

Note that you shouldn’t be changing these values on a production system if you don’t know what your doing. Study pre-start jobs first. Learn what the attributes mean before changing any of them. And be sure there is actually a problem too.

Tom

Thanks for all the answers, I have learned a bit about QZDASOINIT. The problem I have is whan a QZDASOINIT job hold a LOCK on particular files. I believe the ODBC job/process has completed, but there are still locks on files, causing failures later on in unrelated batch work. One particular example is when a file needs clearing down overnight it fails due to a lock on a QZDASOINIT, but that’s in a TIMW state. Any ideas please.

Had a similar problem – overnight jobs were having problems due to QZDASOINIT jobs tied to an application server. Ended up writing a program using the QWCLOBJL (List Object Locks) API to identify those QZDASOINIT jobs locking the particular files and end them.