We had the same thing happening at our shop:
Many new server jobs starting (we also think that the users would click on
the link a second/third time because the application appeared to not
respond).
Most of the jobs in a lock wait state.
We checked with IBM and found that opening a spool file will lock/unlock
the printer file and the output queue.
Normally this all happens in a fraction of a second. But if you have more
jobs then the storage pool can handle, a job with the lock may be waiting
in what
IBM calls a CPU-queue. This is just what the name says: The job is waiting
to get back into the CPU to be processed and release it's lock(s).
We did exactly what you did: remove the open of the spool file unless it
was needed. We were also using them to trace the activity and to help in
debugging.
This solved our problem, no more locks.
Leonard Hrabar
Senior Developer
Holy Name Hospital
718 Teaneck Road
Teaneck, NJ 07666
(201) 833-3000 ext: 5861
hrabar@xxxxxxxxxxxxxxxxx
Mike Cunningham
<mcunning@xxxxxxx
> To
Sent by: "'Midrange Systems Technical
web400-bounces@mi Discussion'"
drange.com <midrange-l@xxxxxxxxxxxx>, "'Web
Enabling the AS400 / iSeries'"
<web400@xxxxxxxxxxxx>
11/07/2007 09:12 cc
AM
Subject
[WEB400] Web jobs and PRINTER files
Please respond to in RPG
Web Enabling the
AS400 / iSeries
<web400@midrange.
com>
Sending this to Midrange and Web400 as I think it crosses over.
We have been using QPRINT and EXCEPT statements in web RPG apps we have
been developing as a way to trace activity and as a way to report
unexpected results in the application. We usually have the QPRINT file set
for automatic open when the app starts. We have not had any trouble with
this until just this week when we had heavier than normal web activity. (We
are a college and this week was class scheduling for Spring). When 300
students were hitting the web server Monday at 8:30 the web response
stopped almost completely. CPU use was only around 30%. Green screen still
worked OK. There was very high faulting/paging numbers (web server pool had
9GB of ram assigned). System pool faulting was not about 1. When we did
some digging we saw many of the web server CGI jobs in a lock-wait status
on QPRINT. And the web server had started about 100 CGI handlers (we
normally run with 3). After about 20-30 minutes like this it stopped and
was fine the rest of the day. The scheduling web
app runs in a named activation group and our web system is a mix of
java/net.data/RPG CGI. Tuesday morning at 8:30 it happened again, exactly
same symptoms and after 20-30 minutes it was fine. Yesterday we changed
each app that had a QPRINT file being opened and either removed it
completely or changed it to user open and only open it if needed and this
morning (Wed) the problem did not return and the number of CGI handlers is
around 20 instead of 100.
I think what was going on was that while one CGI job was waiting on QPRINT
the next hit had to spawn a new handler which also tried to get a lock on
QPRINT so the next hit started a new handler which tried to get a lock,
etc, etc, etc, and each new job just too resources away from the first job
that was trying to get the lock. These apps also open lots of DB files and
we never saw a lock wait on those files. Does opening a spool file require
a lot of overhead that would take more time/resources to open as compared
to a DB file? Does opening a spool file require a lock on some shared
object like the OUTQ that QPRINT goes to? I am trying to get an
understating about what might have happened so we don't make the same
mistake again.
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/web400.
midrange.com
