PARSEC Technical Information

Logical Disks, presented in OpenVMS as LDAnnn: devices, are one of the operating system's best-kept secrets, even though there's really no conspiracy. Implemented as a Files-11 file system inside of a “container file,” logical disks can often serve as a solution to problems (or opportunities) you haven't yet known you face.

Logical Disks (sometimes also called Virtual Disks in this VMS context, although both terms have other technical meanings in other environments) are implemented using the freeware LDdriver layered product, available for VAX, Alpha and Integrity platforms for free here:

https://www.digiater.nl/lddriver.html (software product description) and
https://www.digiater.nl/downloads.html (downloadable .ZIP files, latest version is V9.7)

Good documentation is available on the above website, and also here:

http://h41379.www4.hpe.com/openvms/journal/v6/disk_partitioning_with_lddriver.pdf

Among various other uses, Logical Disks can be used as a “sandbox” (playground) VMS disk for training new users (where they cannot “hurt anything”), as well as for an ODS-5 structured Files-11 volume (e.g., on an ODS-2 volume) for installation of and/or experimentation with open source software.

Install the LDdriver package this way:

• Download the appropriate LDdriver .ZIP file from the website above.
• Unzip that .ZIP file (using the freeware VMS UNZIP utility).
• Install the resulting LD*.PCSI product installation kit using PRODUCT INSTALL.
• Read the Release Notes, and invoke the following product startup com-file in your VMS system's SYS$MANAGER:SYSTARTUP_VMS.COM file:

$ @SYS$STARTUP:LD$STARTUP

This layered software product installation adds a new DCL command, LD, to SYS$LIBRARY:DCLTABLES.EXE. To pick up this command for immediate use, you can either logout and log-back-in again, or just issue this command:

$ SET COMMAND /TABLE=SYS$LIBRARY:DCLTABLES

Once you've got the new LD command at your process's disposal, explore LD HELP this way:

$ LD HELP

LD

        The logical disk utility is a system management tool available
        to any user for controlling logical disk usage.

        A Logical Disk is a file available on a Physical Disk, which
        acts as a real Physical Disk (the file may or may not be
        contiguous). The Logical Disks are available in any directory
        of the Physical Disk.

        A large disk can be divided into smaller sections, each a Logi-
        cal Disk, supporting the same I/O functions as the Physical Disk.
        By giving the Logical Disk File a good  protection level and
        mounting it private or with device protection, you are able to
        add a number of protection levels to your file system.

        The logical disk is controlled by the LD utility, which can
        be directly invoked from DCL.

        Format:

        LD [/qualifiers] [Filespec] [Device]

  Additional information available:

  Author     Command_summary       Driver_functions      Error_messages
  Features   HELP       New_features_V5.0     New_features_V5.1
  New_features_V6.0     New_features_V6.2     New_features_V6.3
  New_features_V7.0     New_features_V8.0     New_features_V8.1
  New_features_V8.2     Parameters Privileges_and_Quotas Restrictions
  Setup      IO_Trace_example      CONNECT    CREATE     DISCONNECT NOPROTECT
  NOWATCH    SHOW       TRACE      NOTRACE    PROTECT    WATCH      VERSION
  Examples

LD Subtopic? 

Explore these help topics at least: Command_summary, Features, Setup, Examples, CREATE, CONNECT and SHOW. The primary commands you'll use are CREATE, CONNECT, SHOW and maybe DISCONNECT.

We'll demonstrate the creation and connection of a new Logical Disk next.

Let's start by creating a “sandbox” (or “playpen”) Logical Disk file, just to fool around with, in a user's home directory ― the size of 50,000 is arbitrary, but plenty big enough for experimentation:

$ SHOW DEFAULT
DSA2:[LRICKER]
$ LD CREATE /SIZE=50000 /CONTIGUOUS /LOG DSA2:[LRICKER]SANDBOX.DSK
%LD-I-CREATED, File DSA2:[LRICKER]SANDBOX.DSK;1 created

NOTE: The /CONTIGUOUS is not required

This just creates a big file, with no actual contents other than whatever “junk data” was previously in the disk blocks allocated to this file. Note that, although we've used .DSK as the file extension in this example, you can use whatever file extension you like, as there's no specific file-type enforced. However, stick to a filename and type that is conventional and “obvious.”

$ DIRECTORY /SIZE /DATE /OWNER /PROT *.DSK

Directory DSA2:[LRICKER]

SANDBOX.DSK;1   50000       2-AUG-2017 08:21:25.30   [STAFF,LRICKER]  (RWED,RWED,,)

Total of 1 file, 50000 blocks.

The LD-container file needs to be created just once, of course – once created, it can be connected and mounted numerous times, whenever needed. The container file can also be disconnected from the LD-driver and summarily deleted, if you're sure you're done with it… You can “start over again.” Of course, you can have as many Logical Disks (files) as you practically need.

Once created, this Logical Disk file next has to be connected to an actual LDAxxx: device (based on the LDA0: template device), so we have to find an unused unit number xxx:

$ SHOW DEV LD

Device                  Device           Error    Volume         Free  Trans Mnt
 Name                   Status           Count     Label        Blocks Count Cnt
$254$LDA0:    (CLASS8)  Online               0
$254$LDA10:   (CLASS8)  Online               0
$254$LDA11:   (CLASS8)  Online               0
$254$LDA12:   (CLASS8)  Online               0
...
$254$LDA19:   (CLASS8)  Online               0
$254$LDA101:  (CLASS8)  Online               0
$254$LDA102:  (CLASS8)  Online               0
...
$254$LDA109:  (CLASS8)  Online               0
$254$LDA200:  (CLASS8)  Mounted              0  OPENSOURCE     5641984     1   2
$254$LDA1024: (CLASS8)  Mounted              0  RUBYMINE         29500     1   1

On our CLASS8 training system here at PARSEC, we play with numerous Logical Disks, so we've got lots. Your mileage will vary, and to begin with, you'll likely show no LDAnnn: devices on your system – this will be your first. On a system with existing LDAnnn: devices, pick a totally new, unused unit number.

Because it's easy(er) to remember and type, let's use LDA77: for our experiments. This will likely be a temporary use for this particular unit number – if you ever decide to “go to production” or other regular, persistent use for a particular Logical Disk, be sure to more-or-less permanently allocate an LDAxxx: (unit number) to that LD-file; likely, you'll put all of that into a startup command file for consistency.

$ LD CONNECT /LOG DSA2:[LRICKER]SANDBOX.DSK LDA77: LDISK$SANDBOX
%LD-I-CONNECTED, Connected $254$LDA77: to DSA2:[LRICKER]SANDBOX.DSK;1

We're making consistent use of the /LOG qualifier for these LD-commands just to show what's happening… this qualifier is optional.

Note: Experience shows that the LD CREATE and CONNECT (and, by extension, the DISCONNECT) commands are particular, picky even, about the colon “:” on the end of the LDAxxx: device name – Don't omit that colon!

Now, LDA77: is a device that just happens to be “backed by” (or implemented as) a file. Since this file has just been created, it has no valid contents – and certainly does not yet have a file system in it. So this:

$ SHOW DEVICE LDA77: /FULL

Disk $254$LDA77: (CLASS8), device type Foreign disk type 1, is online, file-
    oriented device, shareable, available to cluster.

    Error count                    0    Operations completed                  2
    Owner process                 ""    Owner UIC              [SYSTEST,SYSTEM]
    Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
    Reference count                0    Default buffer size                 512
    Total blocks               20000    Sectors per track                    11
    Total cylinders              152    Tracks per cylinder                  12
    Allocation class             254

…simply shows us a “foreign device,” un-mounted and un-loved. This device needs to be initialized with a file system.

We do this next command – not surprisingly, an INITIALIZE command – once (per newly-created LD-device)… Note that this command does not initialize the file, it initialized the device. Whenever we create a new LD-container file and connect it, we need to next initialize its file system (contents). Be sure to give the file system a meaningful volume label; you can choose either a Files-11 ODS-2 (default, or /STRUCTURE=2) or ODS-5 (extended file system, /STRUCTURE=5) file system:

$ INITIALIZE /STRUCTURE=5 LDA77: SANDBOX

Note that you can create an ODS-5 Logical Disk (file) on a host-disk that is itself an ODS-2 file structure (or visa-versa); this gives you considerable flexibility!

Now, let's mount it and then look at the device's structure:

$ MOUNT LDA77: SANDBOX SANDBOX
%MOUNT-I-MOUNTED, SANDBOX mounted on _$254$LDA77: (CLASS8)
$ SHOW DEVICE /FULL LDA77:

Disk $254$LDA77: (CLASS8), device type Foreign disk type 1, is online,
    mounted, file-oriented device, shareable.

    Error count                    0    Operations completed                530
    Owner process                 ""    Owner UIC               [STAFF,LRICKER]
    Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
    Reference count                1    Default buffer size                 512
    Total blocks               50000    Sectors per track                    13
    Total cylinders              190    Tracks per cylinder                  13
    Logical Volume Size        50000    Expansion Size Limit              53248
    Allocation class             254

    Volume label           "SANDBOX"    Relative volume number                0
    Cluster size                   1    Transaction count                     1
    Free blocks                49886    Maximum files allowed             12000
    Extend quantity                5    Mount count                           1
    Mount status             Process    Cache name         "_$32$DKA0:XQPCACHE"
    Extent cache size             64    Max blocks in extent cache         4988
    File ID cache size            64    Blocks in extent cache                0
    Quota cache size               0    Maximum buffers in FCP cache       2239
    Volume owner UIC [STAFF,LRICKER]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD

  Volume Status:  ODS-5, subject to mount verification, file high-water marking,
      write-through XFC caching enabled, write-back XQP caching enabled, special
      files enabled.

That's much better. As usual, the MOUNT command gives us “free” volume logical names to use for this new “disk”:

$ SHOW LOGICAL /FULL *SANDBOX*

(LNM$PROCESS_TABLE)     [kernel]
                        [no protection information]

(LNM$JOB_859BE4C0)      [kernel]  [shareable]  [Quota=(44672,50000)]
                        [Protection=(RWCD,RWCD,,)]  [Owner=[STAFF,LRICKER]]

  "LDISK$SANDBOX" [super] = "$254$LDA77:"
  "SANDBOX" [super] = "$254$LDA77:"

(LNM$GROUP_000007)      [kernel]  [shareable,group]
                        [Protection=(RWCD,R,R,)]  [Owner=[STAFF,*]]

(LNM$SYSTEM_TABLE)      [kernel]  [shareable,system]
                        [Protection=(RWC,RWC,R,R)]  [Owner=[SYSTEST,SYSTEM]]
  ...

And where did those logical names “DISK$SANDBOX” and “SANDBOX” come from? (Left as an exercise to the reader…)

With this disk initialized (once only) and mounted (whenever we want and need to do so), we can now treat it just like any other disk device (or, more properly, volume) and examine its contents.

$ DIRECTORY /SIZE /DATE /PROTECTION DISK$SANDBOX:[000000]

Directory DISK$SANDBOX:[000000]

000000.DIR;1               1   2-AUG-2017 08:57:33.72  (RWED,RWED,RE,E)
BACKUP.SYS;1               0   2-AUG-2017 08:57:33.72  (RWED,RWED,RE,)
BADBLK.SYS;1               0   2-AUG-2017 08:57:33.72  (RWED,RWED,RE,)
BADLOG.SYS;1               0   2-AUG-2017 08:57:33.72  (RWED,RWED,RE,)
BITMAP.SYS;1              14   2-AUG-2017 08:57:33.72  (RWED,RWED,RE,)
CONTIN.SYS;1               0   2-AUG-2017 08:57:33.72  (RWED,RWED,RE,)
CORIMG.SYS;1               0   2-AUG-2017 08:57:33.72  (RWED,RWED,RE,)
GPT.SYS;1                 68   2-AUG-2017 08:57:33.72  (RWED,RWED,RE,E)
INDEXF.SYS;1              19   2-AUG-2017 08:57:33.72  (RWED,RWED,RE,)
SECURITY.SYS;1             1   2-AUG-2017 08:57:33.72  (RWED,RWED,RE,)
VOLSET.SYS;1               0   2-AUG-2017 08:57:33.72  (RWED,RWED,RE,)

Total of 13 files, 103 blocks.

