|
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 <macwheel99@xxxxxxxxxxx> 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
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.