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

I second Larry on this - you can do it online while users are working, be not afraid, but expect increased system load.

We have some monitoring files which usually have between 0.8 and 1.8bln records and 20-50% of deleted records,
so reorg is a good idea - but we do have 4 Cores and 256GB RAM for this 20 files, so it is not an issue.

If you're in doubt, use the iACS reorg function and monitor the progress. Do not expect the progress
percentage counter to run linear - if you cancelled an online reorg before, the first some % do go rather
fast while the rest of the reorg can need a significant amount of time. The preparation phase can do
need some hours - expect on large files this process can run over night and impact your
night batch processing or backup.

Also be aware of:
* maintaining the LF also depends on their size and make - your disk I/O will increase
* keep backup in mind while reorganizing - good test for your system performance ;-)
* depending on your QPFRADJ system value the QZDASSINIT job runs with varying priority
drawing some CPU
* If you use transactional based system mirroring (journal based) like Maxava, BUS4i etc,
you maybe want to exclude this file from mirror while being reorganized - there is a good
chance you'll need to keep an eye on your disk.
* avoid reorganizing multiple files the same time. It can be done if your business partner
sold you an appropriate machine.
* last but not least - sometimes, applications do use ALCOBJ *exclusive - you can imagine what might happen...

Best regards,
Mit freundlichen Grüßen
Holger Scherer

IBM Champion 2022
IBM Community Advocate
POWERbunker.com - your IBM i bunker

Am 18.10.2022 um 17:43 schrieb Larry DrFranken Bolhuis <midrange@xxxxxxxxxxxx>:

I have customers that do this routinely on files with 9 digits of rows.

Pretty much the two things two know are to specify NOT to rebuild the access paths or they'll get rebuilt when an application touches them, and that's bad. The alternative is to maintain them. Yes that slows it down but means users can access data.

The second thing is pay attention to the journal receiver size and quantity. You'll generate a LOT of entries so set the receiver size small, and delete them once detatched from the journal.

Or you could remember that "I sell Disk." ;-)

As an FYI if you run this through ACS instead of green screen batch job you get a VERY nice status of where it's at and how it's progressing.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2023 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.