Author: Graham

• DEC MicroVAX I
• MicroVAX I Disassembly
• MicroVAX I Emulation
• MicroVAX I Startup
• MicroVAX I Archiving Floppy Disks
• MicroVAX I Floppy Drive
• MicroVAX I Disk Images
• MicroVAX I Gotek/Flashfloppy
• MicroVAX I Hard Disk Backup
• MicroVAX I VMS Stuff
• MicroVAX I Software
• MicroVAX I VAX C Installation
• MicroVAX I Kermit Installation
• MicroVAX I A Rosetta VAX
• MicroVAX I Creating a New Image
• MicroVAX I Transfer of New Image

The subject of this site is microcomputers and although this unit has micro in the title it is actually a minicomputer. Why get hung up on consistency?

It belonged to a gentleman (Andrew C) who developed security software for the VMS operating system. I thought at first that this machine may have been a nostalgic purchase, but i am now convinced that this machine was used for development of software.

Curiously, it came with a bunch of tapes and a few high density 5.25″ disks none of which can be read by this machine.

The MicroVAX I was released in 1984 and was quickly superseded by the MicroVAX II which is a more common and more useable model.

The MicroVAX series was a more compact and less capable derivative of the VAX computers that i used as a student at Adelaide Uni in the early eighties, speaking of nostalgia.

The MicroVAX I uses a Q-bus backplane which was also used in some DEC PDP computers. The CPU consists of two Q-bus cards. The MicroVAX I typically shipped with 1MB memory. This one has a dual floppy disk drive and a 30MB hard disk and would therefore have a floppy/hard disk controller.

With the only wired I/O being a serial line for a console terminal this unit is truly standalone. Additional Q-bus cards can be added for many other functions but i imagine they won’t be easy to find.

There are RIFA line filter capacitors inside, so there was work to be done before power could be applied.

I last used a VAX when i was a uni student in the early eighties. We used the vax to learn a little Fortran and a lot of Pascal. We also used it to run spice and graphical silicon design tools.

I kept a few souvenirs. This is a printout of a pascal program i wrote on a VAX in 1985.

My hope for this machine was that i might be able to get it to run a couple of compilers as a demonstration of what it could do.

This machine relies on a whole bunch of parts that i would struggle to repair or replace, so a huge investment in upgrades would be a significant risk.

The VAX/VMS ecosystem is not for the feint-hearted. VMS is both complicated and unlike more common system, the systems are often customised, the available documentation is incomplete, and the binary you want is never on the media that your machine can read. It turned out to be quite an adventure.

As usual, i have relied upon the good work of many other people who have taken the time to scan manuals, archive media, create emulators and other tools, and to post their experiences. I’ve tried to capture all those items in my posts although often the often anonymous individuals involved do not get the credit they deserve.

With two screws removed from the rear of the case the computer can be removed from its skin. The skin itself is very heavy and once gone the computer can be easily lifted on to a bench by two people.

The front panel comes off with the removal of several screws. The drives are on skids and can be released by pressing on the handles at the bottom of the case.

Two screws retain the back panel. Two ground leads need to be disconnected for the panel to be free and the rack to be revealed.

I pulled each of the cards for a photo and to confirm the ID. The ejection handles are solid and require a fair bit of effort to operate. They have to be positioned precisely when the cards are inserted into the rack. The levers pull the cards home.

The machine has:

• A KA610/KD32 CPU consisting of two cards M7135 Data Path Module and M7136 Memory Controller.
• Memory modules including 1x M7551 MSV11-QA 1MB Memory Module and 2x M8067 MSV11-PL
• M8639 RQDX1 Disk Controller – not sure of version. Could also be RQDX2.

The only external I/O is the console serial port, so this is very much a standalone system. If it shows promise then i could acquire some additional cards.

A few screws and some cable disconnections and the power supply is out. There are 4 RIFA line filtering capacitors and they were cracked as expected. There were no obvious issues with any other components.

