RE: "Undead" Jobs -- MIDRANGE-L

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

-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Åke Olsson
On a few occasions we have seen this happening in a batch
subsystem (one of many sbs on machine):

A job starts using way to much resources and needs to be put
out of its misery.
We try killing the job *immed.
It still stays on - forever - using up constantly around 30%
of the CPU on A 570 box.
Trying to use endjobabn does not help.
The subsystem cannot be stopped.
The "undead" job cannot be held or changed in any other way.

One peculiar thing about these "undead" jobs is that they
show no program stack despite the fact that they use both i/o
(loads of open files) and CPU.

The only solution seems to be to IPL the system, which is
highly impopular with the users.

The box is on V6R1. As for PTF level I do not know. I simply
assume that the sysadmins do their job with regards to
installing critical and cum ptf:s.

Any ideas? Does this ring a bell?

Yes! Your story reminds me of Alien. Segourney Weaver tried killing it by blowing up the space ship and escaping in the shuttle.
Up until now, I've only seen spooled files that can't be deleted or shown.

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.