RE: List Spooled File API SLOW (again)

Brad,

 Just a few stabs in the dark.

 When was the last time the systems were IPL'ed?  

 Are the *SYSVALs for initial and additional values for:
QACTJOB 
QADLACTJ
QADLSPLA
QADLTOTJ
QJOBSPLA  
QMAXJOB   
QMAXSPLF  
QRCLSPLSTG
QTOTJOB 

 high enough?  (Maybe the job job control block tables are very fragmented
due to many extensions.)

 Could it have something to do with the expanded spoll file number (each
entry might be receiving an error, which is being swallowed by the
application.)

 When was the last time a RCLSPLSTG was run?

 I haven't use this *SYSVAL, but is QSPLFACN set to *DETACH?  That might
have some side effects.

 -mark

Original Message:
-----------------
From: Brad Stone brad@xxxxxxxxxxxx
Date: Thu, 25 May 2006 09:58:56 -0500
To: midrange-l@xxxxxxxxxxxx
Subject: List Spooled File API SLOW (again)


I posted a while back about this and got a few ideas.

The PTFs listed at
http://www-912.ibm.com/n_dir/nas4apar.nsf/ALLAPARS/SE24829
were applied, but no help.

A recap, the QGYOLSPL API is being used and on 2 systems
(out of a few thousand) they are seeing that the first time
the command is run to list spooled files (using just an
output queue as a filter) takes anywhere from 15-30
minutes, no matter if there are zero, 16, or 100 spooled
files in the list.

I can't get it to happen on my V5R2 machine, or any of the
V5R3 machines I have access too.

Once it's been run once, after that it's normal speed, so
to me it seems like it has something to do with the
QGYSERVER job that is started when this API is used.  I
would think that the same issue would be popping up with
OpsNav as it uses the same API (I assume it does, since it
also starts the QGYSERVER job when listing spooled files).

Any ideas?  Anyone else seeing this issue?



--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .