When was the last time your site did package clean-up? Does you site have packages that are no longer needed? Read this article to find out how ...

Products

• Endevor
• Endevor Natural Integration
• Endevor - ECLIPSE Plugin
• Endevor - Enterprise Workbench

Issue/Introduction

When was the last time your site did package clean-up? Does you site have packages that are no longer needed? Read this article to find out how ...

How do I clean up my package file ?

Environment

Release:
Component: ENDBAS

Resolution

It is recommended that you establish an automated "batch package" job to commit, archive and then delete (in that order) any package whose create date is older than "x" number of days. Using the SCL Guide chapter "Batch Package SCL" as a reference this can be set up as 3 separate jobs, one job with 3 steps, or one single job step that performs all 3 actions.

 

For example

COMMIT PACKAGE *
OPTION WHERE OLDER THAN x DAYS.

 

ARCHIVE PACKAGE *
TO DDNAME archpkg
OPTION WHERE OLDER THAN y DAYS
DELETE AFTER ARCHIVE.

 

DELETE PACKAGE *
OPTION WHERE OLDER THAN z DAYS
WHERE PACKAGE STATUS IS status1 status2 status3.

 

The COMMIT PACKAGE action removes the package's backout records and deletes the associated backout members from your output libraries while retaining package event information. The COMMIT action is only performed against packages with a status of Executed or Exec-failed.

 

The ARCHIVE PACKAGE action offloads all of the package's records to an external data set, then optionally deletes the package after it has been archived successfully. The ARCHIVE action can be performed against packages with statuses of Executed or against a package that has a status of Committed. Regardless of whether the status is Executed or Committed, you cannot use the ARCHIVE action with the delete option against any package that has backout members. If needed for auditing purposes you can use package reports 56, 57, or 58 to report against the archived package file. Refer to the Reports Guide for more information on archived package reporting.

 

The DELETE PACKAGE action allows you to delete packages. You can use the DELETE PACKAGE action to delete packages of any status.

 

Now the question arises as to who is allowed to perform these actions. The answer depends on the package's status and the package security (PKGSEC) setting in your C1DEFLTS table. Except for IN-EDIT packages, all package actions require the submitter of the job to be either an approver (PKGSEC=APPROVER) or be granted access via an external security rule (PKGSEC=ESI or MIGRATE).

 

However, the "SUPER-USER" feature allows you to specify 'super user" id's to remove IN-EDIT non-sharable packages. The super user feature is enabled through the Optional Features Table (ENCOPTBL) parameter ENHOPTSU (user1, user2). The userids cannot be wild carded. Once you have entered your "super user" ids you must uncomment the line and reassemble the source, and refresh the linklist if applicable. These user ids will now be able to delete non-sharable in-edit packages.