because that previous INITIALIZE command did not use the /SYSTEM qualifier, this LD-volume is owned by the user, not by [SYSTEM] (or [1,4]). This may or may not be a problem for a particular use case, so just be aware of the options involved here, just like for any other disk/device/volume.

Let's use this new volume – exercise it with a few file commands:

$ CREATE /DIRECTORY /OWNER=PARENT /LOG DISK$SANDBOX:[LORIN]
%CREATE-I-CREATED, DISK$SANDBOX:[LORIN] created
$ DIRECTORY /SIZE /DATE /OWNER /PROTECTION DISK$SANDBOX:[000000]LORIN

Directory DISK$SANDBOX:[000000]

LORIN.DIR;1              1   2-AUG-2017 09:07:34.95  [STAFF,LRICKER]                  (RWE,RWE,RE,E)

Total of 1 file, 1 block.

So far, so good!… It seems to work just like a “real disk”… as it should. More:

$ SET DEFAULT disk$sandbox:[lorin]
$ SHOW DEFAULT
DISK$SANDBOX:[LORIN]
$ copy /log SYS$LOGIN:LOGIN.COM []
%COPY-S-COPIED, DSA2:[LRICKER]LOGIN.COM;14 copied to DISK$SANDBOX:[LORIN]LOGIN.COM;14 (2 blocks)

I hope you weren't expecting magic or miracles ― it really works quite normally…

$ copy LOGIN.COM []
$ copy LOGIN.COM []
$ copy LOGIN.COM []
$ purge /log LOGIN.COM
%PURGE-I-FILPURG, DISK$SANDBOX:[LORIN]LOGIN.COM;16 deleted (2 blocks)
%PURGE-I-FILPURG, DISK$SANDBOX:[LORIN]LOGIN.COM;15 deleted (2 blocks)
%PURGE-I-FILPURG, DISK$SANDBOX:[LORIN]LOGIN.COM;14 deleted (2 blocks)
%PURGE-I-TOTAL, 3 files deleted (6 blocks)

Seen enough? Can you make one of these work for your own practice sessions, learning, and …maybe… find a way to exploit this in some production scenario?

Oh, just one more thing…

$ BACKUP DISK$SANDBOX:[*...]*.*;* SYS$LOGIN:SANDBOX_SAFETY.BCK /SAVE /LOG
%BACKUP-S-COPIED, copied DISK$SANDBOX:[000000]000000.DIR;1
%BACKUP-S-COPIED, copied DISK$SANDBOX:[000000]LORIN.DIR;1
%BACKUP-S-COPIED, copied DISK$SANDBOX:[LORIN]LOGIN.COM;17

Now we've got a backup save-set for safety, just in case we want to recover our sandbox disk in the future.

Well, since this is just a practice session, how do we get rid of the evidence? How do we clean up? Just like this…

$ SET DEFAULT sys$login
$ SHOW DEFAULT
DSA2:[LRICKER]
$
$ DISMOUNT LDA77:
$ LD DISCONNECT /ABORT LDA77:
$ DELETE SANDBOX.DSK;1 /LOG
%DELETE-I-FILDEL, DSA2:[LRICKER]SANDBOX.DSK;1 deleted (50112 blocks)

Dismounting an LD-disk is just dismounting a disk device. Read about the LD DISCONNECT /ABORT qualifier – usually unneeded, unless there are pesky multi-user connections that won't “let go”. The DELETE command makes the sandbox file good and truly gone. But easily recreated…

To summarize – Logical Disks are good for:

• Practicing VMS file commands, etc. – As a learning tool, having one or more sandbox disks available for users (and yourself) to practice in makes it easy and stress-free to learn (“No, you can‟t break anything… play to your heart's content…”).
• Containers for isolation, development and testing – Need an ODS-5 disk structure without changing the underlying host-ODS-2 disk (or visa versa)? Create a logical disk with the target file system structure.
• Containers for installing a layered product or complete application suite into… without disrupting production use of the real/released-version of that software package. Do you see how the principles of rapid deployment might benefit from this tool/resource?
• Providing very-fine-grained security protection (protection masks, ACLs) both to the LD-container file itself, and to any/all files it contains.
• Any other purpose where containers can be used to isolate, enclose and protect packages of software, project use, or other special-purpose scenarios.