TAPESYS® V6.2.3—Release Notes

Copyright ©1983 - 2008 Software Partners, Inc. All rights reserved.





These release notes are for Software Partners customers and others who are upgrading to TAPESYS V6.2 from any previous version.


Topics covered include:


·        Upgrade (or New Installation) Instructions

·        New Features

·        Modifications


Questions or problems

Please email or call Software Partners, Inc. if you have any questions or comments about this version of TAPESYS. Our email address is tech_support@softwarepartners.com, and our telephone number is



Supported platforms

TAPESYS V6.2.3 supports the following platforms.


·        OpenVMS for VAX V6.2 - V7.3.

·        OpenVMS for Alpha V6.2 – V8.3.

·        OpenVMS for Integrity V8.2 – V8.3-1H1.


In this document

The following table lists the topics covered in the following pages.




See Page



Upgrading from TAPESYS V5.2.X to V6.2.x




Upgrading from TAPESYS V6.1.x




Installing TAPESYS v6.2.x




New Features in V6.2.x




Modifications in V6.2.1




Modifications in V6.2.2




Modifications in V6.2.3




Upgrading from TAPESYS V5.2.x to V6.2.x



This section details the procedure for upgrading TAPESYS to V6.2.x.



Please take time to read through each step in this procedure before actually performing the upgrade/installation. Performing this upgrade in any way other than the prescribed manner could result in problems.


Upgrade path

To upgrade to V6.2.x, you must be running TAPESYS V5.2.x or higher.


Before you begin…

Prior to performing the upgrade procedure, you MUST delete all pending TAPESYS backup jobs from your queues. These jobs are dependent upon procedures and executables from the previous TAPESYS version and will not execute properly.


The table below details how to delete these jobs.





Check the batch queues for pending TAPESYS jobs. Use the following command to check for existing jobs:


If there are NO TAPESYS jobs present go to Step 3.


If TAPESYS jobs are present, delete them with the following command:

  $ DELETE/ENTRY=<entry_#>

where <entry_#> is the TAPESYS batch job entry number.


Shutdown TAPESYS by issuing the following command:


where <disk> is the disk device where TAPESYS is installed.

Result:  The TAPESYS manager processes will shutdown. 


After shutting down TAPESYS, deassign the following logicals:



Proceed to the installation on page 5.

Upgrading from TAPESYS V6.1.x

If you are currently running V6.1.x:

If you are currently running TAPESYS V6.1.x, you should use the following instructions:






Back up your current TAPESYS V6.1 tree.


Bring down TAPESYS on all nodes using this TAPESYS root.


Rename the file tapesys_6r1.dir to tapesys_prod or something similar.


Change the UAF accordingly, and issue a DEASSIGN/SYS/EXEC for the logical TAPESYS_ROOT. Also, do a SHOW LOGICAL TAPESYS_RUNTIME_ROOT; if the value for this logical is not the directory specified above in step 3, deassign this logical as well.


Do an install of TAPESYS V6.2, overriding the default top-level directory spec of [tapesys_6r2] to be [tapesys_prod] (or the other name you chose in step 3 above), so that TAPESYS V6.1 is overlaid.


Issue the command




replying “no” to all questions except for forcing a relink. Make sure that this is done on the lowest version of VMS for the architecture.


Restart TAPESYS on the lowest VMS version node for each architecture using the same root, specifying the full disk and (new) directory spec (for example, @diskname:[TAPESYS_PROD.SYSTEM]STARTUP).


Restart TAPESYS on other nodes after links complete.


Check for command procedures in [custom], compare with possible new versions and merge the changes. Try to get rid of command procedures that replace official procedures if possible. The functionality may now be provided by base TAPESYS, or it may be possible to use pre/post process.





There is no need to move files, since you will be running in the same root tree as before.



Installing TAPESYS V6.2.x


Installation Procedure

The table below details the steps followed when installing TAPESYS V6.2.x.







Unpack the TAPESYS savesets using the following command:


$ @SYS$UPDATE:VMSINSTAL TAPESYS062 <disk:[dir]> <options>

where <disk:[dir]> is the location of the TAPESYS V6.2.x savesets (usually disk:[TAPESYS.KIT]) and <options> are valid options for the VMSINSTAL procedure. An example option is awd=<optional_working_directory>, where <optional_working_directory> is an alternate temporary storage space for the install procedure.

TAPESYS V6.2.x will then be installed.




After installing TAPESYS, issue the following command:


$ @<diskname>:[<dirname>.SYSTEM]CONFIGURE_TAPESYS

where <diskname> is the disk device on which TAPESYS V6.2.x is installed, and <dirname> is the name of the top-level TAPESYS V6.2 directory (such as TAPESYS_PROD or TAPESYS_6R2).


Configure_tapesys consists of several parts, described briefly on the following page. For a more detailed description of configure_tapesys please see the TAPESYS V6.2 Installation Guide.




Installing TAPESYS V6.2.x, Continued




Name of Procedure



Converts the former TAPESYS database to v6.0 format.


Sets up TAPESYS accounts.


Grants the TAPESYS_USER identifier to the accounts specified.


Brings over histories, summaries, and media records from a previous installation of TAPESYS.


Allows interactive customization of SETUP.PAR to the user’s specifications.


Sets the correct protections on all TAPESYS files as needed.


Checks to see if the TAPESYS executables need to be relinked.


Performs the TAPESYS relink if needed.


Removes the TAPE verb from DCLTABLES.EXE. Optionally updates system help libraries with the modified TAPESYS help library.


Optionally places the key file on disk in the proper location.



New Key Mechanism

NOTE: The default location for the key is in TAPESYS_PARAMS as TAPESYS.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. (If you have already set up your key file during the CONFIGURE_TAPESYS procedure, further action is not required.) 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 may 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

Installing TAPESYS V6.2.x, Continued





After CONFIGURE_TAPESYS has completed successfully, issue the following command to start TAPESYS V6.2:


$ @diskname:[<dirname>.SYSTEM]STARTUP


If you have TAPESYS V5.2 histories that you want to convert to V6.2, issue the following command while TAPESYS V6.2 is running:




Follow the prompts to create a SBATTR.COM file and to convert the histories to V6.2 format.


Warning! The conversion of TAPESYS histories from V5.2 to V6.2 can be a lengthy process. To determine how much time might be required, users may choose to convert the histories into a temporary tree and keep track of how long the procedure will take for a given history set. Another option is to “test-convert” each history set separately (using the same target temporary directory over and over as needed). The correct amount of time can then be scheduled for the actual conversion to the correct directory location.


The history conversion from V5.2 to V6.2 does not have to be done all at once. The only requirement is that each history set must be converted before any SYSBAK job tries to write to that set. One possible scenario would be to convert the daily histories first, since these would typically be needed first. The conversion of any weekly history sets from V5.2 to V6.2 might be less urgent, since there may be several days before the next weekly backup. (For this reason, it may be advisable to schedule the upgrade/conversion immediately after a weekly backup.) The same situation would be true with monthlies, annual backups, and infrequent archiving backups.


Users should examine the new DROP_DIRECTORIES and DROP_SYS_FILES parameters in SBATTR.COM, since these can drastically reduce the size of daily or any other incremental backups. Many incremental backups consist mostly of directories, especially for a disk that is not very active, and the DROP_DIRECTORIES parameter can prevent those from going into the history. This doesn't have much impact on the conversion time, since the old file still has to be scanned, but it does save some time.


Installing TAPESYS V6.2.x, Continued





Quite a few sites appear to be using node-specific media type instances. For instance:


$  MTYPE_4  := DLT

$  DENS_4   :=

$  DRIVES_4 := MKA500





or some variation thereof. This was the proper way to do things under the old system, but it doesn't automatically transfer to the new system, which doesn't use these symbols at all. The media types are now part of the main database and are manipulated with TAPE OPER commands.


It would be extremely difficult for the conversion to handle this node-specific code, since it requires parsing of DCL syntax, and there are several different syntax variations that could be used.


On the other hand, doing it manually is very easy and straightforward. You basically examine your old SETUP.PAR (not the converted SETUP.PAR in the 6.x directory, since the DCL has been stripped by the conversion) and add a node-specific media type instance to the media type database for each node involved, using the /node qualifier of the TAPE OPER ADD/MEDIA command.


Note that this only has to be done for node-specific instances. The basic media type symbol groups are converted to the media type database by the conversion. The basic instance above (without the if statements) would already be in the database, as if added with




The commands to add the node-specific instances above would be:





Just go through your old SETUP.PAR and do this for each media

Installing TAPESYS V6.2.x, Continued





type that has node-specific entries.


This should be done as the very last phase of the conversion, after the new TAPESYS has been started. V6.2 allows the media type table to be changed dynamically, unlike the old system. The node-specific media type instances can be added at any point, as long as it is before a sysbak on that node tries to use the media type.


SPI now requires that users remove the TAPE command from DCLTABLES and NOT append in the latest TAPE command set. You will be prompted to remove the TAPE command from DCL tables in CONFIGURE_TAPESYS. Instead, the TAPE command is implemented as a foreign command. The following code should be placed either in individual LOGIN.COM files (for those users who should have access to TAPESYS) OR in SYLOGIN.COM (if all users are allowed to use TAPESYS) to define the TAPE command for users:




New Features in TAPESYS V6.2



TAPESYS V6.2 has new features that will enhance its superior media management and backup/restore utilities in the OpenVMS environment. These include:


o       Compatibility with OpenVMS on Integrity


o       Compatibility with AXP OpenVMS V8.X


o       More efficient format for history update files



Modifications in TAPESYS V6.2.1


Listings from SYSOLDTAPE.BIS


SYSOLDTAPE.BIS can now create a listing file of the saveset being accessed.

Additional information in summary files


TAPESYS summary files now include the actual backup command issued to create the saveset(s), including those for RMU backups.

Change to MAINT menu

When one now adds multiple tapes in TAPESYS using option 2 of the MAINT menu, “Enter new tape(s),” an informational message is output that displays the last tape added.


SLS conversion support

TAPESYS now includes full support for conversion of SLS database files to TAPESYS format.


.PAR files retained longer

SYSBAK .PAR files (not to be confused with SETUP.PAR) are now retained for four days instead of only one, since longer backups could be impacted if these “active” files are deleted while the jobs are running.


Output added for VMSBU


During the run of VMSBU, TAPESYS now outputs VMSBU phase change messages (verifying, recording, deleting) with timestamps.

TOPERS in .SBK files

TAPESYS now allows opcoms to be directed to a specific operator class for a particular SYSBAK job. Use of TOPERS in a .SBK file overrides the value of TOPERS in SETUP.PAR.



Modifications in TAPESYS V6.2.1, Continued


No defaults for PRIMAST and SECMAST

The original defaults for PRIMAST and SECMAST in SETUP.PAR do not work in all node configurations. Too many users suffered confusion and data corruption by simply using the defaults. Therefore, there is no longer a default for these parameters in SETUP_SHIPPED_VERSION.PAR. The customer must explicitly set PRIMAST and SECMAST in SETUP.PAR. Specifically, TAPESYS_ROOT should not be used in the definition when the primary and secondary masters are using different TAPESYS roots. This could be because they are not in the same cluster and therefore pri and sec cannot share a disk, or because they were installed into separate roots for some other reason. See the commentary in SETUP_SHIPPED_VERSION.PAR.




SBUPDT (history) processing would fail when there were two tapes in the history update file, which is a result of using TSHAD. This has been fixed.




In TAPE REPORT/MASTER, TAPESYS now does a hard abort when direct database access fails, instead of falling back to TAPE INQUIRE mode as in the past. Sorting is handled differently in the two modes: If you just switch without reinitializing everything, the sorting can get dropped. Also, if the failure occurs in the middle of the file instead of when trying to open it, the records before the failure will be listed twice, since the second scan starts again at the beginning. In this case, the user must reissue the TAPE REPORT/MASTER command again without /DIRECT.



The SHUTDOWN procedure attempts to use the preferred lock manager method, basically telling DB and RQ to shut down rather than be killed. However, if the process calling SHUTDOWN does not have SYSLCK, this cannot be done. The kill process then falls back to two different system services, with long waits in between to make sure that the prior operations completely finish. This results in SHUTDOWN taking a long time. While much of TAPESYS can be done by ordinary users holding the TAPESYS_USER identifier, and TAPESYS management functions can be done by users holding certain other TAPESYS identifiers, TAPESYS installation, STARTUP, and SHUTDOWN should be performed from an account with privileges equivalent to the VMS system manager. In SHUTDOWN.COM, SYSLCK has been added to the list of required privileges. If SYSLCK is not present or can't be added, TAPESYS now aborts the SHUTDOWN attempt.


Modifications in TAPESYS V6.2.2


RMU backups

Fixed problem with RMU backups where reel was missing from history.


Change to LOADER.COM

In loader, when starting the tape processing batch queue, TAPESYS now uses batn instead of batq in the SET QUEUE command in case the user has changed qualifiers since the INIT/QUEUE was done.


Change in MSTRPT

In MSTRPT, when no date range and /whole_days, set "to" date to "from" date instead of "9999".



FILE_ACC must now be specified

The original default for TRANS_FOR_FILE_ACC in setup does not work in all node configurations. Too many customers had database access problems and unnecessary overhead by using the default. Therefore, there is no longer a default for this parameter in SETUP_SHIPPED_VERSION.PAR. The customer must explicitly set TRANS_FOR_FILE_ACC in SETUP.PAR. See the commentary in SETUP_SHIPPED_VERSION.PAR.


New timestamp feature

Customer requested that DB timestamp messages be suppressed. This will be done if TAPMGR_NO_STAMP_MSG is defined at the system level.




A new BACKUP_CHECK_DAYS parameter has been added to SETUP.PAR so that users can specify a different number of days to check for in CHECK_FOR_BACKUPS. Disks that have not been backed for this many days are flagged.



A new parameter, ALLOCDRIVE_ASSIST, has been added to .SBK files. This allows users to specify /ASSIST on the TAPE SELECT command inside ALLOCDRIVE.COM. For more information, see the file TAPESYS_SYSBAK:SYSBAK_SHIPPED_VERSION.SBK.



A new SYSBAK_LOG_PURGE_DAYS parameter has been added to SETUP.PAR to tell cleanup to purge the contents of the TAPESYS_LOGS directory when a specified number of days has passed.


NEWTAPE option on fatal error opcoms

In SYSBAK.BIS, a NEWTAPE option has been created for fatal error opcoms, so that users can specify that a new tape should be used, as opposed to doing a retry on the same tape. If no saveset was written at all, the end of tape is in a valid state and the same tape can be used with RETRY. If not, NEWTAPE should be used, as there is either an invalid saveset at the end of the tape or an invalid end of file/tape.



Modifications in TAPESYS V6.2.2, Continued


Mail sent when backup errors

In SYSBAK.BIS, TAPESYS now sends mail in addition to an opcom if the parameter STATUS_MAIL is defined.


Change in linking images

In LINK_CHECK.COM, when doing a full link, TAPESYS now deletes all the node-specific link data files, except for the node doing the link, to force those nodes to relink the version specific images.


Deassignment of logicals

In SHUTDOWN.COM, all system logical names beginning with "tapesys" or "dir$tape" were automatically deassigned, with the exception of TAPESYS_ROOT and TAPESYS_SYSTEM. TAPESYS now allows users to specify that certain logical names be excluded from deassignment, by creating another logical, <logical-to-exclude>_deass_exclude. For instance, to prevent deassignment of TAPESYS_STUFF, define tapesys_stuff_deass_exclude. The logical TAPESYS_DISK is now excluded from deassignment as well, since some users want to use this convenient specification.


Defining certain TAPESYS logicals

The definition of the TAPESYS logicals TAPESYS_ROOT and TAPESYS_SYSTEM have been separated into a separate command procedure that can be called directly by the user during system startup.


Breaking up the BACKUP command in SYSBAK

In SYSBAK.BIS, TAPESYS now breaks up the writing of the BACKUP command into the summary file. A long backup command can cause a DCL error because the write command is too long. Also, some of the automatically added qualifiers have been shortened so that the backup command is not so long in the first place.


SYSCLN and locking history sets

In SYSCLN/USRCLN, the processing of the sets file, including repack, was not properly locking the history set. This would cause contention between SYSCLN and SBUPDT, resulting in errors. TAPESYS now ensures the set is locked before doing anything with it.


Remote history processing

Various problems with remote history processing when the connection transport uses TCP/IP have been fixed.


TAPE MOD and username

The TAPE MOD command failed to correct an invalid username. This has been fixed.



Modifications in TAPESYS V6.2.2, Continued


Tape handling after backups complete

In SYSBAK.BIS, when a tape is VMS dismounted at the end of a sysbak job, it is also JB dismounted and DCSC dismounted, as applicable. If the tape is not mounted because VMS BACKUP or RMU already did the dismount, the entire procedure is skipped, including the JB and DCSC dismounts. Therefore the tape is left in the drive and not moved to a slot. TAPESYS/JB now performs the cartridge movement even if the tape is not vms mounted.


Remote history processing

Protocol checking has been added into remote history processing to avoid using different versions on opposite sides of the interface.


Adding tapes in MAINT

In MAINT, when adding tapes, TAPESYS now initializes records with the default media type, location, protection, and length from SETUP.PAR.


Database conversion

During database conversion, a problem was erroneously triggering SLS conversions. This has been fixed.


Account field

In the past, database operations had treated the account field as a keyword, not allowing embedded blanks. This has been fixed.



TAPESYS now provides support for backup encryption. The use of /MEDIA_FORMAT in backup qualifiers is no longer allowed. Users must use the COMPRESSION parameter instead. Also, the parameters ENCRYPTION_NAME, ENCRYPTION_VALUE, and ENCRYPTION_ALGORITHM have been added to the .SBK file to allow use of the ENCRYPTION product, which is a layered product on versions of VMS prior to 8.3 and part of the operating system from then on. Therefore you should not use them unless you have purchased the product or are running 8.3 or greater. For more information, see the file TAPESYS_SYSBAK:SYSBAK_SHIPPED_VERSION.SBK.


BACKUP command size

Now that the BACKUP command is passed through the recording mailbox, the original size of the mailbox (256) was too small. This has been fixed.


Disallowing FAL access with media type table

When loading the media type table in RQ, TAPESYS no longer uses FAL access. If “:” is found in the tapesys_master logical name, TAPESYS now uses the DB process to download the media type table.



In the report routines, abort if /DIRECT is used and the access is FAL.



Modifications in TAPESYS V6.2.2, Continued


BACKCMD error masking actual error in backup jobs

If the sysbak.exe process for an individual saveset dies abnormally, it doesn't send the termination information to the main SYSBAK.BIS process. This causes a failure due to the absence of the BACKCMD symbol. However, this masks the real error that caused SYSBAK.EXE to abort in the first place. SYSBAK.EXE will now initialize the symbol to a null string up front, eliminating the bogus error and allowing concentration on the real error.


Merging V6 databases

The capability of merging multiple 6r0 databases into one has been added. This was done back in V6.1, but the files were never added to the main kit.



In LOADER.COM, TAPESYS now installs the compress$shr image.


/DIRECT invalid at times

Various invocations of the command TAPE REPORT/DIRECT have been removed, since this is no longer allowed on satellite nodes, and/or the command fails back to a simple TAPE REPORT/MASTER.


Modifications in TAPESYS V6.2.3


Default values for SBUPDT_Q parameters

The original default for DEFAULT_SBUPDT_Q and REMOTE_SBUPDT_Q was SYS$BATCH. However, when TAPESYS was later changed to set the parameters of its queues during startup, this started causing problems. Basically, the SET QUEUE commands change ownership of the batch queue to TAPESYS (not a good idea for SYS$BATCH). So the defaults have been changed to sbupdt$node for default_* and null for remote_* instead of SYS$BATCH.



In distribute_backups.com, TAPESYS now allows use of a different queue for clones in parallel backups. On a job by job basis, the PARA_BACKUP_Q parameter can be specified in the .SBK. To specify a parallel backup queue for all sysbak jobs, use the SYSBPARQUE in SETUP.PAR. Note that the clone backups must run on the same node as the master backup. Therefore a generic queue should not be specified for clone backups. Nor should a generic queue be specified for the main sysbak jobs, to avoid the same problem in reverse.



A new parameter, PRE_PROCESS_MASTER, has been added to the sysbak parameters. It allows for a procedure to be called prior to splitting a parallel backup into clone backups. The regular PRE_PROCESS procedure is called for each clone. The processing for PRE_PROCESS_MASTER is in distribute_backups.com instead of in SYSBAK.BIS. The former procedure wipes out all of the symbols from the .SBK and reloads them. If the PRE_PROCESS_MASTER procedure has dynamically created symbols, these are also wiped out. Therefore PRE_PROCESS_MASTER must be executed after the .SBK reload, which is in distribute_backups.com.


New parameters for SYSBAK

In sysbaks, the parameters AUTO_RETRY_FATAL, AUTO_RETRY_COUNT, AUTO_NEWTAPE_FATAL, and ABORT_IMAGE_DIRSPEC have been added. Please see the file TAPESYS_SYSBAK:SYSBAK_SHIPPED_VERSION.SBK for explanations of these new parameters.


Network error recognition fixed

The error SYSTEM-F-THIRDPARTY was not being recognized as a network failure, causing malfunctions on tapmgrdb failover with the DECnet and FAL transports. This has been fixed.



Modifications in TAPESYS V6.2.3, Continued


Change with database backup using FAL

Database backup with FAL access has been changed. When the secondary master is active, TAPESYS now backs up the secondary database and copies it to the primary, which is the opposite of normal. VMS backup does not allow backups to a file on a remote disk via FAL. However, the secondary database is supposed to be local. Copy works with FAL, so the primary can then be copied to the primary.



QUEUES parameter in SETUP.PAR

It is intended that batch queues used by TAPESYS are dedicated to TAPESYS, so this is the default for the queue-related parameters. The TAPESYS startup will create or modify all of the queues, then will start them if needed. However, if a customer insists on using non-dedicated general queues for TAPESYS, the startup must leave the queues alone.


MODIFY_QUEUES is used to control this. Modification is enabled by default, because dedicated queues should be used. The use of this parameter is NOT RECOMMENDED. If the customer does disable queue modification by turning off this parameter, he or she is responsible for ensuring that TAPESYS is able to submit to whatever queues are specified. Note: TAPESYS does not inherently have SYSPRV, as it did in V5.x, because the default UIC is no longer a system UIC.


New feature in SYSCLN and USRCLN

In SYSCLN/USRCLN, TAPESYS now can skip processing of a specific history set if a particular logical is set. The logicals are syscln_<histsetname>_skip and usrcln_<username>_skip. The logicals should be set to 1 to skip or 0 to not skip.


USRBAKs started by unprivileged users

USRBAKs (user backups) started by unprivileged users caused problems with TAPESYS. These have now been fixed. Note: Originally the backup was run under the persona of the user, but unprivved users could not access the tape drive for some reason, even when granted access via the TAPESYS_USER identifier. So now the backup runs under TAPESYS. To prevent unprivved users from backing up files they cannot access, sysbak checks for access to the files under that persona. If the persona cannot access the files, the target file name is changed to “file_missing_or_username_cannot_access,” while leaving the disk and directory the same. This causes “%BACKUP-W-NOFILES, no files selected from !AS” as the result of the backup, just as if the files did not exist. This substitution will also happen if the user does have access to the directory, but the actual files do not exist.



Modifications in TAPESYS V6.2.3, Continued



The comments in CHECK_HIST_INTEG.COM state that a file name of “” will be treated as “*”. However this was not actually true. Instead, an abort would result. This has been fixed.




In DISTRIBUTE_BACKUPS.COM, TAPESYS now bypasses the “too many drives” check if none of the FILE_n symbols are defined at all. They may be dynamic (defined “on the fly”).


New param for purging logfiles

In CLEANUP.BIS, TAPESYS now provides the option to purge SYSBAK logfiles by the number of (VMS file) versions rather than by date. This is controlled by the new parameter SYSBAK_LOG_PURGE_VERSIONS. (Check the file SETUP_SHIPPED_VERSION.PAR for further explanation.)



A bug existed in CHECK_FOR_TODAY.COM, where /DELAY was not taken into account for all accesses of input date. This has been fixed.


Change in SBQUEUE

In SBQUEUE.COM, if SYSBAK jobs are queued and the latest version of SYSBAK is not being used, the queued jobs are now deleted. This can occur when SYSBAK jobs are in queue and a user shuts down TAPESYS and upgrades the product without removing the outstanding SYSBAK jobs (which are pointing to the previous version of SYSBAK).


Errors and bad database files

When adding locations, media types, containers, etc., TAPESYS now provides a meaningful message when the database is corrupted.


Change in SYSBAK output

In SYSBAK.BIS, TAPESYS no longer executes the diagnostic “SHOW DEV/FULL” commands if the target device is blank. This pointlessly shows all devices on the system.


Quota default output

In the call of SET_TS_QUOTA_DEFAULTS.COM in SHOW_ENVIRONMENT.COM, the quota values are now suppressed unless the command procedure is in a batch job or a quota is too low.



TAPESYS now allows LOADER.COM to run properly when found in the .CUSTOM directory. Also, TAPESYS now sets privileges immediately inside LOADER.


ACCVIO during update file scan

During the database update file scan, an access violation sometimes occurred when a container update record was found. This has been fixed.



Modifications in TAPESYS V6.2.3, Continued


Freeing of I/O buffers

With all of the network transports, TAPESYS now defers freeing of I/O buffers until later when terminating a connection.


SYSBAK and mail

In SYSBAK.BIS, the scheduling index was not appearing in the mail messages. This has been fixed.


Negative time checking

TAPESYS now includes error checking for negative time, which can apparently occur with DTSS.


Media type table

When loading the media type table in TAPMGRRQ, TAPESYS now ensures that the media type file is closed.