Chapter 5
Problem Report Summary

This chapter describes the following types of fixed and open problems:

The numbers in parentheses identify the problems in the problem-tracking system. You should also refer to the SAMS:Alexandria Release Notes for fixed and open problems against SAMS:Alexandria.

Note that no problems have been explicitly fixed in Backup Toolkit V4.4.4 beyond those required to install and run on DYNIX/ptx V4.6.


Fixed Problems in Backup Toolkit V4.4.3 and SAMS:Alexandria V4.50.70

This section lists the following information about problems that are fixed in the current release of Backup Toolkit and SAMS:Alexandria. No problems were fixed in Backup Toolkit V4.4.3.


Fixed Problems in SAMS:Alexandria V4.50.70

The following problems, which are specific to using SAMS:Alexandria on a DYNIX/ptx host or found on a DYNIX/ptx host, have been fixed in SAMS:Alexandria V4.50.70:


Fixed Problems in SAMS:Alexandria COBRA V4.50.70

The following problems, which were found on a DYNIX/ptx host, have been fixed in SAMS:Alexandria COBRA V4.50.70:


Fixed Problems in Backup Toolkit V4.4.2 and SAMS:Alexandria V4.50.53

This section lists the following information about problems that were fixed in the last release of Backup Toolkit and SAMS:Alexandria:


Fixed Problems in Backup Toolkit V4.4.2

The following problems are fixed in Backup Toolkit V4.4.2:


Fixed Problems in SAMS:Alexandria V4.50.53

The following problems, which are specific to using SAMS:Alexandria on a DYNIX/ptx host or found on a DYNIX/ptx host, have been fixed in SAMS:Alexandria V4.50.53:


Fixed Problems in SAMS:Alexandria COBRA V4.50.53

The following problems, which were found on a DYNIX/ptx host, have been fixed in SAMS:Alexandria COBRA V4.50.53:


Fixed Problems in Backup Toolkit V4.4.1 and SAMS:Alexandria V4.50.17a

This section lists the following information about problems that were fixed in the last release of Backup Toolkit and SAMS:Alexandria:


Fixed Problems in Backup Toolkit V4.4.1

The following problems were fixed in Backup Toolkit V4.4.1:


Fixed Problems in SAMS:Alexandria V4.50.17a

The following problems, which are specific to using SAMS:Alexandria on a DYNIX/ptx host or were found on a DYNIX/ptx host, have been fixed in SAMS:Alexandria V4.50.17a:


Open Backup Toolkit Problems

The following problems have been reported against Backup Toolkit.


systeminfo Script Does Not Warn About Changes to System Configuration that Require a New Custom Miniroot (228491)

The systeminfo script provided by Backup Toolkit does not output any warnings when the system configuration has changed such that you need to build a new custom miniroot tape. Some events that require the creation of a new custom miniroot include installing or updating operating system and layered product software or changing the kernel configuration. This problem was first reported against ptx/ESBM

Workaround. Be sure to create a custom miniroot tape any time the system configuration changes. Details on when a custom miniroot should be created are provided in Chapter 1, "General Disaster Preparation," of the DYNIX/ptx V4.4 System Recovery and Troubleshooting Guide, DYNIX/ptx V4.5 System Recovery and Troubleshooting Guide, and the DYNIX/ptx V4.6 System Recovery and Troubleshooting Guide.


installalex Incorrectly Reports What Script to Re-run When a Failure Occurs (244709)

When installalex fails, it incorrectly says to rerun the .restore_config script, as in the following output:

# ./installalex

Fri Dec 4 13:25:23 PST 1998 - install Starting installation.



* Running Preliminary Checks for Alexandria Install...



* Error: .restore_config

       The alexandria Daemons are running. Please Shut Alexandria down

       and rerun '.restore_config'

*******************************

ERROR: INSTALL IS BEING ABORTED

*******************************



Fri Dec 4 13:25:25 PST 1998 - Alexandria V4.50.02 PN: BKTK-ALEXANDRIA 

(install aborted)

Workaround. Ignore this internal-only script reference. After resolving the error condition, just re-run installalex. In the example above, you would resolve the error condition by shutting down the SAMS:Alexandria daemons.


Open SAMS:Alexandria Problems Specific to DYNIX/ptx

The following problems, which are specific to using SAMS:Alexandria on a DYNIX/ptx host, have been reported:


SAMS:Alexandria Cannot Back Up Files That Have 32-Bit User IDs and Group IDs (220302)

SAMS:Alexandria is not compatible with extended fundamental types that are supported in DYNIX/ptx. For this reason, SAMS:Alexandria can save only those files that have 16-bit user IDs and group IDs. If you are using SAMS:Alexandria with these DYNIX/ptx versions, ensure that your system uses only user ID and group ID values less than or equal to 60,002. (By default, the ptx/ADMIN menu system limits user ID and group ID values to 60,000.)

If you try to back up files with 32-bit user and group IDs, SAMS:Alexandria will output messages similar to the following in the stack history:

FAULT: [109-009] System Call `open' failed.  Error: Value too large for
defined data type (79).
MESSAGE: [109-000] Open called with filename `/usr/alexbkup/Store/Xhost1.47'
mode 02402 perms 0666.
MESSAGE: [817-000] Store Op-Card `motd.op' failed to run successfully.

Workaround. None.


SAMS:Alexandria Operations Generate Excessive Auditing Error Messages (227176)

If the audit feature is enabled in DYNIX/ptx, SAMS:Alexandria generates excessive error messages in the audit log file /usr/spool/audit/audit_log. Errors are reported about user alexbkup and are logged as frequently as every 30 seconds. This problem causes the audit_log file to grow rapidly and eventually fills up the /usr filesystem.

Workaround. Monitor the audit_log file and truncate or remove the file.


Open SAMS:Alexandria Problems Found on DYNIX/ptx Hosts

The following SAMS:Alexandria problems that were found on a DYNIX/ptx host have been reported. For other SAMS:Alexandria problems that have been reported, refer to the SAMS:Alexandria Release Notes.


Restore Operation Cards Do Not Define File Filters Relative to Specific Directory Filters, Causing Unexpected Results (214640)

When creating Restore operation cards, you can define directory filters and file filters to limit the scope of files restored. However, there is no way to designate the file filters that should be used with a specific directory filter. This problem can cause unexpected results when a file with the same name exists in more than one directory and you are trying to restore that file as part of a restore operation that includes multiple directory filters.

When this scenario exists, the restore operation can recover more files than you intended, for example, all files of the same name in all directories specified. Alternatively, the restore operation can recover different files than you intended, for example, if you inadvertently request a file that has never been backed up and a file with the same name has been backed up in a different directory that matches one of the directory filters.

Workaround. Create one Restore operation card for each directory filter you want to apply.


Disk Full Error During Recovery Not Reported as Such (215373, 215381)

With any of the SAMS:Alexandria storage formats, if the disk to which you are restoring becomes full, SAMS:Alexandria does not indicate that the disk is full. Instead, it displays a misleading error message and fails the recovery. For example, the message displayed during a failed recovery using the RPF storage format is similar to the following:

FAULT: [770-004] Incorrect amount of data written to `/tmp/Op-List.39'

The message displayed when using the Alexandria, Tar, and CPIO storage formats is similar to the following:

