Re: Utility to remove and re-add logical file members

I had a thought...

Instead of trying to re-add a logical file member correctly or
recreate the logical file itself correctly....

What if you
1) used CRTDUPOBJ to dup the physical (with no data) and it's logicals to QTEMP
2) deleted the production logicals
3) did the mass data change to the physical
4) used CRTDUPOBJ to duplicate the logicals back into production in an
optimized order?

I'm thinking that might be easier.

Charles

On Thu, Jul 1, 2010 at 9:03 AM, Dennis Lovelady <iseries@xxxxxxxxxxxx> wrote:

Yes, that can be done.  In fact, I wrote a utility to do that optimization
once.

What I did, was take the key information (which you could obtain from
QDBRTVFD or from DSPFD *ACCPTH output) and:
   write that to a temporary file, showing list of keys in one field
   Read that in descending order by the list of keys
   ADDLFM in that order

Unfortunately, I know that I haven't that source anymore - it belongs to the
client.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
Why is the alphabet in that order?  Is it because of that song?

My understanding is that simply removing the logical file member is
enough.  With the member removed the access path is gone and thus not
maintained during the load/purge.  You don't have to actually delete
the logical.

On the other hand, recreating the logicals in an optimized order does
have benefits....I wonder if it's possible to automate the process of
rebuilding the logicals in an optimized order...


Charles

On Wed, Jun 30, 2010 at 10:27 PM, Evan Harris <auctionitis@xxxxxxxxx>
wrote:

Hi Charles

In at least one case dealing with a table of 150+ million rows I

gained

significant advantage by deleting the logicals and recreating them

after my

processing was done. (At least I think I gained an advantage - I may

have a

different view after posting this)

In this case the logicals had been created as determined by

development

requirements (i.e. relatively randomly :) ) which provided an

opportunity to

re-create the logicals in a sequence that took advantage of access

path

sharing to save space, but more importantly to improve the speed of
recreating the subsequent access paths (and probably maintenance as

well).

I tried to order the creation of the logicals in such a way as to

allow

creation of a new logical to leverage already existing access paths

by doing

some analysis on the keys of the logicals - essentially I created

from most

complex to least complex; there may have been better ways to do it. I

also

dual streamed the creation process so that I had two logicals being

created

concurrently and had similar key structures in the same job path.

Maybe I needn't have actually done re-created the logicals - I don't

know if

just removing and adding the member would have the same effect, but

some

testing might shed some light on it.

Regards
Evan Harris


On Wed, Jun 30, 2010 at 3:30 AM, Charles Wilt

<charles.wilt@xxxxxxxxx>wrote:

Before I start rolling my own, is anybody aware of a utility to

remove

all members from dependent logical files (and SQL views/indexes) for

a

given physical that will allow for the members to be automatically
re-added later?

My intent it to purge data from files on our development machine.

remove logical file members
(optionally) stop journalling
delete records from physical
reorg physical
(optionally) restart journalling
re-add logical file members


I'm thinking that at least the logical file member portion may also

be

useful in a bulk data load process..

--
Regards
Evan Harris
http://www.auctionitis.co.nz
--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.