× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



There is system value, QRCLSPLSTG, which automates the RCLSPLSTG.
The QRCLSPLSTG system value can be set to automatically delete unused and empty database members in primary or secondary ASPs.
This command uses synchronous processing.

Paul

From: Jim Oberholtzer [mailto:midrangel@xxxxxxxxxxxxxxxxx]
Sent: Thursday, July 11, 2019 6:40 AM
To: Midrange Systems Technical Discussion
Cc: Steinmetz, Paul
Subject: Re: How much space will a reorg add?

I think someone else pointed out RCLSPLSTG. In order to get spool space back you need to combine the removal of the spool files AND reclaim the storage. Days 0 have never hurt anyone I’m aware of.

On Wed, Jul 10, 2019 at 10:00 PM Steinmetz, Paul via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>> wrote:
Bill,

It depends if you're doing a dedicated REOGR or REOGR While Active.
Dedicated reorg is much faster, takes no additional disk space, but no one can be using the file.
REORG while Active, will be longer, takes additional disk space because the file needs to be journaled, journal receiver will grow, but users may continue to use the file.

If I were in your shoes,
1) find and delete large undeded, spoolfiles,
STRSQL,
SELECT *
FROM QSYS2.OUTPUT_QUEUE_ENTRIES ORDER BY SIZE DESC
FETCH FIRST 100 ROWS ONLY

2) Review and delete any unneeded journal receivers on the system,
WRKOBJ OBJ(*ALL/*ALL) OBJTYPE(*JRNRCV)

3) Review and delete unneeded *savf
STRPDM, 2. Work with objects,
Library . . . . . . . . . . QGPL *CURLIB, name

Object:
Name . . . . . . . . . . . *ALL *ALL, name, *generic*
Type . . . . . . . . . . . *FILE *ALL, *type
Attribute . . . . . . . . *SAVF *ALL, attribute, *generic*,
*BLANK
Check other libraries.

4) Check IFS for large, unneeded STMF, and/or any unneeded image catalogs.
WRKIMGCLG IMGCLG(*ALL) TYPE(*ALL)

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx>] On Behalf Of Howie, Bill
Sent: Wednesday, July 10, 2019 4:51 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: How much space will a reorg add?

Hello all,

I'm working on doing a reorg of the files from our ERP package. It's been a very long time since a reorg was done on these files. What we've done is copy the data library in question over to our test system and we're going to do a test run there and see how long it takes. One problem.....our test system has about half the storage that our production one does and copying this library over has put us at 97% of disk space usage on our test system. Our ERP package does allow for us to reorg the files individually. We hope to get about 90GB back on a system that has 660GB and is 97% full. We have two schools of thought going on. Our thought in-house is that we can individually reorg some of the smaller files, and that should buy us enough space to be able to reorg the bigger ones. Our vendor that hosts our system for us is telling us to clear space ahead of time because of the amount of space that the reorg will add.

Anyone have any experience with how much space a reorg will typically add? I know that being at 97% is crazy. I'm just trying to figure out if we have enough space to slowly but surely reduce it down by reorg-ing individual files or if we should really look at clearing other space first. As always, all your suggestions are greatly appreciated!

Bill

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx<mailto:support@xxxxxxxxxxxx> for any subscription related questions.

Help support midrange.com<http://midrange.com> by shopping at amazon.com<http://amazon.com> with our affiliate link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx<mailto:support@xxxxxxxxxxxx> for any subscription related questions.

Help support midrange.com<http://midrange.com> by shopping at amazon.com<http://amazon.com> with our affiliate link: https://amazon.midrange.com
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.