Thanks for the responses on this one. We have made the changes as outlined on the pdf you reference.

I do have a follow up question. We are a college and for most days of the year workload is fairly random but 10-15 days a year when classes first open up to be scheduled and just before a semester starts when we do Late Registration, we can have 300-400 students who all want to do something at the same time. We usually know when these hits will occur. Every student is going through a web logon that is a java app that will need to make a connection thought a QZDASOINIT job before moving on to use the RPG CGI app that we use for class scheduling. Would we be better off to bump these numbers up really high for these peak days or set the values high enough to deal with a peak day and leave them that way all year?

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Elvis Budimlic
Sent: Thursday, January 08, 2009 1:54 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Question on QZDASOINIT jobs in QUSRWRK

Definitely increase the number of "Initial number of jobs".
If you see oscillations in a number of new requests greater than 2, I also
recommend bumping that up ("Additional number of jobs"). If you do that,
you may need to change the threshold value proportionately.
As for "Maximum number of uses"... there is no definitive answer here, but
200 is as good as any other number you'd come up with so I'd leave it as is.

You can learn more about these settings from an IBM experience report:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/experience/tunepresta
rt.pdf

Regardless of these PERFORMANCE oriented changes, none of these settings can
be causing FUNCTIONAL issues you're mentioning. These random errors have to
be investigated by perusing the QZDASOINIT joblogs of the jobs that failed.
Ideally, your application would trap the errors and email you the
application log, but since this is real life... joblogs are your best
option.

Hth, Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com


-----Original Message-----
Subject: Question on QZDASOINIT jobs in QUSRWRK

We current have a lot of tasks/applications/processes that use the
QZDASOINIT pres-start jobs in the QUSRWRK subsystem. Right now there are 28
of these jobs running only 5 are in the Status of PSRW (waiting for someone
to connect). The other jobs are all in use with connections from various
native java applications and windows .net applications that run all day long
(time clocks for us). According to the Subsystem description entry for the
pre-start job it is set to the shipped defaults to only start 1 at startup
(see below). We are seeing some errors at random times about these jobs
being ended that we can't explain although the value we found here for
Maximum number of uses= 200 might explain some of them. We are just
wondering if anyone has changed these shipped defaults to other values and
if so what did you change them to? Based on our normal use I would change
the Initial number of jobs to around 30. Not sure where to set the Maximum
number of uses

Program . . . . . . . . . . . . . . . . . . . . : QZDASOINIT
Library . . . . . . . . . . . . . . . . . . . : QSYS
User profile . . . . . . . . . . . . . . . . . . : QUSER
Job . . . . . . . . . . . . . . . . . . . . . . : QZDASOINIT
Job description . . . . . . . . . . . . . . . . : QDFTSVR
Library . . . . . . . . . . . . . . . . . . . : QGPL
Start jobs . . . . . . . . . . . . . . . . . . . : *YES
Initial number of jobs . . . . . . . . . . . . . : 1
Threshold . . . . . . . . . . . . . . . . . . . : 1
Additional number of jobs . . . . . . . . . . . : 2
Maximum number of jobs . . . . . . . . . . . . . : *NOMAX
Maximum number of uses . . . . . . . . . . . . . : 200
Wait for job . . . . . . . . . . . . . . . . . . : *YES



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.