Table of Contents
VMFPLC2 Case Study
One of the biggest limitations of working with VM/370 under hercules
is the asymmetry in how CMS stores files, and how modern operating systems store files.
The namespace disparities present some hurdles in taking a 'host viewable' backup of the system.
VMFPLC2
The VM/370 Utility VMFPLC2
can be used to dump collections of files onto tape. Because tapes are of arbitrarily great lengths in the virtual world, it's an easy medium on which to transport files. It also turns out that there is a parallel utility created for the HERCULES
project which can “unpack” these tape formats and transfer them from and to the standard format.
This case study covers the round-trip required to move files from CMS MDisks, to Virtual Tape, to Windows Host, to Virtual Tape, and then to CMS MDisks.
CMS to Virtual Tape
Dumping arbitrary files from CMS is trivial. In broad steps
- Attach a virtual file on a
HERCULES
emulated tape drive - Attach the corresponding virtual tape drive on VM/370 Control Program to the USER's Tape Drive (CMS Uses 181 as the first tape drive).
- Issue the
VMFPLC2 DUMP fn ft fm
command - Write two consecutive tape marks to signify
end of tape
. - Detach the emulated tape drive from the virtual machine
- Detach the attached file from the
HERCULES
emulated tape drive.
Virtual Tape to Windows Host
This is where the fun begins. The HERCULES
HOST version of VMFPLC2
doesn't operate exactly the same way as the VM/370 CMS version of the utility. This is because of the dissimilarities in how the files are named and a control file is employed to act as the bridge between the CMS naming and formatting of files.
Scanning is straightforward, but building the control file, is not.
- The
VMFPLC2
command does a great job of producing a list of the tape's contents… but that's where the fun ends. - Using the
waterloo.aws
tape as a working example, we issue the commandvmfplc2 scan waterloo.aws > waterloo.scan.txt
- We see that the virtual tape file scan contains 135 subfiles.
Scan Data to Control File
The format of the vmfplc2
DUMP command is:
The control file that needs to be derived from this tape, in preparation for loading is a somewhat mechanical transformation. However, there is another complexity. The representation of the on-disk file storage table (FST) looks like this:
X'00'+-----------------------------+ × F I L E N A M E × X'08'×-----------------------------× × F I L E T Y P E × X'10'×-----------------------------× × X'MMDDHHMM' ×WRT PTR×RD PTR× X'18'×-----------------------------× × MODE ×# ITEMS× FCL ×F/V×FL× X'20'×-----------------------------× × LRECL ×DB CNT × YEAR × X'28'×-----------------------------× ×#FULL TAPE BLK×LTH LSTBLK/800× X'30'×-----------------------------× × FILE ORIG PTR× ALT DATA BLK × X'38'×-----------------------------× × ALT ITEM CNT ×#LV×PTRSZ×YYMM× X'40'×-----------------------------× × DDHHMMSS × RESERVED × X'48'×-----------------------------×
Note that the YEAR portion of the record is a two-digit representation. According to the listfile function (as implemented by DMSLST ASSEMBLE
, all date representations PRIOR to the year 1960 are considered to be part of the next century. None of the utilities seem to understand this so even though the tape we've chosen waterloo.aws
has dates after the year 1960, there are MANY files on the VM/370 system which have dates prior to 01 Jan 1960.
The Windows Host version of VMFPLC2
does NOT attempt to adjust dates and simply uses the system date and time at the time of the restore operation when transferring files to the host system. This makes sense because many so-called 'modern' filesystem formats do not understand dates prior to 01 Jan 1980. So preserving dates between systems is a two-step process, if at all.
There are additional challenges such as permissible characters in the hostfile which need to be managed carefully and therefore it makes sense use a utility program to perform this entire conversion.
Automatic Generation
To facilitate the transfer operation, a utility has been created to ingest AWS/HET tapes, and generate the control files and command files necessary to extract the AWS/HET Tape contents to a Windows (or Linux) host filesystem. The ProcAWSTape
utility was created for this purpose.
For each tape, three files are generated by the utility:
<TapeFileName>.files.txt
a formatted/detailed enumeration of the tape's contents including the “host system safe filename” to which the contents can be written.<TapeFileName>.tapemap.ctl
a formatted enumeration of the tape's contents according to the rules of theVMFPLC2
utility. This file is ONLY present if the tape containsVMFPLC2
orTAPE
formatted output. The utility automatically detects which formats are contained within the tape.
<TapeFileName.tapemap.cmd
The generated command file which invokes the proper utilities for exporting the tape's content.
The Control File
The resulting control file looks like this:
Because we have the file “in-hand”, it was also a straightforward process to calculate other statistics about the tape's content:
- The number of Internal Virtual Tape Files
- Sequence Number
- Number of Bytes
- Number of Blocks
- Minimum Block Size
- Maximum Block Size
- Average Block Size
- The Virtual Tape File Format and size (and creation date)
- If formatted, which format was used (VMFPLC2 or TAPE)
- Filename
- Filetype
- Filemode
- Fixed or Variable
- if Fixed, the logical record length
- The “automatically designated” export format (Text or Binary)
- The “automatically derived” host filename.
The entire waterloo.tapemap.ctl
file is available for review.
Windows Host to Virtual Tape
Once the configuration file has been generated, it can be used to reverse the process in writing the files back to the Virtual Tape and then back to the host operating system. Using the same control file is a good starting point for this.
Virtual Tape to CMS
Transferring files back to CMS from the VMFPLC2
formatted tape is trivial (enough) if we got the file and record formats correct in the first place.