In the hope of getting some practice on the machine while i wait for parts i thought that i could try out the simh emulator.

I downloaded the windows version from here:

https://github.com/simh/Development-Binaries/blob/master/simh-2024-07-05_06-07-03-Windows-Win32-4.0-Current-670a3728.zip

https://github.com/simh/open-simh/blob/master/SIMH-V4-status.md

I created a windows folder with the MicroVAX1.exe file as a starting point.

There’s a nice guide to installing MicroVMS 4.0 here:

https://gunkies.org/wiki/Installing_and_Configuring_MicroVMS_V4.0_on_a_MicroVAX_I#Start_the_SIMH_MicroVAX_I_Simulator

I added the disk images and the ini file from the above link. Joy was had.

Attempts to use alternative disk and tape drives are somewhat frustrated by the limitations of the Microvax I, specifically the RQDX1 controller. There is no tape drive controller included in the Microvax I simh model. It may be possible to add one, but that is beyond my capabilities at present.

After replacing the line filter capacitors in the power supply i fired the supply up with a small load and checked the voltages. They seemed fine so i connected it up to the fans and some ide drives (just for supply checks) and that also looked good. A 3A dummy load was still required for the power supply to start.

Then i connected the backplane, and hooked up a terminal with VT100 emulation. The serial connection needs a null modem. On power up i was pleasantly surprised to see the unit sign on and the initial diagnostics passed – except that it gave an error 6 because there was no boot device.

I crossed my fingers and hooked up the hard disk and it booted up. Awesome.

It was nice to see some humour from the previous owner in the startup message. The machine seems to be called ANJIN which i think relates to the company owned by the original owner.

There was a problem though – i did not have any passwords.

It is possible to reset the system password using a rather convoluted and only loosely documented procedure. There are several different versions of VAX machines and operating systems, and naturally commands evolved, so there was no obvious recipe. I had to experiment a little.

The first step is to enter a command boot mode. I found this worked:

• Power on
• Hit the halt button and then release. This gives the >>> ROM prompt.
• Start the command boot mode with >>> B/1 0 (note the space)
• A new prompt comes up SYSBOOT>

Parameters can be changed using the SET command. I have found limited information on these parameters. Initially i tried:

SYSBOOT> SET STARTUP_P1 "MIN"

SYSBOOT> CONTINUE

These settings are not cleared with a boot or power cycle. They have to be explicitly cleared from the SYSBOOT prompt or using the VMS SYSMAN program (see below).

This setting did have the effect of stopping startup scripts but i still could not log on.

With persistent googles i found a procedure that mentioned that an alternate user authorisation file (UAF) could be loaded.

The process is described in some detail in Sections 5.6 to 5.8 of “The OpenVMS Frequently Asked Questions(FAQ)”.

The default alternate UAF allows logon without a system password. The parameter is set as follows:

SYSBOOT> SET UAFALTERNATE 1

SYSBOOT> CONTINUE

After that i could log in with the system account and no password but i could not do a lot of things. I kept getting issues with library functions not being shared. The program that sets these attributes is called INSTALL. While reading about INSTALL i found that share status is reset on every boot so it is necessary to reshare them at startup eg with a script. This all relates to making sure that only validated code is executed by privileged programs. All this stuff is above my pay grade!

Eventually the penny dropped that the startup scripts that i’d disabled really need to be re-enabled because they are setting the necessary attributes. I retraced my steps and cleared the STARTUP_P1 parameter. That was much better.

I could have blown away the original UAF, but that could have had some unexpected consequences so i wanted to change the original. The program to change passwords is AUTHORIZE, but it really wanted to work on the alternate UAF.

More google and i found how to change AUTHORIZE to operate on the original UAF with the DEFINE command.

