Discussion:
Does anyone know if the unsupported TBO (time boost utility that "drifts" time forward or backward by adjusting ticklength) was every ported to the Itanium?
Add Reply
Jon Pinkley
2020-10-29 05:52:13 UTC
Reply
Permalink
We are still running on Alpha, but will be migrating to Itanium.

Instantaneous time jumps are not tolerated well by out application, especially in the fallback direction. So we have always use time drift to move the clocks forward or backward, and SYS$MANAGER:UTC$TIME_SETUP.COM to adjust the TDF.

I am not looking for an answer for this weekend, but since it was on my mind, I thought I would post a question.

Hoff's archived FAQS mentioned that Itanium time support was never documented in any internals manuals. I have seen references to a SETCLOCK utility, but can't find it (and suspect it was VAX only).

http://www.faqs.org/faqs/dec-faq/vms/part3/

I have never seen the low level time support in the Itanium, and the TBO V2.0 utility uses cmkrnl code. $cmkrnl_s routin=reset_hwclk ; Initiate reset routine

And the code has alpha specific parts to gets the clock tick frequency from the HWRPB, so this is going to be more than running through the MACRO32 compiler.

Here is the original comp.os.vms thread for the version we are still using.

https://groups.google.com/d/msg/comp.os.vms/_o1LqXVeSlY/j5n_HNJolk4J

or by original message id:
----
From: ***@nl101.ittpub.nl (Hans van Veen - ITT Gouden Gids)
Subject: Daylight saving - Repost TBO code
Date: 1996/10/23
Message-ID: <***@ittpub>
X-Deja-AN: 191434625
organization: ITT Publitec R+D BV, Amsterdam
newsgroups: comp.os.vms,vmsnet.sysmgt
nntp-posting-user: veen
----

And I know the correct solution would be to use UTC for timestamps, but that won't happen soon.
Stephen Hoffman
2020-10-29 15:24:07 UTC
Reply
Permalink
Post by Jon Pinkley
Instantaneous time jumps are not tolerated well by out application,
especially in the fallback direction. So we have always use time drift
to move the clocks forward or backward, and
SYS$MANAGER:UTC$TIME_SETUP.COM to adjust the TDF.
For not the first time this has been or will be suggested, set the
server system time to UTC† and leave it there‡.

Or reboot the server to switch between standard and daylight saving time.

Put differently, embrace the suck, err, embrace limits of your existing
app design and historical management investments, and that all while
also always maintaining the proper system time.

Otherwise, see if VSI has an update to that TBO tool. Or pay somebody
to figure out how to update TBO to drift the hour. Or fix the app to
use UTC, or to use some different and DST-tolerant design.

I love OpenVMS timekeeping. Not.



†Yes, I know from UTC and TAI and have some familiarity with the rest
of the timekeeping morass, thank you very much. Neither UTC nor TAI
ever decrement.

‡I've asked a few users over the years whether they'd considered that
the server might be located in England.
--
Pure Personal Opinion | HoffmanLabs LLC
Jon Pinkley
2020-10-29 21:35:53 UTC
Reply
Permalink
Post by Stephen Hoffman
I love OpenVMS timekeeping. Not.
I am not in love with OpenVMS timekeeping either. The way the whole TDF mechanism works seems backward to me, i.e. setting UTC as the offset from local time instead of what seems more appropriate to me, setting the "Local" time as an offset from UTC (which the clock should be based on). And the latest change to the CRTL to deal with TDF was in my opinion, a Rube Goldberg "solution". Sort of like the Ptolemaic Model to explain retrograde planetary motion.

And now there another "design" that can't be fixed because it will break backward compatibility.

What was really needed was a way to have per process time zones, and have the 64bit base epoch system time be 17-NOV-1858 00:00:00.00 UTC.
Post by Stephen Hoffman
†Yes, I know from UTC and TAI and have some familiarity with the rest
of the timekeeping morass, thank you very much. Neither UTC nor TAI
ever decrement.
http://leapsecond.com/java/gpsclock.htm
https://www.timeanddate.com/time/universal-time.html
Post by Stephen Hoffman
‡I've asked a few users over the years whether they'd considered that
the server might be located in England.
But even England has BST British Summer Time. And it is not coordinated with USA DST.

The problem is that we no longer live in a "local world", and many VMS systems are used be people in many time zones (and tz rules).

But then every customer/application must develop their own way to deal with how time will be stored and displayed. It is easy enough to have offsets from UTC and display time in an application in a user's time zone, but that doesn't fix the show time output at DCL and in the queue manager, etc.

I agree that TDF (local base time to UTC offset) should really be zero. But I do wish there were VMS provided time services to get/display time in other time zones, and that these tz offsets would be automatically maintained by VMS.

But unix/linux doesn't get this correct either, i.e. I am not aware of per process/task/fork/thread tz in unix, but I'm not an expert unix/linux user either.

It isn't an "easy" problem to solve in a way that will please everyone, so DEC just put the problem in the customer's lap, and then there is no "standard" solution. Are file dates stored in "UTC", and if so, will the times displayed be wrong when the offset is changed. Dealing with time zones is a pain

