Release Notes - THRUway V3.2.9
Copyright
2006 Software Partners, Inc. All rights reserved
Overview
|
Introduction |
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: |
|
Topic |
See Page |
New Features and Supported Platforms
|
Introduction |
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.
|
|
Introduction |
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.DISKS and/or THRUWAY_PSERVER · 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. |
|
Step |
Action |
|
1 |
Make sure that all THRUway connections have been TERMINATEd. |
|
2 |
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). |
|
3 |
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: $ THRUWAY OPCOM/STOP |
|
4 |
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. |
|
Step |
Action |
|
5 |
Load the distribution media. |
|
6 |
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. |
|
7 |
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. |
|
8 |
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. |
|
9 |
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
|
10 |
Define the THRUWAY symbol (if not already defined). $ THRUWAY :== $THRUWAY |
|
11 |
Create the THRUWAY_TCPIP.PROXY file to enable connections between OpenVMS nodes using TCP/IP. |
|
12 |
Either 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. |
|
13 |
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. |
|
Step |
Action |
|
1 |
Start THRUway system-wide disk connections by typing: $ @diskname:[twhomedir]THRUWAY
SYSTARTUP DISKS= -
(FILE=THRUWAY.DISKS, LOG=log_file, - |
|
2 |
Start the THRUway print server by typing: $ @diskname:[twhomedir]THRUWAY
SYSTARTUP PSERVER= -
(LOG=log_file, PRIO=priority, - PROC=process_name) |
|
3 |
Start the OPCOM process by typing: $ @diskname:[twhomedir]THRUWAY
SYSTARTUP OPCOM= - (LOG=SYS$MANAGER:THRUWAY_OPCOM.LOG) |
|
4 |
Your system is set up for THRUway operations. |
|
$ @sys$update:vmsinstal
OpenVMS AXP Software Product Installation Procedure V7.3-2 It is at any time for help. %VMSINSTAL-W-ACTIVE, The following processes are
still active:
TCPIP$PORTM_1
TCPIP$FTP_1 * 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: THRUWAY
V3.2
Beginning installation of THRUWAY V3.2 at %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.
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 root. %VMSINSTAL-I-SYSDIR, This product creates system
disk directory IAGO$DKA0:[THRUWAY]. %CREATE-I-EXISTS, IAGO$DKA0:[THRUWAY] already
exists %VMSINSTAL-I-SYSDIR, This product creates system
disk directory
IAGO$DKA0:[THRUWAY.ALPHA.V731]. %CREATE-I-EXISTS, IAGO$DKA0:[THRUWAY.ALPHA.V731]
already exists 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
GET_VMS_VERSION.com provided %THRUWAY-I-PROVIDED, New version of GET_SADRIVER_VERSIONS.com
provided %THRUWAY-I-PROVIDED, New version of
LOAD_SADRIVER.com provided %THRUWAY-I-PROVIDED, New version of
CHECK_SA_VMS_VERSION.exe provided %THRUWAY-I-LINKING, Linking THRUWAY.EXE %THRUWAY-I-LINKING, Linking THRUWAYMES.EXE %THRUWAY-I-LINKING, Linking
IDENTIFY_THRUWAY_BUILD.EXE %THRUWAY-I-LINKING, Linking THRUWAY_LOADABLE.EXE %THRUWAY-I-LINKING, Linking THRUWAY_DECNET.EXE %THRUWAY-I-LINKING, Linking THRUWAY_TCPWARE.EXE Your VMS
system will now be updated to include the following files (in addition
to any SADRIVER files previously listed):
IAGO$DKA0:[THRUWAY.ALPHA.V731]THRUWAY.exe
IAGO$DKA0:[THRUWAY.ALPHA.V731]THRUWAY_LOADABLE.exe
IAGO$DKA0:[THRUWAY.ALPHA.V731]IDENTIFY_THRUWAY_BUILD.exe . . . IAGO$DKA0:[THRUWAY]THRUWAY_MESSAGES.TXT
IAGO$DKA0:[THRUWAY]THRUWAY_MESSAGE_HELP.TEXT
IAGO$DKA0:[THRUWAY]THRU_DIAG_LOGS.COM
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 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. |
Location of THRUWAY_TCPIP.PROXY file |
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. |
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. |
THRUWAY_TCPIP.PROXY |
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. |
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). |
SADRIVER change |
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
check_for_stack.com, 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. |
SADRIVER change |
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. |
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. |
THRUWAY_LOGS |
All THRUway logfiles are placed in the new THRUWAY_LOGS directory (consistent with behavior of TAPESYS and JB). |
THRUWAY_TCPIP.PROXY |
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. |
CONNECT /READ_ONLY |
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. |