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



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.



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.