The Problem with Time & Timezones - Computerphile


But this is a longstanding problem recognized early in VMS. There was an article in (I believe the PageSwapper) by Don Golden(?), with a title like "Just a Modest Proposal" where it was proposed that VMS time should always be UTC (perhaps it used GMT) and that there should be an offset for the local time.

The base time 0h 17-NOV-1858 is supposedly based on the MJD introduced by SAO in 1957, and by definition that is UT based.

Before I go too far off the main topic, I will say that I hope when the new SYSUAF layout that supports longer password hashes is cast in stone, it would be nice if there was a reserved field for a per user time offset/tz rule that could be used to provide a default, if OpenVMS ever does support per process tz rules.

Another thing it should have is a field to store the "Account Creation Date", as there is nothing there currently (other than the "UAI$_USER_DATA" blob, where a customer could store it, but then there is no standard way), and the closest thing there is is looking at the creation date of the user's UAF Default directory, aka sys$login directory, but that isn't an accurate mechanism, since moving a user to another disk will cause that date to change.

And if it ever does support per user tz, it should be possible for a user to "change" the tz from a DCL/RTL so that the process could view the time from a different perspective.
Stephen Hoffman
2020-10-29 23:35:56 UTC
Reply
Permalink
Post by Jon Pinkley
Post by Stephen Hoffman
I love OpenVMS timekeeping. Not.
I am not in love with OpenVMS timekeeping either. The way the whole
TDF mechanism works seems backward to me, i.e. setting UTC as the
offset from local time instead of what seems more appropriate to me,
setting the "Local" time as an offset from UTC (which the clock should
be based on). And the latest change to the CRTL to deal with TDF was
in my opinion, a Rube Goldberg "solution". Sort of like the Ptolemaic
Model to explain retrograde planetary motion.
And now there another "design" that can't be fixed because it will
break backward compatibility.
Change is feasible. It'd mean saved times on storage and timestamps
elsewhere and prior to the migration would be ±13 hours or so, though.
Among other wrinkles. But yes, compatibility claims another victim,
here.
Post by Jon Pinkley
What was really needed was a way to have per process time zones, and
have the 64bit base epoch system time be 17-NOV-1858 00:00:00.00 UTC.
Post by Stephen Hoffman
...
‡I've asked a few users over the years whether they'd considered that
the server might be located in England.
But even England has BST British Summer Time. And it is not
coordinated with USA DST.
The most common answer to that question of mine has been "Oh!", and
they seldom ask any more. If they do ask more, then discussing UTC is
fodder. But they usually wander off. Sorting the audience being the
intent of that question.
Post by Jon Pinkley
The problem is that we no longer live in a "local world", and many VMS
systems are used be people in many time zones (and tz rules).
Clusters are single timezone, too.

All sorts of interesting timeouts and skews and thresholds and limits
lurk here, too. DECset CMS will object for instance, should it detect
a time off by more than 30 seconds.
Post by Jon Pinkley
But then every customer/application must develop their own way to deal
with how time will be stored and displayed. It is easy enough to have
offsets from UTC and display time in an application in a user's time
zone, but that doesn't fix the show time output at DCL and in the queue
manager, etc.
I agree that TDF (local base time to UTC offset) should really be zero.
But I do wish there were VMS provided time services to get/display
time in other time zones, and that these tz offsets would be
automatically maintained by VMS.
Sort of.

There are calls for contending with that and most other time-related
needs, among the C RTL calls, the UTC system service calls, and the
DTSS calls.

The classic system service calls, and the DCL commands associated with
time, not so much.

http://h30266.www3.hpe.com/odl/i64os/opsys/vmsos84/4493/4493pro_016.html#port_api

http://h30266.www3.hpe.com/odl/i64os/opsys/vmsos84/5763/5763profile_068.html#tzset_function

http://h30266.www3.hpe.com/odl/axpos/opsys/vmsos84/6677/6677pro_gen.html#heading_3.12

etc

The OpenVMS documentation here is scattered at best, and scattershot.
Post by Jon Pinkley
But unix/linux doesn't get this correct either, i.e. I am not aware of
per process/task/fork/thread tz in unix, but I'm not an expert
unix/linux user either.
Per process timezone is sort-of available. Per thread, AFAIK, is not.
Post by Jon Pinkley
It isn't an "easy" problem to solve in a way that will please everyone,
so DEC just put the problem in the customer's lap, and then there is no
"standard" solution. Are file dates stored in "UTC", and if so, will
the times displayed be wrong when the offset is changed. Dealing with
time zones is a pain
...
And if it ever does support per user tz, it should be possible for a
user to "change" the tz from a DCL/RTL so that the process could view
the time from a different perspective.
TZ is available. Sort of.

But I long ago gave up and switched to UTC sans DST.

