Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!YKTVMH3.BITNET!PERSHNG From: PERSHNG@YKTVMH3.BITNET ("John A. Pershing Jr.") Newsgroups: comp.lang.asm370 Subject: (none) Message-ID: <9009061415.AA08150@ucbvax.Berkeley.EDU> Date: 6 Sep 90 12:59:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: IBM 370 Assembly Programming Discussion List Distribution: inet Organization: The Internet Lines: 27 The CVTxxx stuff is MVS specific and won't work, e.g., on VM. The TOD Clock is explained quite well in Principles of Operation in Chapter 4, "Control". The basic rules are that on a single CPU the TOD clock will always appear to increase -- successive STCK instructions will store ever-increasing values -- and on a multiprocessor system the TOD clock will always yield a *unique* value even if two CPUs issue STCK instructions "simultaneously". The "recommended standard epoch" of January 1, 1900, 0 a.m. GMT is essentially universal. The high-order ("sign") bit of the TOD clock turned to a '1' on the fateful day of May 11, 1971, on which day it became apparent who was (incorrectly) using signed arithmetic (the TOD clock is unsigned). If you STCK and this high-order bit is a '1', then your clock is most likely set to the recommended standard epoch. The high-order word measures Mega (i.e., 2**20) microseconds, which is the basis for the seemingly bizarre resolution of 1.048576 seconds. As mentioned in the PrincOps, this is more than enough resolution for determining the current time of day (since the system TOD clock is typically set from the operator's wristwatch). For measuring elapsed time intervals, you should use both words of the clock for maximum resolution, with the caveat that different processor models have different actual resolutions. John Pershing IBM Research, Yorktown Heights