.; .; This is article for submission to the RSX-MultiTasker .; .; LAST EDIT: 30-NOV-1987 11:50:12 .; .;.ps 58,80 .;.lm 10 .;.rm 75 .lm 0 .rm 65 .c; AS TIME CLUNKS ON .s .c; Peter Stadick .c; Cargill, Inc. .c; Commodity Marketing Division .c; P.O. Drawer AR, Reserve,LA 70084 .s 2 .i 5 Realtime control software is often required to record the time events occured and be able to manipulate those time values. The problem has been the lack of a convenient way to record those times in a format the could be compatible with other software packages, calculate new time values from existing time values and yet do this in some uniform "generic standard". Believe it or not a method does exist, "clunk" time. .s .i 5 A "clunk" is a unit of time equal to 100 nanoseconds or thats 10 million clunks per second. A clunk time (date/time) is defined as the number of clunks, expressed as a 64-bit unsigned integer, since November 17,1858. This was the date the first photographic plate was exposed at the Smithsonian Astrophysical Laboratory ushering in the age of modern astronomy. Clunks provide very fine time resolution, yet can be used to span centuries. As a 64-bit integer it will take some 58,000 years before it will overflow. That should suffice for your programs until that next company merger when all programming is overhauled. .s .i 5 DEC has used the clunk date/time concept in RSX Datatrieve (USAGE IS DATE) and in VMS for the system date/time and VMS software products including VMS Datatrieve. .s .i 5 In 1982 Bob Rock of Northern Telecom wrote an article for the Multitasker on clunks. At that time he had written several routines that converted the DEC date and time stamp into clunks and visa versa. The routines did not actually let you manipulate the clunk time values. .s .i 5 About a year ago I designed some logistics modeling software in which I needed to record events for later analysis as well as predict when future event should occur. Parts of the model required time calculations over periods of months while in other parts minutes was the order of magnitude. Here is where clunks really payoff. They are just as accurate over many years as over several seconds. To find the difference between two times all that is required is to subrtact the two clunk time values and divide by the time unit, in clunks, needed. To calculate a new clunk time value in the future or past the reverse of the process is done. .s .i 5 Another major reason that clunk time representation was chosen is because Datatrieve uses clunks as the internal date representation for fields declared 'USAGE DATE'. The software involved using Datatrieve for some of the report generation and OMSI Pascal to perform the modeling calculations. Here, clunks proved a way to represent dates in a format compatable with both software packages. .s .i 5 Datatrieve works only with the date portion of the clunk date/time and truncate the hours, minutes and seconds off a date printed in a report. Clunk dates written by Datatrieve will have "00:00:00" as the time value. If you need to do date comparisons in Datatrieve, keep this in mind. Datatrieve will arrive at an exact match of an externally written clunk time only if you used "00:00:00" as the time (IF DATE EQ "14-FEB-87"). If you use another time value, exact matches must be done with a range comparison (IF DATE GE "14-FEB-87" AND DATE LT "15-FEB-87"). .s .i 5 Clunks do have a problem when it comes to RMS key compatability. There is no 64-bit unsigned integer key type in RMS-11. When a 'USAGE DATE' field in Datatrieve is declared as a key field, Datatrieve sets the key type to an eight character ASCII string. This allows Datatrieve to search for exact matches but will not allow 'greater than' searches. This is because the clunk values are stored least significant word to most significant word. If the clunks were stored in the reverse order 'greater than' searches would be possible. .s .i 5 In real practace, working with 64-bit integers on a PDP-11 does present some problems. For example, there is no instruction to do a 64-bit unsigned integer divide returning the quotient and remainder. To overcome this problem, we have enhanced the clunk time routines to allow 64-bit integer manipulations. On the upcoming release of the Fall 87 RSX-SIG tape we have submitted an overhauled version of Bob Rock's original submission with some new features. (This supercedes our Fall 86 submission.) The capability to convert between clunks and the DEC date and time stamp is still there but three new functions have been added. The first is a routine to calculate the difference in time between two clunk time values, returning the number of days and amount of time. The second is the ability to compute a new clunk value by adding or subtracting a specfic amount of time from an existing clunk value. The third function returns which day of the week a given clunk value falls on. .s .i 5 The rudimentary routines to do 64-bit unsigned integer adds, subtracts, multiplies and divides have been included to do the added clunk date/time manipulations. These routines have been isolated as standalone routines so they can be used outside of the "clunk date" context for other purposes where 64-bit integer arithmetic would be handy. A 64-bit integer allows storage and manipulation of numbers from 1 to 17 quintillion (thats 17 with 18 zeros) with no rounding errors. Use of these routines will let you work with the U. S. budget and deficit figures (at least for the next few years) with resolution down to the last penny, or let you program traders get set for the next market crash. .s .i 5 All nine of the routines use the DEC call site convention to pass parameters. This enables the routines to be used by FORTRAN, Basic-Plus-II, OMSI Pascal or MACRO-11. Great pains were taken when revising and writing the software to write only pure, position independent code. This enables the routines to be built into a shared resident, cluster or supervisor mode library. A resident and supervisor mode library example is included in the submission. .s .i 5 I found clunks to be a very useful way of storing and manipulating time values. They didn't have the shortcomings and pitfalls of other methods I have seen and tried. The concept of a date/time stamp that can span centuries and yet retain 100 nanosecond resolution provides the ultimate in flexibility. Now that some of the overhead in manipulating clunk time values has been simplified, maybe clunk's time has come.