Discussions around continuing with the use of localtime or switching to
UTC have arisen with each previous port of OpenVMS, too.
--
Pure Personal Opinion | HoffmanLabs LLC
Chris
2020-10-30 01:27:43 UTC
Reply
Permalink
Post by Stephen Hoffman
I love OpenVMS timekeeping. Not.
I am not in love with OpenVMS timekeeping either. The way the whole
TDF mechanism works seems backward to me, i.e. setting UTC as the
offset from local time instead of what seems more appropriate to me,
setting the "Local" time as an offset from UTC (which the clock should
be based on). And the latest change to the CRTL to deal with TDF was
in my opinion, a Rube Goldberg "solution". Sort of like the Ptolemaic
Model to explain retrograde planetary motion.
And now there another "design" that can't be fixed because it will
break backward compatibility.
Change is feasible. It'd mean saved times on storage and timestamps
elsewhere and prior to the migration would be ±13 hours or so, though.
Among other wrinkles. But yes, compatibility claims another victim, here.
What was really needed was a way to have per process time zones, and
have the 64bit base epoch system time be 17-NOV-1858 00:00:00.00 UTC.
Post by Stephen Hoffman
...
‡I've asked a few users over the years whether they'd considered that
the server might be located in England.
But even England has BST British Summer Time. And it is not
coordinated with USA DST.
The most common answer to that question of mine has been "Oh!", and they
seldom ask any more. If they do ask more, then discussing UTC is fodder.
But they usually wander off. Sorting the audience being the intent of
that question.
The problem is that we no longer live in a "local world", and many VMS
systems are used be people in many time zones (and tz rules).
Clusters are single timezone, too.
All sorts of interesting timeouts and skews and thresholds and limits
lurk here, too. DECset CMS will object for instance, should it detect a
time off by more than 30 seconds.
But then every customer/application must develop their own way to deal
with how time will be stored and displayed. It is easy enough to have
offsets from UTC and display time in an application in a user's time
zone, but that doesn't fix the show time output at DCL and in the
queue manager, etc.
I agree that TDF (local base time to UTC offset) should really be
zero. But I do wish there were VMS provided time services to
get/display time in other time zones, and that these tz offsets would
be automatically maintained by VMS.
Sort of.
There are calls for contending with that and most other time-related
needs, among the C RTL calls, the UTC system service calls, and the DTSS
calls.
The classic system service calls, and the DCL commands associated with
time, not so much.
http://h30266.www3.hpe.com/odl/i64os/opsys/vmsos84/4493/4493pro_016.html#port_api
http://h30266.www3.hpe.com/odl/i64os/opsys/vmsos84/5763/5763profile_068.html#tzset_function
http://h30266.www3.hpe.com/odl/axpos/opsys/vmsos84/6677/6677pro_gen.html#heading_3.12
etc
The OpenVMS documentation here is scattered at best, and scattershot.
But unix/linux doesn't get this correct either, i.e. I am not aware of
per process/task/fork/thread tz in unix, but I'm not an expert
unix/linux user either.
Per process timezone is sort-of available. Per thread, AFAIK, is not.
It isn't an "easy" problem to solve in a way that will please
everyone, so DEC just put the problem in the customer's lap, and then
there is no "standard" solution. Are file dates stored in "UTC", and
if so, will the times displayed be wrong when the offset is changed.
Dealing with time zones is a pain
...
And if it ever does support per user tz, it should be possible for a
user to "change" the tz from a DCL/RTL so that the process could view
the time from a different perspective.
TZ is available. Sort of.
But I long ago gave up and switched to UTC sans DST.
Discussions around continuing with the use of localtime or switching to
UTC have arisen with each previous port of OpenVMS, too.
How does VMS keep time ?. Does it use ntp, or some system of it's
own ?. Most of the world seems to use UTC +/- offset these days,
which seems sensible...

Chris
Stephen Hoffman
2020-10-30 01:56:26 UTC
Reply
Permalink
Post by Chris
How does VMS keep time ?.
OpenVMS and most apps use a quadword value containing centiseconds
typically configured for localtime, and with few apps having adopted
the UTC timekeeping that semi-recent OpenVMS versions can also provide.

Here's some general reading on this topic from the old FAQ and from the
current manuals:
http://www.hoffmanlabs.com/vmsfaq/vmsfaq_004.html#faq_time
https://vmssoftware.com/pdfs/HP_branded_docs_1st_batch/HP_OpenVMS_System_Managers_Manual_Vol1.pdf#page=173


If after having read through that and should you still have questions,
stop back and I'll try to either clarify or confuse things more.

C provides the C APIs, as do other languages.

Details here do vary over the versions, with OpenVMS V7.3 and later
having integrated support for timekeeping and timezones—older releases
had that data largely in either the IP or DECnet-Plus stack.

V7.3 was when there started to be timezone-related prompts at OpenVMS
install time, among other updates.
Post by Chris
Does it use ntp, or some system of it's own ?.
OpenVMS uses its own local timebase, unless specifically configured for
NTP or DECnet-Plus DECdtss.

When OpenVMS and the IP or DECnet-Plus network stack is configured to
synchronize using NTP or DECdtss, those mechanisms then use system APIs
to manage and to drift the system time.

NTP presents the system with UTC values, meaning arithmetic to convert
UTC to localtime.
Post by Chris
Most of the world seems to use UTC +/- offset these days, which seems
sensible...
Localtime. And twice a year the localtime value shifts either manually
or automatically, for those that still "celebrate" DST.

