Dear R.
 
On Fri, 24 Nov 1995, R. Van Valkenburgh wrote:
 
> Another possible cause: very busy CPU.  The default case for sessions is
> a higher priority than jobs.  Jobs with the *EXEC have finished the INIT
> state and are just beginning the EXEC state --but really haven't done so.
>  A job not being aborted after an ABORTJOB is another symptom of this
> type of problem.  What happens is that all of the available CPU cycles
> are being consumed by (higher priority) sessions with none left for
> (lower priority jobs).  Remember a job needs CPU time to abort....
>
 
> Regards,
>
The problem recoursed when two sessions were active and Stan's BOUNCE.
Possibly a file transfer was running when a job was in the *EXEC state.
That happened in Wednesday 15:30. And I saw this job still in *EXEC state at
Thursday 10:30. And all subsequent jobs, streamed on Thursday morning
were in *EXEC state. I suspect an ugly bug in our MPE/V version: The
initiated job looks around for some resources. If it makes at a bad moment
or for a specific resource then it does not ask for the freed path again
but remains sleeping forever.
 
Last Thursday I tried to see a SUE list, the recommended SHOWQ, ABORTIO,
finally  had to COOLSTART the system.
 
No power failure was logged that time.
 
Stan, can you send me some details, what are the columns appearing on the
SUE screen, and how can  analyze such situations with this program.
 
TIA
                                              Frank
 
  |\  /~ ~~|~~~ Family : NAGY; first name : FERENC; title : Ph. D.
  | \ |   -+-   Institute of Isotopes of the Hungarian Academy of Sciences
  |  \|    |    1121 BUDAPEST Konkoly-Thege M. ut 29, HUNGARY (1525 Bp. POB 77)
`-'   '  `-'    E-mails : [log in to unmask]; [log in to unmask]
 
Fax: (36)-1-156-5045, work phone: (36)-1-275-4351, home phone: (36)-1-277-4229.
Home address: H-1214 BUDAPEST Raketa u. 29. I. 3.
 
There are 3 kinds of programming errors:  syntactical, semantical and mystical.
The programmers have to suck up the users just as much as absolutely necessary.