|
midrange.com
One basic tactic I would start with would be definitely charting out the
days and times where you see the issue. From that, you could make use of
the performance monitoring and graphing features within Ops Navigator's
Management Central to then go back and see what various measures look like
during those problem times. From there you may see something that is
obviously spiking (LAN, disk, interactive, etc.) and then try and hunt down
a cause. The good thing about the graphs is that they offer a good deal of
drill down capability for seeing what jobs caused the CPU spike, what LAN
adapter got busy, etc.
Al Mac
<macwheel99@sigec
om.net> To
Sent by: midrange-l@xxxxxxxxxxxx
midrange-l-bounce cc
s@xxxxxxxxxxxx
Subject
AS/400 falls asleep
08/30/2005 04:48
AM
Please respond to
Midrange Systems
Technical
Discussion
<midrange-l@midra
nge.com>
We are on AS/400 model 170 OS/400 V5R1 mixed mode, with more people
connected via PCs than via twinax.
We recently moved our AS/400 to our main factory in the boonies, and made
corporate offices HQ the remote site. There's a few odds & ends not hooked
up yet, such as the ECS line. I opted to remain in the city, and commute
to the AS/400 occasionally. Since the move, there are some unexpected new
problems to struggle with.
There are actually several things going wrong, such that when we have an
incident, it is seldom obvious what is the cause this time.
One problem is, it seems to me the AS/400 at random moments decides to go
to sleep.
Some days I see this happen several times in the same day.
Some days I go whole day and not see it happen.
At the remote site on twinax, I am looking at the input inhibited X, and
the only thing I did was try to scroll in SEU to another page, or select a
report to change, nothing major ... now that this has happened several
times, I know to work on something that does not require keying on the 400,
and in 5 minutes it clears & is Ok.
My co-workers are on Client Access, and they have some kind of time out
that disconnects them, when this happens. Other folks on VPN from home or
travel, same deal. Phone to other site ... is 400 sluggish for you right
now? Oh yes, they having similar problem.
We check in the "computer communications room" and see that the Perle says
communications is normal with the AS/400.
Then when the 400 "wakes up" I go right into GO STATUS and
WRKACTJOB response time data, WRKPRB, DSPLOG for last 1/2 hour, check
messages on QSYSOPR and other places, and I cannot find a smoking gun. We
habitually run only one JOBQ, our disk space is at about 62% used, there's
about 1500 reports in spool, the largest being 50,000 pages of error
messages from a runaway job I had to kill.
Seems to me the AS/400 is ignorant of the fact that it had a nap.
I have exhausted interrogating "the usual suspects" and now I looking over
WRKSYSVAL stuff I not looked at in eons, such as DSPJOBTBL, and I looking
for the manual on STRSST to see if there is some error log incident rate
that not rise to the level of WRKPRB noticing, but when the AS/400 is busy
with whatever errors, it is not busy catering to the humans.
We're too cheap to have any of the performance tools.
Since shortly before the move, there has been a small reduction in the
total # of users, with a marginal increase in the number of sessions per
work station. I figure the overall demand on AS/400 resources has not
altered dramatically in many months. Printers is one area I should perhaps
figure out how to check how much of a drain, if any ... we have ups and
downs in how many concurrent printers talking to the 400, and currently we
are on the way up. However, right after 400 wakes up, I have checked
printers, and not seen much activity there associated with 400 nap time.
There has been no significant program changes in the last few weeks, that I
might think contributes to this ... I am tuning some new reports. There
was one that used to take 30 minutes & I changed how the files accessed,
shaving 3 minutes off the run time.
Years ago we had someone run a certain query on-line, that joins several
files of over a million records, but I would always hear from the culprit,
because his work station also locked up, and in fact the entire 400 would
lockup until we could kill the session in question. I will have to teach
someone at the formerly remote site how to do this, and God help us if the
culprit is on the main console.
I used to get MIDRANGE_L many years ago but the volume of traffic was more
than I could stand ... in the interim there has been a regular famine of
other good places to get answers, and I am experiencing a growth in
challenges that need answers that I suspect MIDRANGE_L would be a good
place to ask.
-
Al Macintyre http://www.ryze.com/go/Al9Mac
BPCS/400 Computer Janitor
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
_____________________________________________________________________________
Scanned by IBM Email Security Management Services powered by MessageLabs.
For more information please visit http://www.ers.ibm.com
_____________________________________________________________________________
ForwardSourceID:NT00029D3A
_____________________________________________________________________________
Scanned by IBM Email Security Management Services powered by MessageLabs. For
more information please visit http://www.ers.ibm.com
_____________________________________________________________________________
As an Amazon Associate we earn from qualifying purchases.
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.
