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


  • Subject: Re: errors
  • From: "Emilio Padilla T." <vpadilla@xxxxxxxxx>
  • Date: Fri, 24 Sep 1999 11:52:39 -0500

Hi,
Did you try the Hoghunter option? I've use it a couple of times and it
work's fine.  In both times, i had only one job eating my cpu.
In case you don't know, you can use the option 76 in control panel.  This
function is available since v3r2.  I'm not in the office so I'm not sure if
it is available in power machines.

A new control panel function (¥76) is supported at V3R2, and PTFs MF11581,
MF11960, MF11982, SF29221 at V3R1, which will invoke an internal VLIC
mechanism to inspect for a high-priority CPU blocking job; if one is found,
its priority may be lowered immediately by +20 (i.e., a priority 15 job will
become a priority 35 job). This  function thus provides a new alternative
for the support person to correct system 100% busy symptoms (i.e., Processor
Active light on solid) and no terminals are responding to operator requests.
There may be cases when the priority can not be changed, an example would be
if the job found was QSYSARB or QLUS.
Hoghunter will not change the priority of any system jobs or VLIC tasks.
This function may not be totally successful, as the real cause of the
symptoms may be much more complex. After selecting control panel function
¥76, one of the following status SRC sequences will be displayed on the
control panel:

D600 0652 -> A900 2052 - a job's priority was changed >
D600 0653 -> A900 2053 - system job was indicated, priority not changed
D600 0654 -> A900 2054 - no CPU blocking job was found >

(To clear one of these SRCs, it will be necessary to SIGNON the console). A
message will be sent to QHST, and QSYSMSG or QSYSOPR describing the
action(s) which were taken; and an internal VLIC LOG entry (1700 0301 or
1700 0302 or 1700 0303) will also be recorded to assist with any possible
subsequent problem resolution; this may include another selection of control
panel function ¥76.

Emilio Padilla

----- Original Message -----
From: Debbie Helms <DHelms@Lance.com>
To: <MIDRANGE-L@midrange.com>
Sent: Jueves 23 de Septiembre de 1999 10:56 AM
Subject: RE: errors


David - I tried everything to get rid of the jobs.  I could not change,
hold, or end the jobs.  Where would I look to determine what the problem
was?  I have sent a main storage dump to IBM - I don't really expect to hear
from IBM in reference to this dump.  We did run srvtrc on the jobs that were
running.  I have pages and pages of trace information.  I have wrapped
joblogs, history, lic logs.  I really don't know what I'm looking for.  I am
afraid that we will experience this problem again if we don't find the cause
of this problem.
I agree that it sounds like os400 when you can not flush a job - but try to
argue with IBM.



-----Original Message-----
From: Kahn, David [JNJFR] [SMTP:DKahn1@JNJFR.JNJ.com]
Sent: Thursday, September 23, 1999 8:48 AM
To: 'MIDRANGE-L@midrange.com'
Subject: RE: errors

Debbie,

I don't know BPCS but it looks suspiciously like a classic bug in an
error
handling routine causing the program to jump into the error routine
where it
again errors, jumps back into the routine and so on ad infinitum.

Occasionally you get this kind of thing being triggered off by an
interactive job losing contact with a 5250 emulation session. As
this
happened to 5 jobs simultaneously you may have had some kind of
communications glitch(?).

When you can't cancel run-away jobs you can sometimes contain them
by
changing their priority to 99. 10 minutes after they were "ended"
with the
*IMMED option, you can should be able to clobber them with the
ENDJOBABN
command. This usually, but not always, gets rid of them. If that
doesn't
work then you're generally stuck with them until the next IPL. Did
you try
these steps?

It's one thing for IBM to say it's a BPCS problem, but no matter
what the
bug if you can't flush a problem job out of your system that has to
be an
OS/400 problem, surely?

Dave Kahn
Johnson & Johnson International (Ethicon) France
Phone : +33 1 55 00 3180
Email :  dkahn1@jnjfr.jnj.com (work)
   dkahn@cix.co.uk      (home)


-----Message d'origine-----
De: Debbie Helms [mailto:DHelms@Lance.com]
Date: 22 September 1999 22:53
À: 'MIDRANGE-L@midrange.com'
Objet: errors


I had an interesting problem (opportunity) today.  Our 640 locked up
around
10:30 this morning.  We had about 5 jobs in QINTER that brought the
system
to its knees.  We could not cancel the jobs in any form.  IBM could
not help
us cancel the jobs.  Finally we decided the only option was to IPL.
The
joblogs wrapped so we do not know what exactly happened.  Listed
below is a
portion of the joblog that repeated itself.  In 40 seconds it had
repeated
this 8,400 pages.  IBM thinks the problem is in BPCS.  I don't know
what to
think.  If anyone has ever heard or seen this please let me know.
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to
MIDRANGE-L@midrange.com.
| To subscribe to this list send email to
MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.