$ DEFINE/SYSTEM/EXECUTIVE_MODE SYSUAF SYS$SYSTEM:SYSUAF.DAT
$ RUN SYS$SYSTEM:AUTHORIZE
AUTHORIZE> MODIFY SYSTEM /PASSWORD=new_password
AUTHORIZE> EXIT

Once done, the UAFALTERNATE parameter can be set to 0 using SYSMAN (or via conversation boot):

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> PARAMETERS USE CURRENT
SYSMAN> PARAMETERS SET UAFALTERNATE 0
SYSMAN> PARAMETERS WRITE CURRENT
SYSMAN> EXIT

After a shutdown and reboot i had the original UAF with the new SYSTEM password and curiously a different login screen:

$ set terminal/device_type=vt100

$ sh mem

$ sh devices

$ sh sys

Now i need to learn some more about VMS.

The system came with about 15 floppy disks which were archived using a Greaseweazle. Several were a high density format, one was not a VMS disk, and the rest were RX50 format. The first thing i wanted to do was to archive these disks.

There is some basic information on the rx50 format here:

https://www.vaxarchive.org/hardware/rx50.html

I wasn’t sure if the disks were RX50 disks so i started by reading them as SCP files using greaseweazle.

An 80 track 96 TPI drive capable of writing double density disks is required. One option is the rx50 itself, but there are other drives that work fine as well. I have previously used a Panasonic JU-475-5 drive for making 80 track disks for the Sirius One and the BBC Master. I’d expect other drives to work as long as they observe the density select pin including changing the rotational speed to 300rpm for double density disks.

These disks can be archived with greaseweazle simply by reading the flux into an SCP file.

gw read --revs=5 --tracks="c=0-79:h=0" <file>.scp

I could then load them into the HxC software for a look.

Then i exported them to IMG.

Greaseweazle is also capable of doing the conversion using a custom disk format and this is the more efficient approach if you already know the disk format.

# Example custom.cfg
disk RX50
  cyls       = 80
  heads      = 1
  tracks * ibm.mfm
    secs       = 10
    bps        = 512
    interleave = 1 
    rate       = 250
    rpm        = 300
  end
end

gw write --diskdefs=custom.cfg --format=rx50 <file>.img

Greaseweazle could attempt the deinterleave here by setting interleave=2, but it turns out to be more convenient to not do this.

There was nothing particularly notable about the media. Given the format is 80 track 96 TPI single-sided disks i expect DEC would have insisted on quad density disks, but generally this was a labelling/certification exercise rather than any fundamental difference from normal double density (or single density) media. The disks that were labelled were single sided double density.

As it turned out, some of the disks were high density disks (probably RX33 compatible) and one was not for the MicroVAX at all.

I was hopeful of retrieving some games from them, but it turns out that the first disk in the backup set is rotten.

Having archived the disks i tried to mount them on the Microvax.

Each disk has a “label” written to it. I didn’t know the labels for these disks but if you put in a random word it will fail and tell you the actual label. I found most would not mount regardless.

$ mount dua1: <label>

I also tried to initialize a fresh disk but this also failed which didn’t seem like a good sign. I even tried a disk that had been erased with the Greaseweazle erase function. No joy.

$ initialize dua1: test

It was the same with the second drive. The RX50 dual drive is a curiosity in that it has only one hub motor and one head position motor shared by the two drives. The disk is inserted upside down in the bottom drive.

At this point i thought it would be worth pulling the drive, giving it a good clean, and testing it out with ImageDsk on an old PC. I found enough commentary on the web to believe that the interface was generally consistent with the shugart interface – noting that there are a few variations.

This allowed the alignment to be checked and some read/write tests to be done. Alignment relies on reference disks and with the drive being 80 track double density my commercial DOS disks weren’t going to cut it. Instead, i just used the disks that came with the machine.

One of the pressure pads was loose and the other seemed to be worn. I re-glued the good one and replaced the other with a handcrafted felt.

The rotational speed was good, but the drive was a little out of alignment. Adjustment is by loosening the head position motor screws and rotating the body a little. DEC have made this more awkward than it needed to be:

1. Remove the rear side plate screws and loosen the middle ones.
2. Remove the rear PCB
3. Loosen the screws on the body motor – but just a little
4. Reassemble
5. Test and adjust (it is hard to get a good grip) using the Image disk alignment function
6. Repeat steps 1-2. Tighten the motor body screws.
7. Reassemble

After this i could mount all the DDSS disks that came with the unit. They generally have backup files on them so i have not had time yet to install.

I still found there was a problem initialising disks. I could only initialise disks that had been previously initialised. I think this may be a DEC thing. I suspect that they sold pre-formatted disks rather than providing a genuine format program. Lexitron pulled a similar swifty with their word processors.

It is easy enough to work around this by writing an archived disk using greaseweazle and then initialising it. Once that’s done the freshly initialised disk can be archived and used to write more formatted disks.

I’m interested in writing third party images to physical floppy disks for use in the MicroVAX. Images available via the net are often used with simh eg

MicroVAX I Emulation

They often have an extension of DSK, but it is not the only extension used. On the face of it these images contain the raw sector data.

In my naivety, i thought that i would be able to take these images and write them with greaseweazle in much the same way as i had read the disks that came with the machine.

# Example custom.cfg
disk RX50
  cyls       = 80
  heads      = 1
  tracks * ibm.mfm
    secs       = 10
    bps        = 512
    interleave = 1 
    rate       = 250
    rpm        = 300
  end
end

gw write --diskdefs=custom.cfg --format=rx50 <file>.img

I attempted this and achieved an epic fail. The MicroVAX could not make sense of them. Sometimes it recognised the label, other times it recognised an unexpected label, but it could never find its “home block”.

I was able to “initialise” these disks though, and it was interesting to read these back and compare the resulting IMG file with the original.

The first track ie the first 10x512byte sectors are the same. It is as-if the MicroVAX ignored the first track when it initialised the disk. The original label remains on this track.

Once the disk is re-initialised, the MicroVAX sees the new label which is on the second track. This gives the impression that there is a search order ie it looks for a label on the second track and then, if it does not find one, it tries the first track and perhaps all tracks. It gives the appearance of searching the whole disk.

Is it possible that the track zero sensor is out by a track? If there is a problem then the disks that came with the unit must have been written with that fault because they all work.

Or is there some track numbering magic going on eg 0 to 79 vs 1 to 80?

This post on VCF provided some insight (and, even better, solutions):

https://forum.vcfed.org/index.php?threads/gotek-w-flashfloppy-as-rx33-rx50-floppy-emulator.1242665/page-2

The first track is only used by the DEC Rainbow – a CP/M machine that also uses the RX50 floppy disk drive. It also says that images used with simh have the first track moved to the end of the image. Important info.

This is not the only difference though. The position of the sector that holds the root directory on the original image is in the third sector of the first track whereas the disk formatted in the MicroVAX has this directory in the sixth sector of the third track. This hints that the downloaded files may have the sectors in a logical order. Several sources state that the disk controller uses an interleave of 2. Just changing the interleave to 2 when creating the img does not resolve the problem.

But the above post does contain a solution in the form of two python scripts that handle the conversions between a raw image and the images used by simh. Inspection of them reveals some detail regarding the interleave.

I would never have worked out the rotation. Bravo to shirsch for solving it and coding the translators!

Depending on direction of conversion:
skewtab = [8, 0, 2, 4, 6, 9, 1, 3, 5, 7]
skewtab = [1, 6, 2, 7, 3, 8, 4, 9, 0, 5]

So we have two different image/binary formats.

The first represents the sectors in the order in which they are occur on the disk surface. The first track is unused. I am using the IMG extension for these files.

The second has the unused first physical track moved to the end of the file, and the sectors in logical order. I will use the DSK extension for simh style disk image files. Naturally, this is the opposite of the author’s assumption so:

dsk2img.py --input-file file.img --output-file file.dsk

img2dsk.py  --input-file file.dsk --output-file file.img

Using these scripts, i have been able to move floppy disk images easily between the simh and physical environments.

The IMG files can be read from, and written to, disk by greaseweazle using the definitions near the top of this page.

I haven’t found a way to move files in and out of images. There are some programs that appear to do this, but they may not support the Files-11 Structure Level 2 that is used by the MicroVAX. If the available tools support file extraction (and i’m thinking of cpmtools for the DEC rainbow) they may not support directories, for example. I would have to give it a whirl.

I was keen to find a way to archive files from the MicroVAX hard disk. In time i may acquire a hard drive emulator or even get Kermit up and running, but with the disk being a time-bomb i need to get the critical stuff off now.

The 30MB disk is about 90% full so it would take a lot of floppies to do the lot – about 75! A lot of it is system files, but i can still easily see 30 disks being required. Practically it is easier to use solid state storage even if it is still limited to 400kB at a time.

Flashfloppy on a gotek supports the RX50 disk format. A configuration file is required. The key lines are:

interface = shugart
host = dec

I found this worked well with the IMG files that i read with Greaseweazle. The Microvax was happy to initialize disks and copy over data.

Piece by Piece Backup

The simplest approach, although arduous, is to backup to floppy disk. The hard disk is close to full. With a disk capacity of 400kB this will about 75 disks.

The machine has a RD52-A hard disk with a capacity of about 30MB. Ideally this would be backed up using an image backup to a solid state drive with a matching configuration. Maybe one day i will have such a drive but presently i do not.

Doing this with real floppy disks would be unlikely to succeed – there would inevitably be a bad sector and the process would grind to a halt. The odds improve with solid state storage but i would still run the risk of a bad sector on the hard disk causing a halt.

Instead, of doing one single backup i thought it might be more practical to do it in sections requiring less than 20 disks.

I started by working out where stuff was stored in the directory structure. This means running a bunch of directory commands eg.

dir dua0:[000000] /size /grand_total
dir dua0:[sys0] /size /grand_total

This revealed a tree as follows:

Directory (- is one level) (> is a file)	Size (blocks)	Approx Floppy Disks (800 blocks)
dua0:[000000]	55863	70
-development	7782	10
-v5_development	1680	3
-security	3187	4
-sys0	36244	46
–syslib	9640	13
–sysexe	21915	28
–>pagefile.sys	6800	Not backed up
–>swap.sys	3836	Not backed up
—the rest of sysexe	11279	15
–the rest of sys0	4689	6
–the rest of root	6970	9

I backed up the bolded folders above. This required using the exclude option for some backups and that gets quite complicated (for me).

Along the way i learnt that the first disk needs to be initialised and mounted as foreign. The backup command to floppy disk is of the form:

$ sys$system:backup <input> <output>

Directory	<Input>	<Output>
dua0:[000000]
-development	dua0:[development…]	dua1:[000000]development.bck/save_set
-v5_development	dua0:[v5_development…]	dua1:[000000]v5_development.bck/save_set
-security	dua0:[security…]	dua1:[000000]security.bck/save_set
-sys0
–syslib	dua0:[syslib…]	dua1:[000000]syslib.bck/save_set
–sysexe
–>pagefile.sys
–>swap.sys
—the rest of sysexe	dua0:[000000…]/exclude=(*.sys)	dua1:[000000]sysexe.bck/save_set
–the rest of sys0	dua0:[sys0…]/exclude=([sysexe…],[syslib…])	dua1:[000000]sys0.bck/save_set
–the rest of root	dua0:[000000…]/exclude=([development…],[v5_development…],[security…],[sys0…])	dua1:[000000]root.bck/save_set

It took a lot of experimenting to get the hang of the backup command. Some of the commands became very long, so i changed the terminal settings to use 132 columns. Commands and qualifiers can be abbreviated as long as uniqueness is unaffected.

Directory	Approx Floppy Disks (800 blocks)	Actual Disks
-development	10	13
-v5_development	3	3
-security	4	5
–syslib	13	16
—the rest of sysexe	15	18
–the rest of sys0	6	10
–the rest of root	9	9

Several files were not copied because they were locked including accounting.dat and operator.log. Pagefile.sys and swap.sys were excluded but probably would have been locked.

Backing up sysexe gave an error re a bad block in dua0:[sys0.sysexe]set.exe and stopped the backup. I can’t see this file so i just excluded it. Perhaps a disk integrity issue.

The files in a save_set can be listed using:

$ mount/foreign dua1:
$ sys$system:backup/list dua1:[000000]<name>.bck/save_set

It will prompt for each disk. It was curious to see that some disks seemed to be more full than others. Perhaps it splits files across disks. Not sure.

I believe i have now taken a copy of everything that matters from the hard disk. I don’t think this would be sufficient to rebuild the disk as it stands right now; i have no boot track.

Image Backup

To achieve this i would need to do an image backup. Given the number of disk required, that looked daunting at the start, but it seemed possible after getting some confidence in the backup process. I tried it.

I created about 100 blank floppy disk images and loaded them on to a gotek.

I created a standalone backup kit using three blank floppy disk images on the gotek. The MicroVAX was then booted with the standalone backupkit and the image backup was done with the blank images.

$ backup/image/log dua0: dua2:hdimage.bck/save_set

The backup used 68 disk images and took about 100 minutes.

These disks (including the standalone backup kit) were then converted from the IMG to DSK using dsk2simh.py as described here.

I created a new instance of the simh MicroVAX I and attached an empty disk to dua0:. I used the same standalone backup kit to restore the original disk image to the emulation.

$ backup/image/log dua2:hdimage.bck/save_set dua0:

The restoration was faster because simh runs faster than the real hardware, but is more tedious because of the convoluted process for changing media.

It was a great relief to see it come up. There was one reported issue, but otherwise it seems to behave in much the same way as the physical system. This ticks two boxes: firstly the backup seems to be good, and secondly i have a good emulation of the physical MicroVAX I as received (more or less).

The reported issue was:

%%%%%%%%%%%  OPCOM  28-APR-2026 20:37:46.41  %%%%%%%%%%%
Microcode for device _PUA0: (RD/RX controller) is not up to the current revision level

I think this is saying that the storage controller used by simh is earlier than that on the physical hardware. I could try running sysgen.

As i have no V4.4 installation disks it may be impossible to add devices, eg an ethernet card, unless the driver is already installed. This may prove limiting.

When i was a student back in the eighties i had the pleasure of using VMS on the uni’s VAX systems. We were very much constrained in our usage though so my expertise was very limited. I remember the versioning of files, and having to purge old versions to get under the quota requirements, but that’s about all that i remember. I now find myself with a little VAX/VMS system and system privileges – and i have no skills at all.

I started with the VAX/VMS primer which describes things like how to use the command line, how to use the editor, EDT, how filenames work, directories including the default directory, and few commands. It’s a gentle start but leaves a lot unsaid.

I don’t have a full manual set for MicroVMS 4.4. Instead i have found a mix of resources for various versions with OpenVMS probably having the most comprehensive documentation. I have spent a lot of time googling to discover things that are probably very obvious to a regular VMS user.

The rest of this page is really a set of adhoc notes. Don’t take them too seriously.

Built-in commands are described in the VAX/VMS Command Language User’s Guide

Hard disk: dua0

First floppy disk drive: dua1

Second floppy disk drive: dua2

Change to a specific directory:

$ SET DEFAULT DISK$USER:[USERNAME.SUBDIRECTORY]

Move to a higher-level directory (Parent):

$ SET DEFAULT [-]

Move up two levels:

$ SET DEFAULT [--]

Move to a peer directory:

$ SET DEFAULT [-.SUBDIRECTORY]

Return to user login directory:

$ SET DEFAULT SYS$LOGIN

Change to a new disk:

$ SET DEFAULT DISK2:[000000]

Show the current directory.

$ show default
  SYS$SYSROOT:[SYSMGR]

The root directory on a drive is [000000].

To see what is in the root directory:

$ dir dua0:[000000]

Directory DUA0:[000000]

000000.DIR;1        BACKUP.SYS;1        BADBLK.SYS;1        BADLOG.SYS;1
BITMAP.SYS;1        CONTIN.SYS;1        CORIMG.SYS;1        INDEXF.SYS;1
SYS0.DIR;1          SYSEXE.DIR;1        SYSMAINT.DIR;1      USER.DIR;1
VOLSET.SYS;1

Total of 13 files.
$

Subdirectories appear as files with a .DIR extension.

For the first level the 000000 is not required eg with the subdirectory sys0 and its subdirectory tmp:

$ dir dua0:[sys0]

Directory DUA0:[SYS0]

SYSCBI.DIR;1        SYSERR.DIR;1        SYSEXE.DIR;1        SYSHLP.DIR;1
SYSLIB.DIR;1        SYSMAINT.DIR;1      SYSMGR.DIR;1        SYSMSG.DIR;1
SYSTEST.DIR;1       SYSUPD.DIR;1

Total of 10 files.
$ dir dua0:[sys0.syshlp]

Directory DUA0:[SYS0.SYSHLP]

EDTHELP.HLB;1       EXAMPLES.DIR;1      HELPLIB.HLB;1       UAFHELP.HLB;1

Total of 4 files.
$

Console output can be redirected with /output=filename

Subdirectories are included with …

$ dir dua0:[000000...]*.dir

Directory DUA0:[000000]

000000.DIR;1        SYS0.DIR;1          SYSEXE.DIR;1        SYSMAINT.DIR;1
USER.DIR;1

Total of 5 files.

Directory DUA0:[SYS0]

SYSCBI.DIR;1        SYSERR.DIR;1        SYSEXE.DIR;1        SYSHLP.DIR;1
SYSLIB.DIR;1        SYSMAINT.DIR;1      SYSMGR.DIR;1        SYSMSG.DIR;1
SYSTEST.DIR;1       SYSUPD.DIR;1

Total of 10 files.

Directory DUA0:[SYS0.SYSHLP]

EXAMPLES.DIR;1

Total of 1 file.

Grand total of 3 directories, 16 files.

Size can be shown with /size (block =512B):

$ dir dua0:[000000] /size

Directory DUA0:[000000]

000000.DIR;1              1
BACKUP.SYS;1              0
BADBLK.SYS;1              0
BADLOG.SYS;1              0
BITMAP.SYS;1             16
CONTIN.SYS;1              0
CORIMG.SYS;1              0
INDEXF.SYS;1           1024
SYS0.DIR;1                1
SYSEXE.DIR;1              1
SYSMAINT.DIR;1            1
USER.DIR;1                1
VOLSET.SYS;1              0

Total of 13 files, 1045 blocks.
$

Total size of directories can be shown with grand_total.

$ dir dua0:[000000...]*.*   /size /grand_total

Grand total of 10 directories, 176 files, 13800 blocks.
$

To mount a floppy disk:

$ mount dua1: <label>

to dismount a floppy disk:

$ dismount dua1:

Logical names are used extensively as a shorthand for things. They are revealed by show logical *

$ show logical *

(LNM$PROCESS_TABLE)

  "SYS$COMMAND" = "_SALONE$OPA0:"
  "SYS$DISK" = "SYS$SYSROOT:"
  "SYS$ERROR" = "_SALONE$OPA0:"
  "SYS$INPUT" = "_SALONE$OPA0:"
  "SYS$OUTPUT" [super] = "_SALONE$OPA0:"
  "SYS$OUTPUT" [exec] = "_SALONE$OPA0:"
  "TT" = "OPA0:"

