[Simh] OS development

[Johnny Billquist]

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: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol