Brian Initially testing confirms that a R versus L is the problem. thanks. Roger Original Message ----- From: Brian Leach Date: Thursday, March 5, 2009 5:41 am Subject: Re: [U2] Universe Index not working To: [email protected]
> Hi > > Over the past months we've seen a number of problems reported on > this list that seem to relate to changes in the way that > UniVerse is interpreting numeric/non-numeric fields. > > Clearly .20 is numerically the same as .2, but they shouldn't be > indexed together. > > If you do a LIST.INDEX, is it reporting the index as left or right justified? > > Brian > > Current problem. > > when selecting for another item, i get 2, one of which is the 'unselected' > record that we have been looking for. > BEEN USING > SELECT FILE WITH INVOICE EQ "509010016.2" and get zero when no > using NO.INDEX > if I switch to another invoice number > >ED FILE.INDEX 509010016.20 > 3 lines long. > 0001: 01*261318*IN.509010016.20 > 0002: 01*261318*IN.509010016.2 > 0003: 01*261318*RF.509010016.2 > Bottom at line 3. > >SELECT AR.OPEN.B4 WITH INVOICE EQ "509010016.20" > 2 record(s) selected to SELECT list #0. > the two selected, first is number 1, 16.20 and the second is the > one i want, # > 2. > --- > > Back in Version 6. I created several nifty indexes for the > order file. Which > had been designed to contain all orders, open or closed. by > marrying the > status flag to the custno, I created a unique enough key as to > not bog down. > Yeah, my first mistake was to create an index based on open or > closed, which > caused quite a performance hit. > But by creating > OPEN.ORDERS > 001 = I > 002 = IF STATUS = 'OPEN' THEN CUSTNO ELSE "" > > and create.index ORDER.DET OPEN.ORDERS NO.NULLS. I created a very useable > index.. ditto when I swapped ORDNO for CUSTNO, so that the index was keyed by > the ORDER NUMBER... > > But I haven't > > ----- Original Message ----- > From: Charles Stevenson > Date: Wednesday, March 4, 2009 4:45 pm > Subject: Re: [U2] Universe Index not working > To: [email protected] > > > In a prior release 10.0 or earlier, I encountered a problem that could > > corrupt an index if a write was issued without an explicit readu > > precedingit. I don't think IBM ever corrected that because > > writing without explicitly locking is Bad Form. > > If I remember, when process A holds a lock on a record and then > > process B issues a write (w/o explicitly locking),by default B sits and > > waits for 20 minutes, then gives up with a write error. (In my opinion, the > > defaultlock.wait should either be forever, or a uvconfig parameter, not 20 > > minutes.) > > > > If process B's write was to a file that had indexes, that complicated > > things - I don't recall the > > tails - and we ended up with > > inconsistencies between the data files and the index files. > > > > How to proceed: - Monotor uv/errlog to see if you have write errors. > > - Look for programs that write without locking. > > - 20 minute wait limit is configurable. I set ours to one > month > > (=2678400seconds), effectively forever, since we'd bring UV > down > > & up more frequently > > then that. To do so, execute a basic program from UV.LOGIN > > (that all uv > > processes execute on startup) that does ASSIGN 2678400 TO > > SYSTEM(1999).TCL command SET.SQL LOCK.WAIT 2678400 > > accomplishes the same. > > > > All that is from memory, by that's the gist of it. > > > > > > Completely separate, but did you know you can create an F- > > pointer to the > > index file itself and then select, ed, basic open/read/write > it > > like any > > other file? The F-pointer would look something like this: > > F > > I_FILE/INDEX.00n > > D_your_debugging_index_dictionary_with trans()s to data file, etc. > > > > Sometimes that can help you troubleshoot or even manually > > correct a critical > > index on the fly. But be careful. You can easily introduce more > > corruption. Especially if you leave the F-pointer lying around > > after you're > > done. > > > > Chuck Stevenson > > ------- > > 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/ > ------- > 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/
