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
midrange.com