(LNM$JOB_800E4610)

  "SYS$LOGIN" = "SYS$SYSROOT:[SYSMGR]"
  "SYS$LOGIN_DEVICE" = "SYS$SYSROOT:"
  "SYS$SCRATCH" = "SYS$SYSROOT:[SYSMGR]"

(LNM$GROUP_000001)

(LNM$SYSTEM_TABLE)

  "$CONSOLE" = "_OPA0:"
  "$DISK1" = "_DUA0:"
  "$FLOPPY1" = "_DUA1:"
  "$FLOPPY2" = "_DUA2:"
  "$TERMINAL0" = "_TTA0:"
  "$TERMINAL1" = "_TTA1:"
  "$TERMINAL2" = "_TTA2:"
  "$TERMINAL3" = "_TTA3:"
  "ACP$BADBLOCK_MBX" = "MBA3:"
  "DBG$INPUT" = "SYS$INPUT:"
  "DBG$OUTPUT" = "SYS$OUTPUT:"
  "DISK$MICROVMS" = "SALONE$DUA0:"
  "LNK$LIBRARY" = "SYS$LIBRARY:IMAGELIB.OLB"
  "LNK$LIBRARY_1" = "SYS$LIBRARY:STARLET.OLB"
  "MTHRTL" = "SYS$SHARE:UVMTHRTL.EXE"
  "SYS$ANNOUNCE" = ".Welcome to MicroVMS V4.0"
  "SYS$COMMON" = "SALONE$DUA0:[SYS0.]"
  "SYS$DISK" = "SALONE$DUA0:"
  "SYS$ERRORLOG" = "SYS$SYSROOT:[SYSERR]"
  "SYS$EXAMPLES" = "SYS$SYSROOT:[SYSHLP.EXAMPLES]"
  "SYS$HELP" = "SYS$SYSROOT:[SYSHLP]"
  "SYS$INSTRUCTION" = "SYS$SYSROOT:[SYSCBI]"
  "SYS$LIBRARY" = "SYS$SYSROOT:[SYSLIB]"
  "SYS$MAINTENANCE" = "SYS$SYSROOT:[SYSMAINT]"
  "SYS$MANAGER" = "SYS$SYSROOT:[SYSMGR]"
  "SYS$MESSAGE" = "SYS$SYSROOT:[SYSMSG]"
  "SYS$SHARE" = "SYS$SYSROOT:[SYSLIB]"
  "SYS$SPECIFIC" = "SALONE$DUA0:[SYS0.]"
  "SYS$SYLOGIN" = "SYS$MANAGER:SYLOGIN.COM"
  "SYS$SYSDEVICE" = "SALONE$DUA0:"
  "SYS$SYSDISK" = "SYS$SYSROOT:"
  "SYS$SYSROOT" = "SALONE$DUA0:[SYS0.]"
  "SYS$SYSTEM" = "SYS$SYSROOT:[SYSEXE]"
  "SYS$TEST" = "SYS$SYSROOT:[SYSTEST]"
  "SYS$TOPSYS" = "SYS0"
  "SYS$UPDATE" = "SYS$SYSROOT:[SYSUPD]"
  "SYS$WELCOME" = "@SYS$MANAGER:WELCOME.TXT"
$

A logical can have more than one directory path so the command processor could search multiple directories for a file.

There are also symbols which seem to be effectively string variables.

EXE files are run using a run command.

Scripts are run with @ prefix eg

$ @SYS$UPDATE:STABACKIT ;makes a standalone backup kit

There is a whole manual on backup and restore: VMS Backup Utility Manual.

A lot of other things are described by role in the System Manager’s Guide and the Operator’s Guide.