Which is at the core of this thread.

DEC OpenVMS by way of DEC MICA is where Microsoft Windows inherited its
bad timekeeping ideas from, too.

Put differently, if you could pick a simple and utterly wrong approach
to timekeeping, that'd be what OpenVMS uses. Heap on ~forty years of
app upward compatibility, and things get even more muddled.
--
Pure Personal Opinion | HoffmanLabs LLC
Chris
2020-10-31 00:07:07 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Chris
How does VMS keep time ?.
OpenVMS and most apps use a quadword value containing centiseconds
typically configured for localtime, and with few apps having adopted the
UTC timekeeping that semi-recent OpenVMS versions can also provide.
Here's some general reading on this topic from the old FAQ and from the
http://www.hoffmanlabs.com/vmsfaq/vmsfaq_004.html#faq_time
https://vmssoftware.com/pdfs/HP_branded_docs_1st_batch/HP_OpenVMS_System_Managers_Manual_Vol1.pdf#page=173
If after having read through that and should you still have questions,
stop back and I'll try to either clarify or confuse things more.
C provides the C APIs, as do other languages.
Details here do vary over the versions, with OpenVMS V7.3 and later
having integrated support for timekeeping and timezones—older releases
had that data largely in either the IP or DECnet-Plus stack.
V7.3 was when there started to be timezone-related prompts at OpenVMS
install time, among other updates.
Post by Chris
Does it use ntp, or some system of it's own ?.
OpenVMS uses its own local timebase, unless specifically configured for
NTP or DECnet-Plus DECdtss.
When OpenVMS and the IP or DECnet-Plus network stack is configured to
synchronize using NTP or DECdtss, those mechanisms then use system APIs
to manage and to drift the system time.
NTP presents the system with UTC values, meaning arithmetic to convert
UTC to localtime.
Post by Chris
Most of the world seems to use UTC +/- offset these days, which seems
sensible...
Localtime. And twice a year the localtime value shifts either manually
or automatically, for those that still "celebrate" DST.
Which is at the core of this thread.
DEC OpenVMS by way of DEC MICA is where Microsoft Windows inherited its
bad timekeeping ideas from, too.
Put differently, if you could pick a simple and utterly wrong approach
to timekeeping, that'd be what OpenVMS uses. Heap on ~forty years of app
upward compatibility, and things get even more muddled.
Thanks for that, not something I had thought much about. I guess there
will be a move to UTC as baseline at some stage, with all else
calculated from that...

Chris
Stephen Hoffman
2020-10-31 15:04:00 UTC
Reply
Permalink
Post by Chris
Thanks for that, not something I had thought much about. I guess there
will be a move to UTC as baseline at some stage, with all else
calculated from that...
I'd doubt that VSI will reset the time-base to UTC, given the singular
and necessary focus on the port.

Switching the time-base would mean that all saved times from prior to
the switch are off by ±13 hours or so.

Some customers won't notice that. Some can tolerate that. Some cannot.
Among other wrinkles. And there will be wrinkles.

If history repeats, we'll probably then next discuss this topic around
the time of the Arm or RISC-V port.
--
Pure Personal Opinion | HoffmanLabs LLC
Jon Pinkley
2020-10-31 09:26:52 UTC
Reply
Permalink
Post by Stephen Hoffman
There are calls for contending with that and most other time-related
needs, among the C RTL calls, the UTC system service calls, and the
DTSS calls.
The classic system service calls, and the DCL commands associated with
time, not so much.
http://h30266.www3.hpe.com/odl/i64os/opsys/vmsos84/4493/4493pro_016.html#port_api
http://h30266.www3.hpe.com/odl/i64os/opsys/vmsos84/5763/5763profile_068.html#tzset_function
http://h30266.www3.hpe.com/odl/axpos/opsys/vmsos84/6677/6677pro_gen.html#heading_3.12
etc
Thanks for the links, the decdts

I skimmed through the first link and finally got to the last page, where there was an example.

http://h30266.www3.hpe.com/odl/i64os/opsys/vmsos84/4493/4493pro_021.html

But unfortunately, you must need to be using DECnet-Plus. Why they don't mention this until the end where it has (with invalid cc /output= instead of /object=)

Assume the preceding program is named compare_events.c . To compile and link the program on a DECnet-Plus for OpenVMS system, enter the following command:

$ cc compare_events.c/output=compare_events.obj
$ link compare_events.obj, sys$input:/options[Return]
sys$library:dtss$shr.exe/share[Ctrl-z]
$

We have DECnet IV and are not using DDTS for time.

I found some old threads with a search for "DECdts" on google groups. They said that DECdts is included after 7.3-2, and the system has sys$library:dtss$shr.exe, but I can't find utc.h to #include
Stephen Hoffman
2020-10-31 14:58:53 UTC
Reply
Permalink
Post by Jon Pinkley
But unfortunately, you must need to be using DECnet-Plus. Why they
don't mention this until the end where it has (with invalid cc /output=
instead of /object=)
Log some feedback with VSI, if that's still the case with the current
manuals and current VSI software.

