Search Posts:

Digitial MicroVAX 3100 30 System

SHARE

Return to Threads

  Digitial MicroVAX 3100 30 System by Bill Degnan - 04/10/2015 14:34
MicroVAX 3100 with Storage Expansion
Pictured here is a 1988 (?) Digital MicroVAX 3100 with Storage Expansion boxes. The model number of the 3100 is DV-31BT4-A-A01 which I believe makes it a 3100 model 30. The storage expansion boxes are basically external SCSI hard drives. Their model numbers are DV-31BT4-A-A01(middle) and SZ123-XA (bottom). Click image for larger view.


Show Dev command VAX output
So far I have not done much other than boot the system from the console and run a SHOW DEV command to see what the VMS/VMB assignments are. The system is running VMS 5.2.


More photos

Reply
  VAX VMS 5.2 by Bill Degnan - 05/15/2015 18:33
Accessed the SYSTEM user, reset the password and poked around the system. Both hard drives returned present, I was able to change directories, etc. Overall system seems to be OK.

Reply
  Multinet Config by Bill Degnan - 02/22/2016 10:50
Configured the Ethernet parameters to match a newly-assigned IP for this machine. microvax3100.vintagecomputer.net is the FQDN for this machine, contact me if you would like to connect to this box for research purposes. I can now access the box remotely which is nice for convenience.

Note - There is a switch on the back left of the unit that allow a person to toggle between the 15-pin AUI and BNC (round/old style) Ethernet connectors. I have a AUI cable, so I have that style selected.

NEXT - get email working correctly, currently when I attempt to send a message I get the error "MAIL-E-USERSPEC, invalid user specification '@GMAIL.COM' which means that I have to read the manual and clean up the old configuraton to now use my Comcast Business class network. Stay tuned.

Reply
  multinet 4.2 and SMTP by Bill Degnan - 02/22/2016 13:39
$ multinet show/version

Process Software MultiNet V4.1 Rev A, MicroVAX 3100, VAX/VMS V5.5-2

MAIL> MAIL
To: SMTP%"bill@myemail.net"
Subj: This is a test
Enter your message, etc.

... this works and I can get messages.
* * *

Note I have to format the email differently than when I send messages from my VAX 4000-200. When I reply to email above, I get a postmaster error.

Bad address --
Error --
%MAIL-E-USERSPEC, invalid user specification ':'

let's see... Can I configure the machine to send a receive emails without old-fashioned VMS formatting.
Also, can the system receive replies from a modern Internet address and have it not get rejected by the POSTMASTER?

(for example:)
Bad address --
Error --
%MAIL-E-USERSPEC, invalid user specification ':'

I posted a question CCTECH to see what they have to say, and I will keep looking into this.

Reply
  cctech feedback by Bill Degnan - 02/23/2016 10:12
I posted some questions to CCTECH to see if anyone there knew about the older versions of Multinet and VMS I am running, as they relate to SMTP mail. Here is what I learned

"I think being able to that (without the trailing doublequote) came in with
VMS MAIL in V7.something.

If you install PMDF (which also has a hobbyist licence), you get the PMDF MAIL
client which can do this and can also do MIME attachments and is generally a
lot more capable than VMS MAIL.

* * *
Multinet is an excellent TCP/IP stack but the SMTP server included with it
is a bit limited and V4.1 is old. If you allow it to accept SMTP mail directly
from the internet, it may be difficult or impossible to secure it against
exploitation as a spam relay which would cause lots of problems for others
as well as yourself.

Having said that, it should be possible to feed mail to it from a more capable
internet facing SMTP mail server or set it up to send/receive SMTP mail on your
internal network only.

To do this, you don't need the DECnet to SMTP mail gateway you mentioned. If
this was configured on your machine, it may have been used to allow the machine
running Multinet SMTP to accept mail from the internet and pass it on to other
DECnet connected machines which did not run SMTP. ...

