All,

Have tried searching and for the life of me I can't determine how to get the time at a nano-second level. Need this as we have a servlet which during a single session may be called multiple times within a minute with different inputs. Regular hold files appear to be fine of course, but we have a part of this that has to use -WRITE commands, and that file needs to be unique, to avoid conflicting processes writing to the same file.

This message has been edited. Last edited by: Kerry,

Acording to this document you can convert with a lengh of 12 and it will include nanoseconds.
Don't know if this will work in your case.

nano

I want to do this against current time, so how do I get the current time (including nano-seconds)

Unfortunately, though you can get the Date-Time with nano seconds, the nano seconds are zero:

TABLE FILE CAR
PRINT 
COUNTRY NOPRINT
COMPUTE CURRDTTM/HYYMDn = HGETC(12, 'HYYMDn');
WHERE RECORDLIMIT EQ 1
ON TABLE SET HOLDLIST PRINTONLY
ON TABLE HOLD AS H001 FORMAT ALPHA
END
-RUN

-READ H001 &CURRDTTM.A23.
-SET &CURRDTTM= EDIT(&CURRDTTM,'9999/99/99 99:99:99.99999999');

-TYPE &CURRDTTM

Based on documentation, this would supposedly return number of nanoseconds:

-SET &CURR_NANOS = HPART(HGETC(17,'H17'),'nanosecond','I9');
-TYPE &CURR_NANOS

Dan,

Thanks for getting me on the right track, and Francis thanks for pointing out that nanos come back as 0. I can use microseconds along with a random number to virtually guarantee that I won't have a repeated "key" during the same timeframe.

Thanks Again for your help

DWM:

Last time I experimented, it appeared that WF used current time to the *second* as the random-number-generator seed. If that is so, you'll gain nothing (in terms of uniqueness) from appending a "random" value to the ms-granular time

The other option is to use the TSCom Id.

-SET &Temp = FGETENV(7,'EDATEMP',80,'A80') ;
-SET &Temp = TRUNCATE(&Temp) ;

-SET &TSCom = EDIT(GETTOK(&Temp,&Temp.LENGTH,-1,'\',8,'A8'),'$$999999') ;
-TYPE &TSCom

The delimiter may have to change depending on the OS.

quote:

-SET &CURR_NANOS = HPART(HGETC(17,'H17'),'nanosecond','I9');
-TYPE &CURR_NANOS

This will not work unfortunately, only accurate to the nearest tenth in reality. The HGETC 'clock' appears to increment in .015/.016 second steps.

The microsecond part is always 232 and the nanosecond part is always 224.

I think the nanosecond support depends on the OS.