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


  1.  Home
  2. MIDRANGE-L
  3. June 2005

RE: not allowing operator from end a specific job

Hi Tom
the subsystem will wait for a specified time limit (which I have a feeling might just be *NOMAX,,,) if you use end option *controlled (from memory this is the default) but ending it *immed will normally cause the jobs running in it to end in fairly short order. I too have seen many sites that do this rather than coding an end process for any background tasks or programs they leave permanently running.
Having said this I have seen jobs that did not end in response to an ENDSBS command but ended quite happily when the job itself was manually ended by a specific ENDJOB request. I have not taken the time to work through the various reasons this might occur.
I was kind of speculating that removing *JOBCTL would then remove the ability to use ENDSBS anyway (no manuals to hand and too late to go hunting) 

Hope this helps.

Regards
Evan Harris



At 02:52 p.m. 28/06/2005, you wrote:

midrange-l-request@xxxxxxxxxxxx wrote:

>  10. RE: not allowing operator from end a specific job
>      (Walden H. Leverich)
>
>Just wondering, if you aren't allowed to end a job, but you are allowed
>to end the subsystem in which the job is running, what happens? Not that
>silly a question in this case since we're speaking about backups and
>lots of places just bring down entire subsystems for backups.


Walden:
In general, a subsystem won't end until the jobs within it end. I suspect that the subsystem will be in an end-pending state and then end when the job finished -- don't know what messages might result. But I've never tested this scenario. 

Tom Liotta

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.