TAA Tools
TAA TOOLS FOR SYSTEM CLEANUP


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
the cleanup.

-   Everyday cleanup
-   Periodic cleanup
-   Large space considerations
-   Deleted record space
-   Infrequently or never used objects
-   Source members
-   General use tools


Everyday Cleanup

On a regular basis you should perform cleanup of several things. The
following are the most critical in terms of space.

Spooled files

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:

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

DLTJOBLOG
    A specific tool for deleting old job logs based on a retention
    date.

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:

SPLARC
    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
other messages.

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:

DLTQHST
    Allows deletion based on a number of days old.

QRPLOBJ Library

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

A good tool to consider is:

DLTOLDQRPL
    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
    hours.

Journal Receivers

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:

MTNJRN
    Allows optionally generating a new receiver and optionally
    deleting old receivers based on a retention date.

PRTJRNRCV
    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:

RMVMSGQMSG
    Removes messages based on a date and time and/or a list of message
    IDs.


Periodic Cleanup

EVFEVENT file

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

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:

        DLTF FILE(*ALL/EVFEVENT)

User Profiles

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:

DLTOLDUSR
    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
    deleted.

Messages in Message Queues

Messages can sit in message queues for a long period of time. A good
tool to consider is:

RMVOLDMSG
    Removes old messages that were sent prior to a specified date.

PTFs

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"

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

Reclaim Storage

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
consider is:

RCLSTG2
    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:

PRTDBFSIZ
    Provides a listing of files that exceed a certain size. Both
    physical members and dependent logicals are shown. You may specify
    a minimum size.

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

PRTDBFANL
    Allows a comparison of how data base files are growing based on
    periodic use of the tool.

DSPMBRSTAT
    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

Journal receivers may consume a considerable amount of space. A good
tool to consider is:

PRTJRNRCV
    Prints a summary of journal receivers that exist and their sizes.

Save Files

Save files can be created for a variety of reasons and then left on
the system.

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:

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

IFS

The IFS can accumulate large objects. Good tools to consider are:

DSPIFS
    Displays a listing of IFS objects allowing various selection
    criteria such as size and last used date.

DLTIFS
    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:

DSPDLTSPC
    Provides a listing of files with deleted record space that you can
    consider reorganizing.

RGZLIB
    Reorganizes all files in one or more libraries with various
    options.

RGZALLPFM
    Reorganizes all members in a file.

CPRDLTRCD
    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
    exclusive lock.


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.

CHKOLDOBJ
    Prints a listing of objects that have not been used from a
    specified use date. One or more libraries may be specified.

PRTLSTUSE
    Prints a listing of objects for one or more libraries that have
    never been used or not used for a number of days.

PRTUSECNT
    Prints a listing of objects for one or more libraries based on the
    'number of days used' information.

PRTLSTUSE2
    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

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:

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

PRTSRCCHG
    Prints one line per source statement in a source file with the
    last changed date (as per the source statement) based on a date.

CHKOBJSRC
    Checks for whether source exists for an object and attempts to
    identify the source if it has moved from where the object was
    created from.

SRCARC
    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
    is possible.


General Use Tools

A periodic summary of your system or a library may be helpful. Good
tools to consider are:

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

PRTSYSANL
    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
    job summary.

PRTLIBDTL
    Prints one line per object in a library with owner and size
    information.



Copyright TAA Tools, Inc. 1995, 2017
					

Added to TAA Productivity tools November 30, 2002


Home Page Up to Top