"

Reply
  SYSTEM logical by Bill Degnan - 02/24/2016 12:32
Peter Coghlan from CCTECH and I think Ireland logged into my system and found the solution to the email problem, he writes:

"I found the problem.

You can do all sorts of nifty stuff with logical names on VMS.

Somebody (presumably at the municipality) had set up a logical name for
SYSTEM. As far as VMS MAIL is concerned, this is like setting up a forward
for SYSTEM to another user, except the logical name definition did not
correspond to a valid username. Whoever did this likely intended to create a
short way of referring to files in a particular directory and not trying to
do anything with MAIL.

To temporarily get rid of the logical name I did:

$ DEASSIGN /SYSTEM /EXEC SYSTEM

Then I managed to successfully send a local test message, then another from
here over the internet.
"

I need to learn more about logical names then! Did not know that you could do that.

Reply
  Oops! Formatted Drive!!! by Bill Degnan - 03/01/2016 21:59
I *thought* DKA700 was a backup drive with nothing on it. I had this bright idea to back up the boot partition, DKB500 to DKA700 so if one drive died the other would be available. Big mistake. This is the drive with the MULTINET programs. Now I have to find a way to get them back on from another machine. Given that VCF XI is coming up in two months, I will have to get back to this problem in a few months. Stupid mistake!

Reply
  Building Connections by Bill Degnan - 03/12/2016 12:32
Summary of advice I got from Peter Coghlan to questions I asked about connecting one VAX to another to attempt to copy files using the external hard drive of the 3100 while attached to the VAX 4000:

I think you said that the machine was previously owned by a local municipality?
They probably had a backup strategy that involved backing up the disks to
tape. Did you get a tape drive with the machine? Were there any tapes with it?

It's not impossible that the backup strategy involved backing up to disk but
I think it is unlikely, particularly for relatively static data like the
MULTINET files.

If there are on disk backups, the strategy for creating these would have been
devised by the machine owner. Unless you have documentation from them, it
would be necessary to guess what the files containing the backups are called.
Savesets created by BACKUP are sometimes given .SAV or .BCK file extensions but
this is just a convention and they could be called anything.

$ DIRECTORY DKA0:[*...].SAV,.BCK /SIZE=ALL /DATE=(CREATE,MODIFIED)

will list all files with extensions .SAV or .BCK on the DKA0 disk for example
and give their sizes and creation and modification dates.

Rather than having to install it, I'm hoping that DECnet is already installed
and configured on the 3100 and on your 4000. Can you try:

$ SHOW LICENSE DVNET*
$ SHOW NETWORK
$ SET HOST 0

on each and see what happens?

If you also have DECnet and MULTINET running on your VAX 4000, maybe I could
telnet to the that machine and then log in to the 3100 via DECnet?

With VMS, before you can use a disk or tape, it must be mounted. The system
disk is mounted automatically at boot time but other disks must have a MOUNT
command issued for them. This is usually done in the startup file. If you
moved a disk from the 3100 to the 4000, the 4000 won't have a MOUNT command for
it in its startup file and

$ SHOW DEVICE D

will show it up as "Online" instead of "Mounted". Before you can access it on
the 4000, you would need something like:

$ MOUNT /NOASSIST /SYSTEM DKA100 label

where label is the disk volume label. If you don't know what the label is, try
any random label. VMS will tell you what the actual label is in an error
message and you can repeat the command with the correct label.

Bear in mind that depending on which disk controller on the 4000 you attach the
disk that was DKA700 on the 3100, it may show up as DKB700, DKC700 etc on the
4000. (The 700 is the SCSI id multiplied by 100 and DK indicates a SCSI disk
so those parts of the device name should remain the same).


I successfully booted up the 4000 and mounted one of the two external drives to a SCSI port of the 4000-200.



Reply
  Installting MULTINET by Bill Degnan - 03/13/2016 08:42
