Temp Workspace on AS/400

I would like to take a quick survey for those of you on AS/400...and who have time. I am fighting was appears to be excessive temp workspace on my 270 @ V5R2.
1) How many GB's usable drive space do you have?
2) How much temporary workspace do you typically have during the day?
3) How many QZDASOINIT threads (average) do you run in a day?
4) How many drives do you have?

Thanks!

Ryan Hunt

1. 430 Gb
2. 0.85 to 1.25, It's been as high as 2.8 but not for a long time.
3. 650 - 1000
4. 79

TRY this. WRKSYSACT F16 Resequence, Option 4 Sequence by allocated storage, F11 three times for the allocated and deallocated storage screen and see if you can spot any particular offenders.


Darrell Allison
Systems Programmer
AS/400 V4R5 9406-730 8-Way / OneWorld B7332 SP11.3

Ryan,
1) How many GB's usable drive space do you have?
5.3T Total/ 3.1T Free
2) How much temporary workspace do you typically have during the day?
Temp: 788M (I use unprotected space for this number)
3) How many QZDASOINIT threads (average) do you run in a day?
Avg 1700, Max this month 2052
4) How many drives do you have?
180, We RAID them

Other factors:

108 Kernel jobs running in 2 instances. (English/Western European & Japanese)
BSFN's mapped back to the AS/400
This box is production only
We normally run 8-20 concurrent UBE's
300-400 concurrent users
12-Way w/8 active and 32G RAM, with 27.5G active.
CPU currently running at approx 60%
We plan on expanding this box to 2000-3000 active users over the next couple of years.

Hope this helps.

Wow. If I can confirm a couple numbers with you...

You have 5.3 terabytes of drive space and only 788MB of unprotected space, right?

That is very different from my 316.4GB total, 199GB used, with up 22.5GB unprotected space...and growing. I had to IPL yesterday becaue it hit 35GB (over a 5 day period) and the system slowed to a crawl.

Thanks for the info.

Ryan Hunt

Ryan,

Whoops. I have 778G of unprotected space. If I cycled services every day, I could reuce this to about 300G. This is because the JDE kernels NEVER seem to close a file. I can have several 1000 (thousands) of open files PER KERNEL at the end of a few days. We cycle services about twice a week when we deploy a package. This keeps us in the 300-1000G range.

On occasion we will go several weeks without cycling sevices we then can have 1.5T unprotected. Also be aware that un-protected is normally given back to the system when the process (normally job) that has it allocated terminates. It is almost always given back if the process terminates normally, and 80% of the time is given back if the process terminates abnormally.

Last paragraph is just my personal experience.

Sorry about the typo.

Tom

Which kernel types seem to be the offenders?
It would be interesting to see if it is always callobject kernels, as you might be able to hunt down business functions that open files but never close them yourself, saving resources. Outside of that, your results at the very least would make for a nice call to JDE!

Seg,

Been there, done that.

Call closed. Working as designed.

Offending kernels are CALL OBJECT, only about 60 of them.

We have a no-mod policy, except for legal requirements, signed off by Global, Regional, & Local legal depts. So closing them myself is not possible.

I did ask JDE if there was a way to give a CALLOBJECT kernel a lifetime (# of users served), after which it would terminate and another one would start, however they were not receptive to taht either.

Tom
Tom

Tom,
What version of OS400 are you running? What CUM level?

Thanks

Ryan

I've completed the same upgrade, V5R2 on 270 with SP21_F1. It's on a development AS/400, and only have a few users testing, cannot tell the difference in performance yet. I have not seen any increase in use of temp space. I was following your other post and thought you had the problem taken care of. Are you saying that the cum PTF upgrade did not fix this problem then?

No, the IBM CUME PTF package applied fine. For whatever reasons, it did not apply the HIPER group PTF package from the image catalog.

Ryan,

We are at V5R1, Cum TL003007.

Tom

Jean,
It turns out that our 270 was undersized and I need to double the amount of disk drives. I believe that will clear most or all of our performance issues.

I am new to AS/400 administration and the temp workspace is something I have been watching...not sure if I have a problem or not. I have 10 - 10,000RPM drives for a total of 316.4 GB usable space. I watch the uprotected workspace grow from about 5GB (after IPL) to about 30-35GB after 4 days. The only reason I have been concerned I have a problem is that in this state, the 270 slows to a crawl, and I have to IPL to clear out the space. I have been trying to determine if:
1) I have a memory leak issue
2) If too few disks are causing thrashing and inefficient paging.
3) Or, if 35GB of temp workspace is completely acceptable, and my need for an IPL every three days is simply related to the natural decrease in drive efficiency that comes with a lot of temporary information being stored (on too few drives).

I have applied every PTF IBM has suggested, so I am starting to thing my temp workspace is functioning as designed. Hopefully, 8 of the 15,000 RPM drives and the new raid controller (760+ MB of write cache) will allow me to IPL every two weeks. ;-)

Sorry this email was so wordy...

Ryan Hunt

Ryan,

You shouldn't need to IPL to reduce the temp space, this isn't WinTel, in the UNIX-400 market a 're-boot' is not a acceptable recovery option (end of editorial viewpoint). Make sure that you are looking at the 'Current unprotect used' and not the maximum.

If your current is 35G you can track down what jobs are using so much. In my case the JDE CallObject Kernels, and end that job (if possible), again in my case I cycle JDE services.

You can tell what job(s) are using in unprotected by doing a WRKACTJOB and taking option 5 (work with job) then option 3 (run attributes), the temp space number is the amount of unprotected space allocated to the job (in M), in my case this is almost always above 600M per CallObject Kernel.

Hope this helps.

Tom Davidson

thanks for the update. Yes, I've been supporting As/400 operations for 15
years and have never worried about temp workspace. It has always taken care
of itself. But you never know what can pop up in an upgrade.

You can limit the amount of temp space used by any job with classes, routing
entries in subsystems.



Jean Driscoll
AS/400 Co-existent Xe 17.1, Update 4/A73Cum12
WWW.JDETips.com

Also, Ryan, the temp workspace is used by job space. Jobs are not purged until all print files are deleted. Make sure that the cleanup routine is deleting spool files from outq's like QEZJOBLOGS, QEZDEBUG. Once the spool file is deleted, the job is purged from the system and temp job space is released.

Jean,

I don't know how to check that. Can you tell me a little bit more about this cleanup routine?

Thanks

Ryan Hunt

IBM commands that come with OS/400:
Change Cleanup CHGCLNUP - this really is the setup option. Use the other
commands only if you do not want this to run automatically.
End Cleanup ENDCLNUP
Retrieve Cleanup RTVCLNUP
Start Cleanup STRCLNUP

At V5R1, JDE started putting garbage spool files on system. Look at the job
description associated with the OneWorld profile (or whatever profile you
use to start services) The OUTQ that is associated with that profile is
where the garbage spool files are. I set this parameter to an OUTQ not used
by anyone else, then I can perform a CLROUTQ once a week.

JDE also has some garbage files in QGPL. I think they are created to hold
processing options. The files start with T or U and are following by a
string of numbers.

Also on the AS/400, the PRINTQUEUE file in the system library needs to have
members purged on a regular basis, as you are not allowed to have > 32000
members in a file. Along with this, sign onto OneWorld and delete old jobs.





Jean Driscoll
AS/400 Co-existent Xe 17.1, Update 4/A73Cum12
WWW.JDETips.com