I'm trying to create or find a way of creating unique ID's.

System(19) only allows for 27 unique ID's per second (todays date
concatenated with the internal time plus a letter between 'A' and 'Z' if
system(19) is accessed more than once per second), and system(21) uses the
internal date along with a number from 0 to 65535.

When using system(19) the whole system can get throttled down waiting for a
new second to elapse if more that 27 system(19)'s are performed in a single
second.

System(21) does not guarentee unique id's in a single day.

I've experimented with a subroutine that uses a single record to dish out an
ID and then increments the ID and writes the item back for the next process
to use. This method seems extremely slow as compared to using the
system(21).

Does anyone have a better way? The subroutine is as follows:

subroutine get.unique(val)

open 'unique' to da.file else stop 201, 'unique'
readu val from unique,'unique' else
val = 0
end
val += 1
if val gt 9999999 then val = 0
write val on unique,'unique'
return

When I run a test of 9 processes that just call this subroutine an print the
value returned, many times a process will stop processing for a couple of
seconds waiting for its turn.

I would have thought that the numbers returned would have been distributed
more evenly but most process get about 20 to 50 sequential numbers.

I'm open for suggestions other than changing systems. :-)

Regards,

Dale

Hi
You are getting bogged down with the file open not the reads and writes.
Use a COMMON file or if you are really brave a NAMED COMMON for the file
open and you will not be able to time it.
Peter McMurray
"Dale" <benedictknowspam (AT) silk (DOT) net> wrote

Dale;

Throw the file into common. Not having to reopen the file repeatedly will
help tremendously. At least it did for me on UniData - I broke out of a
conversion routine that had been running for 3 days, put the files in common
and it ran in hours. You may want to track accounts - or use the same file
across accounts.

If you're worried about 27 ID's a second not being enough - resetting the
counter at 999999 - wouldn't that be just over 100 days? Especially with no
warning/error/recovery... or is that like the da.file/unique error in the
example?

Strange about the distribution. I would expect that if you were using some
combination of locked/sleep but not with a straight readu.

hth
Colin Alfke
Calgary

"Dale" wrote:

Dale,

I think you will find that your process is getting stuck with the READU
- the suggestion peter made about opening file once & keeping in common
is a good one .... I'd also keep your current PIB in common as well,
just to avoid having to do

field(oconv("","u50bb")," ",1)

Your revamped subroutine will now look something like :

subroutine get.unique(val)
common /uniquenamedcommonifyouaregame/ unique.fv, mypib

read val from unique.fv,mypib else
val = 0
end
val += 1
if val gt 9999999 then val = 0
write val on unique.fv,mypib
val := ".":mypib
return

This will be good for around 10,000 unique @id's/second, and doesn't
hit the lock table, so there is another speed "tweak" .... this is a
modified version of a routine we used to use within Visage (if anyone
is "keen", my current Visage routine can generate over 200,000 unqiue
@id's/second, and even avoids the file I/O "bottleneck" of the above
routine --> funny the things you will optimise when you aren't adding
features :-)

In a practical sense, I'm guessing anything over 1,000/second will be
more than you can process

HTH

Ross Ferris
Stamina Software
Visage > Better by Design!





On Oct 12, 12:23 pm, "Peter McMurray" <excalibu... (AT) bigpond (DOT) com> wrote:

"Dale" wrote:

That's not correct, many years ago RD enhanced system(19) to go to AA
through ZZ. I don't care how fast your CPU is, you're not going to go
through that many calls to this code in one second.

The problem with the basic A to Z was that with a faster CPU we went
through to Z and then the call hung on a lock until the clock ticked
over to the next second - bad news. That problem was fixed quickly,
and a looong time ago.

T

Now appears to goto 3 alphas (7.4.0), which will give >17,000 second,
though on machinbe I tested on here only yielded 6,000/sec .... still
"heaps" for most practical purposes


On Oct 12, 3:19 pm, Tony Gravagno
<g6q3x9lu53... (AT) sneakemail (DOT) com.invalid> wrote:

"Dale" wrote
change in the next release of D3.

You can produce system-global-unique ID's in
your own application code if you concatenate

a) time()
b) this port number
c) a one-up counter kept in a named common,
set to 1 at logon

but you'll have to prevent two successive logon
sessions on same pick port from getting into your
app code during the same second.
{maybe sleep 1 during logon proc,
or sleep(1) in your top-level process
at either its birth or at its final 'wrapup & die'}

Also, since all of a-c above have varying lengths
and are all numeric, you'll need a:'*':b:'*':c instead
of just a:b:c or you'll risk duplicate ids.

"Frank Winans" wrote

d) date()

Also, a purist would trade b and c above since the ids
hash based on first umpteen characters...

Just for the record, D3/NT still uses 2 alpha suffix, so I've reported
the "anomoly"


Ross Ferris
Stamina Software
Visage > Better by Design!

On Oct 12, 5:10 pm, "Ross Ferris" <r... (AT) stamina (DOT) com.au> wrote:

"Frank Winans" wrote:

I hope you mean "in case they break in the next release of D3". The
definitions of System() functions never change, but yes, some things
break, which is why I always encourage that interested developers
volunteer to run Beta releases.

If you want to avoid system functions, use this technique:
...normal app code
GOSUB GET.UNIQUE
KEY = UNIQUE
...STOP
GET.UNIQUE: * this is in a INCLUDED module
* change this code if the function breaks and
* just recompile all programs to activate change.
UNIQUE = SYSTEM(19)
RETURN

You can do that for any system code that you don't trust. Or for code
that's subject to change in a platform migration you can put
platform-specific code in separate subroutines in separate modules,
and control compilation with #IFDEF techniques.

Chances of that are slim given how long it takes processes to attach,
login, do something, then wrapup. If there is even a remote chance of
that happening then it isn't a good idea to rely on this particular
technique which invites the problem.

Your solution is reasonable but needs a little more work: without the
date() in the value, each day and every time you generate a new ID,
you stand a very remote chance of duplicating IDs.


System(19) is a core system function that deserves as much or as
little trust as any other core operation. While I agree that there is
some value to having custom generators for a unique ID and some other
functions, I personally don't waste my time with such things unless
faced with a critical release-specific bug. YMMV

T