Turns out that MULTINET install files were already on one of the external drives.

I attached the drive to my VAX 4000-200 and Peter Coghlan connected via telnet to inspect it. He was planning on uploading a copy of the MULTINET install files from one of his systems to this drive. I could then re-attach to the 3100 and run the install program from there. In the process of inspecting the drive he found that the install files were already on the drive. What luck. Here is a capture of his log session:

SESSION LOG

In particular:

$ dir cobuck$dkb200:[000000]

[this command used to display the multinet install files]

-----------
INSTALLING MULTINET
-----------

(re-)Install the MULTINET service to the MicroVAX3100 (microvax3100.vintagecomputer.net on 10.1.10.31)

First I initalized DKA700 and changed the label to its original USER3:

// example: $ INITIALISE /SYSTEM device label

// for my system:
$ INITIALISE /SYSTEM DKA700 USER3

next I mounted the drive:

$ MOUNT /NOASSIST /SYSTEM DKA700 USER3

// The MULTINET installation file instructions can be reviewed by using the
// EDIT command; or, TYPE /PAGE to view them or
// PRINT if you have a printer set up.

Next I checked the external drive installation directions using EDIT:

$ edit cobuck$DkB200:[000000]MULTINET_INSTALLATION.TXT

-----------

INSTALL NOTES and COMMENTS BASED ON
FACT THAT I ALREADY HAD MULTINET INSTALLED BEFORE

-----------

Email exchange between myself and Peter Coghlan:
Because this MULTINET version has already been installed on this particular
3100, you should be able to safely skip many tedious parts about checking
system parameters and checking account quotas. Whoever installed this the
first time has already done this and the results of their work should hopefully
still be on the VMS system disk.


The actual install command for my case:
$ @SYS$UPDATE:VMSINSTAL MULTINET041 cobuck$DkB200:[000000]


"...[and then] telling it where the installation save sets are located, telling it where to
install MULTINET and then answering some questions about what ip address,
default gateway, network mask and so on to use.

VMSINSTAL might try to default to installing MULTINET on the VMS system disk.
Don't let it do that as there might not be enough space there - I can't recall.
It is probably best not to try to second guess whoever originally decided to
install it on a different disk - they probably had their reasons.


>
> I will wait to hear from you if you have any advice about running the
> install script once I return the drive to the 3100, otherwise I will
> carefully work through it and try to re-match up what the startup_v5 was
> trying to do.
>

"..There is probably very little referencing MULTINET in the startup procedures...: ..

For the record, the start command is:
@DISK$USER3:[MULTINET.COBUCK.MULTINET]START_MULTINET.COM

Basically I installed MULTINET to the same places referenced by the statup script.

---------
INSTALL COMPLETE
---------

cleanup:

See: SYS$SYSTEM:MODPARAMS.DAT

I could not start MULTINET right away. The boot script claimed the server MODPARAMS.DAT's INTSTKPAGES value was 4 but it needed to be = 10. I saw it was already correct by checking MODPARAMS.DAT by using EDIT:

$EDIT SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT

(My guess is that when multinet was installed, VMS reverted the INTSTKPAGES value to 4, for some reason.)

To apply the correct value of INTSTKPAGES I ran autogen manually, as follows;

$ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT NOFEEDBACK

---- OK -----

At this point everything is working the way I want it to.

---- OK -----

NOTE: The install instructions include directions for installing the product license. I skipped this step.

$ @MULTINET:PAK-DELETE
$ @SYS$UPDATE:VMSLICENSE

----------------
TESTING
----------------


testing (from the online manual) -
ftp.multinet.process.com - still up?

$ MULTINET FTP /USERNAME=ANONYMOUS/PASSWORD="emailaddress" FTP.MULTINET.PROCESS.COM

