How to return time value to thousandths of a second?

[alanplayford]

I'm converting a heap of Assembler programs to MF Cobol, one of which uses the BAL "TIME" macro to get the system time in format hhmmssttt.
I'm using the COBOL FUNCTION CURRENT-DATE to do the same, but this only returns time to a precision of hhmmsshh.

Is there any way of getting more precision out of the function, chaps?

 

[fredericofonseca]

cobol vendor, version and operating system please

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[alanplayford]

Sorry, Frederico!
Cobverting BAL from IBM Enterprise System to COBOL on Windows PC using MicroFocus Mainframe Express (MF COBOL), v3.1

 

[jmanj]

I don't know about thousandth of a seconds but in Tandem system I usually use micro seconds (millionth of a second)
which is 1000000 micro seconds. A practical usage is when you are trying to find the days or time differences between two dates and time. You simply convert hours, minutes and seconds
into micro seconds then add all the micro seconds.

Here's some numbers (it's been a long time so I hope it is the correct conversion):

Hours * 3600000000 = total micro seconds in an hr.
Minutes * 60000000 = total micro second in a minute.
Seconds * 1000000 = total micro seconds in a second.

Your working storage should be like PIC 9S(18) COMP.

 

[3gm]

You might want to use LE callable services to get the local time in YYYYMMDDHHMMSS999 format (CEELOCT). Check the LE programming guide for details.

Regards,

Glenn

 

[webrabbit]

A millisecond is only 1,000 microseconds. By definition.

 

[alanplayford]

Thanks to all who responded.

3gm, I have tried the CEELOCT option (have to set LE environment option to enable), but actually this cheats a little, and the CEELOCT program code always inserts a zero in the thousandths position. It therefore returns the same precision as the ACCEPT or FUNCTION methods, it only appears at first glance to be more precision?

I'm currently experimenting with the WINAPI functions such as "GetSystemTime" etc. these appear a little better, but apparently the Windoze hardware tends to jump in iuncrements of several thousandths of a second. Guess it just doesn't think anybody would want more precision? )

I'll plough on, but this appears to be a problem that many people have found in the past, and it depends on your platform as to which options are available (e.g. Unix has a diffenent environmental function)

 

[papadi]

Hi There,

IIRC - The intrinsic FUNCTION CURRENT-DATE in Enterprise COBOL can give you resolution up to 100th of a second.

Guess it just doesn't think anybody would want more precision?

How is one more digit of precision needed for this requirement?


If you really, really must, suggest you consider an assembler STCK (or STCKE if you want to cover the STCK overflow in 2042).

 

[Glenn9999]

I'm currently experimenting with the WINAPI functions such as "GetSystemTime" etc. these appear a little better, but apparently the Windoze hardware tends to jump in iuncrements of several thousandths of a second. Guess it just doesn't think anybody would want more precision?

I don't know precisely what your programs are looking to do, but if you're timing something, GetSystemTime isn't what you want. All it's good for is getting the date and time out of the system into your program, and from the comment you made, I guess that's NOT what you're doing.

These two are what you want if you want to time stuff:
QueryPerformanceFrequency
QueryPerformanceCounter

and if worse comes to worse and you're on a 9X series box, use:

timeGetTime



Measurement is not management.

 

[MarcLodge]

Alan,

Have a look at this link

http://groups.google.com/group/comp.lang.cobol/browse_thread/thread/9272c02e24c385fb?pli=1

It contains some interesting information, much of which I think you have already investigated, but there might be something there of use.

Marc