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.