There is a need to cleanup a system by removing old and unused
objects, deleted record space, etc. You may also want to cleanup to
remove clutter, reduce the amount of information that must be saved,
or just make it easier to operate and understand your system.
The following sections discuss what is needed and tools to assist in
- Everyday cleanup
- Periodic cleanup
- Large space considerations
- Deleted record space
- Infrequently or never used objects
- Source members
- General use tools
On a regular basis you should perform cleanup of several things. The
following are the most critical in terms of space.
By default (see discussion of QSPLFACN system value), when a spooled
file is written, the spooled file is associated with a job control
block. The job control block will not be deleted until the last
spooled file for the job is removed. Printing the spooled file (unless
SAVE = *YES is specified) will delete the spooled file. However,
spooled files tend to be left on the system in obscure output queues.
Good tools to consider are:
Allows deletion based on a number of days left on the system. An
option exists to move the old spooled files to a central output
queue for review.
A specific tool for deleting old job logs based on a retention
Users often want to retain the spooled files for longer than needed to
allow for printing or re-printing. This can require a lot of space. A
good tool to consider is:
Allows you to archive the spooled files to a data base file
(compressed format) and delete the spooled file. The data base
file may be kept online for several days and then offline for a
long retention period.
The QSPLFACN system (added in V5R2M0) allows you to detach the spooled
files from the job, so the job control block may be deleted when the
job completes. However, setting this option, prevents the use of
WRKJOB, WRKSBMJOB, etc from being able to find the spooled files
associated with the job.
QHST history data
The QHSTxxx files in QSYS can contain a large amount of history. The
system forwards all messages sent to QSYSOPR on to QHST as well as
There are tools to analyze this information such as SYSHST,
PRTQHSTANL, and PRTJOBSUM which require the information to be online.
You may also want to review the information with the system DSPLOG
command. The DSPQHST2 tool provides better search and review
capability than the DSPLOG command.
At some point you need to cleanup the old files when they are no
longer needed. A good tool to consider is:
Allows deletion based on a number of days old.
If you do not IPL frequently or you replace a large number of objects
(such as programs), the prior version of the object is placed in
QRPLOBJ. The library is cleared at IPL. While this library can be
large, you do not want to delete objects that are still in use in the
A good tool to consider is:
Allows deletion of objects from QRPLOBJ based on the last change
date/time (when they were placed in the library). For example, you
can delete everything that has existed in QRPLOBJ for at least 10
In addition to your own journaling requirements, the system performs
several journaling operations on your behalf which generate entries
into various receivers. When the receivers are no longer needed, they
should be deleted. While you might not want to delete receivers
everyday, you do want a regularly scheduled deletion action.
Some good tools to consider are:
Allows optionally generating a new receiver and optionally
deleting old receivers based on a retention date.
Prints a summary of journal receivers that exist and their sizes.
QSYSOPR Message Queue
QSYSOPR may receive many messages. If you do not IPL frequently, there
may be many messages in existence. A good tool to consider is:
Removes messages based on a date and time and/or a list of message
The EVFEVENT file is created by the system when you create a program
and an option is specified for debugging functions (also used by RDi).
A separate member is created for each program which contains
information created by the compiler such as errors. For example, if
OPTION(*SRCDBG) is used for OPM programs this causes a member to be
This 'old compiler error information' is worthless if you are only
using it for debug or once the program. You can find the files with:
WRKOBJ OBJ(*ALL/EVFEVENT) OBJTYPE(*ALL)
and use the delete option to clean them up.
or you can specify:
If you have an environment where user profiles are being created for
temporary use, you will want to periodically cleanup old profiles. A
good tool to consider is:
Deletes user profiles if the user has not signed on for a number
of days. An option exists to allow a review of what would be
Messages in Message Queues
Messages can sit in message queues for a long period of time. A good
tool to consider is:
Removes old messages that were sent prior to a specified date.
Temporary PTFs can take a large amount of space on your system
particularly after you have applied a cumulative package. After the
PTFs are confirmed by a few days of usage, you can apply them
permanently. A good command to review the status is"
Prints a summary of the PTFs by product and type.
To make a PTF permanent, you need the APYPTF command:
APYPTF LICPGM(*ALL) APY(*PERM)
In some cases you may see a message (CPF3674) which states that the
apply failed because a pre-requisite PTF must be applied first. You
must issued individual APYPTF commands for the pre-requisites.
Even if you do not use RCLSTG, you should display the library QRCL to
see if any objects exists that can be deleted.
While the need for RCLSTG has diminished over the years, it is still a
good idea to perform once in awhile if you have the time. Note that
RCLSTG does not impact the amount of deleted record space on your
system (see section on Deleted Record Space).
RCLSTG places recovered objects into library QRCL. Sometimes you may
find something that was lost, but most of the time its just junk and
you can clear the library.
The major question on RCLSTG is always 'How long will it take?' and
most users don't remember because it is seldom done. A good tool to
Runs RCLSTG, but captures information about its use to allow for
better planning purposes for the next usage.
Large Space Considerations
There are a few object types on the system that can consume a large
degree of space. If you are trying to reduce the amount of space on
your system, a good place to start is to review the large objects to
see if they are still needed.
Data base files (see later section on deleted record space)
Both data members and access paths may take up a considerable amount
of space. A good tool to review the large files that exist is:
Provides a listing of files that exceed a certain size. Both
physical members and dependent logicals are shown. You may specify
a minimum size.
If you use a member for a unique days worth of transactions, the
number of members may build up significantly. You can remove
members by retention date with RMVOLDMBR2.
Allows a comparison of how data base files are growing based on
periodic use of the tool.
On each IPL, the system refreshes the member statistics that are
kept by member for opens, closes, updates, adds, edc. You can see
this information with the DSPMBRD tool or get a listing with the
DSPMBRSTAT tool. You may be able to eliminate some large access
paths or find a different solution for large data spaces that are
very infrequently used.
Journal receivers may consume a considerable amount of space. A good
tool to consider is:
Prints a summary of journal receivers that exist and their sizes.
Save files can be created for a variety of reasons and then left on
Not all save files are bad. In some cases you may want to do a
compressed save of infrequently used objects to gain a space advantage
or simplify restore. Having an empty save file rather that causing a
re-create on every usage may also be an advantage.
However, there can be large save files that have no advantage and
should be deleted or cleared. A good tool to consider is:
Displays or prints a listing of all save files in one or more
libraries that exceed a minimum amount of space. An option exists
to bypass those save files that are empty.
The IFS can accumulate large objects. Good tools to consider are:
Displays a listing of IFS objects allowing various selection
criteria such as size and last used date.
Deletes objects from the IFS with various selection criteria such
as size and last used date.
Deleted Record Space
When you delete a record from a file, only a flag is set and the data
still remains. The space for the data is not re-used unless the file
is specified REUSEDLT(*YES). It is possible to retrieve deleted
records with the RTVDLTRCD tool.
You can reclaim the deleted record space with CLRPFM or RGZPFM.
Deleted record space can be significant. Good tools to consider in
reviewing and reclaiming are:
Provides a listing of files with deleted record space that you can
Reorganizes all files in one or more libraries with various
Reorganizes all members in a file.
Compresses deleted records to the end of the file to allow the
TRNDLTRCD tool to be used to reclaim space. CPRDLTRCD may run a
long time, but it may run simultaneously with production jobs.
TRNDLTRCD runs for a short period of time, but requires an
Infrequently or Never Used Objects
The system updates an object when it is used the first time each day
with a date and a count. Note that the count is actually 'number of
days used'. Several tools use this information to allow you to
sequence by this date or the count.
Prints a listing of objects that have not been used from a
specified use date. One or more libraries may be specified.
Prints a listing of objects for one or more libraries that have
never been used or not used for a number of days.
Prints a listing of objects for one or more libraries based on the
'number of days used' information.
Prints a listing of one line per library and the date of the most
recently used object. You may flag those libraries that have not
been used for a specified number of days. Designed for deleting
libraries that are not being used.
Source members can take up a large amount of space and it can be
difficult to determine if the source is actually used to create an
existing object. Good tools to consider are:
Prints one line per source member in a file (or files) with the
last changed date (as per the member description) and offers
selection criteria. An option exists to check the date changed
based on the individual source statements.
Prints one line per source statement in a source file with the
last changed date (as per the source statement) based on a date.
Checks for whether source exists for an object and attempts to
identify the source if it has moved from where the object was
Provides for multiple on line versions (compressed) of source in a
source archive. Allows deletion of the actual source member (from
the source file) to help minimize the number of members that must
exist in a source file. Retrieval of any version from the archive
General Use Tools
A periodic summary of your system or a library may be helpful. Good
tools to consider are:
Captures important system information every day (just after
midnight) and summarizes it into single record. This includes the
amount of storage used, jobs run, interactive transactions,
average response time, CPU used, number of libraries, user
profiles, when PTFs were applied, when major backups were done,
etc. This provides a good historical perspective of where you have
been and how you are growing.
Invokes several other tools to summarize various functions on your
system. A major tool is PRTLIBANL which prints one line per
library and then provides summary by object type, source, save and
restore, etc. Another major tool is PRTQHSTANL which provides a
Prints one line per object in a library with owner and size
Copyright TAA Tools, Inc. 1995, 2020