×
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.
Isn't there also some implications for backups? If the PF is keyed you can't backup the data without also backing up the index since it is all in one object. If the PF is un-keyed you can choose to backup the key if you think that is in your own best interest, by backup up the logical files.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dave McKenzie
Sent: Tuesday, March 11, 2008 3:54 AM
To: Midrange Systems Technical Discussion
Subject: Re: Why non-keyed PFs back then? Why today? ( was Re: Which of the SYSIBM tables/views show the row count for )
Tom Liotta wrote:
So, the question remains -- WAS there ever a reason /in fact/ for
non-keyed PFs?
I always thought the reason was so that you could remove the index(es),
by removing the LF member(s).
For example, the rule of thumb was that if you had to add a large batch
of records (say > 10% of the current # of records), it was faster to
remove the index, add the records, and re-add the LF mbr, which would
rebuild the index.
You can't remove the index of a PF.
--Dave
--
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.
midrange.com
