UV10 STILL DOES NOT UPDATE INDEXES if the index is part of the ID.
> From: Norman, David (SAAS)
>
> In UV9.4 CNAME didn't update secondary indexes, which left a bit of
> a mess behind. This has now been fixed, probably from 9.6.
Example. A 2-part id: [internal-date]*[something] indexed on date (
@ID['*',1,1] or FIELD(@ID,'*',1) )
Changing a "0" to a "1" in a date in a particular id:
CNAME file 13350*ABC,13351*ABC
will leave old, nonexistant id "13350*ABC" indexed under date "13350"
and will not add the new id to "13351".
IBM knows this (probably forwarded from the Vmark days), but resolutely
will not fix it because the underlying i/o routines used by CNAME are
different from the norm and won't easily support the change. This
list's archives will support that claim.
One could reasonably restate that as, "It's too hard to fix, so just
live with the inherent data integrity vulnerability."
Or even, "Help, help we're being oppressed. Come see the vulnerability
inherent in the system."
Chuck Stevenson
P.S. As for speed, for type-1 & -19 CNAME is faster than other
read/write/delete schemes one could program. I *believe* it invokes a
unix "mv" command which simply repoints the inode without actually
moving any files. Similar on MS.
P.P.S. I recall CNAME was originally a PRIMOS command similar to unix
mv. Information just borrowed the name and handled type-1 ( UFDs
(UserFileDirectories) ) with the primos mechanism, and used its own
mechanism for hashed records.
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