The DECdts callable routines have been integrated with and shipped as
part of OpenVMS for most of two decades. I had the related API doc
moved from the DECnet-Plus manuals to the OpenVMS manuals and that then
first (re)published in the OpenVMS V8.2 docs IIRC, but the routines
were migrated earlier; with the integration of the timezone and related
timekeeping support at OpenVMS V7.3.

https://groups.google.com/d/msg/comp.os.vms/e7PzJ1W3eSs/0Hua0U2VrBYJ
Post by Jon Pinkley
I found some old threads with a search for "DECdts" on google groups.
They said that DECdts is included after 7.3-2, and the system has
sys$library:dtss$shr.exe, but I can't find utc.h to #include
The separate header files are for reference, and moderately-old C
stopped extracting the header files from the system definitions. See
the libext tool on the Freeware, as I got that code open-sourced when
the compilers stopped offering to extract the header files into the
reference directories. The compilers do look in the proper spot for
headers. But if you don't have the utc.h file around in the C header
text libraries (I don't have anything running as far back as you seem
to be using), you're left to back-port that or to upgrade OpenVMS to
something approaching current OpenVMS.
--
Pure Personal Opinion | HoffmanLabs LLC
Jon Pinkley
2020-11-01 03:54:50 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Jon Pinkley
But unfortunately, you must need to be using DECnet-Plus. Why they
don't mention this until the end where it has (with invalid cc /output=
instead of /object=)
Log some feedback with VSI, if that's still the case with the current
manuals and current VSI software.
The DECdts callable routines have been integrated with and shipped as
part of OpenVMS for most of two decades. I had the related API doc
moved from the DECnet-Plus manuals to the OpenVMS manuals and that then
first (re)published in the OpenVMS V8.2 docs IIRC, but the routines
were migrated earlier; with the integration of the timezone and related
timekeeping support at OpenVMS V7.3.
https://groups.google.com/d/msg/comp.os.vms/e7PzJ1W3eSs/0Hua0U2VrBYJ
Post by Jon Pinkley
I found some old threads with a search for "DECdts" on google groups.
They said that DECdts is included after 7.3-2, and the system has
sys$library:dtss$shr.exe, but I can't find utc.h to #include
The separate header files are for reference, and moderately-old C
stopped extracting the header files from the system definitions. See
the libext tool on the Freeware, as I got that code open-sourced when
the compilers stopped offering to extract the header files into the
reference directories. The compilers do look in the proper spot for
headers. But if you don't have the utc.h file around in the C header
text libraries (I don't have anything running as far back as you seem
to be using), you're left to back-port that or to upgrade OpenVMS to
something approaching current OpenVMS.
--
Pure Personal Opinion | HoffmanLabs LLC
I extracted the example from help on eisner, pasted into eve editor, converted tabs to spaces, used box select and box cut insert to remove the leading blanks, changed the command to /object= and put in comment.

It works the same on Eisner running VSI 8.4-1L2, here's a log.

I must be doing something wrong.

(void)scanf("%d",&tmTime.tm_min);
(void)printf("Inacc Secs? ");
(void)scanf("%d",&tmInacc.tm_sec);
if (utc_mkanytime(utcTime,
&tmTime,
(long)0,
&tmInacc,
(long)0,
(long)0))
exit(1);
}
/*
Assume the preceding program is named compare_events.c. To
compile and link the program on a DECnet-Plus for OpenVMS system,
enter the following command:
$ cc compare_events.c/object=compare_events.obj
$ link compare_events.obj, sys$input:/options<Return>
sys$library:dtss$shr.exe/share<Ctrl-z>
$
*/
[End of file]
Buffer: COMPARE_EVENTS.C | Write | Insert | Forward

126 lines written to file USR_SCRATCH:[PINKLEY]COMPARE_EVENTS.C;4

$ sho log decc*

(LNM$PROCESS_TABLE)

(LNM$JOB_81F57700)

(LNM$GROUP_000030)

(LNM$SYSTEM_TABLE)

"DECC$CRTLMAP" = "SYS$SHARE:DECC$SHR_EV56"
"DECC$SHR" = "SYS$SHARE:DECC$SHR_EV56"

(LNM$SYSCLUSTER_TABLE)

(DECW$LOGICAL_NAMES)
$ cc/ver
VSI C V7.4-002 on OpenVMS Alpha V8.4-2L2
$ tail USR_SCRATCH:[PINKLEY]COMPARE_EVENTS.C
(void)scanf("%d",&tmTime.tm_hour);
(void)printf("Minute? ");
(void)scanf("%d",&tmTime.tm_min);
(void)printf("Inacc Secs? ");
(void)scanf("%d",&tmInacc.tm_sec);
if (utc_mkanytime(utcTime,
&tmTime,
(long)0,
&tmInacc,
(long)0,
(long)0))
exit(1);
}
/*
Assume the preceding program is named compare_events.c. To
compile and link the program on a DECnet-Plus for OpenVMS system,
enter the following command:
$ cc compare_events.c/object=compare_events.obj
$ link compare_events.obj, sys$input:/options<Return>
sys$library:dtss$shr.exe/share<Ctrl-z>
$
*/
$ cc compare_events.c/object=compare_events.obj

