I wouldn't bank any money on the 'unique within the same PC'. Fire up two instances of Fox; into the command window of the first paste this code:

public s, n
s = _cliptext
n = 0
? m.s
do while not (sys(2015) == m.s)
   n = m.n + 1
enddo
? m.n

Don't execute this yet. Into the command window of the second Fox paste this and execute:

local i
for i = 1 to 1000000
   = sys(2015)
next i
_cliptext = sys(2015)
? _cliptext

Then switch back to the first Fox pronto and execute the code you pasted earlier. If Nick is right then this will never terminate but I don't think you'll have to wait very long.

My statement in the other article regarding 'unique within the same process' was not quite correct, though, since you can pull several instances of the Fox runtime into one and the same process via COM. However, AFAICS these instances do not share name spaces in any way.

For names shared across processes - filenames etc. - you could use the classic technique of combining a locally unique id (SYS(2015)) with some info that uniquely identifies its generator - i.e. process id plus module handle of the Fox runtime. If the filename needs to be unique on the network then you could add the NetBIOS computer name or the DNS name. But in most such cases one can skip this effort and simply call SYS(2015) until an unoccupied filename is found, which is usually (99.9999...% of all cases) on the first try. Which approach is best really depends on the specific application.

As regards the question whether SYS(2015) wraps on overflow or bumps the day count: it wraps. A simple test script just managed to wrap the counter after 45 minutes of calling SYS(2015) in a tight loop (avg. speed about 800,000 calls/s). *g*