On 2015-06-13 12:46, Timothe Litt wrote:
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...
Well, the product "hacks" were done by DEC. Yes, it was after 36-bit
development had stopped. You could possibly hit problems with files from
old PDP-6 Monitor systems, or rather early versions of Tops-10. But
either DEC ignored this, or else they decided that this was not a
realistic problem. I wouldn't know.
Either way, other systems decided to define the two year field as
representing 1970 to 2069. Deal with it, or decide to be incompatible.
I don't even know if Tops-10 supports DAP, or if it's TOPS-20 only. The
RSX documentation only talks about issues and details related to
communication with TOPS-20. Tops-10 is never mentioned.
And TOPS-20 is all newer than 1970 anyway.
I don't remember ever seeing DECnet on a Tops-10 system, but then again,
the last time I seriously used Tops-10 was in the mid 80s.
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.
I have been searching without success as well, as there are a lot of
data in DAP that is not in that spec. I've been especially interested in
additional OS and filesystem codes.
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.
The binary date format would be nice, but RSX don't support it either. I
guess I could implement that if I found a spec for it, and it wouldn't
involve changing just about everything in DAP around. Might be Phase V
only...?
Seems like RSX and VMS agrees on the "old" format. And yes, it is a
potential problem with Tops-10 systems.
Now, developing a new format is all fine. But if you want any kind of
interoperability, you have to bring all other systems aboard as well.
Or else you define something that is dynamically detected and handled
only between your systems, and keep the old behavior for all other
systems. And in the latter case, why not implement the "extension" that
pretty much all other systems already have done for communication with
those systems?
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.
It is more complicated. Mentec Inc. folded about 8 years ago, or so. The
PDP-11 software was bought from the carcass, and is now owned by XX2247
LLC. However, they also inherited the agreement between Mentec and DEC.
Now, of course, DEC merger with Compaq, which then merged with HP, so at
that end, it would be extremely hard to find information about the
agreement.
Mentec Inc. declared bankrupcy, and any papers from there would also be
extremely hard to find, and XX2247 do not have any copies. They only
have papers saying that they still need to adhere to the conditions that
they don't even have copies of.
(Or that is my understanding of the situation anyway.)
So the PDP-11 software is still very much owned by an entity, but
exactly what can be done with it is unknown. So it remains in limbo.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
