Tracking 'temporary storage' and 'size of QTEMP' for active jobs on your System i servers can be challenging for systems administrators. The operating system lacks good commands for monitoring the top consuming jobs on the system.
You can use the IBM commands WRKACTJOB and WRKJOB to get to some of this information - but it can be a tedious process for quickly finding the active jobs on your system responsible for spikes in these resources.
With a better understanding of these distinctly different issues and resources consumed by jobs, you will have a much easier time managing this ongoing issue.
Using the IBM command 'Work with Active Jobs (WRKACTJOB)' and its 'F16=Resequence' function key, you can usually find the jobs consuming the most temporary storage on your system. It takes a little pecking around to find them, but the data is available. The same applies to jobs that are consuming large amounts of temporary DASD via QTEMP libraries.
It takes CPU to consume temporary storage. If a job is creating large QTEMP files, a lot of I/O has been performed. Use the 'F11=Display elapsed data' function key to show total CPU and auxiliary I/O data for all currently active jobs on the system. Using the F16 function key on these columns will sort the jobs descending by these amounts. Use the '5=Work with' subfile option to select the top jobs via the IBM 'Work with Job (WRKJOB)' command.
Using option '3. Display job run attributes' will show you the 'Temporary storage used' by the selected job. Option '13. Display library list' can be used to get access to an active job's QTEMP library. If QTEMP is in the job's library list, you can see its contents using the '5=Display objects in library' option.
This process is a bit clumsy and takes some time, but unfortunately temporary storage and size of QTEMP are not currently showing on the WRKACTJOB screens.
What is the difference between temporary storage and a job's QTEMP library?
All jobs on the system have a QTEMP library. This library is empty when a job starts and it is deleted or cleared when a job ends. Any operating system commands, CL, RPG or COBOL programs that manipulate data in permanent libraries can do the same in a QTEMP library. It is a fairly safe place to create and use temporary objects throughout a single-threaded job stream. Not so safe in multi-threaded jobs. Each job has its own QTEMP - not each thread.
You would typically find temporary physical files, logical files, data areas or maybe some user space objects in QTEMP libraries. Some jobs may not have any objects in this temporary library. The library still exists, but the programmer did not use it for temporarily storing objects.
The amount of temporary storage consumed by a job is much less understood than a job's QTEMP library. A simple way to look at it is to see QTEMP as disk storage and temporary storage as memory usage. Calling a program requires that program to be 'loaded into memory'. The program object is permanently stored on disk but at execution time it is brought into memory and consumes temporary storage.
As a program executes, it allocates variable fields that consume memory. Some variables are 'static' and are automatically allocated and freed by the operating system. Other variables are 'dynamic' and are created explicitly in the code. These variables are the ones that are likely to not be destroyed properly if overlooked by the programmer. Whether we are talking about variable fields or the creating and destroying of 'objects' in Java code, we are referring to the usage of memory that does get freed when the job terminates.
Issues with temporary storage arise when you have long running or 'never ending' jobs on the system that don't properly free (or destroy) variables (or objects) that they allocate (or create). Temporary storage is not much of an issue with a job that just runs one CL program. All fields are static. Memory is automatically allocated when the program is called - freed when the program terminates. Your RPG and COBOL programs might be fine as well.
Typically, this becomes a bigger issue with C or Java programs. Using a 'calloc()' in C without a 'free()' is a big problem. Using a 'createObject()' in Java without a 'destroyObject()' is an equally big issue. Java uses 'garbage-collection' to clean up memory. This concept leads to many Java applications that do a lot of 'creating' without explicit 'destroying'. Garbage collection will only clean up objects with no remaining references.
Solution: you create it, you destroy it.
The Workload Performance Series software has many features for tracking disk and memory usage. Our Disk Navigator tool analyzes DASD usage for both the native file system and the Integrated File System (IFS). Our Journal Optimizer performs detailed journal receiver transaction level analysis that can help determine where DASD is being wasted on your system. Our Spool Navigator tool provides detailed tracking and analysis of all spooled files on your system to help determine other ways of optimizing disk usage.
The issue with these tools and with the IBM operating system commands is that they don't provide quick and easy visibility into what is consuming temporary DASD and temporary memory. They focus exclusively on permanent disk storage in permanent libraries or in folders on the IFS.Looking at size of physical files, program objects, journal receivers and spooled files does not help much with tracking the size of QTEMP libraries and temporary storage.
Our System Navigator tool tracks memory usage at a system level, in addition to many other data elements. What has been missing in IBM operating system commands and in our tools is this quick access to the jobs consuming the most temporary storage and containing the largest QTEMP libraries on the system.
A recent enhancement provides existing customers with the ability to go into our System Navigator tool and press the 'F8=Temporary Storage' function key. This new screen can be used with its 'F16=Resequence' function key to sort by either the 'TmpStg' or 'QTEMP' columns and quickly find the jobs that are consuming these resources. Using option '5=Work with' runs the IBM command WRKJOB for the selected job providing you with the quickest access possible to resource culprits.
You may need to use our 'Automated Software Maintenance' features to retrieve and apply this and other software enhancements. A system security level of 30 is required for capturing the QTEMP data.
We invite you to go to our web site at http://www.mb-software.com, take us up on our Free 30 Day Trial offer or just make use of our extensive online Resource Center. White Papers and Webcasts are available which provide educational value to managers, administrators and software developers.