Page 1 of 1

Shut down of Genie jobs

Posted: Mon Feb 01, 2016 9:24 pm
by SeanTyree
What is the recommended process for shutting down Genie jobs?

We are having an intermittent problem where the CGI job behind the Genie job is not ended when our backup job issues an ENDTCPSVR, ENDTCT, & ENDSBS.

Thanks,
Sean

Re: Shut down of Genie jobs

Posted: Tue Feb 02, 2016 9:46 am
by Scott Klement
Is ENDTCPSVR used to end the HTTP server? That will end all CGI jobs, unless they are stuck at MSGW status. When you mention ENDSBS, which subsystem are you referring to? If you are ending the QHTTPSVR subsystem, it will end all CGI jobs.

I'm not familiar with ENDTCT. What is that?

Re: Shut down of Genie jobs

Posted: Tue Feb 02, 2016 2:54 pm
by SeanTyree
Hi Scott,

Sorry for the typo, it should have read ENDTCP. When everything goes normally, all of the CGI jobs end when we ENDSBS (QHTTPSVR), but twice in the the last week we have had the Genie CGI jobs get stuck in an end status, but even after several hours the jobs have not ended and the subsystem is in an END status which prevents any new jobs from starting. Even an ENDJOBABN would not end the CGI jobs and we were forced to IPL.

I'm just wondering if the interactive subsystem should be ended before or after the QHTTPSVR subsystem and if that could cause the situation we are experiencing.

Thanks,
Sean

Re: Shut down of Genie jobs

Posted: Fri Feb 05, 2016 1:58 am
by Scott Klement
Sean,

Technically, I guess the interactive subsystem should be ended first, but I suspect that it won't make any difference in the problem you're seeing.

I've noticed the problem you describe when I've tried to end HTTP server jobs with OPTION(*IMMED), though. And it doesn't matter if they are Profound related jobs, just ending any job in the HTTP server with *IMMED seems to take forever, if they end at all. However, if I end them with *CNTRLD, even if I send the wait time to 1 second, they end pretty fast. I think it's because these jobs are spawned by Apache as child jobs, and using *CNTRLD will send a Unix-type SIGTERM signal to them to end them, whereas ending with *IMMED doesn't send the signal. I could be wrong about this signal stuff, though, it's just a guess.

Could that be it?