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
Shut down of Genie jobs
-
- Profound User
- Posts: 76
- Joined: Fri Jan 11, 2013 6:11 pm
- First Name: Sean
- Last Name: Tyree
- Company Name: US HealthWorks
- State / Province: California
- Zip / Postal Code: 91355
- Country: United States
- Contact:
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: Shut down of Genie jobs
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?
I'm not familiar with ENDTCT. What is that?
-
- Profound User
- Posts: 76
- Joined: Fri Jan 11, 2013 6:11 pm
- First Name: Sean
- Last Name: Tyree
- Company Name: US HealthWorks
- State / Province: California
- Zip / Postal Code: 91355
- Country: United States
- Contact:
Re: Shut down of Genie jobs
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
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
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: Shut down of Genie jobs
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?
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?
Who is online
Users browsing this forum: No registered users and 1 guest