[Simh] OS development

[Timothe Litt]

On 12-Jun-15 11:03, Johnny Billquist wrote:
>
> RSX don't have phase V either.
> Yes, the year field in DAP is just two digits. But it's not 19xx. It's
> actually 1970 - 2069 or some such.
>
Thanks for the data point.  It's not that simple.

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...

For the spec, see the DAP 5.6.0, P.49, which simply says
The preceding three fields should be in the following format:
   dd-mon-yybhh:mm:ss where: ... yy is the year

I haven't seen a later published spec for DAP.

Mentec's DECnet-RSX release notes for 11m/S 4.8 (1998) does reference
"Changes to NFT, FTS and FAL that will allow them to function properly
at the turn of the century (year 2000)."

The VMS 7.2 release notes say this on the subject - NOTE paragraph 3 
and the last sentence of the last paragraph:

---
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).

With this enhancement, RMS and FAL support two formats for the exchange
of file date and time information:

  * 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.
  * 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

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.

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.

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.***

---

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.

The bottom line, as I originally wrote, is that this is a Project to get
right. 

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, ...)

That's why Project has a capital P.

> 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.
>
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. 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150613/c0b2f511/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150613/c0b2f511/attachment-0001.bin>