HP3000-L Archives

August 2009, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jack Connor <[log in to unmask]>
Reply To:
Jack Connor <[log in to unmask]>
Date:
Thu, 20 Aug 2009 08:50:31 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (80 lines)
That's what my guess would be as well.

When the console buffers are full, MPE processes block until console writes can complete and clear some buffer room.

This is the primary reason that it's been a "best practice" recommendation for nearly as long as the 3000 has been around not to run block mode apps from the console...that and the messages through your screen are really a pain :-)

jack

-----Original Message-----
From: Kim Borgman [mailto:[log in to unmask]]
Sent: Thursday, August 20, 2009 11:43 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] Anomaly

We had this happen once also....the system 'hangs' when messages cannot display on the console after the buffer? fills up.

In our case, a simple return at the console displayed everything and we were fine.

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf Of Jim Phillips
Sent: Thursday, August 20, 2009 11:38 AM
To: [log in to unmask]
Subject: [HP3000-L] Anomaly

We had an anomaly with our HP3000 system this morning.  When I got the call just beforee 5 AM, I could ping the server and connect to the remote console yet I could not remote in using either telnet or NS/VT.  I had someone go onsite (the server is located remotely from me) and the console was non-responsive.  Control-B worked, but going back to the console it was still non-responsive.  I finally got the console working via using Control-A and then hitting return (no Control-A command), and then the flood gates opened and hundreds of console messages flooded in.

At that point I could see what jobs were running and everything looked okay, with the exception of them running hours later than they were expected to run.  Looking at the $STDLIST for the restart job that runs after the backup (and which streams all the nightly batch jobs), I find this:

:LISTF @.TEMP.MDSSBASE
THU, AUG 20, 2009, 1:31 AM
FILENAME
C6130002
C6130004
. . .

:SHOWJOB JOB=@J;EXEC
JOBNUM STATE IPRI JIN JLIST INTRODUCED JOB NAME
#J6128 EXEC 10S JCYIT THU 1:00A FULLBACK,MANAGER.SYS
#J6202 EXEC 10S LP THU 1:12A NP92JOB,MGR.MINISOFT
#J6204 EXEC 10S LP THU 1:16A NETBASE,MGR.NETBASE
#J6199 EXEC 10S LP THU 1:11A RESTART,MANAGER.SYS
#J6228 EXEC 10S LP THU 1:26A MS225F,USER.JCY
#J6226 EXEC 10S LP THU 1:26A NITELY,USER.JCY
#J6218 EXEC 10S LP THU 1:23A NITELY,USER.MMS3000
#J6122 EXEC 10S LP THU 7:34A BCKCHK,MANAGER.SYS #J6200 EXEC 10S JCYIT THU 1:12A INETD,MANAGER.SYS
#J6237 EXEC 10S LP THU 1:30A MS220PR,USER.MMS3000 #J6210 EXEC 10S LP THU 1:18A NITELY,USER.MEXICO
#J6206 EXEC 10S LP THU 1:16A SYSCHK,MGR.UTIL
#J6201 EXEC 10S LP THU 1:15A MSJOB,MGR.MINISOFT
#J6233 EXEC 10S LP THU 1:29A MS220PR,USER.MEXICO
#J6205 EXEC 10S LP THU 1:16A JWHSERVR,MANAGER.SYS
#J6235 EXEC 10S LP THU 1:29A NITELY,USER.OVO
16 JOBS (DISPLAYED):
0 SESSIONS
JOBFENCE= 0; JLIMIT= 9; SLIMIT= 256
:SHOWTIME
THU, AUG 20, 2009, 7:34 AM


And what puzzles me about this is the elapsed time between the :LISTF and the SHOWJOB (1:31 AM to 7:34 AM).  The latter time is, interestingly enough, just about the time I got the console to start responding.

So, my question is:  How can I find out what happened to delay things from 1:31 AM until 7:30?

TIA

Jim Phillips




* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2