> CD [CUSTOMER_SUPPORT.SOFTWARE_UPDATES_VMS.Vn

> get update_filename

It turns out that one can still access this FTP site. I was unable to get past the login phase but I only saw a welcome file, I could cd into CUSTOMER_SUPPORT but not SOFTWARE_UPDATES_VMSxyz. There was a vanilla SOFTWARE_UPDATES_VMS.DIR;1 but I could not get access to it. Not sure why.

I was able to email and telnet to other places. Inbound emails work.

Next...Setting up services and networking the Microvax to the Vax 4000 using DECNET.

I ordered a pair of CentreCOM 210T Twisted Pair Transceivers on Ebay.

Reply
  DECnet by Bill Degnan - 03/14/2016 17:09
Peter Coghlan writes:

Hi Bill,

I had a quick look around. I found that DECnet is up and running on that
machine so that should be half the battle in getting a DECnet connection to
your 4000. See log below. I just did a cut and paste of the terminal this time
as that seems to work out better than getting telnet to log stuff and include
all sorts of control codes.

COBUCK is set up as DECnet address 1.1 (area 1, node 1). Everyone seems to do
this and there are way too many machines with that DECnet address around the
world :-)

Another node - RALPH is defined as area 1 node 2. You could add another
definition for your 4000 if you want to be able to address it by name,
something like:


$ MCR NCP
NCP> DEFINE NODE 1.3 NAME VX4000
NCP> SET NODE 1.3 ALL
NCP> EXIT

