RE: PF File Definition questions...

[Mark Lazarus <mlazarus@xxxxxxxx>]

Camille,

At 09:33 AM 10/15/99 -0400, you wrote:
>One of the reasons that I don't place a key on a physical file has to do
>with potential damage of an access path.  You can tell me whether this logic
>is still correct.  If the access path is damaged and the physical file is
>keyed, then the file would have to rebuilt from a restore.  If the physical
>file is not keyed, then the damaged the logical can be deleted and recreated
>without a restore.  Camille Brown  

 If the extremely unlikely event of access path damage (not data or member
damage), there is a  simple solution to retrieve the data. Just do a CPYF
using the FROMRCD( 1 ) keyword.  So the access path damage "myth" problem
is a non-issue when deciding on whether to use a PF index.

 IMHO, there are a few influencing factors.

Pro PF index:

 - One less object (and probably source) to manage
 - Assuming a UNIQUE primary index, you are guaranteeing the uniqueness of
your data.  A LF can be deleted and your data can be corrupted.

Con PF index:

 - If it's a large file and you ever need to restore it, it will take much
longer to do the restore, while the system rebuilds the index.  No index
will restore the data and then you can decide if / when you'll rebuild the
access path.
 
 -mark

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---