FAULT: [751-002] Error writing output file `/home/jones/report1'.

Workaround. Before starting any recoveries, ensure that the disk to which you are recovering has enough available space for the recovered data.


Store Operation Cards Do Not Have Options to Skip a Day or Temporarily Edit the Card (217444)

Alexandria Store operation cards do not have the ability to skip a day in the configured backup schedule, for example for a holiday. SAMS:Alexandria also does not have the ability to temporarily edit a Store operation card.

Workaround. The only way to skip a scheduled backup is to unmanage (unschedule) the operation card before the backup is scheduled to run. However, ensure that you manage (schedule) the operation card again as soon as the backup time has passed. Otherwise, this operation card will never run again. The only way to change the schedule for an operation card is to edit the schedule for the operation card before the backup and then, once the backup is done, manually restore the original schedule.


Cannot Change the Retention Dates for a Completed Backup (219376, 220338)

Once a backup has been made, the retention dates for that backup (Database Retain, Library Retain, and Lifetime Retain) cannot be extended or changed.

Workaround. The only way to change the retention dates in this case is to use the alex-media -sd or alex-media -sg command to scan the tapes. These commands change the retention dates in the SAMS:Alexandria database so that the information never expires unless manually deleted.


Media Location Remains in a Tape Drive After the Drive Is Deleted (221132)

If you delete the configuration for a library in SAMS:Alexandria, the configurations for all tape drives associated with that library are also deleted. The problem that can occur is that any tape left in the drive at the time of its deconfiguration cannot be ejected, because SAMS:Alexandria no longer recognizes the drive's existence.

Workaround. Before deleting a library configuration, ensure that no tapes are in any of the affected tape drives. If this problem occurs, bring the tape drive on line and then move the tape from the tape drive to a library slot. Once this procedure is finished, take the drive off line again.


Database Pack Operations Fail When Permissions on Pack Directory Do Not Match Those on /usr/alexbkup/Database Directory (221230, 221457)

When you are performing database pack operations, if the permissions on the pack directory you are using do not match the permissions of the directory containing the SAMS:Alexandria database (by default, /usr/alexbkup/Database), the pack operation will fail. The pack operation will also fail if the pack directory does not exist. This problem occurs because the alex-dbase -PS command, which enables you to designate the pack directory, does not verify that the directory you designate exists or has the correct permissions. Later, when you pack the database with the alex-dbase -P command, it fails because it could not set the appropriate permissions on files in the pack directory.

Workaround. Always set the owner and group of the pack directory to alexbkup and set the permissions to 700 to match the /usr/alexbkup/Database directory.


Media in Tape Drives When a Library is Power-Cycled Are Marked as Unknown by SAMS:Alexandria (226222)

If a tape resides in a tape drive of a configured SAMS:Alexandria library and that library is power-cycled, the next time SAMS:Alexandria accesses the library it marks the tape as UNKNOWN. Furthermore, if SAMS:Alexandria tries to identify the tape while it is in the tape drive, the tape will be marked as Managed Incorrect (MI). This problem occurs because the library does not return barcode information to SAMS:Alexandria for tapes that are in tape drives. This problem most commonly occurs when both the system and the library have a power failure while tapes are in tape drives. After the system reboots and SAMS:Alexandria is started, SAMS:Alexandria then marks the tapes as UNKNOWN.

Workaround. Using the touch screen on the library or the SAMS:Alexandria graphical interface Xalex, manually unload all tapes from tape drives and reinventory the library.


SAMS:Alexandria Calculates the Estimated Storage Space Based on Uncompressed Data (226703)

Before backing up data, SAMS:Alexandria calculates the estimated amount of tape storage space required by the store operation. This estimation is based on uncompressed data size. If SAMS:Alexandria determines that the library does not contain enough media to handle the estimated storage requirements, the store operation will fail with messages similar to the following:

FAILURE: [817-011] Could not locate any media for data storage.
MESSAGE: [817-000] Make sure libraries have enough available media.
MESSAGE: [817-000] Store Op-Card `FULL-/usr' failed to run successfully.

The estimation algorithm can cause store operations to fail when compression is used to back up the data. In this case, the store can fail even though sufficient media space is available.

Workaround. Ensure that the library contains enough media for the store operation to run based on uncompressed data capacity even though the actual store operation will be using compressed data.


No Warning That Failed or Incomplete Stacks Have Been Requested for a Restore Operation (227359)

If you select a stack for a restore operation that is identified as a FAILURE or that is a partially or incorrectly detailed scanned stack, the restore operation will be initiated for any complete clusters contained on that stack. However, SAMS:Alexandria does not display any warnings that you are restoring a failed or incomplete stack and that some expected data will not be restored. This problem can occur when all tapes for a stack are not scanned or when a store operation was not successful.

Workaround. Before beginning restore operations, check the stacks you want to restore for SUCCESS, FAILURE, or WARNING messages.


Manual Access to Library Can Cause SAMS:Alexandria Operations to Fail (228824)

If a library is manually accessed, for example, by using the front panel of the library to perform tape movement operations, while a SAMS:Alexandria store or restore operation is active that needs to perform some tape movement in that library, the operation will fail with a SCSI Test Unit Ready error (Sense code 0x02, 0x04, 0x00). This problem has been seen while performing bulk moves and queued unloads with the front panel of the DDS-2 library.

Workaround. Ensure that there are no active or pending store or restore operations for the library before manually accessing it. For example, if you need to load and unload multiple tapes on a daily basis, then stop alex-sched at a time outside of the primary backup window, wait for all currently running stores and restores to be completed, load and unload the tapes as needed, and restart alex-sched. Any jobs that were scheduled to start during the time that alex-sched was stopped will start immediately after alex-sched is restarted.


GenOp Does Not Output Information About the Distribution of Filesystems to Child Operation Cards (229828)