#include <utc.h> /* utc structure definitions */
.^
%CC-F-NOINCLFILEF, Cannot find file <utc.h> specified in #include directive.
at line number 2 in file USR_SCRATCH:[PINKLEY]COMPARE_EVENTS.C;4
$ help/nopage decdts example

DECDTS

Example

The following C programming example shows a practical application
of the DECdts API programming routines. The program performs the
following actions:

o Prompts the user to enter time coordinates.

o Stores those coordinates in a tm structure.

o Converts the tm structure to a utc structure.

o Determines which event occurred first.

o Determines if Event 1 may have caused Event 2 by comparing the
intervals.

o Prints out the utc structure in ISO text format.

#include <time.h> /* time data structures */
#include <utc.h> /* utc structure definitions */

void ReadTime();
void PrintTime();

/*
* This program requests user input about events, then prints out
* information about those events.
*/

main()
{
struct utc event1,event2;
enum utc_cmptype relation;

/*
* Read in the two events.
*/

ReadTime(&event1);
ReadTime(&event2);

/*
* Print out the two events.
*/

printf("The first event is : ");
PrintTime(&event1);
printf("\nThe second event is : ");
PrintTime(&event2);
printf("\n");

/*
* Determine which event occurred first.
*/
if (utc_cmpmidtime(&relation,&event1,&event2))
exit(1);

switch( relation )
{
case utc_lessThan:
printf("comparing midpoints: Event1 < Event2\n");
break;
case utc_greaterThan:
printf("comparing midpoints: Event1 > Event2\n");
break;
case utc_equalTo:
printf("comparing midpoints: Event1 == Event2\n");
break;
default:
exit(1);
break;
}

/*
* Could Event 1 have caused Event 2? Compare the intervals.
*/

if (utc_cmpintervaltime(&relation,&event1,&event2))
exit(1);

switch( relation )
{
case utc_lessThan:
printf("comparing intervals: Event1 < Event2\n");
break;
case utc_greaterThan:
printf("comparing intervals: Event1 > Event2\n");
break;
case utc_equalTo:
printf("comparing intervals: Event1 == Event2\n");
break;
case utc_indeterminate:
printf("comparing intervals: Event1 ? Event2\n");
default:
exit(1);
break;
}

}

/*
* Print out a utc structure in ISO text format.
*/

void PrintTime(utcTime)
struct utc *utcTime;
{

char string[50];

/*
* Break up the time string.
*/

if (utc_ascgmtime(string, /* Out: Converted time */
50, /* In: String length */
utcTime)) /* In: Time to convert */
exit(1);
printf("%s\n",string);
}

/*
* Prompt the user to enter time coordinates. Store the
* coordinates in a tm structure and then convert the
* tm structure to a utc structure.
*/

void ReadTime(utcTime)
struct utc *utcTime;
{
struct tm tmTime,tmInacc;

(void)memset((void *)&tmTime, 0,sizeof(tmTime));
(void)memset((void *)&tmInacc, 0,sizeof(tmInacc));
(void)printf("Year? ");
(void)scanf("%d",&tmTime.tm_year);
tmTime.tm_year -= 1900;
(void)printf("Month? ");
(void)scanf("%d",&tmTime.tm_mon);
tmTime.tm_mon -= 1;
(void)printf("Day? ");
(void)scanf("%d",&tmTime.tm_mday);
(void)printf("Hour? ");
(void)scanf("%d",&tmTime.tm_hour);
(void)printf("Minute? ");
(void)scanf("%d",&tmTime.tm_min);
(void)printf("Inacc Secs? ");
(void)scanf("%d",&tmInacc.tm_sec);

if (utc_mkanytime(utcTime,
&tmTime,
(long)0,
&tmInacc,
(long)0,
(long)0))
exit(1);

}

Assume the preceding program is named compare_events.c. To
compile and link the program on a DECnet-Plus for OpenVMS system,
enter the following command:

$ cc compare_events.c/output=compare_events.obj
$ link compare_events.obj, sys$input:/options<Return>
sys$library:dtss$shr.exe/share<Ctrl-z>
$



Topic? Exit
$
Stephen Hoffman
2020-11-01 14:34:17 UTC
Reply
Permalink
Post by Jon Pinkley
I extracted the example from help on eisner, pasted into eve editor,
converted tabs to spaces, used box select and box cut insert to remove
the leading blanks, changed the command to /object= and put in comment.
It works the same on Eisner running VSI 8.4-1L2, here's a log.
...
$ cc compare_events.c/object=compare_events.obj
#include <utc.h> /* utc structure definitions */
.^
%CC-F-NOINCLFILEF, Cannot find file <utc.h> specified in #include directive.
at line number 2 in file USR_SCRATCH:[PINKLEY]COMPARE_EVENTS.C;4
$ ...
I should know better than to roll over and look under any rocks.

Here's a potential work-around, hand-crafting your own header:
https://groups.google.com/d/msg/comp.os.vms/xu_hHbt8_Io/4xQcC-nztiEJ

