RE: Re[2]: Logical Files vs. Physical Keys

I'm not sure if this point has been covered, but,..
1. You can un-delete records from an unkeyed physical.
2. There may be requirements for arrival sequence, (which of course could be
date/time stamp sequence).

Just my .02......

Regards,
Jon A. Erickson
Sr. Programmer Analyst
800.COM Inc.
1516 NW Thurman St
Portland, OR  97209-2517

Direct: 503.944.3613
Fax: 503.944.3690
Web: http://800.com


-----Original Message-----
From: eric.delong@pmsi-services.com
[mailto:eric.delong@pmsi-services.com]
Sent: Tuesday, March 28, 2000 8:57 AM
To: MIDRANGE-L@midrange.com
Subject: Re[2]: Logical Files vs. Physical Keys 



     Sorry, but I can see no advantages to unkeyed physical files. I see 
     no additional flexibility, I have heard no argument that compels me 
     to believe that unkeyed physicals are better. You've stated that 
     nonkeyed physicals are "arguably better" without arguing your 
     point. Just saying it is so is not very convincing :)
     
     eric.delong@pmsi-services.com


______________________________ Reply Separator
_________________________________
Subject: RE: Logical Files vs. Physical Keys 
Author:  <MIDRANGE-L@midrange.com> at INET_WACO
Date:    3/24/00 10:55 PM


Chris,
I can see why you feel this way if you work in an environment where people 
who don't know what they are doing remove members from LFs.  You might want 
to limit their authority.  I'll stick to the  statement that nonkeyed PFs
are 
arguably better than keyed PFs because of flexibility.  If you reserve one
LF 
for all updates as part of your record locking strategy, this LF can be the 
one with the UNIQUE keyword.   On this issue, consistency is probably 
essential no matter what strategy you use (in spite of your signature
quote). 
--Chapin Kaynor
     
> 
>  Date: Fri, 24 Mar 2000 07:47:37 -0800
>  From: Chris Bipes <rpg@cross-check.com>
>  Subject: RE: Logical Files vs. Physical Keys 
>  
>  Yes you can use unique keyed logicals to force your physical unique, that

is
>  until the logical gets its data member removed, thus no index maintained,
>  and some batch program updates the physical.  Now the logical member
cannot 
>  be added back because of duplicate unique keys.  OOPS! some green program
>  just caused you a big headache in scrubbing the data to remove the
>  duplicates or re-assign the unique keys.  Gee what aux files have the key

>  you need to scrub and which record goes to which?  
>  
>  Ok that's a worst case scenario but can be prevented by putting the
unique 
>  key directly on the physical.  I have had the index of a physical get
>  corrupted during a power failure and the ups blowing a fuse.  It was real

>  easy to recapture ALL the data to a new, freshly compiled, physical with
a 
>  simple CPYF FROMRCD(1).  JMHO and bad experience, it is better to put the

>  lowest level unique key on the physical for forcing the data to remain
>  unique always.
>  
>  Christopher K. Bipes  mailto:ChrisB@Cross-Check.com
>  Sr. Programmer/Analyst    mailto:Chris_Bipes@Yahoo.com 
>  CrossCheck, Inc.  http://www.cross-check.com
>  6119 State Farm Drive     Phone: 707 586-0551 x 1102 
>  Rohnert Park CA  94928 Fax: 707 586-1884
>  
>  If consistency is the hobgoblin of little minds, only geniuses work here.

>  Karen Herbelin - Readers Digest 3/2000
>  
>  
>  - -----Original Message-----
>  From: Kaynor@aol.com [mailto:Kaynor@aol.com] 
>  Sent: Thursday, March 23, 2000 7:46 PM
>  To: MIDRANGE-L@midrange.com
>  Subject: Logical Files vs. Physical Keys 
>  
>  
>  Chris,
>  The reasons you give for keying the physical can be achieved by using the

>  UNIQUE keyword on a logical.  Keeping your physicals unkeyed is arguably 
>  better because of the flexibility it provides.  
>  - --Chapin Kaynor
>    Vermont
>  
+---
| 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 
+---
     


+---
| 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
+---
+---
| 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
+---