The GenOp script does not output any information about the filesystems that were backed up by each child operation card that GenOp creates. GenOp dynamically assigns the filesystem backups to child operation cards each time GenOp is run. For this reason, it is possible that one child operation card can back up a filesystem on one day and that a different child operation card can back up that same filesystem the next day. This becomes confusing when you need to recover a full and an incremental backup of a filesystem and these two backups were performed by different child operation cards. In this case, you would need to restore data from two different stacks. However, there is no record of the previous days' filesystem distribution. You can only see the current distribution.

Workaround. Manually search for the data to be restored rather than relying on specific stack IDs to define all the data you want restored.


Detailed Alien Scan Can Silently Prevent Data from Being Recovered When Some Tapes Are Not Scanned (229971)

Assume that you have multiple tapes that comprise one or more stacks from one host. Then you move these tapes to a different host or to the original host which no longer has any references to these tapes and perform a "detailed alien scan" on some, but not all of these tapes. When a restore operation is run that requires data from these tapes, the restore can succeed even though not all the expected data was restored. No warnings are displayed about the missing data.

Workaround. Be sure to scan all necessary tapes.


Restore Operations from a Client Fail When Required Media Is in a Tape Drive and the Tape Drive Name on the Server Differs from That on the Client (231292)

When a client host starts a restore operation, the client host requests from the server host the location of the media to use for that restore operation. When that media is already in a tape drive, the server host returns the name of the tape drive to the client host. If the tape drive name returned by the server is different from the name configured on the client for that tape drive, the restore operation fails with errors similar to the following:

FAILURE: [814-006] Device `host1-lib1-D1' is NOT configured
MESSAGE: [818-000] Restore Op-Card `def.s-Restore-1' failed to run successful
ly.

Restore operations from a client do not fail if the required media is in a library slot.

Workaround. Retry the restore operation when the media is no longer in use. Alternatively, ensure that the library and device names are the same on the server and client. If you want to name the libraries and devices the same on the server and client, you will have to use the Xalex interface. The names generated by SetupHD.Seq and ClientHD for a given device do not match do not match in order to support multiple network interfaces between clients and servers.


Cleaning Tapes Inserted Directly into SAMS:Alexandria Cleaning Slot by Using the Front Panel of the Library Can Cause Subsequent Operations to Fail (231293)

If the front panel of a library is used to insert a cleaning tape directly into the SAMS:Alexandria designated cleaning slot, the next SAMS:Alexandria operation that needs to identify media will move that cleaning cartridge into a tape drive and the operation will fail. The result is that the cleaning cartridge is left in the tape drive and the drive is taken offline.

Workaround. Always use SAMS:Alexandria commands or the Xalex graphical interface to insert and eject cleaning cartridges to and from libraries configured in SAMS:Alexandria.


Cannot Specify Large File in STORE-ROOT Keyword (231555)

If you designate the path of a large file in the STORE-ROOT keyword of a Store operation card (for a full or incremental backup), the store operation fails with the following errors:

FAULT: [109-013] System Call `stat' failed.  Error: Value too
large for defined data type (79).
MESSAGE: [109-000] Stat called with filename `/lsst/LF1/6GBfile'.
MESSAGE: [817-000] Store Op-Card `LF' failed to run successfully.

Workaround. Specify only the directory that contains the large file in the STORE-ROOT keyword.


Shutdown of SAMS:Alexandria Server Daemons Gives "Trying to terminate process UNKNOWN" Message (239825)

When SAMS:Alexandria is shut down, the following messages may be printed:

Trying to terminate process UNKNOWN (7640)...
Trying to terminate process UNKNOWN (7668)...
Trying to terminate process UNKNOWN (7647)...
Trying to terminate process UNKNOWN (7642)...
Trying to terminate process UNKNOWN (7649)...
Trying to terminate process UNKNOWN (7669)...
Process UNKNOWN (7640) TERMINATED
Process UNKNOWN (7668) TERMINATED
Process UNKNOWN (7647) TERMINATED
Process UNKNOWN (7642) TERMINATED
Process UNKNOWN (7645) TERMINATED
Process UNKNOWN (7669) TERMINATED

The processes that are listed as UNKNOWN are typically additional slnetdaemon processes started by various remote accesses including the HTML GUI. This is not an indication of an orphaned process, but that SAMS:Alexandria does not have a process name associated with this process ID.

Workaround. This message can be safely ignored. No incorrect processes will be terminated.


Exiting the SAMS:Alexandria Java GUI Generates Multiple Error Messages (244560)

Error messages are generated on the DYNIX/ptx server in the /usr/alexbkup/ErrorMsgs/Messages file when the SAMS:Alexandria Java-based interface is exited. The errors, which are quite long, are generated when exiting with the [X] in the top right corner and with the [Exit SAMS:Alexandria] button on the main Login screen. These slnetdaemon errors are similar to the following:

  FAULT: [621-011] System call 'recv' failed. Error Connection request
by peer (131). 
MESSAGE: [621-000] TCP/IP Detail Error Information Report.
MESSAGE: [621-000]   ID                      : 141
MESSAGE: [621-000]   Initialized             : YES
MESSAGE: [621-000]   Server                  : YES
MESSAGE: [621-000]   Client                  : NO
MESSAGE: [621-000]   Debug Value             : 0
MESSAGE: [621-000]   Port Number             : 22364
MESSAGE: [621-000]   Program Name            : slnetdaemon

Workaround. These error messages can be safely ignored.


SAMS:Alexandria Database Can Become Corrupted after a Restore from a DATABASE Tape When the Partition Used for the Transaction Logging Database Contains Residual Data (244662)

When SAMS:Alexandria is started for the first time after a restore from a daily housekeeping tape, corruption will be introduced into the SAMS:Alexandria database if transaction logging is turned on and the raw partition for the transaction logging database contains residual data.

The corruption occurs because the database is backed up ONLINE with housekeeping and not marked with a clean shutdown. When the SAMS:Alexandria database is restored and brought up, the database daemon notices the restored database was not shut down clean (because it was backed up online) and reloads the residual data from the raw partition, which in this case is incorrect and should not be applied, thus corrupting the database.

Workaround. Zeroing out the transaction log raw partition before starting SAMS:Alexandria for the first time after restoring from a DATABASE backup tape will wipe out any residual data in the raw partition. For example, the following command will overwrite any data on the raw partition v-alex_raw with zeroes:

# dd if=/dev/zero of=/dev/vx/rdsk/v-alex-tldb bs=64k

The disaster recovery procedures provided for Backup Toolkit on all versions of DYNIX/ptx account for this problem.


Alexandria NT/Client Registry Backup Fails to Store Some Keys (245757)

The AlexClient/NT personality fails to store some of the Registry keys. The backup of the registry keys fails with a status code of 'A', which means that SAMS:Alexandria could not find any attributes describing the file, so it was not backed up. The following registry keys are not backed up:

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\SYSTEM\EISAADAPTER\0\Configuration Data
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\CONTROLS FOLDER\Presentati
on Cache

HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWSNT\CURRENTVERSION\PERFLIB\009\Counter

HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWSNT\CURRENTVERSION\PERFLIB\009\Help

Previous versions of Alexandria also did not back up the HKEY_LOCAL_MACHINE\SECURITY\SAM\C registry key. With SAMS:Alexandria V4.50.53, this registry key is properly backed up.

Workaround. Contact IBM Customer Support if this problem affects your site.


Network Store Operations Can Hang During the First Cluster Build (249837)

SAMS:Alexandria network backups can hang during the first cluster build when it opens a second socket. Starting with SAMS:Alexandria V4.50.53, network operations were changed by opening a second socket during network backups and indications are that the second socket is related to this problem.

Workaround. Disable the second socket from being opened by enabling the Single-Port-For-Remote-Devices configuration option of SAMS:Alexandria. This option should be enabled only for client hosts; it does not need to be enabled on server hosts. Note that only those client hosts that have enabled this option will use one socket to negotiate with the server. Client hosts who have not enabled this option will continue to use two sockets for network backups.

To enable the Single-Port-For-Remote-Devices configuration option, use the alex-option command as follows:

# alex-option -u Single-Port-For-Remote-Devices 'On'

Message Queue IDs Might Not Be Unique, Which Causes Random Failures (255207)

Depending on the type of internal process, SAMS:Alexandria allocates message queue IDs based on either the secondary temporary directory (by default, this is /usr/tmp) or the Alexandria home directory (typically /usr/alexbkup), which is generally a separate filesystem from root. By creating message queue files in different filesystems, the message queue IDs are not guaranteed to be unique.

This situation has been seen to cause random failures over a period of weeks with various messages being output similar to the following:

  FAULT: [400-063] TTY Response -2050 received invalid parameters.
MESSAGE: [400-000] Should have received 8 parameters, but received 9.
MESSAGE: [300-000] Device API associated with device `d0'.

