How did this story end? Or is it still a problem?
> From: [EMAIL PROTECTED]
> Sent: Tuesday, December 13, 2005 9:06 AM
> To: u2-Users
> Subject: [U2] Secondary Index Problem
>
> Hi All,
>
> UV9.6.1.16
> HPUX 11
>
> I have an index that is no longer working and am not sure
> why. The whole purpose of this index is to allow me to use
> the SELECTINDEX to get a list of items that have something in
> field 67 of the record. The index has 13 records but there
> are actually 876 records with something in 67. I can rebuild
> the index but I really want to know what went wrong....
It looked like the other responses were groping in the dark, so I'll add
my grope:
We run HPUX, too. At some point release of 9.6 we also had an index
problem.
Any chance of upgrading? 9.6 is pretty old.
I fhave forgotten most of the details of our corruption. You could
search this list's archives for Spring of 2002.
I think there are some indexing changes mentioned in the release notes,
too, but I can't remember.
See GTAR 22465.
Do you watch your uv/errlog? Look for 010014 Write failures on files
with indices.
My workaround is this program.
The pgm header has some cryptic notes that might help:
PROGRAM SET.LOCK.WAIT
* Sets number of seconds to wait on a lock before taking the ELSE clause
* instead - an event that would NEVER be good.
* Called via UV.LOGIN as globally catalogued routine.
*
* In Rev 8.3.3 UV introduced the LOCK.WAIT "feature" and set the default
* to 3600 (seconds). This says that if a LOCKED clause is missing, then
* after [LOCK.WAIT] seconds, proceed with the ELSE clause ! ? ! ? !
* The workaround for that is to turn that "feature" by setting the
* parameter to 0, typically via:
* ASSIGN 0 TO SYSTEM(1999) basic !!! ZERO NOW A BAD IDEA !!!
* executed from UV.LOGIN, the routine in uv/VOC that everyone hits when
* they enter the universe shell.
* See GTAR 22465.
*
* This has worked since rev 8.3.3, except .. not for type 25 files
(Btree
* tables). If a process tries to update an index while another holds
* the relevant lock: error 010014 "WRITE failure" is triggered.
* Mods
* 5/31/02 CDS
*
************************************************************************
*
*
ASSIGN 604800 TO SYSTEM(1999) ; * 604800 secs in 1 week
* (or EXECUTE "SET.SQL LOCK.WAIT 604800"" CAPTURING IGNORE works too)
RETURN
END
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
