TAPESYS® V6.2.3—Release Notes
Copyright ©1983 - 2008 Software Partners, Inc. All rights reserved.
|
Purpose |
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 978-887-6409. |
|
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. |
|||
|
Topic |
See Page |
|
|
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Introduction |
This section details the procedure for upgrading TAPESYS to V6.2.x. |
|
Remember… |
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. |
|
Step |
Action |
|
1 |
Check the batch queues for pending TAPESYS jobs. Use the following command to check for existing jobs: $ SHOW ENTRY/USER=TAPESYS If there are NO TAPESYS jobs present go to Step 3. |
|
2 |
If TAPESYS jobs are present, delete them with the following command: $ DELETE/ENTRY=<entry_#> where <entry_#> is the TAPESYS batch job entry number. |
|
3 |
Shutdown TAPESYS by issuing the following command: $ @<disk>:[TAPESYS_5R2.SYSTEM]SHUTDOWN where <disk> is the disk
device where TAPESYS is installed. Result: The TAPESYS manager processes will shutdown. |
|
4 |
After shutting down TAPESYS, deassign the following logicals: $ DEASSIGN/SYS/EXEC TAPESYS_ROOT |
|
5 |
Proceed to the installation on page 5. |
|
If you are currently running V6.1.x: |
If you are currently running TAPESYS V6.1.x, you should use the following instructions:
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. |
|||
|
Action |
|
||
|
1 |
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. |
|
|
|
2 |
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
Configure_tapesys |
|
||||||||||||||||||||||
|
|
|
||||||||||||||||||||||
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
|
Step |
Action |
|
3 |
After CONFIGURE_TAPESYS has completed successfully, issue the following command to start TAPESYS V6.2: $
@diskname:[<dirname>.SYSTEM]STARTUP |
|
4 |
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: $ @TAPESYS_SYSTEM:CVT_SYSBAK_6R0.BIS 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
|
Step |
Action |
|
5 |
Quite a few sites appear to be using node-specific media type instances. For instance: $ MTYPE_4
:= DLT $ DENS_4
:= $ DRIVES_4 := MKA500 $ IF NODE .EQS. "PICARD" THEN
DRIVES_4 := MKA200 $ IF NODE .EQS. "OSCARS" THEN
DRIVES_4 := MKB100 $ QUEUE_4 := TAPE$DLT 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 TAPE OPER ADD/MEDIA=DLT/DRIVES=MKA500/QUEUE=TAPE$DLT The commands to add the node-specific instances above would be: TAPE OPER
ADD/MEDIA=DLT/DRIVES=MKA200/QUEUE=TAPE$DLT/NODE=PICARD TAPE OPER ADD/MEDIA=DLT/DRIVES=MKB100/QUEUE=TAPE$DLT/NODE=OSCARS Just go through your old SETUP.PAR and do this for each media |
Installing TAPESYS V6.2.x, Continued
|
Step |
Action |
|
5 |
(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. |
|
6 |
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: $ IF F$GETDVI ("TAPESYS_MAILBOX",
"EXISTS") .AND. - |
|
|
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 fix |
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. |
|
Change in TAPE REPORT /MASTER |
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. |
|
TAPESYS SHUTDOWN modified |
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". |
|
TRANS_FOR_ 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. |
|
BACKUP_ CHECK_DAYS |
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. |
|
ALLOCDRIVE_ASSIST |
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. |
|
SYSBAK_LOG_PURGE_DAYS |
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. |
|
Encryption |
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. |
|
TAPE REPORT |
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. |
|
compress$shr |
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. |
|
PARA_BACKUP_Q |
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. |
|
New SYSBAK parameter PRE_PROCESS_MASTER |
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. |
|
New MODIFY_ 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
|
Change in CHECK_HIST_INTEG |
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. |
|
DISTRIBUTE_ BACKUPS |
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.) |
|
CHECK_FOR_TODAY.COM |
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. |
|
LOADER.COM |
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. |