PARSEC Technical Information

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== How To Use LDAnnn: Logical Disks =====

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.

==== Installing the LDdriver Package ====

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:

<code>
$ @SYS$STARTUP:LD$STARTUP
</code>

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:

<code>
$ 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? 
</code>

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.

==== Creating Your First LDAnnn: Disk ====

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:

<code>
$ 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
</code>

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”.

<code>
$ 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.
</code>

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.

==== Notice About Performance ====

If highwater marking is enabled on the disk holding the container file, then the container file is erased when it is created. This means that it will not have the “junk data” that was previously in the disk but instead will be overwritten with zeros. This is not a bad thing except when creating very large container files. This can take a long time. The solution is to disable highwater marking before creating the container file.

<code>
$ show device /full dsa2

Disk DSA2:, device type Generic SCSI disk, is online, mounted, file-oriented
    device, shareable, available to cluster, error logging is enabled, device
    supports bitmaps (no bitmaps active).

    Error count                    0    Operations completed           10774139
    Owner process                 ""    Owner UIC              [SYSTEST,SYSTEM]
    Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
    Reference count               27    Default buffer size                 512
    Total blocks           142264000    Sectors per track                    96
    Total cylinders            15437    Tracks per cylinder                  96
    Logical Volume Size    104856255    Expansion Size Limit          169279488

    Volume label              "PROD"    Relative volume number                0
    Cluster size                 144    Transaction count                   105
    Free blocks             10094832    Maximum files allowed            494395
    Extend quantity                5    Mount count                           4
    Mount status              System    Cache name         "_$32$DKA0:XQPCACHE"
    Extent cache size             64    Max blocks in extent cache      1009483
    File ID cache size            64    Blocks in extent cache          1009440
    Quota cache size               0    Maximum buffers in FCP cache       1993
    Volume owner UIC  [SYSTEST,SYSTEM]
                                        Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD

  Volume Status:  ODS-2, subject to mount verification, file high-water marking,
      write-through XFC caching enabled, write-back XQP caching enabled.
  Volume is also mounted on HOTVAX, AXPBOX, CLASS3.

Disk $32$DKA100:, device type COMPAQ BF07288285, is online, member of shadow set
    DSA2:, served to cluster via MSCP Server, error logging is enabled.

    Error count                    0    Shadow member operation count  10857417
    Current preferred CPU Id       0    Fastpath                              1
    Allocation class              32

$ set volume dsa2: /nohighwater
</code>

File highwater marking is a security feature. While it is disabled, it is possible for others to scavenge the disk for old data from deleted files. If desired, restore highwater marking after the creation of the logical disk container file.

<code>
$ set volume dsa2: /highwater
</code>
==== Connecting Your LDAnnn: Disk ====

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'':

<code>
$ 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
</code>

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:

<code>
$ 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               50000    Sectors per track                    11
    Total cylinders              152    Tracks per cylinder                  12
    Allocation class             254
</code>

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

==== Initializing Your LDAnnn: Disk ====

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!

==== Mounting Your LDAnnn: Disk ====

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

<code>
$ 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.
</code>

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

<code>
$ 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]]
  ...
</code>

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

==== Using Your LDAnnn: Disk ====

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.

<code>
$ 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.
</code>

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:

<code>
$ 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.
</code>

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

<code>
$ 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)
</code>

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

<code>
$ 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)
</code>

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...

<code>
$ 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
</code>

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

==== Clean-up -- Dismount, Disconnect, even Delete, etc. ====

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

<code>
$ 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)
</code>

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...

==== Summary of Use Cases ====

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.