...assuming that you are going to give it DECnet address 1.3 and call it VX4000
(I can't remember name you already have for it.)

To configure DECnet on the 4000, you would need to use something like:


@SYS$MANAGER:NETCONFIG

Do this on the 4000 and answer the questions. This assumes phase IV DECnet is
installed. If phase V DECnet is installed, I would suggest ignoring it and
installing phase IV DECnet - it is much simpler all around.

To start phase IV DECnet on the 4000:


$ @SYS$STARTUP:STARTNET

You can add that line to the startup file once you have tested it.

There is no need to do any of this on the 3100 - DECnet is already configured
and started automatically there.

Regards,
Peter.


--------------
PETER'S LOG FILE:
--------------

$ telnet microvax3100.vintagecomputer.net
Trying... Connected.




Username: SYSTEM
Password:
Welcome to VAX/VMS version V5.5-2 on node COBUCK
Last interactive login on Sunday, 13-MAR-2016 22:53
Last non-interactive login on Sunday, 13-MAR-2016 20:39


$ show network
VAX/VMS Network status for local node 1.1 COBUCK on 13-MAR-2016 23:35:39.03

This is a nonrouting node, and does not have any network information.
The designated router for COBUCK is node 0 COBUCK.

$ set host cobuck


Username: SYSTEM
Password:
Welcome to VAX/VMS version V5.5-2 on node COBUCK
Last interactive login on Sunday, 13-MAR-2016 23:33
Last non-interactive login on Sunday, 13-MAR-2016 20:39


$ sh users /full
VAX/VMS User Processes at 13-MAR-2016 23:36:32.17
Total number of users = 1, number of processes = 6

Username Process Name PID Terminal
SYSTEM NTY2*SYSTEM 0000011A NTY2: ([10.1.10.52])
SYSTEM NTY33*SYSTEM 0000013A NTY33: ([10.1.10.223])
SYSTEM NTY36*SYSTEM 0000013D NTY36: (mailout.beyondthepale.ie)
SYSTEM OPA0:SYSTEM 00000115 OPA0:
SYSTEM RTA1*SYSTEM 0000013F RTA1: (COBUCK::SYSTEM)
SYSTEM Time Stamp 0000010B (batch)

$ mcr ncp
NCP>show known nodes


Known Node Volatile Summary as of 13-MAR-2016 23:36:58

Executor node = 1.1 (COBUCK)

State = on
Identification = DECnet-VAX V5.5-2, VMS V5.5-2
Active links = 2


Node State Active Delay Circuit Next node
Links

1.2 (RALPH) SVA-0 0
$ logout
SYSTEM logged out at 13-MAR-2016 23:38:08.98
%REM-S-END, control returned to node _COBUCK::
$ logout
SYSTEM logged out at 13-MAR-2016 23:38:13.10

Connection closed by Foreign Host
$

Reply
  creating users by Bill Degnan - 03/21/2016 17:20
Here are the unique values for this server, your server will be different. The user directory is

CREATE/DIRECTORY COBK$DATA:[COBK.PERSONAL.USERNAME] /OWNER=[USERNAME]

these are group 100 privileges, which is what existing users are set:
defprivilege=TMPMBX, OPER, NETMBX
privilege = TMPMBX, OPER, NETMBX


I created a user HJOHNSON as follows:

$ set process/privileges=all
$ set default sys$system:
$ run authorize
UAF> show [100,*] /brief
UAF> add USERNAMEHERE /uic=[100,30] /account=COBK
UAF> modify /password=password
UAF> modify USERNAMEHERE /device=COBK$DATA:
UAF> modify USERNAMEHERE /directory=[COBK.PERSONAL.USERNAMEHERE]
UAF> modify USERNAMEHERE /owner="First Lastname"
UAF> modify USERNAMEHERE /nopwdexpir /flag=nodisuser
UAF> modify USERNAMEHERE /defprivileges=(TMPMBX, OPER, NETMBX) /privileges=(TMPMBX, OPER, NETMBX)
UAF> modify USERNAMEHERE /flags=nodisuser
UAF> exit
$ create /directory /owner=[100,30] COBK$DATA:[COBK.PERSONAL.USERNAMEHERE] /OWNER=[USERNAMEHERE]

when I attempt to log in, the username and password are accepted, but shortly afterwards the system logs the user off

"%Sorry, your default device is unavailable for login, Try again later...

Thinking that maybe I set something up incorrectly I reset the password of a user already installed in the system. I got the same "Sorry.." message.

This tells me that probably the user I created is OK, but something else is not set up correctly system-wide.

I triple checked "sam" vs. "hjohnson" I found no differences other than the directory.

Hmmmm...

Digressing a bit. When I first installed MULTINET, I skipped the step of deleting and installing a new PAK, as described by the MULTINET installation instructions. I was correct in guessing that there was no need to install the license if all I did was delete the program files. I did not know this for sure at the time however and at this point could find no user system reason for the issues.

I then incorrectly concluded that the user login problem must be related to an invalid MULTINET license. I was also incorrect in guessing that I could easily re-install the PAK by using the info I collected.

I took some screenshots of the LICENSE data thinking after I delete the license I can just re-add the same info again:

Here is what I got:

Active licenses on node COBUCK:

------- Product ID -------- ---- Rating ----- -- Version --
Product Producer Units Avail Activ Version Date Expires
MULTINET TGV 200 F 0 0.0 31-JUL-1997 (none)


...to me that looks like a license, but at this point was not sure what Activ = 0 meant, etc. I saw the other licenses have this value too, for example BASIC..It proved useful to have saved these values, assuming this was all I needed to re-install the license. Unfortunatley I did not realize that a very important piece was missing. The license install program needs a/the checksum of/for the PAK itself, not just the PAK keys and codes.

Running the following command is a BAD decision if you do not have the PAK for a piece of VMS software (unless you're ready for a project):

$ @MULTINET:PAK-DELETE

And like that I deleted the MULTINET PAK. When I tried to re-add it I did not know the checksum! With no way to complete the license install I abandoned the program. Seemed like everything was still ok for now but I did not realize I had hosed my MULTINET for the next time I rebooted....uh oh!

But thinking everything was OK because the license was still in RAM memory and I had MULTINET working....I moved on to try something else.

I decided to trace through sys$manager:systartup_v5.com to look at what gets loaded when the system boots up. Maybe there was an instruction, set to block all users except SYSTEM from logging in. I asked around and others independently suggested the same thing.

I found a line at the end of the file that I believe disabled logins, so I changed it from 0 to 5 users permitted to log in at a time....

I rebooted to test the startup_v5.com update...BUT ka boom!

I never really got to test my changes as I was quickly distracted by a larger problem - Rebooting removed the PAK from RAM, and without the PAK in the license.ldb file, it was unavailable to load into RAM again. I hosed multinet!

I undid the startup_v5 changes and sulked..


Reply
  A new MULTINET license PAK by Bill Degnan - 03/25/2016 00:35
To get a new MULTINET license PAK it was suggested I try getting a VMS hobbyists license PAK first. I would then be able to get a free MULTINET license PAK by supplying the checksum from the vms license

1st steps here:
http://www.openvmshobbyi...rum_id=10&thread_id=230

Step 2:
http://www.multinet.process.com/register.html

I was unable to get the license forms to work. But it was a half-hearted attempt because I did not like the idea of trading a corporate OpenVMS license for a hobbyist license (that expires) just to get MULTINET running.

I decided to look for a backdoor that would lead to a MULTINET PAK directly.

Reply
  lmfgen by Bill Degnan - 03/31/2016 09:38
First of all, you can't just "get a checksum" from somewhere else and use it on your system too unless it's an exact clone system. Even if the VMSLICENSE program accepts the values entered (from someone else's PAK), the license validation process will reject the PAK if the matching checksum that VMSLICENSE generates does not match your PAK.

My machine already has a corporate VAX license, and I already had the software installed. I did not want to "downgrade" to an OpenVMS license just to get MULTINET working. I also did not want to reformat or reinstall the OS because I have the servers original files still to be explored. That this VAX houses the City of Buckannon, VA archives for things like parking tickets, etc.

Fortunately I learned of the tool LMFGEN. It was easy to get set up. I generated a few trial and error PAK's based on my particular Multinet 4.1 version and using data I collected from the system. It did not take long to generate a PAK that worked.

Here are some screenshots I collected, plus paper notes ( not shown) that gave me clues as to required fields, what I could leave blank, and the format of the data.

show license
dir license.LDB
vmslicense
LICENSE.LDB DUMP

Here is it, the magic LMFGEN command, using the data I found:

lmfgen /product=multinet /producer=tgv /issuer=tgv /authorization=a-10-098-116512 /version=0.0 /units=200 /availability=F activity=0 /token=AA-10098-116512

From the Windows 10 CMD window, here is the output:

$!
$! Generated by LiBREVMS LMFGEN v1.2 at 31-MAR-2016 17:17:03.00
$!
$! Dedicated to the memory of Big Ken, the Digital Equipment Corporation,
$! and to all the digits who designed, developed, and documented the most
$! perfect operating system on the planet: OpenVMS.
$!
$! Live, learn, enjoy and share and make our world a better place to live.
$!
$ LICENSE REGISTER MULTINET -
/ISSUER=TGV -
/AUTHORIZATION=A-10-098-116512 -
/PRODUCER=TGV -
/VERSION=4.1 -
/UNITS=200 -
/AVAILABILITY=F -
/ACTIVITY=CONSTANT=0 -
/TOKEN=AA-10098-116512 -
/CHECKSUM=2-MDAH-IDIH-OCBG-GKMA
$ LICENSE LOAD MULTINET

I printed this from my Windows 10 PC and entered these values into the License manager on the VAX at the $ prompt.

$ @sys$update:vmslicense

NOTE: If you screw up and the system does not take your data/checksum, try again with a new PAK. It took me a couple of days to figure it out.

Back in Business!

Won't do that again, sheesh!

Now I can return to addressing the problem where only SYSTEM can log in, I need to open up to more users.

Reply
  Clearing SMTP Queue by Bill Degnan - 04/11/2016 14:39