The following documentation reads more like a change spec than
documentation, seemingly omits any reference to the paired
sys$lib_c.tlb file, and somehow neglects to mention how to reference
the libraries from the compiler:
https://vmssoftware.com/docs/VSI_PROGRAM_CONCEPTS_VOL_II.pdf#Page=132
(less-than-preferable page-numbering handling in that PDF file, too.)

If utc.h isn't in the base distro and gets installed from a DECnet-Plus
kit, either use the hack-around above, or yank the file out of the
DECnet-Plus kit and reference it directly (or stuff the header into
your local sys$starlet_c.tlb yourself). If utc.h isn't in
sys$starlet_c.tlb (or maybe in some other local library) in OpenVMS
V8.4-2L1 or V8.4-2L2, log a bug with the folks at VSI, and hopefully
that then get fixed for OpenVMS V9.2, if not sooner. Seems this DECdtss
code isn't used very often, either.


Errata: "Where there is a difference from VAXCDEF.TLB, the old symbol
name is also included for compatibility, but users are encouraged to
follow the new conventions.".... New conventions? That is one of the
more buried programming recommendations I've encountered. And yes,
using __NEW_STARLET (now with the legacy code probably better thought
of as needing __OLD_STARLET, but that default won't get flipped) is a
good idea.
--
Pure Personal Opinion | HoffmanLabs LLC
Jon Pinkley
2020-11-02 09:41:05 UTC
Reply
Permalink
Post by Stephen Hoffman
https://groups.google.com/d/msg/comp.os.vms/xu_hHbt8_Io/4xQcC-nztiEJ
The following documentation reads more like a change spec than
documentation, seemingly omits any reference to the paired
sys$lib_c.tlb file, and somehow neglects to mention how to reference
https://vmssoftware.com/docs/VSI_PROGRAM_CONCEPTS_VOL_II.pdf#Page=132
(less-than-preferable page-numbering handling in that PDF file, too.)
If utc.h isn't in the base distro and gets installed from a DECnet-Plus
kit, either use the hack-around above, or yank the file out of the
DECnet-Plus kit and reference it directly (or stuff the header into
your local sys$starlet_c.tlb yourself). If utc.h isn't in
sys$starlet_c.tlb (or maybe in some other local library) in OpenVMS
V8.4-2L1 or V8.4-2L2, log a bug with the folks at VSI, and hopefully
that then get fixed for OpenVMS V9.2, if not sooner. Seems this DECdtss
code isn't used very often, either.
Thanks, I did a $ product extract file decnet_osi /select=utc.h /source= ...

That worked. I got the compare_events example to compile and link. Changed the #include <utc.h> to #include "utc.h". Get warning for other things, but it runs.

Now, if other things do not work, it is less likely to be due to an error in the utc.h than if I cobbled one together.

It isn't a surprise that the DECdtss code isn't used very often, because DECnet V was never very popular, and if that wasn't installed, then it requires extra work to get the header file, even if the sys$library:dtss$shr.exe is there.

Doesn't solve the TBO problem, but without access to Itanium listings, getting the tick frequency is not an easy task.

After reading more about decdts, it doesn't look like it really handles different timezone rules; it does allow you to specify a tdf, but there can be multiple tz with the same tdf, but different dst rules.

Thanks again. Your links, were helpful.
Jon Pinkley
2020-11-04 08:58:15 UTC
Reply
Permalink
Post by Jon Pinkley
Doesn't solve the TBO problem, but without access to Itanium listings, getting the tick frequency is not an easy task.
This may not be as non-portable as I thought. I looked at the source of LDDRIVER.MAR from digiater.nl, and it has lowlevel access to the hwrpb, and it appears to do the same operations for the Alpha and IA64.

I don't have a working Itanium yet, so I can't try. But it looks like it may be easier than I thought, but that may just be a statement from ignorance.
Volker Halle
2020-11-04 10:48:37 UTC
Reply
Permalink
Jon,

TBO 2.0 (as pointed to by your first entry), compiles and links without error on OpenVMS I64 V8.2. Chances are good, that it will also function correctly, but I didn't try ...

Volker.
Jon Pinkley
2020-11-04 19:47:26 UTC
Reply
Permalink
Post by Volker Halle
Jon,
TBO 2.0 (as pointed to by your first entry), compiles and links without error on OpenVMS I64 V8.2. Chances are good, that it will also function correctly, but I didn't try ...
Volker.
Volker,

Thank you very much.

I wouldn't test it on any production system either. It is unsupported and can easily cause problems, especially if you provide input that it isn't expecting. Like reversing the /DELTA and /RANGE values, which can result in overflows and insane values for EXE$GL_TICKLENGTH. In other words, there is no sanity checking, so if it isn't being used by a command procedure, it is a dangerous utility.

Or as Hoff might say, it has no blade guards.

And that isn't even considering that there may be other lurking problems in the $cmkrnl code that behave slightly differently on the IA64, although my guess is that it will work correctly.

Unfortunately, I don't think we will ever see another version of the IDSM that covers changes in the IA64 or X64 versions of OpenVMS.

Thanks again,

Jon
abrsvc
2020-11-04 20:02:10 UTC
Reply
Permalink
Post by Jon Pinkley
Post by Volker Halle
Jon,
TBO 2.0 (as pointed to by your first entry), compiles and links without error on OpenVMS I64 V8.2. Chances are good, that it will also function correctly, but I didn't try ...
Volker.
Volker,
Thank you very much.
I wouldn't test it on any production system either. It is unsupported and can easily cause problems, especially if you provide input that it isn't expecting. Like reversing the /DELTA and /RANGE values, which can result in overflows and insane values for EXE$GL_TICKLENGTH. In other words, there is no sanity checking, so if it isn't being used by a command procedure, it is a dangerous utility.
Or as Hoff might say, it has no blade guards.
And that isn't even considering that there may be other lurking problems in the $cmkrnl code that behave slightly differently on the IA64, although my guess is that it will work correctly.
Unfortunately, I don't think we will ever see another version of the IDSM that covers changes in the IA64 or X64 versions of OpenVMS.
Thanks again,
Jon
The PARSEC Group has a class that covers the internals differences for V8.3 primarily for system managers. See the link below:

https://www.parsec.com/training/openvms/U3729S.php

Dan
David Jones
2020-11-05 17:04:47 UTC
Reply
Permalink
Post by Volker Halle
Jon,
TBO 2.0 (as pointed to by your first entry), compiles and links without error on OpenVMS I64 V8.2. Chances are good, that it will also function correctly, but I didn't try ...
Volker.
I assume you have to disable NTP service while running TBO or else the NTP daemon will keep trying to correct the drift.
Jon Pinkley
2020-11-06 02:04:34 UTC
Reply
Permalink
Post by David Jones
Post by Volker Halle
Jon,
TBO 2.0 (as pointed to by your first entry), compiles and links without error on OpenVMS I64 V8.2. Chances are good, that it will also function correctly, but I didn't try ...
Volker.
I assume you have to disable NTP service while running TBO or else the NTP daemon will keep trying to correct the drift.
Yes, NTP or anything else that is modifying either TICKLENGTH or TIMEADJUST has to be stopped during the "time dilation or compression" period.

What TBO does is pretty simple. It calculates a new ticklength and timeadjust based on user's input /delta is number of seconds to adjust time by, /range is the period of time this adjustment should take (in "normal" time, e.g. our fallback.com has

$ tbo /direction=backward /range=18000 /delta=3600 /info

The above takes 5 hours (18000 seconds) as measured by stopwatch to adjust the openvms software clock EXE$GQ_SYSTIME back by 1 hour (3600 seconds). In other words, the OpenVMS software clock will advance by 4 hours over a 5 hour period, with the end effect of setting the clock back one hour, while EXE$GQ_SYSTIME continues to march forward with a "relatively" constant rate. TBO does not touch EXE$GQ_SYSTIME; that is updated by the hwclk interrupt service routine, and the ISR also looks at EXE$GL_TICKLENGTH and EXE$GL_TIMEADJUST (and updates them as well, as needed).

; EXE$GL_TICKLENGTH - increment added to clock at each hardware clock interrupt
; EXE$GL_TIMEADJUST - number of ticks to apply EXE$GL_TICKLENGTH (before resetting EXE$GL_TICKLENGTH to the "standard" value EXE$GL_SYSTICK

As far as I know, there is nothing to ensure mutual exclusion, e.g. no DLM lock to prevent another thread from changing these. no blade guards. I don't know if NTP and DTSS know about each other either. TBO does use hwclk spinlock to protect against hwclk interrupt service routine from doing updates to EXE$GL_TICKLENGTH and EXE$GL_TIMEADJUST while TBO is replacing them with new values.

My guess is that if NTP were not stopped, it would quickly replace EXE$GL_TICKLENGTH and EXE$GL_TIMEADJUST with values of its choosing, and the settings that TBO set would be lost. The effect would be that your clock would not be changed. Almost like issuing the command $ TBO /RESET shortly after the initial TBO /dire=... /range=... /delta=... (but the new values wouldn't be the default EXE$GL_TIMADJUST = 0 and EXE$GL_TICKLENTH = EXE$GL_SYSTICK)

Also note that sys$manager:utc$time_setup TDF function will also update the EXE$GQ_TDF, EXE$GQ_TODCBASE and EXE$GQ_SAVED_HWCLOCK, even if you don't request the time to be changed.

If you have programs using the CRTL time functions, they will still see an abrupt change in time when the TDF is changed. So one way to minimize that would be to periodically change the EXE$GQ_TDF to the calculated offset from UTC, but that may cause other problems, because the TZ would still be set to one a specific time zone with offset, and if EXE$GQ_TDF was also "drifting", you would probably odd results.

During the "twilight time zone" if I send email, the sent time is note reported correctly, and it seems to be 2x the difference that I expected. It still causes fewer problems than file timestamps that overlap during the 2AM DST and 2AM ST period, e.g. 1AM to 2AM "local time" is duplicated in the fall if time is just set back one hour.

There are many places that EXE$GQ_SYSTIME is referenced.

Loading...