John Dundas' distribution of VAX/VMS version 3.0 (April 1982) can now be
downloaded from my Dropbox.
The SYSTEM password is MANAGER.
Note: Dropbox does not force you to create an account, if you look
carefully you will see a "Continue to view" link at the bottom of that
pop-up.
Here's what it boots into:
? VAX/VMS Version V3.0 26-APR-1982 16:21
PLEASE ENTER DATE AND TIME (DD-MMM-YYYY? HH:MM) 21-MAR-2020 11:58
%JBC-I-NEWQUEUE, new queue file created
%OPCOM, 21-MAR-2020 11:58:34.51, logfile initialized by operator OPA0
??????? logfile is SYS$MANAGER:OPERATOR.LOG
? Login quotas - Interactive limit=64, Current interactive value=0
? SYSTEM?????? job terminated at 21-MAR-2020 11:58:39.91
Username: SYSTEM
Password:
??????? Welcome to VAX/VMS version V3.0
$
$
Grab it from https://bit.ly/vaxvms30
Regards,
Supratim
--
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet
Speaking about compilers...
TOPS-10 (and TOPS-20) TSU patches were distributed in encrypted form, the
idea being that only people having keys that were delivered with original
product tapes could decrypt them. In fact TSU tapes contain almost complete
versions of most licensed Digital products.
Unfortunately, the tape image of the Fortran-10 V11 product tape available
on both Trailing Edge and Bitsavers is truncated and lacks the saveset with
the keys. It should be the 7th saveset, but the image ends after the 4th.
Does anyone here have some idea about how to overcome this problem? Or, even
better, does anyone know if there could be another copy of the same tape
available somewhere? I've found that the Computer History Museum has a copy
(https://www.computerhistory.org/collections/catalog/102773759) and I wonder
if it's the one from which the truncated image was sourced.
The tape identifier is BB-D480G-SB.
Alternatively I think it might be possible to build the TOPS-10 FORTRAN V11
compiler with the patched sources of the TOPS-20 compiler, in fact they
should share almost everything except maybe OS interfaces like SCAN, WILD,
COMND, and so on...
Thoughts? :)
G.
I just received an email from the HPE program. I guess they are going to
have long term PAKs they are selling to hobbyists. So I guess I am out.
There is someone named Jon you can get these from. I believe Jon Feldman.
Bill
I remember using a C compiler under TOPS-10, but that was far away and
very long ago. Can anybody tell me if my memory is bad, or did that really
exist? Was it a DEC product or a DECUS thing?
Thanks
Bob
No, I'm not complaining about intermittent connectivity with PyDECnet; I'm asking if it's possible!
I don't have persistent Internet connectivity or a fixed IP address at my just-barely-rural home. When my home network is connected to the Internet, it's tethered over my cell phone. And even then, my cell service is spotty. I could possibly resume using a separate hotspot at home rather than my regular cell phone, but even when I was doing that, my connectivity wasn't great. Cell service in my neighborhood isn't very good via either AT&T or Verizon, and wired connectivity is not available.
Would any of the DECnet routing mechanisms supported by PyDECnet possibly be suitable for intermittent connection of my home network, with a small number of DECnet nodes, to HECnet? Or am I just going to have to remain a HECnet spectator until I manage to obtain better Internet connectivity?
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
I thought that I had sent a message to the list a few months ago showing the procedure to use the software DDCMP driver in RSTS V10.1. That's a standard feature, but undocumented and probably unsupported. It works well and interoperates with PyDECnet and with the DDCMP implementation in SIMH. Presumably it will talk to the software DDCMP in RSX, though I have not tried that.
Attached are the instructions and the program mentioned.
paul
Hi all,
Just received the e-mail below. I've hunted around all the various
Hobbyist locations and licensing pages and can't find any additional
information.
I've already replied back to ask what the impact of Hobbyist renewal
licensing will be. I have no further information at this stage.
Have others received this as well? Does anyone have any further
knowledge on this?
I can see a few people have forwarded/posted the same message on
comp.os.vms.
Cheers, Wiz!!
From: OpenVMS Customer Lab [mailto:openvmscustomerlab at hpe.com]
Sent: Saturday, 7 March 2020 3:13 PM
Cc: OpenVMS Customer Lab
Subject: OpenVMS Hobbyist Notification
Dear HPE OpenVMS hobbyist,
This is to inform you that HPE is concluding the HPE OpenVMS Hobbyist
license program in alignment with the HPE OpenVMS support roadmap.
If you wish to understand more details, please reach out to us at the
earliest through the usual license renewal webpage.
Thank you.
HPE OpenVMS team
The recent post about multi-threaded NNTP for VMS (whaaay cool) jogged
my memory about something I had been wondering about.? This morning, a
large number of clocks got switched ahead an hour in the United States.?
Tops-20 did it 'relatively flawlessly' as it has done so since the early
1980's.? Back then, a lot of systems didn't.? None of our IBM systems did.
A lot of that has changed nowadays with NTP clients; even if the base
operating system doesn't support time change, an NTP client can address
that.? So all my systems advanced appropriately, as did an old radio
clock.? I'm not sure how *nix does it, but I don't remember Ultrix
having the code on our 8650 (or 8700). Tops-20 will do the change
whether or not a client exists as the code is in the monitor.
At the time (1980's), I don't believe that VMS had internal code to do
the time change and NTP did not exist as such (some network time
services existed, but I don't remember whether there was a generally
available VMS TCP/IP package; we didn't have it).? I would assume that
this is handled now.? I hesitate to ask about RSX and RSTS, but I would
assume that the C compiler for RSX (with Johnny's TCP/IP interface)
could support an NTP port.? Anyway, the question is: how does VMS handle
the time change?
By 'relatively flawlessly', I mean Galaxy.? If you submit jobs with an
/AFTER: switch, but use an elapsed time, you can get the wrong start
time.? For example, in a daily batch job to do incremental saves,
TODAY+2:00:00 means tomorrow morning at 2:00:00 AM, assuming the current
job was started at 2:00:00.? However today, the job? started at 3:00:00
AM.? No big deal.
However, this used to seriously mess up our operations, who started
shift expecting requests for tape mounts. ? I looked at the issue awhile
back in the 80's, but realized that the problem wasn't in Quasar because
it is only dealing with internal date format.? The issue had to be fixed
by putting some logic into the Exec to differentiate between a specified
time and a calculated time.? As it wasn't immediately straightforward, I
never got to it.? Maybe one of these days...
