× 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.


  • Subject: Re: % temp addresses = 96.800
  • From: MacWheel99@xxxxxxx
  • Date: Thu, 29 Mar 2001 11:43:30 EST

From Al Macintyre

Check WRKSYSVAL ... there's a setting in one of them with information about 
your last IPL circumstances.

The manuals for all this topic include
IBM Work Manual
Managing 400 Performance from 400 network
Al Barsa's presentation at Common

I am looking at the latter on my PC & I am not versatile with Acrobat so 
cannot figure out how to work cut & paste so transcribing it here ... there 
is an API to retrieve IPL attributes that looks like QWCRIPLA ... I unsure of 
the W since the font on my PC makes it almost look like a smudge.

WRKSYSVAL QIPLSTS = Last IPL Status indicator

I got this info via FIND then Control G through the Acrobat - you might want 
the whole Barsa document on System Values, which he kindly offered us via 
attachment a while back.

With ANY of these WRK system information & job statistics ... when you go to 
it the first time is not nearly as illuminating as if you go one time in & 
out then return 10 15 minutes later because if you sit on it with F5 
refreshing then your WRK access is what is consuming the system resources, 
but if you go one time to start the elapsed time clock, then go off & do 
something else, then return, you getting much more meaningful snapshot of 
your system.

I do not pay attention every day, but I do check SOME screens every few days.
I scroll through DSPMSG QSYSOPR & DSPLOG ... I am looking for files being 
upsized & bogus addresses being used & abnormally terminated jobs getting 
inappropriate responses.
DSPSYSSTS is a simpler version of WRKSYSSTS with respect to volume of reports 
out there in which my main interest is % disk space consumption is within 
normal reasonable ranges
DSPJOBTBL gets you to the statistics on these temp addresses
WRKOUTQ I now view job logs every nite after backup before taking a menu 
option to splash them, moving selected ones out based on problems some users 
had that were not reported to me, so I basically have one OUTQ for JOBLOGs I 
want to study & I clear the rest.

> When was the last time you had this happen?

asked Rob Berendt

I have not had the huge % problem, what I have had is the performance 
management challenge in which I cannot afford to not pay attention to some 
details.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
-------------------------- 
Prior stuff context

From:   D.BALE@handleman.com

No one *has* been paying any attention.  Don't hit me for saying this, but it
hasn't been necessary to monitor for this stuff since performance has been
adequate and we have not noticed any slowness.  This is strictly a development
& testing box.

Re having the same problem under RISC:  our very heavily used 9406-510 RISC
branch production box is sitting with .016% of permanent addresses used and
.187% of temporary addresses used.  This box hasn't been IPL'd in over six
months, probably a year.  (Presently trying to scan the archives to find the
thread on how to determine the last IPL on a given box.)  The job for QCTL,
the controlling subsystem, was started on 5/20/2000.  "CALL QSYS/QWCCRTEC"
shows that our CISC box was last IPL'd on October 1, 2000.  The same program
confirms the 5/20/2000 IPL on the aforementioned RISC box.

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952

-------------------------- Original Message --------------------------
We are on RISC & the problem does not go away with RISC.

It only goes away by paying attention to various warnings on the system, like
you are doing, and by periodically studying DSPJOBTBL & other clues to see
what is normal for your reality & making performance tuning so you not using
excess stuff.

For you to get to 96.8 % SURPRISE tells me that either:
no one paying attention while it climbed, or
you are under gassed for what you using your system for, or
you have periods of serious churning of system resources other than time
period involved in your review of WRKSYSSTS which is only good for the time
period YOU personally accessed it then accessed it again, not for the total
overall system.
You might ask whoever signs on first thing in work day to visit this first
thing, then revisit when their day is over ... those statistics would be a
lot more meaningful.

Elapsed time . . . . . . :   00:00:00
means the data you shared is practically worthless for making any judgements.

>  Seeing "Nearly all available machine addresses used." (CPI0997) in
>  the QSYSOPR message queue,
> I am currently looking at a WRKSYSSTS screen on our
>  9406-D60 (running V3R2):
>
>  The second level text for the message recommends that we "Do an initial
>  program load (IPL) to make more addresses available to the system.  The IPL
>  will automatically release available addresses to the system."
>
>  We rarely IPL this box (or any of our boxes for that matter), only once in
> the 6 months I've been here.

>  So, I guess we'll do an IPL this evening.
>  Can anybody tell me what causes the temp addresses to get this high?
>  BTW, I understand that this problem goes
>  away with RISC, and we are close to upgrading to new boxes.
>
>  Dan Bale


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

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.