Workaround. Ensure that all lock files are created in the same filesystem. IBM recommends the following procedure:

  1. Since most lock files are created in the Alexandria home directory (typically, /usr/alexbkup), create a subdirectory in the filesystem for the sscldaemon lock files. In the example that follows, the subdirectory .sscldaemon.LCK is created for the lock files in the /usr/alexbkup Alexandria home directory:

    # cd /usr/alexbkup
    # mkdir .sscldaemon.LCK
  2. Change permissions on the directory so it is owned by user and group alexbkup.

    # chown alexbkup:alexbkup .sscldaemon.LCK
  3. Change the Tmp-Dir-Secondary configuration option to point to this new directory.

    # alex-option -u Tmp-Dir-Secondary /usr/alexbkup/.sscldaemon.LCK
  4. Restart SAMS:Alexandria:

    # /etc/init.d/alex restart

buildmini Utility Cannot Obtain SAMS:Alexandria Bits When Fastpatch 255438 is Installed (255538)

On DYNIX/ptx V4.5.2, V4.5.3, or V4.6.1, if you installed SAMS:Alexandria fastpatch #255438, the custom miniroot built by buildmini does not include support for SAMS:Alexandria. Specifically, the custom miniroot built by buildmini is hardcoded to include SAMS:Alexandria files only from the ~alexbkup/bits/DYNIX.44 directory. The problem occurs because the ~alexbkup/bits/DYNIX.45 directory is the current location of the binaries when the SAMS:Alexandria fastpatch #255438 is installed. (Fastpatch #255438 is required for support of Fibre Channel-connected tape drives and DLT7000E and DLT8000 tape drives.)

Workaround. Install fastpatch #255538, which can be obtained from IBM Customer Support. This patch provides buildmini support for SAMS:Alexandria when the SAMS:Alexandria bits are located in either the ~/bits/DYNIX.44 or ~/bits/DYNIX.45 directories.


Open SAMS:Alexandria Problems that Only Impact ACSLS-Connected Library Usage

This section describes the SAMS:Alexandria problems that occur only when using the ACSLS personality and ACSLS-connected libraries. (The ACSLS personality is part of SAMS:Alexandria and is not a separate software product.) These problems do not apply to any other library usage, including directly-connected STK libraries.


Inserting Media from the CAP to a Pool or Logical Library Sometimes Fails (234796)

Inserting media from the CAP to a pool with the alex-util command or from the CAP to a logical library (insert method is cap-id, for example, 0,0,0) sometimes fails. The failure occurs when the barcode reader of the ACSLS-connected library cannot read the barcode labels on the media in the CAP. This can happen when the CAP door is shut too firmly and the media shifts in the CAP. Media whose barcodes cannot be read are left in the CAP door as would be expected. The problem that occurs is that the media whose barcodes were successfully read are not inserted into the requested pool or logical library. Instead, they are inserted only into the physical library and are unavailable for direct use by SAMS:Alexandria.

Workaround. To prevent this problem, be sure to shut the STK library CAP door extremely gently, preventing the spring tension on the door from closing it more firmly.

If this problem occurs, use the ACSLS server to locate the media that was inserted into only the physical library and eject them from the physical library. Then you can reinsert them into the logical library or pool. For more information on inserting media into an ACSLS-connected library, refer to the Backup Toolkit Administration for SAMS:Alexandria.


Unmounting Tapes with alex-cntrl Can Access Reserved Slots 1 and 2 (235439)

Alexandria logical slots 1 and 2 are reserved for managed database volumes. However, the alex_cntrl +l libraryname +d devicename -u -1 command will unmount the tape but put it in slot 1 or slot 2, if either of these slots do not contain any media. This will cause the recovery pool to incorrectly reflect this tape as a managed database tape.

Workaround. None.


Recovery Pool Does Not Correctly Identify Managed Database Tapes (235441)

The recovery pool is supposed to show barcode labels for all managed database tapes. However, it shows only the barcode labels of the tapes in SAMS:Alexandria logical slots 1 and 2, regardless of the actual media status of those volumes.

Workaround. Use standard SAMS:Alexandria procedures to track managed database tapes. Do not rely on the recovery pool to track these tapes.


Device Configuration Does Not Check for Existence of Pools (235443)

When configuring logical libraries for an ACSLS-connected library, the Library Personality Specifiers window in the Xalex GUI does not verify that the pool-IDs that you enter for the insert, eject, and recovery pools actually exist in the ACSLS.

Workaround. Make sure that the pools have been created.


Early Termination of alex-cntrl -i with CAP Insert Causes Problems (235444)

When the CAP insert method is used with ACSLS-connected libraries, if you issue the command alex-cntrl +l libraryname -i 0 and then terminate the command before entering any tapes into the CAP, the command will terminate but the ACSLS will keep on waiting for tapes to be entered. This will prevent other commands from using the CAP. Also, the ACSLS will accept tapes from the CAP but the tapes will not be put into the correct library.

Workaround. If the alex-cntrl -i command is terminated prematurely, make sure that the enter command on the ACSLS server is also terminated. If the enter command has not terminated, cancel the related enter request from the `cmd_proc' window of the ACSLS server.


Early Termination of alex-cntrl -e with CAP Eject Causes Problems (235446)

When the CAP eject method is used with ACSLS-connected libraries, if you issue the command alex-cntrl +l libraryname -e slot and then terminate the command, the command will be terminated but the ACSLS will probably put some of the tapes into the CAP. These ejected tapes will still be in the library's inventory, causing these volumes to be orphaned from SAMS:Alexandria.

Workaround. If any tapes have come to the CAP because of this eject command, reinsert them into the correct logical library.


Open SAMS:Alexandria Problems That Only Impact IBM 3494 Library Usage


SAMS:Alexandria Cannot Use 3590 Tapes Marked UNKNOWN (255470)

If excessive mount or dismount failures occur for 3590 tapes or a shutdown of SAMS:Alexandria occurs with a tape left in a 3590 tape drive, the tape is marked UNKNOWN for its location as shown via the alex-media command. This problem does not affect store operations, but may affect restore operations. Performing an inventory of the library does not correct this situation.

Workaround. Stop all backup operations to the IBM 3494 library and then delete the libname.SLOTS file from the SAMS:Alexandria server host. Then, reinventory the library (alex-cntrl +l libname -Il) to create an in sync version of the volume mapping file.


SAMS:Alexandria Incorrectly Reports Amount of Tape Remaining for ME Tapes (255471)

SAMS:Alexandria always incorrectly reports the amount of tape remaining for IBM 3590 High Performance Tape Cartridges. SAMS:Alexandria reports 9,214 KB for Managed Empty tapes in IBM 3494 tape libraries regardless of the amount of tape actually remaining on the tape media. The correct "Space Remaining" value should be closer to 36,000 KB for an Extended Length 3590 Cartridge and 19,000 KB for a Standard 3590 Cartridge.

Workaround. None


Custom Miniroot Does Not Contain Support for IBM 3494 Tape Libraries (255534)

The custom miniroot built on DYNIX/ptx V4.5.3 or V4.6.1 does not contain the lmcpd daemon and other files necessary for support of the IBM 3494 tape library.

Workaround. If you plan to use an IBM 3494 tape library for a host's DATABASE backups, you must install fastpatch #255534, which can be obtained from IBM customer support.


lmcpd Daemon Must Be Started Manually When Booted From Custom Miniroot (255534)

When booted from the custom miniroot, the lmcpd daemon is not automatically started. Without this daemon running, SAMS:Alexandria operations with an IBM 3494 tape library will fail. For example, the alex-cntrl command will fail.

Workaround. If you are performing a disaster recovery with an IBM 3494 tape library, ensure that you have installed fastpatch #255534. Then, after booting the custom miniroot, manually start the lmcpd daemon with the following command:

# /etc/lmcpd

Open COBRA Problems

The following COBRA problems that were found on a DYNIX/ptx host have been reported. For other COBRA problems that have been reported, refer to the SAMS:Alexandria COBRA/v4 Personality Release Notes.


COBRA Documentation Has Incorrect Syntax for OPS-DB-INSTANCE Command (245499)

The OPS-DB-INSTANCE keyword/command documented on page 81 of the SAMS:Alexandria COBRA System Administration Guide under "Store Commands Reference" in Chapter 6, "Backup Commands Reference," incorrectly shows the following syntax:

OPS-DB-INSTANCE <unique_id> <db_instance> <ORACLE Home> <node_name> [....]

The correct syntax is as follows:

OPS-DB-INSTANCE <unique_id> <ORACLE Home> <node_name> <db_instance> [....]

SAMS:Alexandria Java-Based Interface Always Sets BACKUP-READ-ONLY ON When COBRA Store Operation Cards Are Saved (245715)

Whenever a COBRA Store operation card is saved in the SAMS:Alexandria Java-based interface, the value of the BACKUP-READ-ONLY keyword is set to ON regardless of the selection for the Skip Read Only TS-s check box. With this problem, it is not possible to use the Java-based interface to disable the back up of read-only tablespaces.

Furthermore, if a Store operation card was previously created with the alex-xfer command so that read-only tablespaces are not backed up (BACKUP-READ-ONLY OFF) and this operation card is viewed with the Java-based interface, the Skip Read Only TS-s check box is correctly displayed as unselected. However, if this operation card is then saved by the Java-based interface, read-only tablespaces will be backed up as the value of the BACKUP-READ-ONLY keyword is reset from OFF to ON by the Java-based interface.

Workaround. Use the alex-xfer command to update this option to OFF if required.


COBRA Documentation Is Missing Information about Copying Parameter Files for Remote OPS Instances to the Local Node (245815)

The section "Backing Up an OPS Environment" in Chapter 7, "Handling Special Backup Tasks," on page 124 of the SAMS:Alexandria COBRA System Administration Guide is missing the following additional information about what COBRA requires:

Parameter files for remote instances must be copied to the local node where COBRA will initiate the backup. This must be done anytime a change is made to the parameter files. If the required startup files of every remote instance are not present on the local node, COBRA attempts to restart all instances with the same startup files, which implies the same thread and instance numbers. This results in starting up only one instance while the other instances fail with error messages.


COBRA Parameter Files Fail to Restore When OPS SIDs are the Same on Remote Nodes (245819)

Some OPS configurations maintain the same Oracle SID for all instances, which is a valid setup in Oracle. Although store operations complete successfully in this scenario, the remote instance's files fail to restore using COBRA restore operation cards that are generated with cobraquery.

In Oracle OPS environments where the Oracle SID is the same across all threads, the following COBRA restore issues exist:

Workaround. Use regular SAMS:Alexandria restore methods to select and restore the object(s).


The Daily Summary Report Mail Does Not Include Stack Details for Store Operations Executed by the Transfer Manager (246557)

The Daily Summary Report mail does not give any details about those stacks created by Transfer Manager Store operations. This includes those Store operations run by COBRA v4.0, ON-Bar, RMAN, and any other backups generated by the Transfer Manager. The Daily Summary Report mail only includes those stacks that are generated by the alex-sched scheduler.

Workaround. Use alex-stack -lA to check the status of alex-xfer based stores. Note that for parent/child store operations the result of the parent store operation indicates the overall success or failure of the backup operation. For example, a child store operation might fail, but then be successfully retired and thus the overall backup operation succeeded.


DYNIX/ptx Does Not Support SAMS:Alexandria with EMC TimeFinder as Indicated in the COBRA Personality Release Notes (248802)

The SAMS:Alexandria COBRA/v4 Personality Release Notes, April 1999, that are provided with SAMS:Alexandria 4.50.70, state that split mirror backups have been certified with EMC Symmetrix® hardware, EMC TimeFinder software, and DYNIX/ptx. This information is provided in the section "Platforms/System Requirements." However, at this time, IBM does not support the use of SAMS:Alexandria with EMC TimeFinder on DYNIX/ptx and EMC Symmetrix hardware.

Workaround. Contact your IBM Sales Representative for information on future support of this functionality.


COBRA Restore Operations Do Not Create Missing Directories (248886)

COBRA does not create any missing directories during Restore operations. When restoring database files to a new location, this problem prevents the Restore operation from successfully completing. This problem exists because of the way COBRA creates the SLT files used during the Restore operation.

Workaround. Before beginning a COBRA Restore operation, ensure that the entire directory tree exists for the Oracle data that you plan to restore.


COBRA Store Operations Involving Databases that Track Numerous Archive Logs Are Delayed When They Write to the Input FIFO (249621)

COBRA Store operations monitor how much data is written to its input FIFO and sleeps for 5 seconds after every 2048 bytes are written. This allows the reader on the other side of the pipe to catch up. In some circumstances, this can cause a long delay during Store operations. For example, COBRA Store operations of Oracle databases that track 3000 or more Archive logs may see a delay of 10 minutes or more.

Workaround. Limiting the size of the v$archived_log table (MAXLOGHISTORY) or properly configuring redo log sizes can help manage the delay. However, there is no workaround for sites that have efficiently configured the size of the v$archived_log table and/or do require an archive log table of greater than 3000 records.