× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Al

You can get some information on how jobs ran from the QHST logs. They are all 
in files, and there is more information there than is displayed in DSPLOG. In 
particular, the CPF1164, which is the "job has ended" message. Here is a bit 
from the Work Management manual

Performance Information and QHST:

Performance information is not displayed as text on message CPF1164. Because 
the message is in the QHST log, users can write application programs to 
retrieve this data. The format of this performance information is as follows.

This is in chapter 5 of the v4r1 manual. There are examples that show you what 
is in the data.

QHST files are named QHSTxxxxxx where the xxxxxx is a julian date and a 
sequence number (letter). This is supposed to be in a certain order but can get 
askew. The text description is more reliable for arranging in order. And you 
can use that to find the file for the time range in which you are interested. 
In order to process all the QHST files, I have used the QUSLOBJ command to get 
the object info into a user space, then used QSORT in RPG to sort the list 
based on the text description, then processed the files in that order. (See Jon 
Paris' "who knew you could do that in RPG" redbook for how to use QSORT - the 
name is not esactly right.)

This is known as poor man's job accounting.

HTH
Vern
-------------- 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. 
> 
> - 
> 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. 
> 

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.