QZDASOINIT threads on AS/400

Hello List,
I recently switched out our AS/400 Enterprise Server from a 720 to a 270, and upgraded from V4R5 to V5R2. Because of all the changes in hardware, etc, I have had to re-tune the box. My last problem is with the QZDASOINIT threads and I am hoping to find an AS/400 person out there with suggestions. I have found both all programs within OneWorld open very slowly the first time they are opened and used. Interactive applications take quite a while to open, and the first QBE is very lethargic. However, once you have completed the initial query, you can close the interactive program and re-open it, only to find it opens very quickly and a different query runs exponentially quicker. I have found the same problem with RPT based programs in that the first try takes a very long to to connect to batch versions.

I understand that the first time you open a program, the initial connection can take longer, but our delays are excessive. Also, this problem did not exist in our previous configuration.

I have changed the amount of pre-start threads so I am sure I have available threads waiting for connection. Yet, the delays can still take a very long time.

Does anyone have any tips or tricks that may speed of the connection/performance of QZDASOINIT threads?

Thanks in advance.

Ryan Hunt

Ryan:

You may need to increase the number of prestart jobs for QZDASOINIT.

Check it (at v5r1 or higher) on command line:

DSPACTPJ QUSRWRK QSYS/QZDASOINIT

You can change the number by:

CHGPJE SBSD(QSYS/QSERVER) PGM(QSYS/QZDASOINIT) <prompt with F4>

Caution: You will have to re-start the QSERVER susbsytem for this to take
effect!

Just tryin' to help...

Rick--

----- Original Message -----
From: "rhunt" <[email protected]>
To: <[email protected]>
Sent: Friday, April 04, 2003 1:45 PM
Subject: QZDASOINIT threads on AS/400


and upgraded from V4R5 to V5R2. Because of all the changes in hardware,
etc, I have had to re-tune the box. My last problem is with the QZDASOINIT
threads and I am hoping to find an AS/400 person out there with suggestions.
I have found both all programs within OneWorld open very slowly the first
time they are opened and used. Interactive applications take quite a while
to open, and the first QBE is very lethargic. However, once you have
completed the initial query, you can close the interactive program and
re-open it, only to find it opens very quickly and a different query runs
exponentially quicker. I have found the same problem with RPT based
programs in that the first try takes a very long to to connect to batch
versions.
connection can take longer, but our delays are excessive. Also, this
problem did not exist in!
available threads waiting for connection. Yet, the delays can still take a
very long time.
connection/performance of QZDASOINIT threads?



OneWorld Xe AS/400 SP21

You can check the JDEdwards World/OneWorld Performance Tuning Guide. If it's all under the TCP/IP umbrella, you can check on changing the MTU and Window Sizes for TCP/IP. The original default settings of 576 and 8K were for dialup connections. Change to *IFC and 65536.

See chapter 21.2.2 p.566
http://www.redbooks.ibm.com/redbooks/SG245195.html

Originating Page:
http://www-919.ibm.com/servers/eserver/iseries/developer/solutionservers/jde/links.html

Ryan:

You may need to increase the number of prestart jobs for QZDASOINIT.

Check it (at v5r1 or higher) on command line:

DSPACTPJ QUSRWRK QSYS/QZDASOINIT

You can change the number by:

CHGPJE SBSD(QSYS/QSERVER) PGM(QSYS/QZDASOINIT) <prompt with F4>

Caution: You will have to re-start the QSERVER susbsytem for this to take
effect!

Just tryin' to help...

Rick--

Have you tried prestarting the jobs when you start the xe services ? i have found that if i start a number of them when i start the xe services it elevates part of this problem

I did that late last week and restarted the QUSRWRK subsystem (the subsystem has changed for V5R2). Things seemed to go very well on Friday, but volume was low. We'll see how it runs today. My prestarts are currently at 500, with a threshold of 10, and additional jobs at 20.

Thanks for you response!

Ryan Hunt

Yes, I have seen that two. Usually what happened for me was the perstarts took priority over the kernel services (only while starting up). We typically don't IPL very often so the prestarts are up and running without interruption to the subsystem.

Thanks!

Ryan Hunt

This is very interresting information. I will look at the redbook (I have exhausted the tuning guide). I don't know what my settings currently are so I should check.

Thanks for the response!

Ryan Hunt