It has been several months since the last post in this blog on MCP Express. I chose to stop writing about XE last Fall after discovering serious problems with the operation of MCP networking on later releases of Windows 10.

As many of you may have already seen in the comments to that last post, I have not been able to get MCP networking to function on any version of Windows 10 after 1803. I am still keeping one Windows 10 laptop on 1803, but it's a bit of a struggle -- Microsoft dropped support for 1803 in December 2019, and they really, really want to upgrade your system to a later version. A couple of updates have gotten through despite my best efforts, but fortunately I have discovered them soon enough to roll them back.

XE still runs fine on Windows 7, but of course Microsoft stopped support for that OS in January of this year. I do not have access to a Windows 8 system, but suspect XE still runs all right there as well.

This networking problem is not restricted to XE. I have another Windows 10 laptop running its for-cost cousin, MCP Developer Studio Personal Edition. It suffered exactly the same problems when updated beyond Windows 10 version 1803. Fortunately, my paid license for Developer Studio gives me access to MCP Firmware updates, and updating from Firmware 1.0 (which is also the base for XE) to 2.1 solved the problem. I've since updated to MCP Firmware 3.0. Alas, that type of update is not available for XE.

The most significant change in the more recent firmware releases is an entirely new implementation of TCP/IP, which Unisys calls TCPv3. Apparently this new implementation avoids whatever problems with the underlying Windows 10 networking infrastructure were introduced after version 1803. TCPv3 is also easier to configure and performs significantly better.

So what do we do about the problems with XE under Windows 10? The only answer up to now is that we wait. As most of you already know, the free license for MCP Express expires each year at the end of July. We can only hope that Unisys will continue to offer XE and release a new version. I am hoping that they will, and that the new version will incorporate, if not TCPv3, then at least some fix to the networking problem under Windows 10. I don't know one way or the other whether any of this will prove to be true; we'll all just have to wait a few more weeks and see.

I am going to proceed with the assumption that a new version of MCP Express will come out in August and that the networking problems with currently-supported versions of Windows 10 will be resolved. My purpose in this post is to help you prepare for the transition to that new version.

First, a Brief Primer on the MCP File System

When you installed MCP Express, the Unisys installation process asked you to specify the names of two folders in your local Windows file system, one to hold the MCP's virtual disk drive and the other for diagnostic files. The installation process then unzipped a 20GB disk image named diskxxx.asd into the disk folder. Such a disk image is termed a "Logical Disk."

That disk image contains the pre-configured MCP environment and related system software for XE, plus about 16GB of available space. By default, that disk image presents in the MCP as unit PK501, although the number can be changed in System Editor. To user software, that disk unit is known by its "family name," DISK.

Disk files are identified as "file name ON family name," where file name is a multi-level name with the nodes delimited by forward slashes, "/". For example, the fully-qualified name of the object file for the Algol compiler is "*SYSTEM/ALGOL ON DISK," where the "*" indicates the file is a global or system file, i.e., not one associated with a specific user. The MCP considers DISK to be the default family name, so whether you've realized it in the past or not, specifying a file name without an on-part implies "ON DISK."

The MCP can support any number of disk families, each with a unique name. Each family can consist of up to 255 disk units. When a family has multiple units, then by default the MCP automatically distributes a file's areas (extents) across the units in an attempt to spread the I/O operations as well.

Just what a "disk unit" is these days can be a complicated question. Possible answers include a physical unit of a certain capacity (either spinning disk or SSD), a Logical Disk image, or some resource configured within a Storage Area Network (SAN). In the case of the Logical Disk files like XE uses, each MCP disk unit (i.e., a PKnnn device) corresponds to a Windows file with a .asd file name extension.

Most people using XE probably are fine with that one disk unit created by the installation process. If you need more MCP space than that unit offers, or want more family names, you can add more disk units using the Logical Disk Manager and System Editor tools within the MCP Console application. I will discuss how to do that in a later post. The reason for giving you all this background has been to give you the necessary context for the rest of this discussion.

Next, Backing Up Your MCP Express Files

One major inconvenience with having to completely wipe out MCP Express and install a new version every year is that it deletes the old diskxxx.asd Logical Disk image. Therefore, you need a way to bring forward any files and configuration settings from the old version that you want to continue using and get them set up under the new version. To accomplish that, there are various ways to back up MCP files and restore them later.

Traditionally, you back up MCP systems to magnetic tape of one form or another. There is a WFL COPY command that will copy files from disk to tape, tape to disk, disk to disk, or tape to tape. In the case of disk to disk, it functions much like a Unix/Linux cp command or a Windows command-line copy or xcopy command.

When copying from disk to tape, the tape has a special multi-file format. The first file on the tape is a directory listing the names of all of the files on the tape. Following that is a file for each of the names in the directory, in the order listed in the directory. Each of those tape files corresponds to one MCP file (it's actually a little more complicated than that with today's high-capacity streaming tapes, but conceptually it's the same).

The first item in each of those tape files is a data structure termed the "disk header." This holds the file metadata, security information, and locations of the file's disk areas. It is similar in concept to a Unix inode. Following the header, the tape contains blocks of sectors copied from disk. When copying from tape to disk, the data in the header allows the MCP to restore the disk file with the same metadata attributes, although typically to different physical disk addresses.

WFL has a number of additional commands that are variations on COPY, including ADD, RESTORE, and ARCHIVE. Taken as a group, and including the CHANGE and REMOVE commands, this facility known as Library/Maintenance, a term that originated in the mid-1960s with the Burroughs B5500 MCP.

XE Backup Method 1: WRAP and UNWRAP

But, you say, MCP Express doesn't support tapes. Right. I told you about COPY so I could tell you about this next thing, WRAP. It works much the same way as COPY, but instead of copying MCP files and their metadata to tape, it copies them to an MCP byte-stream file termed a "wrapped container," which is conceptually equivalent to a Unix tarball.

From the MCP's perspective, a byte-stream file does not have records or blocks -- it is written just as one long stream of 8-bit bytes, or octets. Similar to a Library/Maintenance tape, the wrapped container has a directory listing the names of all its files, along with the disk header and sector data for each of those files.

The interesting thing about byte-stream files is that they can be transmitted transparently across a TCP/IP, SMB, or SSH connection and stored on almost any other type of file system, including Windows, Unix, Linux, and Mac OS X. If you transfer a wrapped container file to another type of system, then later it can be transferred back to the same or another MCP system and its files restored, just as those files had been at the time they were wrapped. Byte-stream files can also be stored on things like thumb drives, USB backup drives, CD/DVD-R disks, DropBox, or any other on-line storage service.

Unisys originally implemented wrapped containers in the mid-1990s primarily for software distribution, but they can also be used as a backup mechanism. There are a couple of issues with backing up to wrapped container files to keep in mind, however. The first is that you need to have sufficient disk space on your MCP system to create the wrapped container. For most XE users, that should not be a problem.

The second issue is that XE restricts the types of files that can be copied into a wrapped container. Unisys appears to have done this partly to inhibit the generation and distribution of malware, but also to inhibit the use of XE for professional and production purposes -- you did agree to an "educational and hobbyist" license, after all.

The restrictions most users need too worry about are object files and DMSII DESCRIPTION files. Object files can simply be recompiled, assuming you have the source, but DESCRIPTION files have critical timestamps and revision numbers to insure the schema they contain matches the corresponding DMSII software and physical data base files. That data is not possible to reproduce by simply recompiling the DASDL (schema language) source. There are ways around this, but they are messy and fraught with peril.

Thus, with the caveats noted above, backing up your MCP files using wrapped containers is a workable solution for most XE users. You can certainly copy and restore your source and data files, and most MCP configuration data, using this method. Then you can transfer that wrapped container to the Windows side of your XE host system (or some other system) and park it there until you have the new version of XE installed.

You create wrapped containers using the WFL WRAP statement. The syntax is similar to, but a subset of, that for the COPY statement. You can find the full syntax in the WFL reference manual, but the basic idea is this:

BEGIN JOB WRAP/TEST;
WRAP FILE/1, FILE/2, FILE/DIR/=, FILE/N FROM DISK
     INTO MY/CONTAINER TO DISK;
END JOB

The list of file names and directories following the WRAP command specifies the files to be backed up. The file name following INTO specifies the wrapped container file that will be created. To wrap all files from a usercode, you can simply do this:

WRAP (ADMINISTRATOR)= FROM DISK INTO WRAP/ADMIN/20200712 TO DISK;

WRAP will silently skip any files not permitted to be copied by XE. Since DISK is the default family name, the "FROM DISK" source and "TO DISK" destination family names are optional.

The wrapped containers can be transferred out of the MCP environment using FTP or by mapping a drive share to the MCP and using any of the Windows methods for transferring files from a shared directory. When using FTP, make sure you do a binary or image transfer.

To restore files from a wrapped container, you reverse the process. First, if necessary, transfer the container file back to the MCP file system. Then use the WFL UNWRAP command to extract the desired files from the container to the MCP file system. The basic form is this:

BEGIN JOB UNWRAP/TEST;
UNWRAP FILE/2, FILE/DIR/= TO DISK
     OUTOF MY/CONTAINER FROM DISK;
END JOB

The list of file names and directories following the UNWRAP command specifies which files will be extracted from the wrapped container. If you specify a file that is not in the container, the MCP issues a warning message and continues with the rest of the file names. The file name following OUTOF specifies the wrapped container file.

You need not unwrap all the files from the container -- you can select any subset of the container's files for restoration. As with WRAP, you can rename selected files and directories as you are unwrapping by using an "AS file name" clause after their names. If you are bringing a container file from another system, there is no restriction on the types of files you can restore, i.e., object code and DESCRIPTION files can be unwrapped using XE. When attempting to wrap or unwrap files from a different usercode, you generally need to be running under a privileged usercode.

XE Backup Method 2: Backup Express

Backup Express is a utility that Unisys supplies with XE. It uses a combination of disk shares, FTP, and wrapped containers to back up MCP files and transfer them to and from another system. It has a Windows GUI client and a server component that must be run from the MCP.

In my attempts to use this utility, I found that it was somewhat complicated to set up and had serious limitations, particularly that file names are limited to 33 characters (otherwise a fatal error occurs during the transfer) and it cannot transfer a directory of files when there is a file with the same name as the directory (something the MCP allows but almost no other file system does).

At its current level of development, I consider Backup Express to be too awkward and limited, and recommend that you not bother trying to use it.

XE Backup Method 3: Capture the Logical Disk Image File

This final backup method is the one I like to use when migrating to a new release of XE -- simply copy the whole Logical Disk image file.

This method has two main drawbacks: The first is that you must completely shut down the MCP while doing the copy -- either click the Halt icon in MCP Console or enter "POWER OFF SYSTEM" on the ODT and wait for all of the system components to go idle. The second is that you need to have at least 20GB available somewhere you can copy the disk image.

The main advantages of this method are that you capture everything that is on your MCP disk, and that you can do it entirely from the Windows side of your host system. A 20GB disk image is a lot to back up, but it should compress pretty well. If you don't have enough space on your host system, you could copy the image to a large thumb drive or a USB backup disk.

I mention this method in the context of migrating to a new release of XE, not so much as a backup mechanism, but as a way to preserve your entire existing MCP environment across the install of a new XE release and give you access to it after the new release is up and running.

Those who have been through one of these XE migrations before know that as part of installing a new release of XE, you must completely uninstall the current one. That uninstall permanently deletes the diskxxx.asd Logical Disk image file. So unless you take some preventative action before you start installing the new XE release, you will lose everything you had.

What I like to do before starting the new install, rather than copying the file, is simply move it to another folder. The process of uninstalling the current version of XE will silently ignore the fact that the diskxxx.asd file is no longer in XE's disk folder. The install will, of course, place a new diskxxx.asd file in that folder.

You should also rename the old disk image file, because we are eventually going to move it back into XE's disk folder. I suggest that you put a version number or a year in the name so that later you will be able to understand where it came from. For example, the current XE firmware is version 5.0 and has MCP 18, so I plan to rename my current diskxxx.asd file as DISK1850.asd. Something like DISK2019.asd would work well, too.

Where I am heading with this is that after the new XE release is installed, we will move that older disk image back into the XE disk directory and configure it as an additional MCP disk unit. Once we get the new version of the MCP running, we will be able to see that second disk, give it a different family name, and be able to access the files on that old disk. In particular, we will be able to copy files from the old disk to the new one, including object code and DMSII DESCRIPTION files. If you have the disk space to support two 20GB disk images, at least temporarily, this is in my experience a much easier way to move your files to the new release.

So, how do you accomplish all that? Stay tuned -- once I can get a copy of the new XE release and install it, I'll write a blog post on my experience with the new release and describe in detail how to get the old disk image configured and working.

There is one more piece of preservation you may wish to do before uninstalling the old version of XE. If you made changes to your ODT or MARC window configurations, you may wish to save those because they will also be deleted when the old version is uninstalled. In the folder C:\Program Files (x86)\Unisys\MCP\WebEnabler\, capture the ODT1.cfg, ODT2.cfg, and ODT3.cfg files.

July 31st is fast approaching, and hopefully you will not need to wait too much longer for both the new XE release and my next blog post.