<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12-Jun-15 11:03, Johnny Billquist
wrote:<br>
</div>
<blockquote cite="mid:557AF4B6.3020200@softjar.se" type="cite"><br>
RSX don't have phase V either.
<br>
Yes, the year field in DAP is just two digits. But it's not 19xx.
It's actually 1970 - 2069 or some such.
<br>
<br>
</blockquote>
Thanks for the data point. It's not that simple.<br>
<br>
As far as I can tell, DAP was never ECOd to have that kind of Y2K
window. There appear to have been some product hacks that did, but
that was after the end of 36-bit development. We would likely not
have gone along with 1970...<br>
<br>
For the spec, see the DAP 5.6.0, P.49, which simply says <br>
The preceding three fields should be in the
following format: <br>
dd-mon-yybhh:mm:ss where: ... yy is the year <br>
<br>
I haven't seen a later published spec for DAP.<br>
<br>
Mentec's DECnet-RSX release notes for 11m/S 4.8 (1998) does
reference<br>
"Changes to NFT, FTS and FAL that will allow them to function
properly at the turn of the century (year 2000)."<br>
<br>
The VMS 7.2 release notes say this on the subject - NOTE paragraph
3 and the last sentence of the last paragraph:<br>
<p style="color: rgb(0, 0, 0); font-family: 'Times New Roman';
font-size: medium; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: -webkit-left; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);">---<br>
With OpenVMS Version 7.2, both RMS and the File Access Listener
(FAL) have been enhanced to support the 128-bit Coordinated
Universal Time (UTC) format for the exchange of date and time
information about files (such as file creation or file revision).</p>
<p style="color: rgb(0, 0, 0); font-family: 'Times New Roman';
font-size: medium; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: -webkit-left; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);">With this enhancement, RMS
and FAL support two formats for the exchange of file date and time
information:</p>
<ul style="color: rgb(0, 0, 0); font-family: 'Times New Roman';
font-size: medium; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: -webkit-left; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);">
<li>New UTC format. This enhancement takes advantage of the DECnet
Data Access Protocol (DAP) option for transferring times using
the 128-bit UTC format. As of this version, this has been made
the default for OpenVMS systems.</li>
<li>Current 2-digit year format. A 2-digit year is used in the
following 18-byte format in accordance with the DAP
specification: DD-MON-YYHH:MM:SS</li>
</ul>
<p style="color: rgb(0, 0, 0); font-family: 'Times New Roman';
font-size: medium; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: -webkit-left; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);">In previous versions of RMS
and FAL, ***as part of their own implementation (not part of the
DAP specification)***, the 2-digit year field pivoted about the
year 1970. YYs from 70 to 99 map to 1970 through 1999; YYs from 00
to 69 map to 2000 through 2069. Thus, this scheme presents no Year
2000 problem for previous versions in the immediate future.</p>
<p style="color: rgb(0, 0, 0); font-family: 'Times New Roman';
font-size: medium; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: -webkit-left; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);">If the client requesting
the file transfer in the system configuration message has set the
system capability (SYSCAP) indicating "support for binary
date/time format," OpenVMS will use the UTC format by default. And
as of this version, it will be set for any OpenVMS client.</p>
<p style="color: rgb(0, 0, 0); font-family: 'Times New Roman';
font-size: medium; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: -webkit-left; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);">If the UTC capability is
not set by a non OpenVMS client, then the current 2-digit year
scheme will remain in effect. ***Note that the pivot around the
1970 year, implemented in the OpenVMS RMS and FAL code, is not
part of the DAP specification; therefore, it cannot be presumed
that either a pivot or a pivot around the specific year 1970 is
implemented by non OpenVMS clients.***<br>
</p>
---<br>
<br>
As for the "New UTC (128 bit) format": that's probably documented
somewhere. But I haven't found it. Native VMS times are 64-bits.
DTSS uses an opaque 128-bit structure that may be the basis for
this, but a quick search hasn't turned up a revised DAP spec. DTSS
time includes precision/accuracy, not just time. <br>
<br>
The bottom line, as I originally wrote, is that this is a Project to
get right. <br>
<br>
Of course, that the base time for TOPS-10 is 1964, not 1970... so
there are valid TOPS-10 file times that can't be represented in this
way. NFT and FAL include tests for the remote OS, so a per-OS pivot
year is possible on the 36-bit side. Which means qualifying the
change against the matrix of 8/16/32/36-bit OSs. (Which include
non-DEC DECnet; Linux has one, Sun had one, ...)<br>
<br>
That's why Project has a capital P.<br>
<br>
<blockquote cite="mid:557AF4B6.3020200@softjar.se" type="cite">Definitely
true. But good luck even finding someone who know what you are
talking about if you start contacting HP about the PDP-11 stuff.
Since it was sold off to Mentec, but DEC retained some control
rights, it is really confused. And I doubt anyone is left who was
around when it was worked out. And I wouldn't be surprised if even
those people didn't entirely understand what they created.
<br>
<br>
</blockquote>
I have no plans to touch that morass. I believe MENTEC abandoned
the US about 10 years ago; they haven't done anything with PDP-11s
in at least that long. That doesn't mean they've lost the rights
that they had - which were limited. I know that a number of people
tried and failed to work something out. It's a shame that we were
too busy building a company to worry about the future of our
artifacts without us. <br>
<br>
<br>
<br>
</body>
</html>