× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.