RE: Logical Files vs. Physical Keys

[Rob Berendt <rob@xxxxxxxxx>]

Why was
'Any coding design that relys on an abnormal termination for a unique key
error instead of doing a SETLL to see if the key exists before writing a
record  is just bad design technique'
in your reply?
I didn't see how that pertained to the persons email in any manner.  His 
steps outlined below didn't do 1 piece of I/O via a program.  Frankly the 
batch program might have been updating the file by doing a CPYF of another 
file into it with *ADD.  In the steps outlined below the key was removed 
by removing the logical so without a key how could they have even have 
done a SETLL?  Read the email again, and see if you're seeing something 
that I am not.  I saw:
1)  Physical file with no key
2)  Logical file with unique key
3)  Member of logical file is removed, thus there is no longer a unique 
key
4)  Batch program updates physical, might now add duplicate key.
5)  An attempt is made to ADDLFM but fails because it cannot rebuild the 
unique key.
Do you see something different?






MCUNNING@pct.edu on 03/24/2000 02:13:07 PM
Please respond to MIDRANGE-L@midrange.com@Internet
To:     rpg@cross-check.com@Internet, MIDRANGE-L@midrange.com@Internet
cc:      
Fax to: 
Subject:        RE: Logical Files vs. Physical Keys

Any coding design that relys on an abnormal termination for a unique key
error instead of doing a SETLL to see if the key exists before writing a
record  is just bad design technique

>>> rpg@cross-check.com 03/24/00 10:47AM >>>
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
+---