RE: AS/400 falls asleep

I believe they need Performance Tools to get WRKSYSACT. Used to, anyway. But if 
they have it, the output can also go to a *FILE. Of course, be careful about 
using up DASD.   ;-)

-------------- Original message -------------- 

> Al, 
> 
> I suggest opening a second terminal session, or even better, someone local to 
> the machine doing it, on to WRKSYSACT, and just let it sit there (or set to 
> auto-refresh) and then when the sleepy period occurs maybe this display would 
> show something going on. Perhaps the run priority of 1 would trump whatever 
> it 
> is that is causing it and allow you to identify the offending task. 
> 
> -Marty 
> 
> ------------------------------ 
> 
> date: Tue, 30 Aug 2005 03:48:21 -0500 
> from: Al Mac 
> subject: AS/400 falls asleep 
> 
> 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. 
>