RE: An instance of QZSRCGI won't end after ENDTCPSVR -- WEB400

Michael,
Two things to try.
1) Are you setting on LR in those CGI apps or not? If not, then they might
be sitting waiting for something that will never get there, and eventually
they time out. You might want to try the SHTDN opcode; testing for an endjob
request. If that happens, set on the LR indicate to cause the program to end
when RETURN is issued. Of course that would only happen if someone hits the
page and the CGI program is called.
2) The other thing is to write a little tool that lists all the jobs for the
server. Then go through each one in a CL program and issue an ENDJOB
LOGLVL(0) and perhaps add the OPTION(*IMMED) if that's okay with you. To get
the list of jobs use the CrtJobList() API in the RPG xTools or call the
QUSLJOBI API and iterate through the list.
-Bob


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of michael.bailey@xxxxxxxxxx
Sent: Thursday, July 01, 2004 4:15 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] An instance of QZSRCGI won't end after ENDTCPSVR

Hi Brad,

Usually most of the jobs end within a couple of seconds, then two or three 
take 20 minutes to end and the final job is still running after 2 hours or 
more before I'm forced to cancel it. I'm fairly sure it's not a joblog 
problem as they're small like the okay jobs and I also don't see the jobs 
writing the joblogs when I do WRKACTJOB. Also, the final job sits on 
"TIMW"/"RUN" not "END".

Perhaps the slow and never ending jobs are struggling to complete a 
transaction of some sort, my colleague suggested (although he may have 
imagined it) that there may be a "flush" function in the Apache config 
that could detect problematic jobs and end them before they become a 
problem. If I can't find this then I guess I could write a procedure to 
abort any slow ending jobs a minute after the ENDTCPSVR command but this 
is a bit of a bodge which I hate. 

I'm off on holiday on Saturday so I've got to hand support off to a 
colleague (who doesn't have a baby!). It's a pain to leave this problem 
behind although it won't be the first thing on my mind when I'm relaxing 
on a Spanish beach!

btw in case you're interested Brad, the site in question is 
www.office-world.co.uk, it's actually a product that we sell called retail
therapy (see the URL below) all written native on the iSeries using 
CGIDEV2. Sadly one of the sales blockages we encounter a lot is that it's 
hosted on an iSeries, the combination of the unknown and the relative 
expense of the box has been a thorn in our side since the launch in 
February. We're even pondering whether to rewrite the product in .Net. 
However, Office World are a 400 shop so they know how good it is and 
they're very, very happy to have their website and (apart from this 
problem) it's just so stable and secure.

If you have any other thoughts I'd appreciate them Brad.

Cheers
Michael

Michael Bailey
Director
Q Technology Ltd (Qtec)
Office - 020 8832 9013
Fax - 020 8832 9029
e-mail - michael.bailey@xxxxxxxxxx
Web - http://www.qtec.co.uk/retailtherapy





"Brad Stone" <brad@xxxxxxxxxxxx>
Sent by: web400-bounces@xxxxxxxxxxxx
01/07/2004 05:21
Please respond to Web Enabling the AS400 / iSeries
 
        To:     Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
        cc: 
        Subject:        Re: [WEB400] An instance of QZSRCGI won't end 
after ENDTCPSVR


Michael,

Is the job log quite large on this job?  That could be the
problem.  I hate that there's no way to end them quickly.
 Does it ever end on it's own?  (have you waited 10 minutes
or so?)

I've had similar problems where it seems to take forever to
end jobs  But they do eventually end.

Brad

On Wed, 30 Jun 2004 10:27:30 +0100
 michael.bailey@xxxxxxxxxx wrote:
> We host an e-commerce website which was built using the
> CGIDEV2 tools. 
> It's been running almost faultlessly for nearly 2 years
> using the 
> "classic" IBM HTTP server. A month ago I migrated the
> HTTP server to 
> Apache and again it seemed to go very smoothly.
> 
> At night the sight is taken down for 10 minutes to run a
> back-up and 
> refresh, the dayend job issues an ENDTCPSVR, waits for 60
> seconds then 
> issues a STRTCPSVR to begin another APACHE server
> instance  that serves a 
> static "Sorry, site down for 10 minutes...." page. Both
> 

of these server 
> instances share the same port but both would normally
> never be up at the 
> same time. This has worked fine all of the time. 
> 
> However, occasionally one of the QZSRCGI jobs doesn't end
> and just sits 
> there locking files (all of the jobs hold locks all day
> as the files all 
> remain open as soon as the  server starts). The job isn't
> looping, it just 
> sits with "TIMW" status and occasionally goes to "RUN"
> status. The static 
> page instance works fine and successfully serves the
> closed site page. 
> However, of course, the dayend crashes because the rogue
> server instance 
> is locking files that need to be backed up. Subsequent
> text messages to my 
> cellphone wake me (and our baby) up at 4am to tell me
> that it's crashed, I 
> usually log in and put a 4/*immed against the job. It
> usually takes about 
> 5-10 minutes to end which is very odd because the entire
> server usually 
> ends almost instantly when it works correctly.
> 
> All of the PTF's are up to date as I did this at the same
> time as 
> upgrading to Apache.  I've looked at the job logs and
> they look exactly 
> the same as ones for a normal instance. There are no
> related QSYSOPR 
> messages either. I also checked history logs and usually
> one or two of the 
> other QZSRCGI instances took 10-20 minutes to end
> although the other 20 or 
> so ended okay.
> 
> Has anybody encountered this or have any ideas on how I
> could try to 
> resolve it as I'm getting a bit weary?
> 
> Thanks
> 
> Mike Bailey
> _______________________________________________
> 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.
> 

Bradley V. Stone
BVS.Tools
www.bvstools.com
_______________________________________________
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.


_______________________________________________
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.