RE: AS/400 falls asleep

Sounds like you are having a problem with your connection.  I would have
the networking people look at the router logs and see what the traffic
pattern looks like.  Printing over a WAN can really tie up bandwidth.
The Perle will lock all the keyboards and wait for the AS400 to
re-establish communications.  You then pick up where we left off.  Of
course the AS400 does not care it took 5 minutes to get a response from
the perle.  And VPN users time out and disconnect.  I would be looking
at your WAN/LAN.


Chris Bipes
Information Services Director
CrossCheck, Inc.

-----Original Message-----

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.