Charles:

Are you saying that copying 13350*ABC to 13351*ABC wouldn't properly update
the indexes?  Or is CNAME using some obscure method of updating  which
bypasses the normal I/O that indexing handles?

Bill

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Stevenson,
> Charles
> Sent: Friday, July 23, 2004 6:57 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [U2] Longstanding aversion to CNAME?
>
>
> 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/
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to