Not decommissioned yet. Varying amounts of work still being performed.
On Tue, Jul 1, 2014 at 11:58 AM, Porterfield, Sean <SPorterfield@xxxxxxxx>
IIRC, this is a system that is to be decommissioned. Have you considered
the following options on the SAVLIB portion of the backup (not sure what's
in your version; I'm on 7.1)?
From: John McKee
Sent: Monday, June 30, 2014 15:32
To: Midrange Systems Technical Discussion
Subject: Re: Deleted records
Thank you for the explanation. I had no intent of attempting to operate
on this particular file. To me, QSYS is not a library to be tinkering with.
I had hoped that there was a method to release the deleted records.
Currently, our backup just barely requires a second 3590 cartridge. I had
hoped, by reducing deleted records, to allow the backup to fit on a single
cartridge. There will not be any significant new development. Boss wants
to make backup unattended. Freeing deleted records seemed like a
possibility. RCLDBXREF with *CHECK reported no problems were found.
On Mon, Jun 30, 2014 at 12:03 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:
On 30-Jun-2014 11:33 -0500, John McKee wrote:entries.
A few weeks ago, I ran DSPFD on production (well used to be)
libraries. Found a lot of deleted records and reorganized those
files. They were set to reuse deleted records.
Ran the CL again on all files in all libraries.
The files QADB* in QSYS should be explicitly omitted from such
processing. The effects from issuing Reorganize Physical File Member
(RGZPFM) against those files needs to be expressly evaluated for the
potentially highly negative impact to the system operation; the
request to reorg any of those files should not be on a whim or even a
mere consequence of something akin to a whim due to some algorithm
blind to the relevance of the underlying data and the requirements
[for the users and the system] to have access to that data.
QSYS/QADBIFLD has 678746 records and 361,585 deleted records.
The file QADBIFLD is the System Database Cross-Reference (DBXREF)
How is space recovered from this file?
table of columns; i.e. as physical data, primarily for the SYSCOLUMNS
SQL Catalog VIEW. When any new columns are created, a new record to
track that column is placed in the file QADBIFLD in QSYS; in effect,
whenever that column is deleted, the row representing that column
within the catalog is deleted, and that becomes a deleted record.
Thus whenever new file(s) are created, due to the file QADBIFLD having
the Reuse Deleted Records (REUSEDLT) feature activated, deleted rows
will tend toward being utilized instead of remaining as /deleted/
DBXREF feature, to be incorrect.
The *DBXREF feature enables a data-refresh feature with either the
Reclaim Database Cross-Reference (RCLDBXREF) or the Reclaim Storage
(RCLSTG) features. The refresh is typically the most favorable
approach [over reorg], first because the system is offline thus
limiting impacts to concurrent work, and second because any errors
with the data should be resolved by the request [whereas a reorganize
would just move any incorrect data]; the former command has an option
to display if the status of the DBXREF data is known already by the
This email is confidential, intended only for the named recipient(s) above
and may contain information that is privileged. If you have received this
message in error or are not the named recipient(s), please notify the
sender immediately and delete this email message from your computer as any
and all unauthorized distribution or use of this message is strictly
prohibited. Thank you.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives