Release Notes - THRUway V3.2.9

Copyright 2006 Software Partners, Inc. All rights reserved





These release notes contain


  detailed procedures for upgrading to THRUway V3.2.9 from any existing version of THRUway, and


  enhancement and bug-fix information.


Questions or Problems

Please call Software Partners if you have any questions or comments about this new version of THRUway or if you have problems with the upgrade procedure.


Note:  For information on bug fixes prior to V3.2, please call Software Partners Customer Support at (978) 887-6409.


Table of Contents

The following topics are covered in the release notes:



See Page

New Features and Supported Platforms


Upgrade Procedures


Sample Installation/Upgrade


THRUway, Backups, and Account Quotas


Problems fixed in V3.2.1


Problems fixed in V3.2.2


Problems fixed in V3.2.3


Problems fixed in V3.2.4


Problems fixed in V3.2.5


Problems fixed in V3.2.7


Modifications/Problems fixed in V3.2.9



New Features and Supported Platforms



This section describes new features, supported platforms, and product compatibility with THRUway V3.2.x.


Supported Platforms

THRUway V3.2.x supports the following platforms:


  OpenVMS for VAX V6.2 through V7.3

  OpenVMS for Alpha V6.2 through V8.2


TCP/IP Support

THRUway V3.2.x supports the following TCP/IP packages:


  MultiNet V4.0b through V4.4

  PathWay for OpenVMS V3.1 and V3.5

  TCPware for OpenVMS V5.1 through V5.6

  TCP/IP Services for OpenVMS V4.2 through V5.3


Changes in V3.2.0

Changes for THRUWAY V3.2.0:


  1) The product key checking has been modified to use the new key format, which allows multiple SPI products in a single key.


  2) THRUway files have been taken out of sys$system. The system manager may now place them off the system disk if desired. This makes it much easier to have a single installation for multiple systems, including multiple architectures (VAX/Alpha/IPF) by installing on a shared disk. In this case, the installation needs to be done once per architecture and VMS version combination.


  3) The THRUway loadable image is now copied into sys$loadable_images upon startup.


  4) Many THRUway components have been repackaged to share code with other Software Partners products, providing consistency.


  5) Redundant code in the THRUway TCP/IP command procedures has been eliminated. THRUway now uses one common command procedure for all TCP/IP stacks.




 6) Support is now provided for more modern versions of Compaq TCP/IP. For instance, all processes are now prefixed with “TCPIP” instead of “UCX.” Support for the old UCX is still in the product, but this support should not be specified at installation unless one of those old versions is actually running on the customer system.


  7) Code has been added to intercept interfaces that are not really available. Even though multiple TCP/IP stacks can be physically installed on a system, only one can actually be active during a particular boot. Pre-3.2 versions of THRUway would create the transport list based entirely on the presence of the THRUWAY_<transport> command procedure(s), even if said procedures were residue from an earlier time when a different stack was used on this system. THRUway would place these inactive stacks in the transport list and would attempt to start the servers. This was a particular problem with UCX, since all of the other stacks emulate UCX.

   THRUway would think UCX was actually present when it wasn’t. This would only have become worse with the new shared-root version of THRUway, because different machines could be using different stacks. Therefore, all THRUway instances would have attempted to start servers for all stacks used anywhere in the cluster. Of course, the servers could not actually start, but the log files would accumulate.


8) The installation kit has been restructured for faster install. Only code that is VMS version–dependent is compiled at installation time.


Upgrade Procedures



This section describes the procedure to upgrade and set up your system for THRUway V3.2 operation.


Note:  This section provides basic upgrade guidelines. Please refer to

Chapter 2 in the THRUway Operation Guide V3.2 for more detailed information that may be useful in your upgrade.


If you are upgrading from THRUway V3.1.x, you will need a new key. Please call Software Partners at 978-887-6409.




Before beginning the upgrade

If the following processes are running on your system, they must be terminated. This may be accomplished by using the steps in the table below.


·        THRUWAY_tcpip, where “tcpip” is the name of your TCP/IP package

·        THRUway processes with names like “<nodename>$<diskname>” or “<nodename$tw_dev_name>” (i.e. “SAFE1$SBC1”)


If THRUway is not running on your system, proceed to Step 4 and continue with the upgrade/installation procedure.





Make sure that all THRUway connections have been TERMINATEd.


Note the process identification numbers for

  the parent process (usually called THRUWAY.DISKS),

  the print server (called THRUWAY_PSERVER),

  the OPCOM server (called THRUWAY_OPCOM), and

  the TCP/IP process (called THRUWAY_tcpip).


Stop each of the above processes by typing the following (for each process):

$ stop/ID=process_id


Stop the THRUWAY_OPCOM by typing the following:




Proceed to the next step to upgrade THRUway.


Continued on next page

Upgrade Procedures, Continued


Upgrade Procedure

The table below describes how to perform the upgrade.






Load the distribution media.


Run VMSINSTAL. Take the defaults when prompted, with the exception of

1) the top-level root for THRUway – either the default ([THRUWAY] on the system disk) or another directory may be chosen

2) the virtual device driver

  the default is SA.

  if SA has been used previously, rename the virtual device driver to SB, SC, etc. The same two-letter template cannot be layered over itself.


Note:             If using the same two-letter template for the virtual

                     device driver, a system reboot is required.


If choosing DECnet support during the installation, there will be a prompt for a network object number. The default is 140. Any network object number may be used, but the object number must be the same on all nodes running THRUway.


Note:       The network object number cannot be 0 (zero) if using

               DECnet Phase V.


If choosing support for a TCP/IP package, there will be a prompt for a master socket number. The default is 42269. Either the default value or another socket number not currently in use may be specified.


If choosing support for HP’s TCPIP product, there is now an option to support older versions of the product (known as UCX). Specify “Y” to install support for earlier versions of this product or “N” to continue with the upgrade.


Continued on next page

Upgrade Procedures, Continued



Define the THRUWAY symbol (if not already defined).




Create the THRUWAY_TCPIP.PROXY file to enable connections between OpenVMS nodes using TCP/IP.



  verify that proxy access is set up between all nodes running THRUway, or

 use "user password" in any THRUWAY CONNECT or THRUWAY PRINT commands and/or in the THRUWAY.DISKS file.


NOTE: THRUway now has a new key format/mechanism. The default location for the key is in THRUWAY_HOME as THRUWAY.KEY. However, a “central” key directory can be created, referenced by a logical such as SP32_KEY_DIR, and populated with a Software Partners key that is valid for several products. For example, create a top-level directory named SP32_KEY and then define a logical to point to it.


"SP32_KEY_DIR" [super] = "diskname:[SP32_KEY]"


Then edit the file SP32_MASTER.KEY in the new directory and populate it with the contents of the key file provided with the product.


Individual product keys can also be stored in the common directory rather than in the various product directories. Thus, one master key may exist in the common directory, individual product keys in the common directory, or individual keys in the product directories.


The product searches for a key in the following order:

1.  <normal-product-key-dir>:<product>.key

2.  sp32_key_dir:<product>.key

3.  sp32_key_dir:sp32_master.key


Upgrade Procedures, Continued


Setup Procedure

The table below describes an optional setup procedure.





Start THRUway system-wide disk connections by typing:


$ @diskname:[twhomedir]THRUWAY SYSTARTUP DISKS= -

  (FILE=THRUWAY.DISKS, LOG=log_file, -


Start the THRUway print server by typing:


$ @diskname:[twhomedir]THRUWAY SYSTARTUP PSERVER= -

  (LOG=log_file, PRIO=priority, -



Start the OPCOM process by typing:


$ @diskname:[twhomedir]THRUWAY SYSTARTUP OPCOM= -



Your system is set up for THRUway operations.


Sample Installation


$ @sys$update:vmsinstal


      OpenVMS AXP Software Product Installation Procedure V7.3-2

It is 23-JAN-2004 at 14:18. Enter a question mark (?)

at any time for help.


%VMSINSTAL-W-ACTIVE, The following processes are still active:




* Do you want to continue anyway [NO]? yes

* Are you satisfied with the backup of your system disk [YES]? <cr>

* Where will the distribution volumes be mounted: SAFE1$DKA200:[THRUWAY_SETS]


Enter the products to be processed from the first distribution volume set.

* Products: thruway032

* Enter installation options you wish to use (none): <cr>


The following products will be processed:


      Beginning installation of THRUWAY V3.2 at 14:19


%VMSINSTAL-I-RESTORE, Restoring product save set A ...

%VMSINSTAL-I-RELMOVED, Product’s release notes have been moved to SYS$HELP.


                Installation of THRUWAY V3.2.4 - Remote Mass Storage Access

        Copyright (C) 1990, 2000 Software Partners, Inc.  Topsfield, MA  USA

                              978-887-6409    All rights reserved.


* Do you want to purge files replaced by this installation [YES]? <cr>

* Enter the name of the device to put THRUWAY on [IAGO$DKA0:]: <cr>

* Enter the name of the top-level root for THRUWAY [THRUWAY]: <cr>


This product accesses constructs in system space and must therefore be linked

to a particular version of VMS.  You can still have a common root on a shared

disk, which may or may not be a system disk, but each combination of VMS

version and architecture will have a separate directory for its executables.

Therefore you must install the product for each architecture/version

combination.  Also, if you upgrade VMS on a node, you must reinstall the

product unless you have already installed that version/architecture in that



%VMSINSTAL-I-SYSDIR, This product creates system disk directory IAGO$DKA0:[THRUWAY].


%VMSINSTAL-I-SYSDIR, This product creates system disk directory  IAGO$DKA0:[THRUWAY.ALPHA.V731].



    Mixed VAX and Alpha VMSclusters


This system is part of a VMScluster.  If the cluster includes both VAX and Alpha systems that will share the same set of THRUWAY directories and configuration files, the installation needs to be run separately for each architecture.


    Also, the product must be installed for each version of VMS, due to

    dependencies on VMS internal structures that can change from version to

    version.  Therefore the product must be installed for each combination of

    architecture and version.


(If the systems are in a cluster, but will use different THRUWAY roots, answer NO to the following question.  You will need to perform a full installation to the other root(s) separately.)


* Does this VMScluster include both VAX and Alpha systems or multiple VMS versions of either architecture [NO]? yes


It is not necessary to install the non-binary files (files other than .obj and .exe) more than once, since these are identical between architectures and VMS versions.  Therefore, the first installation to a root should be a full installation, the others may be binaries only.


If this is the first installation to this root, reply FULL.  If you have already performed one installation to this root, and want to install just the objects and/or executables, reply BINARIES (or just B).  Any response not starting with B will cause a full installation.


* Should this installation be FULL or BINARIES-ONLY [FULL]: <cr>

This Software Partners product uses the SADRIVER virtual device.  You need to specify the device name prefix for the virtual devices, if you want a prefix different from the default.


        Note: if you are sharing a common product root with multiple versions

        of VMS or the same version of VMS but multiple architectures (VAX or

        Alpha or IPF), they must all have the *same* prefix.  This is because

        the command procedures must be aware of the driver prefix, and these

        are shared.  The product installation must be performed for each

        version and architecture combination, and the same prefix must be

        used for each installation.


* Two character name of virtual device driver [SA]: SB

* Do you want to include DECNET support [Y]? <cr>


We will now set the DECNET object number for THRUWAY.  In the past, the

default for this has always been zero.  However, OpenVMS Alpha 7.1 (DECnet

Plus, really) by default does not like zero object numbers and connections

cannot be made if they are used.  Therefore, the default object number has been changed to 140.


The important thing to remember is that the object number must be the same for all nodes running THRUWAY.  In addition, the object number chosen must not be in use on any of the nodes or a conflict will occur trying to connect to that machine.  The currently active object numbers can be displayed with "mcr ncp show known object".  Do this on all machines and use a number between 128 and 255 that does not appear on any of them.


You may continue using object 0 if you do not have any machines running

DECnet Plus, especially on OpenVMS Alpha 7.1 or later.


* Network object number [140]: <cr>

* Do you want to include TCPWARE support [Y]? <cr>


A TCP/IP stack has been selected, so a master socket number must be specified.


* Master socket number [42269]: <cr>

* Do you want to include Compaq TCPIP (formerly UCX) support [Y]? no

* Do you want to include UCX (4.x or earlier) support [Y]? no

%VMSINSTAL-I-RESTORE, Restoring product save set B ...

%THRUWAY-I-PROVIDED, New version of SBDRIVER.exe provided

%THRUWAY-I-PROVIDED, New version of SBDRIVER.OLB provided

%THRUWAY-I-PROVIDED, New version of SBDRIVER.STB provided

%THRUWAY-I-PROVIDED, New version of SBDRIVER.DSF provided

%THRUWAY-I-PROVIDED, New version of provided

%THRUWAY-I-PROVIDED, New version of provided

%THRUWAY-I-PROVIDED, New version of provided

%THRUWAY-I-PROVIDED, New version of CHECK_SA_VMS_VERSION.exe provided








    Your VMS system will now be updated to include the following files (in

    addition to any SADRIVER files previously listed):





. . .





                Installation of THRUWAY complete


    Please read any SYS$HELP:THRUWAYnnn.RELEASE_NOTES files.

    Refer to the THRUWAY installation guide for further instructions.


    Add the following line to your SYSTARTUP.COM file:


        $ @IAGO$DKA0:[THRUWAY]thruway systartup


    See THRUWAY documentation for more details on the above command line.


%VMSINSTAL-I-MOVEFILES, Files will now be moved to their target directories...

        Installation of THRUWAY V3.2 completed at 14:24


    Adding history entry in VMI$ROOT:[SYSUPD]VMSINSTAL.HISTORY


    Creating installation data file: VMI$ROOT:[SYSUPD]THRUWAY032.VMI_DATA

THRUway, Backups, and Account Quotas


Minimum Suggested Quotas

THRUway is commonly used to backup remote systems, in conjunction with TAPESYS or simply with VMS BACKUP. When performing backups in this manner, it is important to adjust account quotas and system parameters on both the client and server ends of the THRUway connection. Tuning THRUway backup accounts properly prevents erratic backup behavior, such as hanging THRUway connections.


The following are suggested minimums for THRUway backup account quotas. Please note the use of the word suggested. These quotas will not be sufficient for every THRUway connection serving every backup on every OpenVMS machine, but should serve as a good starting point for system administrators preparing their OpenVMS systems for using THRUway for efficient backups of remote disks (or backups of local disks to remote tape drives). The suggested minimums are:


Rule of thumb: An account’s FILLM value should never exceed the system’s CHANNELCNT value.


Fillm - 1200

Diolm - 4096

Astlm - 4608

Biolm - 1200

Bytlm - 331776

Enqlm – 2048


A CHANNELCNT value of 1500 or higher is suggested to accompany the above recommendations. Keep in mind that CHANNELCNT is not dynamic; any changes to it must be followed by a reboot of the system.


Consult the OpenVMS documentation set for more complete tuning suggestions.


Problems Fixed in V3.2.1


Location of THRUWAY_

THRUway was not looking for the file THRUWAY_TCPIP.PROXY in the new THRUWAY_HOME directory; instead, it was still looking in SYS$SYSTEM (the location of most THRUway files under V3.1.x).


This has been fixed.


Linking under VMS V6.2

THRUway would not link under VMS V6.2.


This has been fixed.


Linking with VAX and TCPware

THRUway would not link with VAX when TCPware was in use as a TCP/IP package.


This has been fixed.


Problems Fixed in V3.2.2


Failure in using TCP/IP packages as transport protocol


In the THRUway TCP/IP command procedures, parameters were used to pass stack specific information. This caused the THRUWAY_tcpippackage process to fail to start, since these parameters were already being used for other purposes. Symbols are now created in the calling procedure instead.



During startup, the .proxy file is now copied from SYS$SYSTEM to THRUWAY_HOME if the file is found in the former location but not in the latter.


Length error in command line

A length error occurred in DCL when detaching the THRUway TCP/IP server process.


This has been fixed.


Problems Fixed in V3.2.3


Error output when key logical is missing

The error output when the THRUway key logical could not be found was too vague: “Unable to translate logical name.” A specific error message indicating that the key could not be found is now displayed if the key logical is missing.


TCP/IP node name different than VMS node name

THRUway now handles the case where a site uses a TCP/IP node name that is different from the VMS node name. This new override is controlled by the logical BYPASS_TCPIP_NODE_CHECK. This logical should be set to 1 before starting THRUway if the TCP/IP and VMS node names are not the same.


Wrap-around diags introduced

A mechanism has been created for wrap-around diag. In many cases, a huge amount of diag is created, and only the diag at the very beginning and at the very end is really needed. Therefore, the diag system has been enhanced to allow wrap-around diag. A set number of lines can be specified, and the diag will never exceed this limit, no matter how much diag is generated. When the max line count is reached, a wrap occurs and the diag lines are written at the beginning of the file, overwriting the previous diag. When wraparound is in effect (triggered by a logical name), only the last n lines are present in the diag (n being specified in the logical name definition). This should be used only in special cases (such as situations where enabling full diags would create logfiles that might fill the target disk).



Problems Fixed in V3.2.4



A bogus function code has been added to SADRIVER so that virtual devices can be identified. Using this, TAPESYS can now determine whether it is talking to a virtual tape drive (like a THRUway device) or a real device, and then respond accordingly. For instance, if a THRUway disk dies, sysbak will now say "failure of virtual device" instead of the "file not accessed on channel" error that has caused so much confusion in the past.


UCX issue

In, THRUway now forces the show connection verb into uppercase format. This is contained within a logical name. THRUway translates the logical, extracts the verb, and matches it with the string "UCX". This worked perfectly with the version of ucx used during development. But under unknown conditions, the verb appears as lowercase "ucx" on some systems. So the verb is now forced to uppercase to guarantee a correct match.


Initial itanium changes

Initial changes to support itanium have been made. All occurrences of "if alpha" have been changed to "if not vax", and occurrences of "if not alpha" have been changed to "if vax". Since itanium and alpha are mostly code compatible, this is sufficient for the bulk of the code.



Problems Fixed in V3.2.5



In a past version of THRUway V3.2.X, SADRIVER was modified to return "%SP32-F-VIRT_DEV_FAIL, there has been a failure of the virtual disk or tape drive; control process has abnormally terminated" instead of the original "file not accessed on channel" when the client process dies.


However, it appears that the io$_deaccess performed during sys$dassgn explicitly checks for the original code and absorbs it. Of course, io$_deaccess does not recognize the SP32 code above and passes back to the rundown procedure, which causes a system crash during the kernel rundown.


Therefore, SADRIVER has been modified to return the original code if the function code is io$_deaccess.


THRUway itself is not changed at all for this version, just the SADRIVER embedded within it.


Problems Fixed in V3.2.7


ACCVIO on SHOW DEVICE and system crash

With certain VMS patch levels and configurations of OpenVMS Alpha

V7.3-2, THRUway is successful in making a connection, but a SHOW DEVICE Snx command on the local side of the newly-created virtual device yields an ACCVIO.


In similar situations, a THRUWAY CONNECT may yield a system crash. This crash involved accessing the DEV$M_VRT bit. The problem has been solved by turning off this bit in THRUway.



Modifications/Problems Fixed in V3.2.9


Compatibility with Alpha OpenVMS V8.2


THRUway is now compatible with Alpha OpenVMS V8.2 as of V3.2.9.



All THRUway logfiles are placed in the new THRUWAY_LOGS directory (consistent with behavior of TAPESYS and JB).


The THRUWAY_TCPIP.PROXY file, which gives remote accounts access via THRUway, is now saved during upgrades, so users do not have to recreate it.



In THRUway server processing, THRUway now aborts a connection if the client node has been designated as a read-only node and the connection was not made with /READ_ONLY.


Diagnostic improvements

THRUway now contains the capability of aborting a connection if the connection sits idle for a specified period of time. Also, kernel trace capability is now included in the product.