Re: COBOL Time of Day in micro-seconds or nano-seconds

On Fri, 30 May 2008 09:03:32 -0500, "HeyBub" <heybub@xxxxxxxxxxxxxxx> wrote:

don@xxxxxxxxxxx wrote:
All

Does anyone know of a "standard" or widely accepted way to get COBOL
time of day in micro-seconds or nano-seconds for use in generating
more accurate transaction time-stamp and for use in measuring
transaction turn-around time.

The current-date function only returns hundredth of a second.

Using mainframe assembler the micro-second clock counter can be
accessed but that's not standard COBOL and not portable across
platforms. In J2SE Java, there is the method System.nanotime() to get
the more accurate time of day in nano-secounds available from the host
system but that's not standard COBOL either.


On PCs, the best resolution is ghastly, I think it's 16 milliseconds. But
whatever, you're limited to the resolution of the CPU's timer.

The interrupt 10 timer is ancient history. Its resolution was 1/18.2 sec = 56 ms. Intel
and Windows have offered higher resolution timers since the 80386 circa. 1994.

The question seemed oriented to mainframes and/or Cobol. ANS Standard Cobol offers no
solution. The z/OS API does but it's not portable, as stated in the question. So does
POSIX, but it too is tied to one OS family (Unix). I think the best answer is a non-Cobol,
OS-independent one such as GNU C.

Another tack is to get a start time, process 'n' transactions (where 'n' is
a large number), get an ending time then compute an average.

Yep, that's my preferred way. When trying to time a single event or iteration, the
overhead of GETTING the time can be longer than, or a significant percentage of, the event
being timed.

But the question was how to get a high resolution transaction timestamp, which would be
used to order events chronologically or detect collisions.
.

Relevant Pages

  • Re: Method to force keeping of source
    ... It appears to me that your wish is that the COBOL standard should prevent ... environment for the compiler or in the execution environment. ... > implementor defined is one of the problems as I look at the situation as ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... Here's the problem with OO COBOL - it is still very incomplete.. ... realized that OO was incomplete without support ... It's about two years ago a former, retired M/F Manager, (not Bill Klein ... Micro Focus above - but he was referring to the fact that Standard ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... There are users of OO COBOL; they are just far fewer than either the vendors ... whether from the same vendor or not. ... disagreed with you that XML should be supported *first* by the OO features ... > being spent by J4 to provide these facilities through a standard that will ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... some aspects of OO COBOL have grown and evolved since then. ... Classes from ANY vendor on ANY platform can be "wrapped" (provided the ... 2002 standard implemented. ... I really don't care what J4 or WG4 or SG-1 ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... on the ISO Date/Time formats proposal. ... provided *precisely* so that a *single standard* numeric format including ... personal focus is on "core COBOL" and extending what's already there. ... In addition, at the WG4 meeting in October, with the support of J4, I ...
    (comp.lang.cobol)