What is the most reliable way to generate unique sequential keys without
having to resort to a record on disk updated through readu/write? The keys
don't have to be contiguous but only be sortable in the order in which they
were generated by several phantom processes running concurrently. I'm
Marco,
I have used similar processes in the past, but also have appended port
number to the beginning of the key. Separating the fields with '*' so the
date and time can also be used as a time stamp rather than duplicate the
same info in the record.
Cheers,
David Murray
*
Marco Manyevere wrote:
What is the most reliable way to generate unique sequential keys without
having to resort to a record on disk updated through readu/write? The keys
don't have to be contiguous but only be sortable in the order in which they
were generated by several phantom processes
Of course if the port number is added to the end of the key then you can
still sort by date/time.
In the past I've done an R%5 oconv on both the (internal) date and time
before concatenation - this gives you a 10 digit number regardless of
the date and time used, so no need for separators...
If you use @USERNO, instead of the pid, it will be OS independent.
Tom Whitmore
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Allen Egerton
Sent: Thursday, April 24, 2008 6:58 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Guaranteed unique
Setup a loop
This assumes you've already set up ID with the date:time
I=0
LOOP
I += 1
WRITE.ID = ID : '*' : I
READV JUST.CHECKING FROM FILE.NAME, WRITE.ID, 0 ELSE
WRITE REC ON FILE.NAME, WRITE.ID
EXIT
END
REPEAT
This will always append *1 to the end of the ID unless it already
David, Allen, Edward, thanks for the suggestions but I want to be able to sort
theB records in the exact physical order in which they occured.B Using the
port or pid numbers could potentially give me the wrong sequence should two
events occur within the same millisecond (unless it is ruled out
We are running UniData 6.0.4 on an HP.UX 11 and the following error
keeps appearing:
2:blk check error in U_catch_tuple for file 'OPEN.MO', key
'082352500', number=1327
I have run following command:
:!guide OPEN.MO -o
OPEN.MO
Basic statistics:
File
You could use SETENV / GETENV but I wouldn't think this is any faster /
safer than READU/WRITE.
Edward
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marco Manyevere
Sent: 24 April 2008 13:47
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Guaranteed
Wow - what kind of application needs THAT kind of accuracy?!?... old man
voice Why I remember when two items writing in the same SECOND was a feat!
/old man voice
In this case, I don't know how you escape having to do a READVU on the
item, and only writing on the ELSE clause, and changing the
No, fast systems can generate records faster than SYSTEM(12) - so you
need something to check the timestamp on SYSTEM(12) and handle
accordingly.
We've used a common block to do this.
As far as two users writing the same time/date/mili - well you're going
to need a port ID or a system to lock a
And on this part ...
potentially give me the wrong sequence should two events
occur within the same millisecond (unless it is ruled out
that this is not possible).
I was only partially kidding about the 'two items a second' thing -- even if
this were NOT possible today, in the lifetime of
But common wouldn't help here as it can't be shared between processes?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc Harbeson
Sent: 24 April 2008 14:42
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Guaranteed unique sequential keys
No, fast
Wyatt,
A simple memresize or RESIZE should clear these errors up.
Buffington, Wyatt [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
04/24/2008 09:54 AM
Please respond to
u2-users@listserver.u2ug.org
To
u2-users@listserver.u2ug.org
cc
Subject
[U2] Corrupt file
We are running
Wyatt;
guide and verify2 simply find the corruption.
dumpgroup/fixgroup and fixfile are used to correct the file. fixfile takes
the output from guide and does it's own dumpgroup and fixgroup. I use
dump/fixgroup mostly because I like to see what's happening.
My steps:
1. get exclusive access to
I have already found records that are only 28 milliseconds apart and the
server isnt really a big one. Its not so much the clock accuracy thats
important but the records must be processed in exactly the same order in which
they were written to disk. Thanks for the confirmation. It seems there is
D3 has a 'System-Wide' Unique ID generator in their SYSTEM()
selectiosn...
U2 does not. Darn it.
Ah, but nothing's free. To ensure uniqueness, there needs to be some sort
of negotiation. Years ago I worked on a Sequoia system running Pick O/A.
We were happy to see SYSTEM(19), which
Is the start time tied in with the phantom starting up? If so the
process number is generally allocated in an incremental fashion, so
date:milliseconds:process number would give you an approximation of what
you're looking for?
Some background information on what the phantoms are doing might help
True.
:-)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Edward Brown
Sent: Thursday, April 24, 2008 10:07 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Guaranteed unique sequential keys
But common wouldn't help here as it can't be shared
You need to re-read my solution, it will do exactly what you want.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Marco Manyevere
Sent: Thursday, April 24, 2008 05:47
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Guaranteed unique sequential keys
Hi Marco - this is in fact the way I update files on very busy systems - we are
getting say 30 hits per second and for logging with unique keys I have in the
past used the date():system(12):endbit where endbit is incremented after
doing a readvu to check if it exists or not. (as per your
OOPS!! I forgot the RELEASE on the THEN!!
Bad David!!
BASE.KEY = KEY
SEQCNT = 1
DO.WRITE = 0
LOOP UNTIL DO.WRITE
READVU TESTINGIT FROM FILENAME, KEY, 0 LOCKED
* No need to wait, Drop To Key Update
END THEN
RELEASE FILENAME, KEY ; VERY NEEDED!
*
Use the suggestion about a read to verify the non-existence of the record and
then loop around until the time() function changes to a unique id.
From: [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Guaranteed unique sequential keys
Date: Thu, 24 Apr 2008 11:02:26 -0500
Humor
But then you've limited your performance to one write a millisecond at
best...
Who could *stand* that kind of limitation?!?
/Humor
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ron Hutchings
Sent: Thursday, April 24, 2008 10:55 AM
To:
Lol
Now you've opened up the GOTO or LOOP REPEAT debate. :-)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of DAVID WADEMAN
Sent: Thursday, April 24, 2008 10:58 AM
To: u2-users@listserver.u2ug.org
Cc: u2-users@listserver.u2ug.org
Subject: RE: [U2]
Only needed if you care about eventually running out of locks. LOL It
will run a few thousand transactions before it blows up the system. :-D
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Wolverton
Sent: Thursday, April 24, 2008 11:51 AM
To:
At 08:12 AM 4/17/2008, you wrote:
Under Unidata 7.1.x on Solaris (9/10) we're seeing @LOGNAME truncated to 8
characters. Others on different OSes are not seeing this behavior. Does
anyone know if this is a Unidata setting or how Unidata is interacting with a
system call (eg: and therefor
This is reponse to Symeon Breen's reply. Yes, CRT does not prevent UniObject
to call UniSubrouitne. But you can't see the CRT output unless you convert
them into an output paramater like Eric Armstrong suggests here. But my
problem is sometimes the Unidata subroutine fires some warning messages,
[AD]
U2logic announces a new Unidata resize tool available on May 2nd called XLr8
Resizer. It will be downloadable at www.u2logic.com/update via Eclipse's
Update Manager. XLr8 Resizer will be out for Universe 2 weeks later.
XLr8 Resizer is built as a plug-in for the open source Eclipse.org
Sorry - maybe I misunderstood you - when you say returns nothing I assumed you
meant the returned parameters in the call are empty. This would be odd as it
certainly works in uoj as I stated regardless of crt's and error messages.
However there is no way of capturing any crt, or error message
I forgot to mention in my previous post is that a WRITE of a new record into a
UniVerse/SQL table is regarded as an INSERT.
So the new key generation will occur.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Here is a UniVerse/SQL answer.
Create the primary key with a default value of NEXT AVAILABLE.
CREATE TABLE MyTable (
MyKey INTEGER NOT NULL PRIMARY KEY DEFAULT NEXT AVAILABLE,
Column1 VARCHAR,
Column2 VARCHAR,
Column3 VARCHAR NOT NULL MULTIVALUED,
Column4 VARCHAR MULTIVALUED,
That's very good, but DICT NEXT.AVAILABLE sure is ugly. It means you
can't make a dictionary read-only. Dictionaries should be under source
control. And a data file can have multiple dictionaries.
A better answer would be to embed the next-id in the file header.
Then give a utility to edit it
I'm surprised to see most people suggesting a date time stamp for the
record key.
Isn't a sequential number the ideal? Which hashes better?
I like Mr. Stevenson's suggestion of storing a next-available key in the
file header. It could be configurable by file to be an integer, or some of
the
How to write?
I'd probably go for INSERT statements via the pre-defined @HSTMT statement
handle and the BCI function SQLExecDirect.
That's because the WRITE statement requires a key value.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit
You'll need a central key generator to manage high resolution sortable
sequential keys. You can use whatever connection medium is feasible and let
a single process/phantom generate the keys in numerical order. The problem
with using a key generator like this is that you could easily produce a
36 matches
Mail list logo
