This name is used to reference the archive in save and restore requests. There are no required or ad-hoc conventions for archive names, so they can reflect their usage in your environment. However, there are ad-hoc conventions for environment names based on the archive name, so you should restrict the archive name to 60 characters.

ABS supports two types of archive, which are hopefully self-explanatory:

A catalog contains information about what data is stored in the archive and where it is stored. Each archive uses exactly one catalog, although catalogs can be shared among different archives. ABS defines a default catalog called ABS_CATALOG, which is assigned to all archives by default if a different catalog is not specified. If you wish to define a different catalog for an archive, then specify a catalog object name (not its location) in the catalog attribute of the archive. For the archive to be useful, the catalog must be defined as a catalog object in MDMS.

An archive with a name of “DISASTER_RECOVERY” is the only archive allowed to have no catalog associated with it and the save operation is therefore not catalogued (see Chapter 7).

ABS supports the concept of consolidation criteria which determine when a volume set should be retired from use in the archive and a new volume set used. ABS supports three types of consolidation criteria, of which none, one, two or all three can be applicable:

If you specify multiple consolidation criteria, ABS creates a new volume set when the first of any of the defined criteria are exceeded. The default consolidation criteria is an INTERVAL of 7 days. If no consolidation criteria are specified, then ABS creates a new volume set when the ANSI limits apply, or upon the first error writing to the volume set. This is not recommended as you may create excessively large volume sets, and may have to split a volume set between onsite and offsite (vault) locations. Consolidation criteria are only applicable to an archive type of TAPE.

If you specified an archive type of DISK, you must enter a destination attribute for the archive, or use the default of ABS$ROOT:[000000]. The destination contains the disk and directory location of the data saved in this disk archive. When specifying destination, you should ensure that the specified disk has enough free capacity to handle all data to be saved in this archive. ABS does not monitor the disk for sufficient capacity. ABS clears this attribute if the archive type is TAPE.

Also, if you have specified a logical name as part of the destination name, then ensure that before the restore request is executed, the logical is defined as a concealed logical that is either defined as a system-wide logical name or just has the physical device name before the restore request is executed. If you do not want to use the logical name, then specify the physical device name followed by the directory path as the destination for the restore request.

ABS allows you to enter a list of drives that can be used by save and restore operations to and from this archive. This should be used only to restrict the drives that would normally be available for these operations for some reason. Normally, you can let ABS select drives for all operations based on media type and location, and so you do not need to specify the drives in the archive. If you do specify drives, be aware that these drives apply to restores as well as saves. Drives are only applicable to an archive type of TAPE.

ABS supports two alternative methods of specifying when an archive expires. These are:

Either retention days or expiration date may be given, but not both. By default, ABS defines retention days of 365, meaning that volume data is valid for one year after retirement of the volume set.

For an archive type of TAPE it defines the initial scratch date of the tape volume set. Once a volume has transitioned to FREE state and it has been re-used all catalog entries relating to the past usage of this volume are deleted. You can change the expiration of the archive by setting a new scratch date for the volume. Whenever data is added to the volume set a new scratch date will be set if the expiration date extends beyond the old scratch date.

For an archive type of DISK it defines the time at which the on-disk saveset is deleted. At the same time all catalog entries relating to that saveset are also deleted.

Expiration date and retention days are only applicable to an archive type of TAPE.

ABS supports save requests that sometimes perform full backups and sometimes perform incremental backups. Under these circumstances, it is useful to use different volume sets with different retention days or expiration dates for the fulls and the incrementals. To support this, ABS allows you to specify two archives for save requests: the first applies to the full backups, and the second applies to the incremental backups.

A location is an MDMS object that defines the physical location of volumes, drives or jukeboxes. The location is used as one of the selection criteria (along with media type) for allocating a drive to load a scratch volume to extend the archive. If no location is specified for the archive, ABS uses the default onsite location defined in the MDMS domain. This is the default. Location is only applicable to an archive type of TAPE.

ABS supports multiple parallel save operations using a single archive, each operating on a different drive and volume set (archive type TAPE). To enable this feature, specify the maximum number of parallel saves that are desired using the maximum saves attribute. Values can range between 1 and 36, with 1 being the default. This attribute also applies to an archive type of DISK, but without the implications of multiple drives and volume sets being allocated.

Media type is an MDMS object that describes the type of tape media to be used in the archive. Specify a media type that is defined within MDMS, or use the default domain media type. The media type is used as a mandatory selection criterion (along with optional pool and location) for volumes to be used in the archive. Media type is only applicable to an archive type of TAPE.

A pool is a logical MDMS object that relates a collection of volumes to a set of authorized users. In this way, you can allocate a collection of volumes to certain users knowing that other users cannot use volumes from the pool. Similarly, you can assign a pool to an archive, so that all volumes used in the archive must be taken from the volumes that are in the pool. You can specify only one pool per archive. If you do not specify a pool, then only volumes that have no pool defined can be used for the archive (this is also known as the scratch pool).

The volume sets attribute indicates which volume sets are currently being used by save requests using the archive. There may up to the maximum saves number of volume sets currently being used. These volume sets are those to which the next save operation will be written to the archive. This attribute is normally maintained by ABS and you should not modify it unless there is a pressing need to remove one or more of the volume sets from the list and let ABS allocate new volume sets. Under no circumstances should you add volumes to the volume set list.

This name is used to reference the catalog. There are no required or ad-hoc conventions for catalog names, so they can reflect their usage in your environment.

Catalogs are node specific. You have to specify the MDMS node name where the catalog resides. An empty catalog node name means the local node where the command was issued or where the request executes. In a VMScluster, multiple nodes can share the same catalogs on a common disk as long as they have direct access to the catalog files. During a save operation ABS always accesses the catalog on the local node even though a different node name is specified in the archive. During a restore operation the catalog lookup will be performed for the catalog at the specified node. This allows to restore data that has been saved on another node.

ABS supports four types of catalogs, which are hopefully self-explanatory:

By default catalog files are created in ABS$CATALOG. Without modification ABS$CATALOG points to ABS$ROOT:[CATALOG]. When creating a new catalog you can create the catalog files in a different location by specifying a device and directory. You have to update the definition of ABS$CATALOG logical in ABS$SYSTARTUP.COM to include the new device and directory solution in form of a search list.

$ CREATE/DIRECTORY DKA100:[ABS_CATALOG]
$ DEFINE/SYSTEM/EXECUTIVE ABS$CATALOG ABS$ROOT:[CATALOG],-
DKA100:[ABS_CATALOGS]

This creates a new directory for catalog files and adds it to the ABS$CATALOG search list. The same definition needs to be set in ABS$SYSTARTUP.COM.

If a “SHOW CATALOG/FULL” does not display a directory for a catalog it means the catalog’s location is not included in the ABS$CATALOG search list.

A catalog that is setup for staging improves the performance of the save operation because the catalog entry for a saved file is first written to a sequential disk file in ABS$CATALOG. Once the backup operation has completed a separate process moves the entries from the staging catalog file to the final catalog which is specified in the archive associated with the save request.

The final catalog does not contain the information about the save operation until the staging process has completed. If you request a backup operation and immediately look in the final catalog, the entries may not be available, yet. The backup operation and the staging process must complete before the currently saved files can be looked up in the catalog.

You can always modify the staging setting for an existing catalog. The use of staging is highly recommended to improve your overall backup times.

The staging catalog file is created in the first location pointed to by logical name ABS$CATALOG.

Save entries contain information about executing or executed save operations:

File entries contain information about files which have been saved.

Catalog files are RMS index-sequential files and as such need regular maintenance to avoid unnecessary file growth and performance penalties. ABS provides a catalog conversion command procedure (“ABS$SYSTEM:ABS$CONVERT_CATALOG.COM”) that improves the target catalog update performance by doing a file-to-file conversion. By converting the target catalogs, you improve catalog update time.

$ @ABS$SYSTEM:ABS$CONVERT_CATALOG MyCatalog

$ @ABS$SYSTEM:ABS$CONVERT_CATALOG MyCatalog DKA100:[ABS_CATALOGS]

$ @ABS$SYSTEM:ABS$START_CATALOG_CLEANUP "CATLG1 CATLG2 CATLG3" "+2-"

$ DEFINE/SYSTEM ABS_CATALOG_VAOE_CLEANUP 1

21:21:07   COORD: Staging process PID :  2300143C
21:21:07   COORD: Staging catalog :      ABS$CATALOG:ABS_CATALOG_4.STG;1
21:21:07   COORD: Staging procedure :    ABS$CATALOG:ABS_CATALOG_4_1.COM;1
21:21:07   COORD: Staging logfile :      ABS$LOG:ABS_CATALOG_4.LOG

This name is used to reference the environment in save and restore requests. There are no required conventions for environment names, but ABS uses an ad-hoc convention that pairs environments and archives. If you specify an archive of name FOO, then by convention there should be a matching environment named FOO_ENV. You can choose to follow or ignore this convention for your site.

The action attribute specifies one of three possible actions to be performed on files saved using this environment. Specify one of the following three actions:

Although RECORD_DATE is supported for VMS_FILES only, it remains the default for all data types, and is simply ignored for the other types.

ABS supports the following types of compression for UNIX clients:

It is recommended that you either use the default UNIX environment (UNIX_BACKUPS_ENV) or a single user-created environment for all your UNIX client saves, using a single type of compression for all UNIX saves. If you mix compression types among your UNIX saves, you should be very careful to assign the appropriate environment on any restore. If you specify the wrong compression option on a restore, then ABS will not be able to restore the data. The default is no compression.

The environment object allows you to specify one or more data safety features to ensure the reliability of the data on your offline tape volumes. You can select one or more of the following options:

CRC - Performs a Cyclic Redundancy check and writes it for each data block on a tape volume. This enables detection of a bad block during a restore operation.

FULL_VERIFY - Rereads all saved data and compares to what is on disk during a save. This option approximately doubles the time for the data copy phase of a save operation.

XOR - If the CRC check detects a bad block during a restore operation, the XOR mechanism allows recovery of the block. This option is applicable only to data type VMS_FILES, for which the backup agent is VMS BACKUP.

By default, all three options are enabled for maximum data safety.

The drive count specifies the number of tape drives to use for each save or restore using this environment. If there are at least as many drives available as the drive count, that number of drives are allocated for each save and restore request. If not, a reduced number of drives are allocated.

The default and highly recommended value is 1. The number of drives may range from 1 to 32.

The prologue and epilogue attributes in the environment allow you to invoke a command procedure before and/or after the entire save or restore request. This allows you to perform pre-processing and post-processing operations around the entire request. Compare the order of environment prologue and epilogue procedures operations to the individual save and restore prologue and epilogue procedures, which are executed before and/or after each file or disk specification in the save or restore request. The order of execution is illustrated below:

ABS defines logical names that can be used within the prologue or epilogue command procedure. These are defined in the process job table as follows:

You should enter an OpenVMS command of up to 80 characters in the prologue and/or epilogue strings. For example:

@ABS$SYSTEM:ABS_ENV_PROLOGUE.COM

By default, there are no prologues or epilogues defined for an environment.

The retry limit and retry interval options allows you to specify the number of times and how often ABS should retry a object in a save or restore request before operator intervention is required. Specify the following:

Each time a retry attempt is made, ABS generates a warning message. If you wish to see the warning messages, select the warning option in the when attribute for notification.

For UNIX clients, ABS provides the option to either backup UNIX symbolic links only, or to follow the UNIX symbolic links and backup up the data as well. The default is to backup the symbolic links only (not the data).

In addition, ABS allows you to backup only the root file system (such as the disk the root directory resides on) or an entire file system if the filesystem spans physical devices. The default is nospan filesystems, which copies the root file system only.

Both attributes apply to data type UNIX_FILES only.

The listing option allows you to specify the type of listing generated for save and restore requests using this environment. Specify one of the following options:

If not specified, NONE is the default option.

ABS allows you to specify what a save request should do when data usage conflicts occur by means of the lock attribute. If you specify lock, ABS saves the data even if other applications have the data locked for write access. If you specify nolock ABS does not save the data if other applications have the data locked for write - this is the safer approach. If you specify lock, it is possible that the data you save is inconsistent, as the other application may be writing to the file during the actual save operation. Use lock with caution. The default is nolock.

ABS uses the notification attributes in the environment to determine who, how and under what circumstances users are notified of ABS events during save and restore operations. ABS supports notification using mail, OPCOM or both. You can specify up to 32 separate notification options in each environment, using the following attributes:

You associate a TYPE and WHEN for each MAIL or OPCOM option provided. If you do not specify a TYPE and/or WHEN, a notification option acquires a TYPE of BRIEF and a WHEN of COMPLETE.

If you specify no notification options, then by default ABS sends a brief OPCOM message to class TAPES on completion of every request executed under the environment.

ABS allows you to specify the user name, node name, cluster name, rights and privileges under which save or restore requests in the environment will execute. ABS supports three main options for username:

It is recommended that you only specify a user profile for user backups. All other backups should run under the default ABS user profile.

You must assign a unique name to each save and restore request, which is used as the only method of referencing the request. There are no required conventions associated with save and restore names. However, in previous ABS versions, the names could be generated automatically so you might see names that are a combination of the creation date of the request and a generated unique identifier (UID) if you are converting from pre-V4 ABS. For version V4 and later, ABS almost always references saves and restores by name rather than UID, and ABS no longer shows UIDs by default.

Each save or restore requests is associated with one or two archives, which contain information about where the backed up data is stored. The two archives are for those requests that involve both full and incremental operations: the first archive applies to the full operations and the second applies to the incremental operations. In this way, fulls and incrementals can reside on different volume sets with their own retention days or expiration dates. In other types of request, only one archive is used.

If you do not specify an archive, ABS chooses SYSTEM_BACKUPS.

The base date is the date and time that you wish the request to first execute on a regular basis. The base date is used for two purposes:

Unless you want to change the scheduling or save type basis for the request, you would not change the base date. As such, the base date will remain a date in the past. Compare this to the start date, which specifies the next start date and time for the request. The start date is updated whenever the request is run to reflect the next time it is scheduled, or NONE if it is not scheduled again.

When a request is first created, and you specify only one of the dates, both dates are set (i.e. the next start date is the base date). By default, neither a base date or start date are supplied so the request is not scheduled for execution.

You can use the start date and skip time to request a one-time special, or non-scheduled, execution of the request. For example, assume that the normal scheduled time for a request is 23:00, as specified in the base date. However, you know that this is a particularly busy night and you want to start this request for tonight only at 21:00 instead. You can do this by setting the start date to 21:00. However, when the request is rescheduled, it will be rescheduled to the next iteration of the base date, or 23:00 the same day. You probably do not want this, so to avoid it you can set the start date together with a skip time to avoid running the request twice. The skip time is an exclusion time (expressed as a delta time) from the specified start date in which the request will not be rescheduled: normally you can set this to one day to avoid running the request twice in the same day. The following table shows some examples of base date, start date and skip time definitions based on a daily frequency:

When you specify a skip time, ABS saves it in the database until the request is next rescheduled. When the rescheduling takes place, the skip time is applied to the calculation, then cleared from the database. If you set a skip time and do not see it in the request, then it has already been applied to the next start date.

When restoring files, you can choose a specific iteration of the files based on their archive date - that is, the date that they were saved in the archive. If you know the exact date archived, use the data archived attribute. If you know only an approximate date archived, use the before or since attributes to specify a range of dates. So, for example, if you wish to restore a file as it existed in the first week of January, you can specify a before date of the 8th January (at midnight), or a since date of 1st January (at midnight). When determining appropriate before or since dates, you should probably lookup the files in the catalog before requesting a restore, so that you can specify before and since dates that uniquely identify a single iteration of the file to restore.

The before and since dates in the restore apply only to the archive date of the file. They are not related to the before and since dates in the selection object, which refer to files’ online dates that are maintained by OpenVMS.

On a restore, you can specify a catalog name instead of an archive name if you know the name of the catalog from which to locate the restore information, and do not know the name of the archive. Normally, however, you would specify the archive under which the data was saved rather than the catalog.

One of the more obvious attributes of a save or restore request are the file names, disk names path names or database names that you wish to save or restore. There are two options for specifying these names in a save or restore request:

When you specify disk, file and database names by including them in the save and restore request, then you are effectively creating a default selection object. This selection object has the same name as the save or restore, with the suffix “_SAVE_SEL_DEL” or “_REST_SEL_DEF” respectively. You can specify the following attributes directly in the save or restore request for inclusion in the default selection:

The following table shows examples of the appropriate file, disk, path or database names that are valid for each data type:

$1$DUA420: (full disk, physical name)
DISK$USER1: (full disk, logical name)
DISK$USER1:[SMITH...]*.*;* (selective)
DISK$USER1:[SMITH]LOGIN.COM;3 (file)

If you prefer to use selection objects directly (which enable you to specify additional selection criteria), then create a selection as shown in Section 3.3, then include the selection in the SELECTIONS attribute in the save or restore request. You can include up to 24 selections in a save or restore request with the caveat that a maximum of 24 disk, file or database file specifications (in total) are supported in a single save or restore request.

Some saves and most restores are intended to be run only once, and have a frequency of ONE TIME ONLY. With this in mind, ABS automatically deletes such requests after a defined interval after the request has executed. This interval is the delete interval and can be customized for each save and restore request. If not specified, all ONE TIME ONLY requests are deleted approximately 3 days after execution: the actual delete is performed by a daily scheduled activity which runs at a certain time every day. If the frequency is something other than ONE TIME ONLY, ABS does not automatically delete the request. If the delete interval is set to NONE, then the request is deleted the next time the scheduled activity runs after execution of the request.

If you do not wish to have these requests automatically deleted, then set the keep attribute. This flags the request to be kept indefinitely and clears the delete interval.

ABS allows you to restore data to a different disk, directory, file system or pathname from where the data was saved. This is useful if you wish to make additional copies of data from the archive. If you wish to restore to a different location, enter the disk, directory, file system or pathname in the destination attribute of the restore. If not specified, the data is restored to the original source location of the data.

The environment attribute specifies an environment object name for this request. An environment contains attributes relating to how the request is executed. For example, an environment specifies data safety options, notification options and user profile. If not specified, the environment SYSTEM_BACKUPS_ENV is selected if available, otherwise DEFAULT_ENV is selected.

ABS supports very flexible options for scheduling save and restore requests, both using the internal MDMS scheduling options and using a third part scheduler. The scheduling options can be divided into three main categories:

Select from one of the following frequencies:

Every save or restore request can be flagged as an incremental operation or a non-incremental operation. An incremental operation saves or restores files based on a previous operation - either a full operation or another incremental operation. For example, you could define a save request that performs a full disk save on Sunday, and an incremental save request that performs incremental saves on Monday through Saturday. The incremental saves will only save files that have been created or modified since the previous save (whether full or incremental). Restores can be performed in a similar fashion.

By default, saves and restores are not flagged as incremental. If you wish to define an incremental save or restore, then set the incremental attribute.

It is important to point out that if you execute an incremental save 127 times in a row without an intervening FULL save, then the 128th “incremental” save will actually be a full save. This rule actually applies to each individual file, disk, path or database specification within the save request, and as such, it is possible for the various files, disks, paths or databases within a single save request to be backed up at different incremental levels, or have a mixture of fulls and incrementals. As such, it is recommended that you intersperse a non-incremental (full) save at least once a week to avoid unexpected full backups on saves/restores marked incremental and to reduce the restore time required with a large number of incrementals. If you are mixing FULL and INCREMENTAL save requests, use the same catalog for both save requests so that the FULL catalog entry will be found and used as a base for the incrementals.

ABS always performs save and restore operations on an OpenVMS execution node, under the control of the ABS coordinator process. Only one execution node actually executes any particular save or restore request at a particular time, but you can specify a list of compatible nodes using either the nodes or groups attributes. At execution time, the node list or group list is scanned in order to determine the execution node, and ABS will attempt to schedule the operation on the first such node. If ABS fails to establish a connection to that node, it will try the next node on the list, and so on until the request is successfully submitted.

For data types VMS files and Oracle databases of all types, the execution node is also the node where the data resides. Therefore, all execution nodes or groups must have access to the data being saved or restored. For data types UNIX files and Windows files, the execution node is the node running the ABS coordinator process, not the UNIX or Windows node on which the data resides: that node is specified by the SOURCE NODE attribute in the save or restore (or selection).

If you wish to enter nodes individually, enter a comma-separated list of nodes in the NODES attribute or select a list of nodes from the GUI. Enter the MDMS node object name (which should be the same as the DECnet Phase IV name if DECnet is running) - do not specify the TCP/IP name or DECnet Phase V fullname.

MDMS supports the notion of groups, whereby you can associate a list of nodes which have something in common (for example, nodes in a cluster) into a group, and simply reference the group name. In this case, you can simply enter one or more group names in the GROUPS attribute.

The NODES attribute and GROUPS attribute are mutually exclusive - you have to choose which one to enter.

If you enter neither nodes nor groups, then ABS enters the node from which the save or restore was created in the NODES attribute.

The prologue and epilogue attributes in the save or restore request allow you to invoke a command procedure before and/or after each disk, file, path or database specification in the request. This allows you to perform pre-processing and post-processing operations around individual save or restore iterations. Compare the order of save and restore prologue and epilogue procedures operations to the environment prologue and epilogue procedures, which are executed before and/or after the entire save or restore request. The order of execution is illustrated below:

ABS defines logical names that can be used within the prologue or epilogue command procedures. Each name is suffixed by “_n”, where n is the iteration number for each include disk, file, path or database specification. The value for n starts at 1 and goes to 24, the maximum number of include specifications supported by ABS. These logical names are defined in the process job table as follows:

The reschedule attribute is used to create a new job with an external scheduler product. Normally, when you create a save or restore request, ABS creates a new scheduler job for the request. If you modify the request, then ABS modifies the existing scheduler job. However, there are circumstances whereby the scheduler job is deleted and needs to be re-created. You can set the reschedule attribute to re-create a new scheduler job for the request. This attribute has no effect when MDMS scheduling is in operation.

As discussed in section 3.2.3.6, you can specify the files, disks, paths or databases to be included in a save or restore request in one of two ways:

The SELECTION attribute is how you associate a selection object with a save or restore request. Simply include the selection names as a comma-separated list in the selections attribute. If you wish to have no selections and use the default selection, specify no selections.

A save operation involves a data copy phase and a post-processing phase. For archive type TAPE, the post-processing phase does not require the use of a tape drive, so ABS could start on the next data copy phase using the drive before the post-processing phase of the previous operation is complete. This option speeds up the total save operation - if you want to use this option, specify OVERLAPPED as the sequence option. If, on the other hand, you prefer the data copy and post-processing phases to be performed sequentially, enter SEQUENTIAL for the sequence option.

By default, the sequence option is set to SEQUENTIAL.

This feature allows the system administrator to prevent scheduling of operations on certain dates as operators are not available to service requests.

As stated earlier, the start date specifies the next start date and time for the request. This start date is updated whenever the request is run to reflect the next time it is scheduled, or NONE if it is not scheduled again.

Before a calculated date is assigned to the start date, it is compared against a list of holidays which is loaded into memory from MDMS$DATABASE_LOCATION:HOLIDAYS.DAT at start up.

If the calculated date matches any of the holiday definitions, this date is ignored and we search further for the next valid start date. This process continues until we find a calculated date that does not match any of the holiday definitions and hence can be assigned to the start date.

At start up time, the MDMS server reads all the records in HOLIDAYS.DAT and loads the valid holiday definitions in memory. Definitions that do not confirm to the stated record format are ignored. The valid holiday definitions loaded in memory are displayed in:

$ MDMS SHOW DOMAIN/FULL

By default, there are no holiday definitions. If the system administrator wishes to define a list of holidays, a HOLIDAYS.DAT file has to be created in the database location where the MDMS DATABASE files are present (MDMS$DATABASE_LOCATION:HOLIDAYS.DAT).

dd-mmm-yyyy,xxxxxxxxxxx

dd—is the day
mmm—is the first three letters of the month
yyyy—is the year
xxxxxxxx—is the name of the holiday

04-JUL-2002,Independence Day
02-SEP-2002,Labor Day
28-NOV-2002,Thanksgiving
25-DEC-2002,Christmas

ABS uses a backup agent to perform saves and restores, and the backup agent is dependent on the data type as follows:

Although ABS passes information that you specify in the save, restore and environment to the backup agent, you can pass qualifiers directly to the backup agent using the agent qualifiers attribute. Refer to the appropriate backup agent documentation for information on these qualifiers.

For save requests, you can select files for saving based on the date files were last modified. You can specify either or both of the following:

If you specify both a before and since date, you are providing a range of dates in which to select files. If a file does not have a revision date (modified date), then ABS uses the creation date instead.

ABS does not yet support the date type attribute, which would allow you to select any one of the four online dates maintained by OpenVMS.

When restoring files, you may find that there are files of the same name already located in the destination directory or original source location. You can specify what ABS should do if it encounters this situation by specifying one of the following conflict options:

If not specified, the default is RETAIN VERSION.

In exactly the same manner as in save and restore requests, you can specify the following attributes in selection objects directly:

The following table shows examples of the appropriate file, disk, path or database names that are valid for each data type:

With ABS custom scheduling, you can actually define one schedule to execute after another schedule has completed. For example, if you want SAVE2 to execute immediately after SAVE1 completes, you can modify SAVE2’s schedule object and setting its AFTER SCHEDULE attribute to SAVE1’s schedule object. In this case:

• SAVE2_SAVE_SCHED:
• After Schedule: SAVE1_SAVE_SCHED

If you specify an after schedule and only want the associated request to execute after the after schedule (and not at any other time), then do not specify any other date or time attributes in the schedule. If on the other hand you want the associated request to execute at regular times AND after the specified after schedule, then you can associate date and time attributes to the schedule.

With after schedule, you can also define conditions upon which the schedule will run after the other schedule. The conditions are stored in an attribute called after schedule when. Select from one of the following:

If an after schedule name is defined, but no conditions are specified, the default condition is ALL. To remove the after schedule dependency, specify no after schedule.

For ABS save and restore commands, the command to run a schedule and execute the associated save and restore request is:

MDMS RUN SCHEDULE schedule_name

You should not modify this command line, unless you know how to activate an ABS request in some other way.

For non-ABS save or restore requests, this command line can be any command that can be submitted to the OpenVMS CLI.

There is a restriction with using the /AFTER_SCHEDULE qualifier. Only those schedules (created automatically by MDMS) that have an associated save can be assigned to the /AFTER_SCHEDULE qualifier. Schedules that do NOT have an associated save cannot be assigned to the /AFTER_SCHEDULE qualifier. Hence, any schedule (one with an associated save, or one which executes DCL commands) can have a dependency on a schedule with an associated save, but not on a schedule which executes DCL commands. This is a current MDMS design limitation.

ABS supplies three attributes in the schedule object by which you can specify on what days you want the schedule to be regularly executed. These are:

You can specify the actual dates in the month that you want the schedule to run by number. Here are some examples:

If you do not specify a date attribute, the default is every day of the month.

You can specify the actual day in the week that you want the schedule to run by name. Here are some examples:

If you do not specify a day attribute, the default is every day of the week.

Finally, you can specify the actual months in the year that you want the schedule to run by name. Here are some examples:

If you do not specify a month attribute, the default is every month of the year.

The dates, days and months attributes work together so that all must qualify for the schedule to be run. Therefore if you specify days SUN, but months of JAN, JUL only, then the schedule only runs on Sundays in January and July.

The following table shows some examples of how the days, dates and months attributes work together to produce custom schedules.

If there are schedules that cannot be accommodated by this scheme, then you can use the INCLUDE and EXCLUDE attributes as explained below.

Although the days, dates and months attributes can produce a very flexible scheduling scheme, there may be specific days that you want to include or exclude regardless of the regular schedule. You can do this using the following attributes:

The dates are specified in the standard OpenVMS format DD-MMM-YYYY, and can range from the current date to up to 10 years in the future. Only dates may be specified, not times. Specification of include and exclude dates override the regular schedule as determined by the dates, days and months attributes.

You can also use the include and exclude attributes to augment the days, dates and months in situations that they do not cover what you want. For example, to run on the last day of every month, you can specify DATES 31, DAYS MON-SUN and MONTHS JAN-DEC, then specifically include 28-Feb, 30-Apr, 30-Jun, 30-Sep, 30-Nov.

ABS allows you to specify times that you wish your schedule to run. Normally a schedule runs only once per day, but ABS allows you the flexibility to specify up to 100 times per day for a schedule to run. Simply specify times in the times attribute as a comma-separated list. Be careful to not specify so many times that the schedule executions overlap each other.

The domain attribute ABS_RIGHTS controls whether a user having certain pre-V4.0 ABS rights can map these to MDMS rights for security purposes (see Chapter 5 for more information about rights). Setting the attribute allows the mapping, and setting the attribute to false disallows the mapping.

The right MDMS_APPLICATION_RIGHTS is a high-level right that maps to a set of low level rights suitable for MDMS applications (for example, ABS and HSM). Normally these rights should not be changed, or at least not reduced from the default settings otherwise ABS and HSM may not function correctly. You may add rights to application rights if you have your own MDMS applications or command procedures. The ABS and MDMS$SERVER accounts should have MDMS_APPLICATION_RIGHTS granted in the User Authorization File.

The check access attribute determines if access controls are checked in the domain. MDMS uses two forms of security: Rights and Access Control. Rights checking is a task-oriented form of security and is always performed. However, access control is an object-oriented form of security and can be optionally enabled or disabled with this attribute. Setting Check Access enables access control checking. Clearing Check Access disables access control checking even if there are objects with access control entries.

When a volume is deallocated after its data has expired, it may go into one of two states. The transition state is an interim state that the volume goes into after deallocation, but it is not eligible to be used again until a period of time called the transition time expires. This is a safety feature that allows you to examine whether the data has legitimately expired, and if not to retain the volume (put back to the allocated state). If you do not wish this feature, you can disable the transition state and allow volume to return directly to the free state, where it is eligible for immediate allocation and initialization for new data. The domain deallocate state is applied to all volumes that are automatically deallocated by MDMS. When manually deallocating volumes, you can override the domain deallocate state with a state on the deallocate operation itself.

The MDMS default rights attribute maps a set of MDMS low-level rights to all users in the domain. This allows you to give all users a limited set of rights to access MDMS objects and perform operations, without having to expressly modify their accounts. Be aware that default rights are applied to all users on all nodes in the domain, so granting such rights should be carefully reviewed. By default, MDMS maps no rights to the default rights.

When MDMS deallocates volumes based on their scratch date (an operation that is performed once per day), it sends a mail message indicating which volumes were deallocated to the set of users defined in the mail users attributes. You should enter a list of users in the format node::username. Every user in the list will receive the deallocate volume mail messages. This mail address is also used when the ABS catalog unpack process encounters an error.

The maximum scratch time is the maximum scratch time that can be applied to any volume when it is allocated. The scratch time is the period of time that you wish the volume to stay allocated because its data is still valid. The maximum scratch time imposes a maximum limit and overrides the volume’s scratch time if it exceeds the maximum. For HSM, the maximum scratch time should be set to zero (unlimited), as HSM volumes’ data remains valid until it is repacked. For ABS uses, this value should be set to the longest period of time you wish to retain any volume.

The domain media type attribute is the media type that is applied to new volumes and drives by default when they are created. In a simple configuration, you may only have a single media type, so specifying it in the domain allows you to not have to specify it when creating individual drives and volumes. It may also be applied as a default to ABS archives. You may always override the domain default media type with a specific media type when you create or modify drives and volumes.

The domain offsite location attribute is applied by default to the offsite location field of new volumes when they are created. The offsite location is an MDMS location that is used for secure storage of the volumes in case of a disaster. You can always override the domain default offsite location when you create or modify volumes.

The domain onsite location attribute is applied by default to the onsite location field of new volumes when they are created. The onsite location is an MDMS location that is used for storage of the volumes when they are onsite, or quickly accessible to jukeboxes and drives. You can always override the domain default onsite location when you create or modify volumes.

The domain OPCOM classes attribute contains the default OPCOM classes that are applied to new node objects by default when they are created. OPCOM classes are classes of users whose terminals are enabled to receive certain OPCOM classes. You can override the domain default OPCOM classes with specific classes on a per-node basis when you create or modify a node.

The right MDMS_OPERATOR_RIGHTS is a high-level right that maps to a set of low level rights suitable for operators managing the domain. The default set of operator rights allow for normal operator activities such as loading and unloading volumes into drives, showing any object or operations, and moving volumes offsite and onsite. However, you can add or remove low level rights to/from the operator rights as you wish.

The domain protection attributes defines the default protection applied to new volumes when they are created. This protection is used by MDMS when it initializes volumes, and writes the protection on the magnetic tape volume itself. You can always override the domain default protection by specifying the protection specifically when creating or modifying a volume.

The relaxed access attribute controls the security when a user or application tries to access an object without any access control entries, and access control checking is enabled. If relaxed access is set, such access is granted. If relaxed access is clear, such access is denied. The relaxed access attribute is ignored if the check access attribute is clear.

MDMS uses sequentially increasing request identifiers for each request received by the MDMS database server, and this attribute displays the ID of the next request. If this ID is becoming very large, you can reset it to zero or one (or indeed any value) if you wish. The request ID automatically resets to one when it reaches one million.

MDMS performs scheduling operations on behalf of itself and ABS. For ABS scheduling, you can choose a scheduler type that best meets your needs, as follows:

MDMS-initiated scheduled operations such as MDMS$MOVE_VOLUMES always use the internal MDMS scheduler.

The domain default scratch time is the default scratch time applied to new volumes when they are created. Scratch time indicates how long a volume is to remain allocated (that is, how long its data is valid and needs to be kept). You can override the domain volume scratch time when you create, modify or allocate individual volumes. For HSM volumes, the scratch time should be set to zero (unlimited), since HSM data remains valid until a volume is repacked.

MDMS uses user account rights as one mechanism for security within the domain. MDMS allows you to control whether the OpenVMS privilege SYSPRV can map to the ultimate MDMS right MDMS_ALL_RIGHTS. If you set the SYSPRV attribute, users with SYSPRV are assigned MDMS_ALL_RIGHTS, which means they can perform any operation subject to access control checks. Clearing SYSPRV gives users with SYSPRV no special rights.

The domain default transition time is applied to volumes by default when they are deallocated into the transition state. The transition time determines how long the volumes remain in the transition state before moving to the free state. This attribute is used alongside the deallocation state attribute, which determines the default state that volumes are deallocated into. You can override the domain default transition time when you create, modify, or deallocate a volume.

The right MDMS_USER_RIGHTS is a high-level right that maps to a set of low level rights suitable for non-privileged users that perform ABS or HSM operations. The default set of user rights allow for user activities such as creating and manipulating their own volumes and loading and unloading those volumes into drives, showing their volumes. However, you can add or remove low level rights to/from the user rights as you wish.

The access attribute controls whether the drive may be used from local access, remote access or both. Local access includes direct SCSI access, access via a controller such as the HSJ70, access via TMSCP, or access via Fibre Channel, and does not require use of the Remote Device Facility (RDF). Remote access is via a DECnet network requiring RDF. You can set the access to one of the following:

Automatic reply is the capability of polling hardware to determine if an operator-assist action has completed. For example, if MDMS requests that an operator load a volume into a drive, MDMS can poll the drive to see if the volume was loaded, and if so complete the OPCOM request without an operator reply. Set automatic reply to enable this feature, and clear to require an operator response. Please note that some operations cannot be polled and always require an operator reply. The OPCOM message itself clearly indicates if a reply is needed or automatic replies are enabled.

The device attribute is the OpenVMS device name for the drive. In many cases you can set up the drive name to be the OpenVMS device name, and this is the default when you create a drive. However, the drive name must be unique within the domain, and since the domain can consist of multiple clusters there may be duplicate device names across the domain. In this case you must use different drive names from the OpenVMS device names. Also, you can specify simple or descriptive drive names which are used for most commands, and hide the OpenVMS device in the device name attribute.

By default, drives are enabled, meaning that they can be used by MDMS and its applications. However, you may wish to disable a drive from use because it may need repair or be used for some other application. Set the disable flag to disabled the drive, and clear the flag to enable the drive.

If the drive is in a robotically-controlled jukebox, and the jukebox is controlled by MRD, you must set the drive number to the relative drive number in the jukebox used by MRD. Drives in jukeboxes are numbered from 0 to n, according to the SCSI addresses of the drives. Refer to the jukebox documentation on how to specify the relative drive number.

The groups attribute contains a list of groups containing nodes that have direct access to the drive. Direct access includes direct-SCSI access, access via a controller such as an HSJ70, access via TMSCP, and access via Fibre Channel. You can specify as many groups as you wish, in addition to nodes that may not be in a group.

If the drive is in a jukebox, you must specify which jukebox using the jukebox attribute. Enter a valid jukebox name from an MDMS-defined jukebox. If there is no jukebox, MDMS treats the drive as a standalone drive or as a stacker.

A drive must support one or more media types in order for volumes to be used on the drive. In the media type attribute, specify one or more MDMS-defined media types that this drive can both read and write. If you wish, you can restrict the media types to a subset that you wish this drive to handle, and not all the media types it could physically handle. In this way, you can restrict the drive’s usage somewhat.

The nodes attribute contains a list of nodes that have direct access to the drive. Direct access includes direct-SCSI access, access via a controller such as an HSJ70, access via TMSCP, and access via Fibre Channel. You can specify as many nodes as you wish, in addition to groups of nodes in the groups attribute.

In addition to media types that a drive can read and write, a drive may support one or more additional media types that it can only read. In the read-only media type attribute, specify one or more MDMS-defined media types that this drive can only read. This allows this drive to be used when the application operation is read-only (for example, HSM unshelves or ABS restores). Do not duplicate a media type in both the media type list and read-only media type list.

You can designate whether a drive is to be used by MDMS applications and users only, or by non-MDMS users. If the drive is not shared, the MDMS server process allocates the drive on all clusters to prevent non-MDMS users and applications from allocating it. However, when an MDMS user attempts to allocate the drive, MDMS will deallocate it and allow the allocation. Set the shared attribute if you wish to share the drive with non-MDMS users, and clear if you wish to restrict usage to MDMS users. ABS users who do their own user backups are considered MDMS users, as are all system backups and HSM shelving/unshelving users.

Certain types of drive can be configured as a stacker, which allows a limited automatic sequential loading capability of a set of volumes. Such drives may physically reside in a loader or have specialized hardware that allows stacker capabilities. If you wish the drive to support the stacker loading capability, set this attribute and make sure the jukebox attribute does not contain a jukebox name. If you wish the drive to operate as a jukebox or standalone drive, clear this attribute.

The drive state field determines the load state of the drive. The drive can be in one of four states:

This is a protected field that is normally handled by MDMS. Only modify this field if you know that there are no outstanding requests and the new state reflects the actual state of the drive.

You allocate a drive so that you can it for reading and writing data to a volume. If you allocate a drive, your process ID and node is stored in the MDMS database, and the drive is allocated in OpenVMS for your process. Because the MDMSView GUI does not operate in a process context, it is not possible to allocate drives from the GUI.

You can either allocate a drive by name, or you can specify selection criteria to be used for MDMS to select an available drive for you and allocate it. The allocation selection criteria include:

You can also specify the following options when allocating a drive:

If you allocated a drive using the DCL “Allocate Drive” command, you should deallocate the drive when you are finished using it, otherwise the drive will remain allocated until your process exits.

Simply issue a deallocate drive and specify the drive name or the logical name obtained from the define option in “Allocate Drive”.

MDMS supports two ways to load volumes into drives:

This section discusses the load drive option. The load volume option is discussed under volumes.

The “Load Drive” operation requests either that a scratch volume (in the free state) be loaded into the drive, or the next volume in the stacker is loaded into the drive. In either case, the volume ID of the volume is not known until the load completes, and MDMS reads the magnetic tape label to determine the volume.

The loaded volumes may or may not already be defined in the MDMS database. You can choose to create volume records by setting the “Create” flag, and optionally providing attributes to apply to the volume as follows:

When issuing the load drive request, you can specify whether the load is for read/write (almost always the case) or read-only, and whether operator assistance is required.

You can also specify an alternative message for the operator. This is included in the OPCOM message instead of the normal MDMS operator message. Use of an alternative message is not recommended.

When initiating a load from the DCL, you can choose a synchronous operation (default) or an asynchronous operation using the /NOWAIT qualifier. From MDMSView, a load is always asynchronous, so that you can continue performing other tasks.

Unlike the load drive operation, the unload drive can be applied to any type of drive at any time. What it does is simply unload the current volume in the drive, and so you can use this when you don’t know which volume is in the drive. Alternatively, you can use the unload volume operation if you know the volume ID in the drive.

The only option for unload drive is to request operator assistance if needed.

When initiating an unload from the DCL, you can choose a synchronous operation (default) or an asynchronous operation using the /NOWAIT qualifier. From MDMSView, an unload is always asynchronous, so that you can continue performing other tasks.

The list of nodes that comprise the group. Nodes must be OpenVMS nodes that are defined in the MDMS database. You should not use groups for non-OpenVMS nodes (for example, ABS UNIX or Windows clients).

The access attribute controls whether the jukebox may be used from local access, remote access or both. Local access includes direct SCSI access, access via a controller such as the HSJ70, or access via Fibre Channel, and does not require use of the Remote Device Facility (RDF). Remote access is via a DECnet network requiring RDF. You can set the access to one of the following:

For DCSC-controlled jukeboxes, the ACS identifier specifies the Automated Cartridge System Identifier. Each MDMS jukebox maps to one Library Storage Module (LSM), and requires the specification of the Library, ACS and LSM identifiers.

Automatic reply is a capability of polling hardware to determine if an operator-assist action has completed. For example, if MDMS requests that an operator move a volume into a port, MDMS can poll the port to see if the volume is there, and if so complete the OPCOM request without an operator reply. Set automatic reply to enable this feature, and clear to require an operator response. Please note that some operations cannot be polled and always require an operator reply. The OPCOM message itself clearly indicates if a reply is needed or automatic replies are enabled.

For DCSC-controlled jukeboxes equipped with Cartridge Access Points (CAPs), this attribute specifies the number of cells for each CAP. The first number is the size for CAP 0, the second for CAP 1, and so on. If a size is not specified, a default value of 40 is used. Specifying a cap size optimizes the movement of volumes to and from the jukebox by filling the CAP to capacity for each move operation.

The control attribute determines the software subsystem that performs robotic actions in the jukebox. The control may be one of the following:

By default, jukeboxes are enabled, meaning that they can be used by MDMS and its applications. However, you may wish to disable a jukebox from use because it may need repair or be used for some other application. Set the disable flag to disabled the jukebox, and clear the flag to enable the jukebox.

The groups attribute contains a list of groups containing nodes that have direct access to the jukebox. Direct access includes direct-SCSI access, access via a controller such as an HSJ70, and access via Fibre Channel. TMSCP access is not supported for jukeboxes. You can specify as many groups as you wish, in addition to nodes that may not be in a group.

For DCSC-controlled jukeboxes, the Library identifier specifies the library that this jukebox is in. Each MDMS jukebox maps to one Library Storage Module (LSM), and requires the specification of the Library, ACS and LSM identifiers.

The location attribute specifies the physical location of the jukebox. Location can be used as a selection criterion for selecting volumes and drives. Specify an MDMS-defined location for the jukebox. This location may be the same as, or different from, the onsite location that volumes are stored in when not in a jukebox. If different, moves from the jukebox to the onsite location and vice versa will be done in two phases: jukebox to jukebox location, then jukebox location to onsite location, and vice versa.

For DCSC-controlled jukeboxes, the Library Storage Module (LSM) identifier specifies the LSM that comprises this jukebox. Each MDMS jukebox maps to one Library Storage Module (LSM), and requires the specification of the Library, ACS and LSM identifiers.

The nodes attribute contains a list of nodes that have direct access to the jukebox. Direct access includes direct-SCSI access, access via a controller such as an HSJ70, and access via Fibre Channel. TMSCP access to jukeboxes is not supported. You can specify as many nodes as you wish, in addition to groups of nodes in the groups attribute.

For MRD-controlled jukeboxes, the robot name is the OpenVMS device name of the robot device. Robot names normally fall into one of several formats:

If the jukebox is controlled by direct connect SCSI (first option), the device must be first loaded on the system with one of the following DCL commands:

Alpha - $ MCR SYSMAN IO CONNECT GKxxx/NOADAPTER/DRIVER=SYS$GKDRIVER.EXE

VAX - $ MCR SYSGEN CONNECT GKxxx/NOADAPTER/DRIVER=GKDRIVER

I64 - $ MCR SYSMAN TO CONNECT GKxxx/NOADAPTER/DRIVER=SYS$GRDDRIVER.EXE

and the device name must begin with GK.

For MRD jukeboxes, the slot count is simply the number of slots (which can contain volumes) in the jukebox. Volumes reside in numbered slots when they are not in a drive. Slots are numbered from 0 to (slot count - 1). Filling in this field is optional: MDMS calculates the slot count by polling the jukebox firmware.

The state attribute is a protected field that describes the current state of the jukebox. A jukebox can be in one of three states:

This field is normally maintained by MDMS, so you should not modify it unless a problem has occurred that needs manual cleanup (for example, the robot is stuck in the in-use state when it is clear that it is not in-use).

MDMS provides the capability of monitoring the number of free volumes in a jukebox. A free volume is one that is available for allocation and writing new data. Many users would like to maintain a minimum number of free volumes in a jukebox to handle tape writing needs for some period of time. You can specify a threshold value of free volumes, below which an OPCOM message is issued that asks an operator move some more free volumes into the jukebox. In addition, the color status of the jukebox in MDMSView changes to yellow if the number of free volumes falls below the threshold, and to red if there are no free volumes in the jukebox. If you wish to disable threshold OPCOM messages and color status, set the threshold value to 0.

The topology attribute specifies the physical configuration of a certain type of jukebox when it is being used with magazines. Topology is only useful when all of the following conditions are true:

You specify the topology of the jukebox so that you can move magazines into and out of the jukebox by specifying a position rather than a start slot.

For each tower in the jukebox, you specify the number of faces in the tower, the number of levels in each face, and the number of slots in each level. For TL820-class jukeboxes, the typical values for each tower are 8 faces, 2 or 3 levels per face and 11 slots per level. The associated magazine contains 11 slots and fits into a position specified by tower, face and level. Other jukeboxes may vary.

The usage attribute determines whether this jukebox is set up to use magazines, and has two values:

You should only set usage to magazine if you plan to use MDMS magazine objects and move all the volumes in the magazines together. An alternative is to move individual volumes separately, even if they reside in a physical magazine; in this case set usage to nomagazine.

MDMS provides the capability to inventory jukeboxes, and “discover” volumes in them and optionally create volumes in the MDMS database to match what was discovered. With this feature, you can simply place new volumes in the jukebox and let MDMS create the associated volume records with attributes that you can specify.

There are two types of inventory:

You can inventory whole jukeboxes, or specify a volume range or slot range, as follows:

While inventorying jukeboxes, MDMS can find volumes that are defined and in the jukebox, that are not defined but are in the jukebox, and that are defined but missing from the jukebox. MDMS provides several options to handle undefined and missing volumes.

If you set the “Create” flag during an inventory, MDMS will create a volume record for each undefined volume it finds in the jukebox. You can specify in advance certain attributes to be applied to this volume record:

If you do not set the “Create” flag, then MDMS will not create new volume records for undefined volumes it finds.

Conversely, you can also define what to do if a volume that should be in the jukebox (according to the database) is found not to be in the jukebox. There are three options that you can apply using the “Missing” attribute:

When initiating an inventory from the DCL, you can choose a synchronous operation (default) or an asynchronous operation using the /NOWAIT qualifier. From MDMSView, an inventory is always asynchronous, so that you can continue performing other tasks.

The parent location is an MDMS location object which is the next level up on the location hierarchy. For example, a location SHELF1 might have a parent location ROOM2, indicating that SHELF1 is in ROOM2. You should define a parent location only if you wish all locations belonging to the parent (including the parent itself) to be compatible when selecting volumes and drives. For example, in a hierarchy of SHELF1 and SHELF2 in ROOM2, volumes in any of the three locations would match a request to allocate a volume from ROOM2. Do not use the location hierarchy for other purposes.

Locations can contain spaces, that are used in OPCOM messages when volumes and magazines are being moved from one place to another. Enter a range of spaces in an alphanumeric range separated by a dash. Examples of space ranges are 1-10, A-Z, AAA001-AAA099, 10A-10Z.

The jukebox name contains the name of the jukebox if the magazine is in a jukebox. When in a jukebox, a magazine can optionally have a start slot or position, as follows:

All three fields are protected and normally managed by MDMS when a “Move Magazine” operation occurs. Only manipulate these fields if an error occurs and you need to recover the database to a consistent state.

When not in a jukebox, a magazine may be either in an onsite or offsite location. An onsite location is one where the magazine can be quickly accessed and moved into a jukebox, which is also onsite. An offsite location is meant to be a secure location in the case of disaster recovery, and generally does not have local access to a jukebox. However, nothing in MDMS precludes the possibility of offsite locations having their own jukeboxes.

Each magazine should have an onsite and offsite location defined, so that operators know where the magazine is physically located. They use these locations, the jukebox name and the placement to determine where a jukebox is at a certain time. Both onsite and offsite locations should be MDMS-defined location objects.

Together with the offsite and onsite locations, you can associate an offsite and onsite date. These dates represent the date the magazine is due to be moved offsite or onsite respectively. Typically, magazines are moved offsite while their volumes’ data is still valid and needs to be protected in a secure location. When the volumes’ data expires, the magazine should be scheduled to be brought onsite, so that the newly-freed volumes can be used for other purposes.

If an offsite and/or onsite date is specified, MDMS initiates the movement of the magazines at some point on the scheduled date automatically. This is performed by the “Move Magazine” scheduled operation, which by default runs at 1:00 am each day. Operators will see OPCOM messages to move the magazines to either the onsite or offsite location.

If you do not wish to have MDMS move magazines automatically, either remove the onsite and offsite dates from the magazine, or disable the scheduled “Move Magazine” activity by assigning a zero time to its schedule object “MDMS$MOVE_MAGAZINES”.

The slot count specifies how many slots are in the magazine. Unlike jukeboxes, this value is required to make magazines work properly.

While in an onsite location, the magazine can occupy a space, which is a labelled part of a location that uniquely identifies where the magazine is. A space can be designed to handle a single volume, but since magazines hold multiple volumes, multiple spaces can also be assigned. Enter either a space or a range of spaces for the magazine.

The supported way to move magazines from one place to another is to use the “Move Magazine” operation. You can move magazines on demand by issuing this operation, or you can let MDMS automatically move magazines according to pre-defined onsite or offsite dates (this is called a “scheduled” move). You can also force an early scheduled move if you want it to occur before the time that MDMS would initiate the move. Moving magazines into jukeboxes must always be performed manually.

When intiating a “Move Magazine”, you can choose a destination for the magazine if the move is not a scheduled move. The destination can be one of three types of places:

If you want to force a scheduled move, you can select “Scheduled”. In most cases, the destination is predefined, so you don’t need to specify it. However, you can specify an alternative destination for the scheduled move if you wish by specifying a destination as outlined above.

Finally, you can specify if you need operator assistance. This is recommended with “Move Magazine” as magazines cannot be moved without human intervention. Only if you plan to do the physical move yourself or you manually let someone know would you disable operator assistance.

The capacity attribute indicates the capacity of the media in MB. This field is not used by ABS or HSM, but is used by the obsolete product “Sequential Media Filesystem” (SMF).

This important field indicates whether you wish the tape to be written with firmware compaction. Enabling compaction usually doubles the capacity of the tape, so this is a desirable option which is set by default. Clear the attribute if you do not wish compaction.

This field indicates the density of the tape that you desire. Many types of tape media (especially DLT tapes) support multiple densities, and certain types of drive can either read and write a certain density, or just read some densities. As such, you can define many media types with different densities that can be assigned to volumes and drives.

MDMS uses the density field when initializing volumes, so the density must be a valid Open- VMS density for the version of the operating system being used. Issue a “HELP INITIALIZE /DENSITY” command to determine the valid densities on the platform.

The length field is used for information purposes only. If your media comes in various lengths, you can differentiate between types by using the length field. Specify an integer value that has meaning to your operators.

MDMS operates as a group of co-operating processes running on multiple nodes in multiple clusters in an MDMS domain. One of these MDMS processes is known as the “Database Server”, and it actually controls all MDMS operations in the domain. Although only one node is the database server at any one time, you should enable multiple nodes to be possible database servers in case the actual database server node fails. In this way, failover is supported.

A database server must have direct access to the database files located in MDMS$DATABASE_LOCATION. Direct access, access via MSCP, and access via Fibre Channel are all considered local access. Access via a network protocol or DFS are not considered local access. It is recommended that you enable at least 3 nodes as potential database servers to ensure failover capabilities.

Set to disable the node as an MDMS node. Clear to enable the node as an MDMS node.

You can specify the OPCOM classes to be used by MDMS for operator messages on this node. By default, the domain default OPCOM classes are used, but you can override this on a node-bynode basis. Specify one or more of the standard OpenVMS OPCOM classes - messages are directed to all login sessions with these OPCOM classes enabled.

You can define which network transports are defined for this node. There are four choices:

If you identify TCP/IP as a supported transport, you must define the TCP/IP fullname in the TCP/IP fullname field. These fullnames are normally in the format “node.loc.org.ext”. For example, SLOPER.CXO.CPQCORP.COM

If you identify DECnet as a transport, you need to specify a DECnet full name only if you are using DECnet-Plus (Phase V). In this case, enter the full name, which is normally in a format such as LOCAL:.node. If you are running DECnet Phase IV, do not specify a DECnet full name. The node’s node name is used.

You can specify a list of authorized users for the pool, as a comma-separated list of users. Each user should be specified as node::username or group::username, where both the node/group and username portions can contain wildcard characters (*%). To authorize everyone, you can specify *::*. To authorize everyone on a node you can specify nodename::*. Everyone in the authorized user list is allowed to allocate volumes in the pool. Other users require MDMS_ALL_RIGHTS or MDMS_ALLOCATE_ALL rights.

Default users are authorized like the authorized users, but in addition are assigned this pool as their default pool. In this case, if they attempt to allocate a volume and don’t specify a pool, they will allocate a volume from this pool. A particular user need only appear in one list: they do not need to be listed in both lists to be an authorized user to their default pool.

Pools are useful for dividing volumes between groups or organizations, but they are only useful is there are free volumes in the pool. MDMS provides the capability of monitoring the number of free volumes in a pool. A free volume is one that is available for allocation and writing new data. Many users would like to maintain a minimum number of free volumes in a pool to handle tape writing needs for some period of time. You can specify a threshold value of free volumes, below which an OPCOM message is issued that asks an operator add some more free volumes to the pool. In addition, the color status of the pool in MDMSView changes to yellow if the number of free volumes falls below the threshold, and to red if there are no free volumes in the pool. If you wish to disable threshold OPCOM messages and color status, set the threshold value to 0.

The account, username and UIC fields are filled in automatically when a volume is allocated, and reflect the calling user or specified user during the allocate. The username is a valid Open- VMS username on the client system performing the allocate, and the account and UIC is from the user’s entry in the system Authorization (UAF) file.

These fields are normally maintained by MDMS and are protected fields. You should not modify these fields unless the volume is deallocated. MDMS maintains the Account, Username and UIC in the volume even after the volume is deallocated, so that you can “retain” the volume back to the allocated state in case of accidental deallocation.

The job name field is not used by ABS, HSM or MDMS.

There are several dates that maintain or control allocation and movement dates for volumes. These are as follows:

If an offsite and/or onsite date is specified, MDMS initiates the movement of the volumes at some point on the scheduled date automatically. This is performed by the “Move Volumes” scheduled operation, which by default runs at 1:00 am each day. Operators will see OPCOM messages to move the volumes to either the onsite or offsite location.

If you do not wish to have MDMS move volumes automatically, either remove the onsite and offsite dates from the volume, or disable the scheduled “Move Volumes” activity by assigning a zero time to its schedule object “MDMS$MOVE_VOLUMES”.

The history dates are maintained by MDMS, but are for information purposes only. MDMS does not use these dates to perform any operations. The following history dates are maintained:

The state field indicates where in a volume’s life cycle the volume exists. The state field itself is protected, and you should not normally adjust it unless an error occurs. However, you can “Update State” using certain keywords, which checks for validity and results in a consistent database state.

A volume can be in one of the following states, which are shown in normal life-cycle order:

A picture showing the normal state transitions is provided at the top of the volumes section.

While changing the state directly is not recommended, there are several options for changing state that are supported:

A volume’s media types define the type of media for the volume, and what potential compaction or density options the volume can support. As such, before a volume is initialized, it can potentially support many media types. However, once a volume is initialized, MDMS uses the density and compaction attributes from a media type to physically write the tape. As such, a volume should only support one media type at and after the first initialization.

If the volume is in the Uninitialized state, select one or more MDMS-defined media types for the volume. If the volume is in any other state, select a single media type. If no media type is specified, the domain default media type is used.

A pool contains a collection of volumes that can be used by a set of authorized users. To insert a volume into a pool, simply specify a pool name in the volume’s pool field. If not defined, the volume is placed in the “scratch pool”, and it can be allocated by any user. If the volume is in the free state, the number of free volumes in the pool is incremented.

These read-only fields indicate if a volume is in a volume set, and what the previous and next volumes are in the set, relative to this volume. A volume set is created when a tape write operation reaches end-of-tape and a new tape is required to complete the operation. ABS and HSM bind the next volume to the current volume, and create a volume set.

These fields are manipulated by “Bind Volume” and “Unbind Volume” operations, both manually and under control of MDMS applications.

The placement fields of a volume indicate where the volume resides, and where it should reside when moved to an onsite or offsite locations. The placement attributes include the following:

The format fields are not used by ABS, HSM or MDMS, but can be used to document certain characteristics of the volume and its data format. The fields are as follows:

The protection field provides System, Owner, Group and World access protection for the volume. This protection is written to the volume when it is initialized, and provides protection from unauthorized use and re-initialization. The standard protection is:

SYSTEM(R, W) OWNER (R, W) GROUP (R) WORLD (None)

If protection is not set for the volume, the domain default protection is used.

MDMS provides three counters for volumes, as follows:

You allocate volumes so that you can use them for writing new data. Allocating a volume places it into the Allocated state, and assigns the calling user (or specified user), UIC, and account in the allocation fields. This effectively reserves the volume to the user. The volume remains allocated to the user and unavailable for other use until the scratch date is reached, or unless the volume is manually deallocated.

When allocating a volume, you may specify the user for which you are allocating the volume (for example, ABS). If you do not specify a user, then you as the calling user are placed in the allocation fields.

Also, during allocation, you can change the following fields in the MDMS database to reflect the format to be used on the tape:

Instead of allocating a volume by name, you can specify selection criteria to be used for MDMS to select a free volume for you and allocate it. You can also allocate a volume set by specifying a count of volumes to allocate. The allocation selection criteria include:

If you specify a volume count of more than one, then that many volumes will be allocated and placed in a volume set. If you also use the “Bind Volume” selection option, the new volume set is bound to the specified volume set.

You can also specify that you wish to change certain attributes of the volume as follows:

MDMS normally deallocates volumes when their scratch date expires. However, you can deallocate volumes manually in order to free them up earlier than planned. You can deallocate your own volumes, or with the appropriate rights deallocate volumes allocated to other users.

If the volume is in a volume set, the volume is also unbound from the volume set.

The following options are available when you deallocate a volume:

Binding volumes is the way to create volume sets, by binding one volume (or volume set) to another volume (or volume set). Normally, MDMS applications such as ABS and HSM perform automatic binding when they reach end-of-tape. However, it is sometimes necessary to perform manual binding. For example, if a volume set has been accidentally deallocated but is still needed, you may need to manually bind the set together (although the retain feature does this quite well).

There are only two options when binding a volume set:

When you bind a new volume to a volume or volume set, the new volume acquires the following attributes of the volume set:

The next and previous volumes are also updated appropriately.

Unbinding a volume removes the volume from the volume set without deallocating it. When unbinding a volume you can choose whether to unbind the entire volume set, or break the volume set at the point of the unbind. You can also unbind on behalf of the allocated user.

There are only two options for unbind:

MDMS supports two ways to load volumes into drives:

This section discusses the load volume option. The load drive option is discussed under drives.

When loading a specific volume, you normally need to specify the drive in which to load the volume, unless a drive has been specifically allocated for a volume (via DCL only). Select a drive with a compatible media type for the volume.

If you are loading a volume into a jukebox drive, and the volume is not in the jukebox, you can specify an automatic “Move Volume” request to move the volume into the jukebox is desired. If you do not specify this option, and the volume is not in the jukebox, the operation will fail.

Another option is to request MDMS to check the volume label. This is normally a good idea as there can be mismatches between the volume’s magnetic label and its bar code label. If the labels do not match, the load fails. If you do not set the label check flag, the load may succeed but the label may be wrong. Use this option with caution.

When issuing the load volume request, you can specify whether the load is for read/write or read-only, and whether operator assistance is required.

You can also specify an alternative message for the operator. This is included in the OPCOM message instead of the normal MDMS operator message. Use of an alternative message is not recommended.

You can unload a specific volume from a drive by issuing the “Unload Volume” operation. Unlike the “Unload Drive” operation which unloads any volume from the drive, the “Unload Volume” function checks the label on the volume on the drive before unloading it. If the label can be read and does not match the specified volume, the unload fails.

There is only one option for unload volume - operator assistance. This is recommended unless you are personally monitoring the unload operation.

The supported way to move volumes from one place to another is to use the “Move Volume” operation. You can move volumes on demand by issuing this operation, or you can let MDMS automatically move volumes according to pre-defined onsite or offsite dates (this is called a “scheduled” move). You can also force an early scheduled move if you want it to occur before the time that MDMS would initiate the move. Moving volumes into jukeboxes or magazines must always be performed manually.

When intiating a “Move Volume”, you can choose a destination for the volume if the move is not a scheduled move. The destination can be one of four types of places:

If you want to force a scheduled move, you can select “Scheduled”. In most cases, the destination is predefined, so you don’t need to specify it. However, you can specify an alternative destination for the scheduled move if you want, by specifying a destination as outlined above.

Also, you can specify whether you need operator assistance to move volume(s) or allow MDMS to move them independently. For example, if you give the MDMS MOVE VOLUME request along with the /PORT qualifer for moving volume(s) to outport(s), MDMS completes the request without operator's assistance based on the availability of free ports.

For every MDMS MOVE VOLUME request, you can view the volume(s) move status. Appropriate OPCOMs are displayed informing the success or failure of a particular MOVE VOLUME request. If operator’s a

MDMS supports initialization of volumes to make them available for use. Initializing a volume consists of writing an ANSI label on the volume, and applying compaction and density attributes and the volume protection field in the label. The volume is then free to be written. If the volume was in the Uninitialized state, it will now change to the Free state. All volumes need to be initialized at least once before ABS and HSM can allocate and use them.

Volumes that are already written need to be initialized again if you wish to use the whole volume for writing again. Both ABS and MDMS initialize volumes on every allocation.

When initializing volumes, you can specify four options:

Once MDMSView is started, it will come up with the default look and feel for the system. For OpenVMS systems, this is the Java/Metal look and feel. For Windows systems, this is the Windows look and feel. You can adjust the look and feel to your taste by using the View menu as follows:

Changing the look and feel requires a new login, so it’s a good idea to change this before logging in. The value is saved in the MDMSView initialization file, and is used on all subsequent invocations from this location.

Once MDMSView is started and the look and feel is set, you need to log into an OpenVMS system, even if you are running on an OpenVMS system already. You can log into any OpenVMS node in the MDMS domain, as long as it supports TCP/IP communication. Logging in requires three fields, as follows:

If there is a login failure for any reason, the node name and user name are retained for subsequent retries, but the password must always be re-entered.

After a successful login, the login screen disappears and the MDMSView splash screen is displayed.

The next step is to select a view depending on what you want to do. Here are some tasks that you might wish to perform, and the associated view(s) that support them:

The domain view and object view produce attribute and operation screens that work on one object at a time. The task view produces screens that can operate on multiple objects, but restrict the display of attributes to those that are common across the objects. The request view is a specialized view that allows you to show current requests (as a whole or in detail), and allows you to delete requests as needed. The report view is a specialized view that generates customized volume reports.

All view displays are divided into two parts:

While resizing the MDMSview screens is not supported, you can choose to view only the left or right screens by using the arrows at the top of the division between the left and right screens. Clicking on the left arrow eliminates the left screen, and clicking on the right arrow eliminates the right screen. To restore the dual screens, click on the opposite arrow.

If you wish to create a new object, you can choose the Domain, Object or Task Views to accomplish this. The Domain and Object Views create objects one at a time, while the Task View can create multiple objects.

To create an object, use one of the following methods:

Once a create screen appears, (except for catalogs) you are prompted for two pieces of information:

The domain and object views allow creation of only one object at a time, whereas the task view allows a comma-separated list of new objects (and also ranges in the case of volumes). Depending on the view, enter the name or names of the new objects you wish to create.

The inherit object allows you to copy most of the attributes from the inherit object to the object being created. If you wish to specify an inherit object, use the combo box to select the existing inherit object. This must be the same type of object, except in the case of restores, in which case you can inherit from either a restore or a save object.

After clicking create, the new object attribute and operations screens appear, which you can then modify to your liking. In the task view, this screen modifies all the newly created objects.

For objects that already exist, you can use the Domain View, Object View or Task View to show and optionally modify objects, or to perform operations on them.

To view an object, use one of the following methods:

When an object is selected, its attributes and operations are displayed in a two-dimensional tab screen as follows:

If you select the Show screen and wish to modify attributes, use the tool tip text for help on any field. Select appropriate values (from all the show tabs as needed), then click on Set. This sends the currently displayed values from all tabs to the MDMS server. If you just wish to view the object’s attributes without modification, click on Cancel after viewing the attributes. This returns you to the object class screen.

MDMSView supports switching from one object to another during displaying of values. For objects that appear in combo boxes or lists, you can view related objects without losing the context of the current object. Each combo box or list attribute supports two methods of viewing, selecting and creating objects:

From the menu, there are the following options:

If you select Show or Create, you will go to an appropriate screen. When you then complete your operation on that object, you will come back to the original object.

You can delete objects from the Domain, Object and Task Views. To delete an object, perform one of the following:

A request to delete an object will always bring up a Delete dialog box for confirmation of the delete. You can confirm “OK” or “Cancel” from here.

The Domain view provides a way to view the hierarchical structure of the MDMS domain. The left side of the screen provides an object-class-object... hierarchy of objects belonging to other objects, or objects contained in other objects. The left side of the screen displays most of the object classes which contain other objects (the exceptions: selections, schedules and volumes, which have no sub-objects). You can begin the hierarchical navigation at any level, and all sublevels can be displayed.

For example, starting at jukebox, you can view all objects that reside in a jukebox: Drives, Magazines and Volumes. If you then click on Drives, you will see all drives in this jukebox. If you then select a drive and click on it, you can see the volume in the drive.

If your domain is sufficiently complex, you might want to expand the left side of the screen by using the right arrow between the left and right screen. You can then view the entire hierarchy of the domain.

If you wish to perform an operation on an object (for example, to load a volume into a drive), you should first display the object’s attributes and operations screens. Then select the desired operation tab, on the right side of the screen. For example, to load a volume, show the volume then click on the Load tab.

The load tab is called an operations tab, and they all follow the same basic concepts. You enter options concerning the operation (for example, operator assistance), then press the appropriate operation button on the bottom left of the screen. This button is always labelled with the appropriate operation (for example, Load).

MDMS has the capability of performing long-running operations synchronously or asynchronously. However, in MDMSView, long-running operations are always submitted asynchronously and control is returned to the user. Asynchronous operations show a dialog box that states that the operation has been queued for processing, but has not yet completed. If you perform an operation that does not result in the dialog box, then you can safely assume it has been completed synchronously.

If you receive a “queued” dialog box, it does not necessarily mean that the operation was fully validated. If you want to check on the status of the operation, use the Request View to monitor the request’s progress.

MDMS treats saves and restores in the same manner as other objects that it manages. You can create new saves and restores in the same way that you create other objects, then select a start time for them to run. Clicking Set will schedule the save or restore to run at the requested start date and time.

From MDMSView, however, there is an additional mechanism to run a save or restore. If you wish to run the request immediately, press the “Run” button at the bottom of the Show screen. This initiates an immediate run of the save or restore.

Once you run a save and restore request, you can monitor its progress by pressing the “Log” tab for the save or restore. This tab provides an up-to-date display of the request’s log file.

The Request View provides a monitoring capability for all current MDMS operations. You can display all current requests by clicking on Show Requests - this results in a table of requests being displayed. This includes all current requests, and some recently-completed requests.

You can also expand the requests on the left side of the screen and click on a specific request for detailed information about the request. Or you can right-click on the request number on the left screen and select Show.

If you feel that a request is not working correctly, or for any reason you wish to delete the request, you can click on delete from the detailed request screen, or select a request number on the left screen, right-click and select delete from the popup menu.

As with other deletes, a dialog box will appear to confirm the delete of the request.

The Report View provides the capability of generating custom reports on volumes. With this view, you can choose attributes that can be displayed and/or used as selection criteria for volumes.

To select an attribute for display, simply click on the attribute and then press the right arrow button to move it to the display screen. The attributes are displayed in the report in the order selected. If you change your mind or wish to re-order the attributes, select an attribute on the display screen and press the left arrow button to deselect it.

If you wish to use an attribute as a selection criterion, click on the attribute, then click on “Use for Selection”. This will enable a field below (either a text field or combo box) to allow you to enter a selection.

You may display any number of fields and use any number of selection criteria to customize the report. When your selections are ready, you can generate the report by clicking on “Generate”. You can see the resultant report in the “Report Results” tab.

If you wish to save this report, enter a report title in the text field at the bottom of the screen and click on save. The report is saved to the following locations:

For example, a report file name is: Report_2001_12_17_8_35_17.txt.

Once the results screen is displayed, you can sort the report using any field by clicking on the field’s header. You can reverse-sort the same field by clicking on the field header again.

To examine past operations in MDMS, you can use the event view to view the MDMS audit and event logfile. There are five pre-configured options and a fully flexible custom option to allow you to select what you wish to see from the MDMS logfile. The five pre-configured options all apply to the MDMS Database Server logfile and show all operations (auditing and events) for the following amounts of time before the current time:

If you wish to see the logfile using other selection criteria, you can use the “Custom” setting. By clicking on “Custom”, a selection screen appears that allows you to select the entries to be displayed as follows:

After entering the selection criteria, you click on the Show button to display. Depending on the size of the log file, this operation may take several seconds to complete. You may want to regularly reset your log files to avoid long response times. The code has been written to scan previous versions of log files if the date and or request selections are not in the latest log file.

The Refresh button at the bottom of the screen refreshes whatever selection is currently on the screen. The Cancel button allows you to enter a new selection.

MDMSView can report two types of errors:

MDMSView provides three types of help:

The MDMS DCL interface uses a consistent syntax for virtually all commands in the format.

$ MDMS VERB OBJECT_KEYWORD OBJECT_NAME /QUALIFIERS

The verb is a simple action word, and may be one of the following:

The object keyword is the object class name that the verb is to operate on. In MDMS, the object keyword cannot be omitted. MDMS supports the following object keywords:

Following the object keyword, you should enter an object name. This must be the name of an already-existing object unless the verb is “Create”, in which case the object must not already exist.

The qualifiers for all commands are non-positional and may appear anywhere in the command line.

There are two exceptions to the general command syntax, as follows:

With this release of MDMS, all of the following commands accept a list of objects, so that you can operate on multiple objects in a single command:

If you specify an attribute in a CREATE or SET command and use an object list, then that attribute value is applied to all objects in the list.

Certain qualifiers accept a list of attributes, and the list can be applied in one of three ways using an appropriate qualifier:

Consider the following examples:

MDMS CREATE GROUP COLORADO/NODES=(DENVER, SPRINGS, PUEBLO)

The group Colorado contains nodes Denver, Springs and Pueblo

MDMS SET GROUP COLORADO/NODE=ASPEN

The group Colorado now contains nodes Denver, Springs, Pueblo and Aspen. With no list qualifier specified, /ADD is applied by default.

MDMS SET GROUP COLORADO/NODE=ASPEN/REPLACE

The group Colorado now contains only node Aspen.

All MDMS objects now accept the /INHERIT qualifier on Create. This allows you to create new objects and inherit most attributes of an existing object. This provides an easy way to “clone” objects, then apply the any differences in individual commands. It saves the effort of typing in all the attributes once a prototype has been established. In general, only non-protected fields of objects can be inherited.

In addition, the object list capability allows you to clone multiple objects in a single command. For example:

MDMS CREATE DRIVE DRIVE_2, DRIVE_3, DRIVE_4/INHERIT=DRIVE_1

This command creates three drives and applies all non-protected attributes of DRIVE_1 to the three new drives.

MDMS now supports symbols on all objects which command procedures can read and process. To use symbols, enter a Show command for a single object. You can define a prefix other than the default one (MDMS_INQ). If prefix is not specified the default prefix is MDMS_INQ. The maximum length of the prefix is 8 characters. This qualifier is supported for wildcard show requests.

The symbols are generally in the format “MDMS_INQ_qualifier”, where “qualifier” is almost always the associated qualifier name for the attribute. The list of symbols for each show command is documented for that command, and is also available in DCL help.

When you issue a Show/Symbols, the show output is not displayed by default. If you wish to see the output as well, use Show/Symbols/Output.

MDMS supports the normal DCL help mechanisms, as follows:

$ MDMS HELP [VERB] [KEYWORD] [/QUALIFIER]
$ HELP MDMS [VERB] [KEYWORD] [/QUALIFIER]

In addition, you can request help on any error message, for example:

MDMS HELP MESSAGE NOSUCHOBJECT

You can request help on any MDMS logical name, for example:

MDMS HELP LOGICAL MDMS$LOGFILTER

Finally, you can locate the mapping of the old (pre-version 4.0) ABS commands to the MDMS equivalent, for example:

MDMS HELP MAPPING CREATE ARCHIVE

The VSI MDMS Reference Guide fully documents all DCL commands and qualifiers.

The easiest way to save your system disk is by using an ABS SAVE object like this:

Save: SYSTEM_DISK
Description: System Disk Backup for Recovery
Access Control: NONE
Owner: BONFYR::FROEHLIN
Archive: DISASTER_RECOVERY
Base Date: NONE
Delete Interval: NONE
Environment: DISASTER_RECOVERY_ENV
Epilogue:
Execution Nodes: BONFYR
Explicit Interval:
Frequency: DAILY
Groups:
Incremental: NO
Job Number: 0
Prologue:
Schedule: SYSTEM_DISK_SAVE_SCHED
Sequence Option: SEQUENTIAL
Skip Time: NONE
Start Date: NONE
Transaction Status:
Selections: SYSTEM_DISK_SAVE_SEL_DEF
Default Selection -
- Data Select Type: VMS_FILES
- Include: $1$DUA300:
- Exclude:
- Source Node:

This SAVE uses the standard archive of DISASTER_RECOVERY and the standard environment of DISASTER_RECOVERY _ENV which comes with ABS. If these objects do not exist on your system run the ABS database initialization program:

$ RUN SYS$SYSTEM:ABS$DB_INIT

This program adds all the missing default ABS objects to the MDMS database.

Saving an OpenVMS system disk online produces many errors for files open for write by the operating system and layered products. Even though, the image backup produced can be used to restore a bootable system disk. The problem comes when executing the site-specific SYSTARTUP_VMS.COM. For example when starting the OpenVMS Queue Manager the command could hang because the Queue Manager files had been saved in an inconsistent state. There are three ways to avoid these kind of problems.

Backing up MDMS$ROOT with ABS will always find the MDMS database files open for write. This cannot be avoided. To copy the contents of these files in a consistent way online copies should be made prior to starting the save request. You can use the standard MDMS command procedure to do this:

$ @MDMS$SYSTEM:MDMS$COPY_DB_FILES

This command procedures uses DCL CONVERT/SHARE to create file copies with a file extension of “*.DAT_COPY”. This can be automatically done by executing this command procedure in the prolog of the environment. All files with that extension can then can be automatically deleted in the epilog of the environment.

See ABS$SYSTEM:ABS$DISASTER_RECOVERY.TEMPLATE for an example.

If MDMS$ROOT is not located on your system disk or you want a separate save operation, you can use a separate SAVE object like this:

Save: DISASTER_RECOVERY
Description:
Access Control: BONFYR::ABS (READ, WRITE, EXECUTE, DELETE, SET,
SHOW,
CONTROL)
Owner: BONFYR::ABS
Archive: DISASTER_RECOVERY
Base Date: NONE
Delete Interval: NONE
Environment: DISASTER_RECOVERY_ENV
Epilogue: @ABS$SYSTEM:ABS$DISASTER_RECOVERY.COM EPILOG
Execution Nodes: BONFYR
Explicit Interval:
Frequency: ON_DEMAND
Groups:
Incremental: NO
Job Number: 0
Prologue: @ABS$SYSTEM:ABS$DISASTER_RECOVERY.COM PROLOG
Schedule: DISASTER_RECOVERY_SAVE_SCHED
Sequence Option: SEQUENTIAL
Skip Time: NONE
Start Date: NONE
Transaction Status:
Selections: DISASTER_RECOVERY_SAVE_SEL_DEF
Default Selection -
- Data Select Type: VMS_FILES
- Include: MDMS$ROOT:[000000...]*.*;*
- Exclude: [*...]*.LOG;*,[*...]*_DB.DAT;*
- Source Node:

This save request excludes all the files open for write by MDMS and therefore does not create any error messages in the save log file.

If you want you can combine the save of the MDMS$ROOT and the ABS$ROOT into one save object.

Backing up ABS$ROOT with ABS will always find the ABS log files open for write because a save request always has a catalog file open for write. Not all catalog files might be accessible through ABS$ROOT. For example if you have created a search list for ABS$CATALOG and extensions to ABS$CATALOG point to other directories and/or disk devices.

If ABS$ROOT is not located on your system disk or you want a separate save operation, you can use a separate SAVE object like this:

Save: DISASTER_RECOVERY
Description:
Access Control: BONFYR::ABS (READ, WRITE, EXECUTE, DELETE, SET,
SHOW,
CONTROL)
Owner: BONFYR::ABS
Archive: DISASTER_RECOVERY
Base Date: NONE
Delete Interval: NONE
Environment: DISASTER_RECOVERY_ENV
Epilogue: @ABS$SYSTEM:ABS$DISASTER_RECOVERY EPILOG
Execution Nodes: BONFYR
Explicit Interval:
Frequency: DAILY
Groups:
Incremental: NO
Job Number: 0
Prologue: @ABS$SYSTEM:ABS$DISASTER_RECOVERY PROLOG
Schedule: DISASTER_RECOVERY_SAVE_SCHED
Sequence Option: SEQUENTIAL
Skip Time: NONE
Start Date: NONE
Transaction Status:
Selections: DISASTER_RECOVERY_SAVE_SEL_DEF
Default Selection -
- Data Select Type: VMS_FILES
- Include: ABSS$ROOT:[000000...]*.*;*,
- Exclude: [*...]COORD_CLEANUP.DAT;*,[*...]*.LOG;
- Source Node:

If this object does not exist on your system run the ABS database initialization program:

$ RUN SYS$SYSTEM:ABS$DB_INIT

This program adds all the missing default ABS objects to the MDMS database.

This save request excludes all the files open for write by ABS like the current logfile and the database file used by the coordinator cleanup process (“ABS$COORD_CLEAN”). There should not be any error message in the save log file.

You have to make sure that you use the DISASTER_RECOVERY archived with an empty catalog name defined. The disaster recovery archive is the only archive which allows no catalog name. Otherwise you get open and verify errors for the catalog being used.

If you have an extended ABS$CATALOG search list, then you have to include the extra entries in the include specification as well. By default the catalog subdirectory is included under ABS$ROOT.

If you want, you can combine the save of the MDMS$ROOT and the ABS$ROOT into one save object.

To restore your system disk you need to use Standalone BACKUP.

Use the information from the ABS save log to specify the parameters for the BACKUP command line:

$ BACKUP/IMAGE MKA500:24DEC20012359590./LABEL=(GKF011,GKF022) -
_$DGA100:/NOASSIST

This restores an image of your system disk in saveset “24DEC20012359590.” on tape volumes “GKF011” and “GKF022” to disk device “DGA100”.

After a successful restore, boot from your restored system disk. If your system does not boot all the way through you may have to disable the execution of your “SYSTARTUP_VMS.COM” command procedure by using a conversational boot and renaming the file.

Once your system is up-and-running you can restore other save sets necessary to complete the disaster recovery: Make sure that all of these components or products are shut down before you restore the individual files. Use the following restore order:

Use the information from the ABS save log to specify the parameters for the BACKUP command lines:

$ BACKUP/NOASSIST/OVERLAY -
$_MKA500:25DEC20010101010./LABEL=(GKF033,GKF044)-
$_DGA100:[VMS$COMMON.ABS.*...]/LOG

Because ABS has not been started up the ABS$ROOT logical is not available yet. This restores the ABS$ROOT files in saveset “24DEC20012359590.” on tape volumes “GKF033” and “GKF044” to disk location “DGA100:[VMS$COMMON.ABS...]”. This assumes that you ABS$ROOT logical was defined as a concealed device name of “DGA100:[VMS$COMMON.ABS.]”.

Starting up RDF software:

RDF software is automatically started up along with then MDMS software when you enter the following command:

$ @SYS$STARTUP:MDMS$STARTUP

Shutting down RDF software:

To shut down the RDF software, enter the following command:

$ @SYS$STARTUP:MDMS$SHUTDOWN

Required privileges:

The following privileges are required to execute the RDSHOW procedure: NETMBX, TMPMBX.

In addition, the following privileges are required to show information on remote devices allocated by other processes: SYSPRV, WORLD.

You can run the RDSHOW procedure any time after the MDMS software has been started. RDF software is automatically started at this time.

Use the following procedures:

$ @TTI_RDEV:RDSHOW CLIENT
$ @TTI_RDEV:RDSHOW SERVER node_name
$ @TTI_RDEV:RDSHOW DEVICES

node_name is the node name of any node on which the RDF server software is running.

To show remote devices that you have allocated, enter the following command from the RDF client node:

$ @TTI_RDEV:RDSHOW CLIENT

Result:

RDALLOCATED devices for pid 20200294, user DJ, on node OMAHA::
Local logical    Rmt node    Remote device
TAPE01           MIAMI::     MIAMI$MUC0

DJ is the user name and OMAHA is the current RDF client node.

The RDSHOW SERVER procedure shows the available devices on a specific SERVER node. To execute this procedure, enter the following command from any RDF client or RDF server node:

$ @TTI_RDEV:RDSHOW SERVER MIAMI

MIAMI is the name of the server node whose devices you want shown.

Result:

Available devices on node MIAMI::
Name         Status   Characteristics/Comments
MIAMI$MSA0   in use   msa0
...by pid 20200246, user CATHY (local)
MIAMI$MUA0   in use   mua0
...by pid 202001B6, user CATHY, on node OMAHA::
MIAMI$MUB0   -free-   mub0
MIAMI$MUC0   in use   muc0
...by pid 2020014C, user DJ, on node OMAHA::

This RDSHOW SERVER command shows any available devices on the server node MIAMI, including any device characteristics. In addition, each allocated device shows the process PID, username, and RDF client node name.

The text (local) is shown if the device is locally allocated.

To show all allocated remote devices on an RDF client node, enter the following command from the RDF client node:

$ @TTI_RDEV:RDSHOW DEVICES

Result:

Devices RDALLOCATED on node OMAHA::
RDdevice   Rmt node    Remote device   User name   PID
RDEVA0:      MIAMI::    MIAMI$MUC0       DJ          2020014C
RDEVB0:      MIAMI::    MIAMI$MUA0      CATHY        202001B6

This command shows all allocated devices on the RDF client node OMAHA. Use this command to determine which devices are allocated on which nodes.

The Network Control Program (NCP) is used to change various network parameters. RDF (and the rest of your network as a whole) benefits from changing two NCP parameters on all nodes in your network. These parameters are:

Pipeline quota

The pipeline quota is used to send data packets at an even rate. It can be tuned for specific network configurations. For example, in an Ethernet network, the number of packet buffers represented by the pipeline quota can be calculated as approximately:

buffers = pipeline_quota / 1498

Default:

The default pipeline quota is 10000. At this value, only six packets can be sent before acknowledgment of a packet from the receiving node is required. The sending node stops after the sixth packet is sent if an acknowledgment is not received.

Recommendation:

The PIPELINE QUOTA can be increased to 45,000 allowing 30 packets to be sent before a packet is acknowledged (in an Ethernet network). However, performance improvements have not been verified for values higher than 23,000. It is important to know that increasing the value of PIPELINE QUOTA improves the performance of RDF, but may negatively impact performance of other applications running concurrently with RDF.

Line receive buffers

Similar to the pipeline quota, line receive buffers are used to receive data at a constant rate.

Default:

The default setting for the number of line receive buffers is 6.

Recommendation:

The number of line receive buffers can be increased to 30 allowing 30 packets to be received at a time. However, performance improvements have not been verified for values greater than 15 and as stated above, tuning changes may improve RDF performance while negatively impacting other applications running on the system.

As stated in DECnet-Plus(Phase V), (DECnet/OSI V6.1) Release Notes, a pipeline quota is not used directly. Users may influence packet transmission rates by adjusting the values for the transport’s characteristics MAXIMUM TRANSPORT CONNECTIONS, MAXIMUM RECEIVE BUFFERS, and MAXIMUM WINDOW. The value for the transmit quota is determined by MAXIMUM RECEIVE BUFFERS divided by Actual TRANSPORT CONNECTIONS.

This will be used for the transmit window, unless MAXIMUM WINDOW is less than this quota. In that case, MAXIMUM WINDOW will be used for the transmitter window.

The DECnet-Plus defaults (MAXIMUM TRANSPORT CONNECTIONS = 200 and MAXIMUM RECEIVE BUFFERS = 4000) produce a MAXIMUM WINDOW of 20. Decreasing MAXIMUM TRANSPORT CONNECTIONS with a corresponding increase of MAXIMUM WINDO may improve RDF performance, but also may negatively impact other applications running on the system.

This section describes how to change the network parameters for DECnet Phase IV and DECnet- PLUS.

The pipeline quota is an NCP executor parameter. The line receive buffers setting is an NCP line parameter.

The following procedure shows how to display and change these parameters in the permanent DECnet database. These changes should be made on each node of the network.

$ run sys$system:NCP
NCP>show executor characteristics

Node Permanent Characteristics as of 24-MAY-1991 10:10:58
Executor node = 20.1 (DENVER)
Management version = V4.0.0
.
.
.
Pipeline quota = 10000

NCP> define executor pipeline quota 45000
NCP>show known lines

Known line Volatile Summary as of 24-MAY-1991 10:11:13
Line State
SVA-0 on

NCP> show line sva-0 characteristics

Line Permanent Characteristics as of 24-MAY-1991 10:11:31
Line = SVA-0
Receive buffers       = 6        <-- value to change
Controller            = normal
Protocol              = Ethernet
Service timer         = 4000
Hardware address      = 08-00-2B-0D-D0-5F
Device buffer size    = 1498

NCP> define line sva-0 receive buffers 30
NCP>exit

Requirement:

For the changed parameters to take effect, the node must be rebooted or DECnet must be shut down.

The Network Control Language (NCL) is used to change DECnet-Plus network parameters. The transport parameters MAXIMUM RECEIVE BUFFERS, MAXIMUM TRANSPORT CONNECTIONS and MAXIMUM WINDOW can be adjusted by using NCL’s SET OSI TRANSPORT command. For example:

NCL> SET OSI TRANSPORT MAXIMUM RECEIVE BUFFERS = 4000        !default value
NCL> SET OSI TRANSPORT MAXIMUM TRANSPORT CONNECTIONS = 200   !default value
NCL> SET OSI TRANSPORT MAXIMUM WINDOWS = 20                  !default value

To make the parameter change permanent, add the NCL command(s) to the SYS$MANAGER: NET$OSI_TRANSPORT_STARTUP.NCL file. Refer to the DENET-Plus (DECnet/OSI) Network Management manual for detailed information.

Changing the default values of line receive buffers and the pipeline quota to the values of 30 and 45000 consumes less than 140 pages of nonpaged dynamic memory.

In addition, you may need to increase the number of large request packets (LRPs) and raise the default value of NETACP BYTLM.

Large request packets

LRPs are used by DECnet to send and receive messages. The number of LRPs is governed by the SYSGEN parameters LRPCOUNT and LRPCOUNTV.

Recommendation:

A minimum of 30 free LRPs is recommended during peak times. Show these parameters and the number of free LRPs by entering the following DCL command:

$ SHOW MEMORY/POOL/FULL

Result:

System Memory Resources on 24-JUN-1991 08:13:57.66
Large Packet (LRP) Lookaside   List   Packets   Bytes
Current Total Size                      36       59328
Initial Size (LRPCOUNT)                 25       41200
Maximum Size (LRPCOUNTV)               200       329600
Free Space                              20       32960

In the LRP lookaside list, this system has:

Example: Changing LRPCOUNT to 50 in SYSGEN

Username:   SYSTEM
Password:   (the system password)
$ SET DEFAULT SYS$SYSTEM
$ RUN SYSGEN
SYSGEN>   USE CURRENT
SYSGEN>   SH LRPCOUNT
Parameter Name   Current   Default   Minimum   Maximum
LRPCOUNT              25         4         0      4096
SYSGEN>   SET LRPCOUNT 50
SYSGEN>   WRITE CURRENT
SYSGEN>   SH LRPCOUNT
Parameter Name   Current   Default   Minimum   Maximum
LRPCOUNT              50         4         0      4096

Requirement:

After making changes to SYSGEN, reboot your system so the changes take effect.

Example: Changing the LRPCOUNT for AUTOGEN

Add the following line to MODPARAMS.DAT:

$ MIN_LRPCOUNT = 50 ! ADDED {the date} {your initials}

Result:

This ensures that when AUTOGEN runs, LRPCOUNT is not set below 50.

NETACP BYTLM

The default value of NETACP is a BYTLM setting of 65,535. Including overhead, this is enough for only 25 to 30 line receive buffers. This default BYTLM may not be enough.

Recommendation:

Increase the value of NETACP BYTLM to 110,000.

How to increase NETACP BYTLM:

Before starting DECnet, define the logical NETACP$BUFFER_ LIMIT by entering:

$ DEFINE/SYSTEM/NOLOG NETACP$BUFFER_LIMIT 110000
$ @SYS$MANAGER:STARTNET.COM

By default, RDF tries to perform I/O requests as fast as possible. In some cases, this can cause the network to slow down. Reducing the network bandwidth used by RDF allows more of the network to become available to other processes.

The RDF logical names that control this are:

RDEV_WRITE_GROUP_SIZE
RDEV_WRITE_GROUP_DELAY

Default:

The default values for these logical names is zero. The following example shows how to define these logical names on the RDF client node:

$ DEFINE/SYSTEM RDEV_WRITE_GROUP_SIZE 30
$ DEFINE/SYSTEM RDEV_WRITE_GROUP_DELAY 1

Further reduction:

To further reduce bandwidth, the RDEV_WRITE_GROUP_DELAY logical can be increased to two (2) or three (3).

Remote Device Facility (RDF) can survive network failures of up to 15 minutes long. If the network comes back within the 15 minutes allotted time, the RDCLIENT continues processing WITHOUT ANY INTERRUPTION OR DATA LOSS. When a network link drops while RDF is active, after 10 seconds, RDF creates a new network link, synchronizes I/Os between the RDCLIENT and RDSERVER, and continues processing.

The following example shows how you can test the RDF’s ability to survive a network failure. (This example assumes that you have both the RDSERVER and RDCLIENT processes running.)

$ @tti_rdev:rdallocate tti::mua0:
RDF - Remote Device Facility (Version 4.3I) - RDALLOCATE Procedure
Copyright (c) 1990, 1996 Touch Technologies, Inc.
Device TTI::TTI$MUA0 ALLOCATED, use TAPE01 to reference it
$ backup/rewind/log/ignore=label sys$library:*.* tape01:test

from a second session:

$ run sys$system:NCP
NCP> show known links
Known Link Volatile Summary as of 13-MAR-1996 14:07:38
Link         Node           PID    Process   Remote link   Remote user
24593    20.4 (JR)       2040111C   MARI_11C_5   8244       CTERM
16790    20.3 (FAST)     20400C3A   -rdclient-   16791      tti_rdevSRV
24579    20.6 (CHEERS)   20400113   REMACP       8223       SAMMY
24585    20.6 (CHEERS)   20400113   REMACP       8224       ANDERSON
NCP> disconnect link 16790
.
.
.

Backup pauses momentarily before resuming. Sensing the network disconnect, RDF creates a new -rdclient- link. Verify this by entering the following command:

NCP> show known links
Known Link Volatile Summary as of 13-MAR-1996 16:07:00
Link        Node           PID     Process       Remote link   Remote user
24593   20.4 (JR)       2040111C   MARI_11C_5    8244          CTERM
24579   20.6 (CHEERS)   20400113   REMACP        8223          SAMMY
24585   20.6 (CHEERS)   20400113   REMACP        8224          ANDERSON
24600   20.3 (FAST)     20400C3A   -rdclient-    24601         tti_rdevSRV
NCP> exit

You can allow specific RDF client nodes access to all remote devices.

Example:

For example, if the server node is MIAMI and access to all remote devices is granted only to RDF client nodes OMAHA and DENVER, then do the following:

OMAHA and DENVER (the specific RDF CLIENT nodes) are allowed access to all remote devices (MUA0, TU80) on the server node MIAMI.

Requirement:

If there is more than one RDF client node being allowed access, separate the node names by commas.

You can allow specific RDF client nodes access to a specific remote device.

Example:

If the server node is MIAMI and access to MUA0 is allowed by RDF client nodes OMAHA and DENVER, then do the following:

OMAHA and DENVER (the specific RDF client nodes ) are allowed access only to device MUA0. In this situation, OMAHA is not allowed to access device TU80.

You can deny access from specific RDF client nodes to all remote devices. For example, if the server node is MIAMI and you want to deny access to all remote devices from RDF client nodes OMAHA and DENVER, do the following:

OMAHA and DENVER are the specific RDF client nodes denied access to all the remote devices (MUA0, TU80) on the server node MIAMI.

You can deny specific client nodes access to a specific remote device.

Example:

If the server node is MIAMI and you want to deny access to MUA0 from RDF client nodes OMAHA and DENVER, do the following:

OMAHA and DENVER RDF client nodes are denied access to device MUA0 on the server node MIAMI.

Before doing the configuration for SBT, you should make sure that Oracle's Recovery Manager is setup and you are able to access it. If you have been using Oracle's Recovery Manager to write to disk, then you are ready to switch to SBT. If you have not been using Oracle's Recovery Manager, you should try a backup of a tablespace as shown in Example 9.1.

RMAN> run
2> {
3>   allocate channel d1 type disk;
4>   backup tablespace system;
5>   release channel d1;
6> }

Example 9.1 created the file ORA_DB:02D9MBV4_1_1.;1 on my system. Of course your file name will be different. If everything works then you are ready to link Oracle to SBT. If this step did not work, then your Oracle Recovery Manager is not setup correctly. You need to correct this before proceeding.

Before using SBT, you must authorize the VOLPRO privilege and grant the MDMS_APPLICATION identifier to the Oracle server database administrator account. The VOLPRO privilege allows the Oracle server to mount volumes that belong to ABS. All volumes belong to ABS. The MDMS_APPLICATION allows the Oracle server to use the objects in the MDMS database.

The following example shows the commands that modify the privileges and grant the right to an account called ORACLE9I:

$ MCR AUTHORIZE
UAF> MODIFY ORACLE9I/PRIVILEGES=VOLPRO
UAF> GRANT/ID MDMS_APPLICATION ORACLE9I
UAF> EXIT
$

In order to link the SBT shareable image, you must change Oracle's link option file and command procedures. This section covers what you need to do for Oracle8i and Oracle9i.

!
!
! rdbms libraries
ora_olb:libvsn8/lib
! ora_rman_mml/lib        COMMENT OUT THIS LINE
ora_olb:libwtc8/lib
ora_olb:libclient8/lib
ora_olb:libcommon8/lib
ora_olb:libgeneric8/lib
ora_olb:libclient8/lib
ora_olb:libcommon8/lib
ora_olb:libgeneric8/lib

ora_olb:libclient8_64/lib/incl=(kgu),-
'rdbmslib$$'-
'plsqllib$$'-
'rdbmslib$$'-
! ora_rman_mml_64/lib,-                   COMMENT OUT THIS LINE
ora_olb:libnro8_64/lib,-
'network$$'-
ora_olb:libtrace8_64/lib,-
'oracore$$'-
'cart64$$'-
ora_olb:libslax8_64/lib,-
'utl$$'-
'oracore$$'-
sys$input/options
sys$share:mdms$sbtshr_ma64.exe/share, -   !!! ADDED THIS LINE

$nonSharedLink:
$ 'loutl_link_cmd$$'/alpha/nouserlibrary'dotrace$$''map$$''mapextra$$''
image$$'=
'filename$$''switch$$''userlink$$'/sysexe -
'p2',-
ora_olb:libclient8/lib,-
ora_olb:libsql8/lib,-
'ocis$$'-
'fastupi$$'-
'network$$'-
'rdbmslib_noshare$$'-
'oracore$$'-
'network$$'-
'rdbmslib_noshare$$'-
'otracelib$$'-
'oracore$$'-
'rdbmslib_noshare$$'-
'oracore$$'-
'useroption$$'-
sys$input/opt
sys$share:mdms$sbtshr_ma64.exe/share, -   !!! ADDED THIS LINE
sys$share:decc$shr/share
! Temporary: fixup readonly attributes between compiler
versions.
psect_attr = $readonly$,pic,shr

!
!
! rdbms libraries
ora_olb:libvsn9/lib
ora_olb:libobk/lib
! ora_rman_mml_64/lib                      COMMENT OUT THIS LINE
sys$share:mdms$sbtshr_ma64.exe/share   !!! ADDED THIS LINE
ora_olb:libwtc9/lib
ora_olb:libclient9/lib
ora_olb:libcommon9/lib
ora_olb:libgeneric9/lib
ora_olb:libclient9/lib
ora_olb:libcommon9/lib
ora_olb:libgeneric9/lib

ora_olb:libobk_64/lib,-
! ora_rman_mml_64/lib,- COMMENT OUT THIS LINE
ora_olb:libnro9_64/lib,-
'network$$'-
ora_olb:libtrace9_64/lib,-
'oracore$$'-
'cart64$$'-
ora_olb:libslax9_64/lib,-
'utl$$'-
'oracore$$'-
sys$input/options
sys$share:mdms$sbtshr_ma64.exe/share, - !!! ADDED THIS LINE
sys$share:decc$shr/share

o$$:libobk/lib,-
! ora_rman_mml_64/lib,- COMMENT OUT THIS LINE
o$$:libnro9_64/lib,-
'network$$'-
'oracore$$'-
'rdbmslib$$'-
'oracore$$'-
'network$$'-
'rdbmslib$$'-
'otracelib$$'-
'oracore$$'-
'plsql$$'-
'slax$$'-
'utl$$'-
'oracore$$'-
'rdbms2$$'-
o$$:libcore9_objlib_64/lib/include=(sscoreed),-
sys$input/opt
sys$share:mdms$sbtshr_ma64.exe/share, - !!! ADDED THIS LINE
sys$share:decc$shr/share

Before relinking the database, you should shutdown the database.

Now that you have prepared the files for relinking, you must relink the ORA_RDBMS: executables. Invoke ORA_ INSTALL:ORACLEINS and select RDBMS for rebuild.

Now that you have relinked the Oracle server, you should startup up the database.

Before proceeding, you should retest Oracle's Recovery Manager as you did in Section 9.1.1.

Before doing the configuration for SBT, you should make sure that Oracle's Recovery Manager is setup and you are able to access it. If you have been using Oracle's Recovery Manager to write to disk, then you are ready to switch to SBT. If you have not been using Oracle's Recovery Manager, you should try a backup of a tablespace as shown in Example 9.8.

RMAN> run
2> {
3> allocate channel d1 type disk;
4> backup tablespace system;
5> release channel d1;
6> }

System Backup to Tape for Oracle Databases

Example 9.8 created the file ORA_DB:39EGCJVM_1_1.;1 on my system. Of course your file name will be different. If everything works then you are ready to link Oracle to SBT. If this step did not work, then your Oracle Recovery Manager is not setup correctly. You need to correct this before proceeding.

Before using SBT, you must authorize the VOLPRO privilege and grant the MDMS_APPLICATION identifier to the Oracle server database administrator account. The VOLPRO privilege allows the Oracle server to mount volumes that belong to ABS. All volumes belong to ABS. The MDMS_APPLICATION allows the Oracle server to use the objects in the MDMS database.

The following example shows the commands that modify the privileges and grant the right to an account called ORACLE9I:

$ MCR AUTHORIZE
UAF> MODIFY ORACLE9I/PRIVILEGES=VOLPRO
UAF> GRANT/ID MDMS_APPLICATION ORACLE9I
UAF> EXIT
$

In rdbms_logicals.com add the following line.

$define/sys abs_sbt SYS$SHARE:MDMS$SBTSHR_MA64_9I2.EXE

You can give the logical whatever name you want, I just picked one for the sake of example and I will be making use of the logical in the RMAN script.

This logical will be defined when you execute orauser.com file for setting up the user's default instance.

Before you can us the SBT feature, you must create a catalog. The catalog stores the tape volume, saveset name, and piece name. The catalog allows SBT to lookup the tape volume for a restore. You should only create one oracle_db type catalog that is accessible to Oracle’s Recover Manager(s). The catalog is created in ABS$CATALOG:. The catalog must be created in the ABS$CATALOG: directory that is local to all nodes that will access the catalog.

Use the following command to create a catalog named ORACLE_ DB:

$ MDMS CREATE CATALOG ORACLE_DB /TYPE=ORACLE_DB

When doing an Oracle Recovery Manager restore, allocateForMaint, or validate command, you must specify the catalog you want to use. However, the default catalog name for SBT is ORACLE_DB. Therefore, if you do not specify a catalog, it will lookup information in the ORACLE_DB catalog on the local node.

Refer to Section 9.7 for information on how to access the ORACLE_DB catalog.

An archive defines the tape volumes and archive attributes where you can safely store data. Each archive has a unique name and contains a set of archive characteristics. You can have as many archives as you want to implement your storage policies. This section describes how to create an archive and what attributes pertain to SBT. You should refer to the command reference guide for information about creating archives and their attributes. You may want to create an archive that keeps tape volumes for a year and another that keeps tape volumes for 35 days.

The following command creates an archive named ORACLE_DB_ ARCHIVE:

$ MDMS CREATE ARCHIVE ORACLE_DB_ARCHIVE -
/ARCHIVE_TYPE=TAPE -
/CATALOG=(NAME=ORACLE_DB) -
/MAXIMUM_SAVES=36 -
/MEDIA_TYPE=DLT_III -
/POOL=DB_BACKUP_POOL -
/RETENTION_DAYS=35
$ MDMS SHOW ARCHIVE ORACLE_DB_ARCHIVE

Archive: ORACLE_DB_ARCHIVE         
Description:
Access Control: NONE
Owner: MOE::ORACLE9I
Archive Type: TAPE                 
Catalog -
- Name: ORACLE_DB                  
- Nodes:
Consolidation -
- Interval: 0007 00:00:00          
- Savesets: 0
- Volumes: 0
Destination:
Drives:                            
Expiration Date: NONE
Location: CR_2                     
Maximum Saves: 36                  
Media Type: DLT_III                
Pool: DB_BACKUP_POOL               
Retention Days: 35                
Volume Sets:

The following describes the different attributes of the archive:

Now that you have created a catalog and archive, you are ready to test that everything is configured correctly. The next section shows how to test the configuration.

This is applicable only to Oracle9i Release 2 (9.2.0.2). Oracle9i Release 2 (9.2.0.2) has support for shared libraries in RMAN. The SBT shared library must be specified as part of the RMAN script for Oracle to load the sbt shared library.

run
{
allocate channel t1 type 'sbt_tape'
parms="SBT_LIBRARY=abs_sbt,
ENV=(MDMS$SBT_ARCHIVE=REG_RMAN_ARCH,
MDMS$SBT_IO_BLOCK_SIZE=65024)";
backup   filesperset 4
database;
release  channel t1;
}

In the above script SBT_LIBRARY is a keyword which is assigned the logical name abs_sbt. Remember that abs_sbt is a system wide logical pointing to SYS$SHARE:MDMS$SBTSHR_MA64_9I2.EXE. We defined abs_sbt to SYS$SHARE:MDMS$SBTSHR_MA64_9I2.EXE in rdbms_logicals.com.

If you do not specify SBT_LIBRARY params in the script, Oracle will not be able to load the SBT shareable image.

Moreover params should be specified for each and every channel in the script.

In order to have SBT select the archive that you want, you must specify the archive in the Oracle Recovery Manager allocate command. The archive is specified in the parms keyword for the allocate command. Example 9.9 shows how to code an Oracle Recovery Manager script for the archive OFFSITE_ARCH. The Oracle server creates the process logical MDMS$SBT_ARCHIVE.

run
{
   allocate channel t1 type 'sbt_tape'
    parms="ENV=(MDMS$SBT_ARCHIVE=OFFSITE_ARCH)”;
   backup tablespace system;
   release channel t1;
}

If you are doing a parallel backup, you need to specify an archive for each channel as shown in Example 9.10. Also the following example shows how to specify a catalog.

run
{
   allocate channel t1 type 'sbt_tape'
    parms="ENV=(MDMS$SBT_ARCHIVE=ONSITE_ARCH)";
   allocate channel t2 type 'sbt_tape'
    parms="ENV=(MDMS$SBT_ARCHIVE=ONSITE_ARCH)";
   allocate channel t3 type 'sbt_tape'
    parms="ENV=(MDMS$SBT_ARCHIVE=ONSITE_ARCH)";
   backup
     ( tablespace tbs1,tbs2 channel t1 )
     ( tablespace tbs3,tbs4 channel t2 )
     ( tablespace tbs5,tbs6, system channel t3 );
   release channel t1;
   release channel t2;
   release channel t3;
   }

If you have an archive you want to use as a default, you can define MDMS$SBT_ARCHIVE as a system wide logical. Then if you want something different for a particular backup, you can define it in the allocate command. Also, you can specify different archives for each channel you allocate.

In order to have SBT select the catalog to use, you must specify the catalog in the Oracle Recovery Manager allocate command. The catalog is specified in the parms keyword for the allocate command. Example 9.11 shows how to code an Oracle Recovery Manager script for the catalog OFFSITE_ CAT.

run
{
   allocate channel t1 type 'sbt_tape'
    parms="ENV=(MDMS$SBT_CATALOG=OFFSITE_CAT)";
   restore tablespace tbs6;
   recover tablespace tbs6;
   release channel t1;
}

If you only have one catalog named ORACLE_DB, you never have to specify MDMS$SBT_CATALOG. I only used different catalogs here for examples.

For a Recover Manager backup operation, the catalog in the archive is always used.The MDMS$SBT_CATALOG in the parms keyword of the allocate command is ignored.

For a Recovery Manager restore, crosscheck, or delete expired comand the catalog that SBT uses is determined by the logical MDMS$SBT_CATALOG, the catalog in the archive, or the default catalog. If the logical MDMS$SBT_CATALOG is defined, SBT uses that catalog. If MDMS$SBT_CATALOG is not defined, SBT checks to see if MDMS$SBT_ARCHIVE is defined. If MDMS$SBT_ARCHIVE is defined, SBT uses the catalog in the archive. If MDMS$SBT_ARCHIVE is not defined, the default catalog ORACLE_DB is used.

To help tune your output to different devices, SBT allows you to specify an I/O block size. In the case of a tape device, the block size is how much data is written to the tape device at one time. The default is the maximum of 65024 bytes. Example 9.12 shows how to code an Oracle Recovery Manager script for the I/O block size of 32768.

run
{
   allocate channel t1 type 'sbt_tape'
    parms="ENV=(MDMS$SBT_ARCHIVE=ONSITE_ARCH,
                MDMS$SBT_IO_BLOCK_SIZE=32768)";
   allocate channel t2 type 'sbt_tape'
    parms="ENV=(MDMS$SBT_ARCHIVE=ONSITE_ARCH,
                MDMS$SBT_IO_BLOCK_SIZE=32768 )";
   allocate channel t3 type 'sbt_tape'
    parms="ENV=(MDMS$SBT_ARCHIVE=ONSITE_ARCH,
                MDMS$SBT_IO_BLOCK_SIZE=32768 )";
   backup filesperset 1
    database;
   backup
    current controlfile;
   release channel t1;
   release channel t2;
   release channel t3;
   }

SBT allows you specify an archive for each stream of a duplex backup. The duplex mode allows duplicate backups to separate tape volumes. This is accomplished in SBT by having a different archive for each stream. The different archives are passed into SBT using Oracle's Recovery Manager allocate command. The parms keyword uses the keyword of ENV. By using MDMS$SBT_ARCHIVE_1, MDMS$SBT_ ARCHIVE_2, and so forth, you can specify which archive to use for which copy. Example 9.13 shows an example of doing a duplex backup with two archives: OFFSITE_ARCH and ONSITE_ ARCH.

run
{
   set duplex=2;
   allocate channel t1 type 'sbt_tape'
    parms="ENV=(MDMS$SBT_ARCHIVE_1=OFFSITE_ARCH,
                MDMS$SBT_ARCHIVE_2=ONSITE_ARCH)";
   backup tablespace system;
   release channel t1;
}

This logical can be optionally used only when performing a restore operation with a single channel .The restore operation will be efficient if this logical is specified. When this logical is specified, SBT will not dismount the tape drive after restoring each backup piece. If the next restore request for a backup piece is in the same tape volume then SBT will position the drive accordingly and restore that piece.

But if the next restore request in that channel is for a backup piece stored in different tape volume then it will dismount the current volume and mount the required volume. When this logical is not specified, SBT will dismount the tape drive after restoring each backup piece. This logical thus avoids unnecessary dismount operations during a restore operation with single channel.

Example 9.14 shows how to use this logical in Oracle's Recovery Manager (RMAN) scripts.

run
{
   allocate channel t1 type 'sbt_tape'
    parms="ENV=(MDMS$SBT_CATALOG=REG_ORACLE_DB,
                MDMS$SBT_RESTORE_SINGLE_CHANNEL=TRUE)";
   restore database;
   recover database;
   release channel t1;
   sql 'alter database open ';
}

If you do not pass the parms="ENV=(MDMS$SBT_ ARCHIVE=archive_name)" in an Oracle Recovery Manager allocate command, SBT will use the default ORACLE_DB_ ARCHIVE archive.

If you do not pass the parms="ENV=(MDMS$SBT_ CATALOG=catalog_name)" in an Oracle Recovery Manager allocate command, SBT will use the default ABS$CATALOG: ORACLE_DB catalog.

If you do not pass the parms="ENV=(MDMS$SBT_IO_BLOCK_ SIZE=block_size)" in an Oracle Recovery Manager allocate command, SBT will use a block size of 65024 bytes when writing blocks on the I/O device. This has nothing to do with the block size that Oracle sends down to be written on the I/O device.

If you do not pass params="ENV=(MDMS$SBT_RESTORE_SINGLE_CHANNEL=TRUE)" in an Oracle Recovery manager allocate command, SBT will not treat this restore as a single channel restore and will force a dismount operation after restoring each backup piece.

This section describes the logical names used to control your SBT sessions. These logical names can be a system wide logical (DEFINE/SYSTEM) or be defined in your Oracle Recovery Manager scripts. When using in Oracle's Recovery Manager scripts, the logical is declared when you allocate a channel with the keyword of ENVfor the keyword parms. The following example shows how the MDMS$SBT_ARCHIVE and MDMS$SBT_IO_BLOCK_SIZE logicals are defined as a process logical with Oracle's Recovery Manager allocate command:

run
{
   allocate channel t1 for 'sbt_tape'
    parms="ENV=(MDMS$SBT_ARCHIVE=OFFSITE_ARCHIVE,
                MDMS$SBT_IO_BLOCK_SIZE=32768)";
   ...
}

SBT Logical Names

When doing a parallel backup and you do not have all of the SBT resources needed could cause a backup not to complete. When doing a parallel backup, the controlling Oracle server does not let any of the Oracle servers doing the backup end until all servers say they have completed their task. I believe this is to keep the database consistent. However, this can cause the backup to not complete if SBT resources are not available.

The following three scenarios can cause a parallel backup not to complete:

To illustrate the problems stated above, I will give an example of setting the Maximum Saves in the archive to 2 and then using a Oracle Recovery Manager script that starts 3 parallel streams. Each stream starts the backup, the first two are allowed to get a volume set and start their backup. The third server starts up and finds that there is no volume set available at this time. It keeps trying to get a volume set. In the mean time, the first two servers finish doing the backup. However, the controlling server will not let them end until the third server is finished. Therefore, they hold on to the resources: drive and volume set. The third server can not finish for lack of resources. Any of the above problems stated above can cause this deadlock.

A piece name length greater than 254 characters is not supported. This restriction may be lifted in subsequent versions to 511 characters for a piece name length.

You can NOT use Remote Device Facility (RDF) drives when using Oracle’s tape I/O slaves. RDF drives may be used with SBT if you are not using Oracle’s tape I/O slaves.

During backup, Oracle background server process results in access violation when "Oracle Dead connection" detection is enabled by setting the parameter SQLNET.EXPIRE_TIME with Oracle 9.2.0.4.

To use the sqlnet.expire parameter, the 'backup_tape_io_slaves=TRUE' should be set in the init.ora file specific to the instance and execute the backup.

This is a workaround when using RMAN and ABS SBT with "sqlnet.expire" set to a non-zero value.

The logical MDMS$SBT_TRACE_LEVEL allows you define how much tracing appears in the trace file, ORA_DUMP:SBTIO.LOG. By default any error that is detected by SBT, is traced in the trace file. You can define the logical MDMS$SBT_TRACE_LEVEL to display more information. The definition of MDMS$SBT_ TRACE_LEVEL is defined in SYS$STARTUP: MDMS$SYSTARTUP.COM. If the logical is not defined on your system, see Section 9.3 to setup the logical.

There are only three values that you might want to use. The rest of the values are for support use. By default the following values are enabled:

As a very minimum, we suggest that you enable the above two values so that you can check the progress of backups and restores. If the backup or restore can not get a volume set, it will loop, once a minute, waiting for the volume set to become available. If a tape drive is unavailable,SBT loops waiting for a drive to become available. SBT tries to allocate the tape drive every minute. SBT reports that it can not allocate the tape drive after five minutes and then after 10 minutes and so forth.

Example 9.18 shows an example of ORA_DUMP:SBTIO.LOG with TR_GENINFO and TR_MEDINFO values enabled. Note that the SBT-00008140 is the pid, in hexadecimal, of the process doing the backup with SBT- prepended.

EDINFO Values Enabled
SBT-00008140 12/17/01 09:27:11 Using archive RMAN_TAPE_TL875_ARCH
SBT-00008140 12/17/01 09:27:12 Starting backup of r1dbtgjd_1_1 for DB:
EMPLOYEE
SBT-00008140 12/17/01 09:27:12 Using catalog ORACLE_DB
SBT-00008140 12/17/01 09:27:12 Allocated drive: MKC200 Device: MOE$MKC200:
SBT-00008140 12/17/01 09:27:13 Drive is in jukebox TLZ875
SBT-00008140 12/17/01 09:27:13 Allocated volume AIF078
SBT-00008140 12/17/01 09:27:17 Unloading drive MKC200
SBT-00008140 12/17/01 09:27:46 Loading volume AIF078 on drive MKC200
SBT-00008140 12/17/01 09:28:39 Deallocating drive MKC200
SBT-00008140 12/17/01 09:28:39 Initializing volume AIF078
SBT-00008140 12/17/01 09:29:00 Allocated drive: MKC200 Device: MOE$MKC200:
SBT-00008140 12/17/01 09:29:00 Drive is in jukebox TLZ875
SBT-00008140 12/17/01 09:29:00 Loading/mounting volume AIF078 on drive MKC200
SBT-00008140 12/17/01 09:29:00 Loading volume AIF078 on drive MKC200
SBT-00008140 12/17/01 09:29:09 Mounting volume AIF078 on device MOE$MKC200:
SBT-00008140 12/17/01 09:29:18 Ready to write to saveset 2001121709291582.
on volume AIF078
SBT-00008140 12/17/01 09:30:47 Using catalog ORACLE_DB
SBT-00008140 12/17/01 09:30:48 Finished writing saveset 2001121709291582.
on volume AIF078

We hope the only thing that might not be obvious in Example 9.18 is the saveset name. We are limited to 17 characters so I change piece name, r1dbtgjd_1_1, into a saveset name, 2001121709291582., on a particular volume.

Another value that you may want to use is TR_TAPSTAT. This gives you statistics about the reading/writing to a tape volume. Example 9.19 shows an example of tape statistics.

SBT-00008140 12/17/01 09:50:49 I/O Statistics:
SBT-00008140 12/17/01 09:50:49 DB block size: 262144 bytes        
SBT-00008140 12/17/01 09:50:50 I/O block size: 65024 bytes        
SBT-00008140 12/17/01 09:50:50 Total I/Os: 620                    
SBT-00008140 12/17/01 09:50:50 Total I/O wait: 23279 milliseconds 
SBT-00008140 12/17/01 09:50:50 Maximum I/O wait: 936 milliseconds 
SBT-00008140 12/17/01 09:50:50 Average I/O wait: 37 milliseconds  
SBT-00008140 12/17/01 09:50:50 Total Kbytes: 40300                
SBT-00008140 12/17/01 09:50:50 Total bytes: 40314880.000          
SBT-00008140 12/17/01 09:50:50 Total seconds: 23                  
SBT-00008140 12/17/01 09:50:50 MBytes/sec: 1.752                 
SBT-00008140 12/17/01 09:50:50 Bytes/sec : 1752820.870           

The following describes the entries in Example 9–19:

If you should ever get an Internal error, you should report it to the customer support center. Example 9.20 shows an example of a fatal internal error. Anyplace that SBT could have received a value that it did not expect, it is captured and reported as a fatal internal error.

SBT-00001DB2 12/17/01 13:53:45 Internal error
SBT-00001DB2 12/17/01 13:53:45 Extended Status:
The invalid archive type, 23
SBT-00001DB2 12

Any time you receive an error in Oracle's Recovery Manager that is related to SBT, you should check ORA_DUMP:SBTIO.LOG for errors. We are limited to 250 characters returned to the Oracle Recovery Manager. Therefore, you may not receive all of the information about the error. However, I am not limited to what I put in the ORA_DUMP:SBTIO.LOG file. So be sure to look in ORA_DUMP:SBTIO.LOG when getting an error message that in not all there.

Example 9.21 shows an example of a fatal error reported in Oracle's Recovery Manager. Example 9.22 shows what is reported in ORA_DUMP:SBTIO.LOG for the same error. The File:, Function: and line are information for me to troubleshoot the problem if it is a software error. In this case, there were no volumes available. Look for it in the ORA_ DUMP:SBTIO.LOG file. In this case, you can look in the archive to see what the media type, pool, and location were.

ORA-27028: skgfqcre: sbtbackup returned error
ORA-19511: Error received from media manager layer, error text:
Fatal media movement error
Failed to allocate tape volume
MDMS object: RMAN_TAPE_TL875_ARCH
System Error: %MDMS-E-NOVOLUMES, no free volumes match selection criteria
%MDMS-E-NOVOLUMES, no free volumes match selection criteria
%MDMS-I-NOVOLSPOOL, no free volumes in the specified pool were found

SBT-0000819F 12/17/01 14:10:20 Fatal media movement error
SBT-0000819F 12/17/01 14:10:20 Extended Status:
Failed to allocate tape volume
MDMS object: RMAN_TAPE_TL875_ARCH
System Error: %MDMS-E-NOVOLUMES, no free volumes match selection criteria
%MDMS-E-NOVOLUMES, no free volumes match selection criteria
%MDMS-I-NOVOLSPOOL, no free volumes in the specified pool were found
File: WRK$ROOT:[SRC]MDMS_SBT_API_MEDIA.C;1, Function:
sbt_media_allocate_volume,
Line 416
Failed to allocate volume with attributes:
Pool:
Media Type: TLZ88M
Location: 110281

When using tape I/O slaves, you may not receive the error message from SBT in Oracle's Recovery Manager. Example 9.23 shows the type of error you may get reported for a tape volume being offsite. Example 9.24 shows the tape volume offsite error reported when not using tape I/O slaves. So when troubleshooting, also look in the trace log file ORA_ DUMP:SBTIO.LOG. In both cases the error was reported in the trace log file.

RMAN-08031: released channel: t1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03006: non-retryable error occurred during execution of command: vali
ate
RMAN-07004: unhandled exception during command execution on channel t1
RMAN-10035: exception raised in RPC: ORA-00447: fatal error in background
process
RMAN-10031: ORA-19583 occurred during call to DBMS_BACKUP_RESTORE.RESTORE
ACKUPP
IECE
RMAN>

RMAN-07004: unhandled exception during command execution on channel t1
RMAN-10035: exception raised in RPC: ORA-19507: failed to
retrieve sequential fi LE, handle="6sd8vntq_1_1", parms=""
ORA-27029: skgfrtrv: sbtrestore returned error
ORA-19511: Fatal catalog access error
Piece 6sd8vntq_1_1 cannot be restored because volume AHI164 is offsite
RMAN-10031: ORA-19624 occurred during call to
DBMS_BACKUP_RESTORE.RESTOREBACKUPPIECE
RMAN>

SBT-00000889 11/13/01 16:28:02 Fatal catalog access error
SBT-00000889 11/13/01 16:28:02 Extended Status:
Piece 6sd8vntq_1_1 cannot be restored because volume AHI164 is offsite

RMU/BACKUP command accepts the /LIBRARIAN qualifier to backup data using ABS SBT.

$RMU/BACKUP/LIBRARIAN=(trace=disk:[directory]tracefile.trace)/LOG DATABASE
FILENAME.RBF

RMU/RESTORE command accept the /LIBRARIAN qualifier for retrieving data using ABS SBT.

$RMU/RESTORE/LIBRARIAN=(trace=disk:[directory]tracefile.trace)/LOG FILENAME.
RBF

FILENAME.RBF is the backup filename. The backup filename excluding the extension must be the same name previously used for an RMU backup using SBT.

The RMU command used with the /LIBRARIAN qualifier cannot specify a list of tape or disk devices. It accepts a backup file ("rbf file") name. Any disk or device specification or file extension specified with the backup file name is ignored for the backup file name specified to the archive. For example, "device:[directory]FILENAME.RBF" is specified as "FILENAME" when the backup file data is stored in or retrieved from the archive. SBT writes trace data to the tracefile, if specified.

The archive application is a "black box" to RMU and the backup file name is the identifier of the stream of data stored in the archive. The MDMS utility used with the ARCHIVE BACKUP SYSTEM is used to associate devices with the stream of data sent to or retrieved from the archive by RMU. Since SBT is a black box to RMU that can store data to tape or disk, device specific qualifiers such as /REWIND, /DENSITY or /LABEL cannot be used with this interface.

$RMU/BACKUP/LIBRARIAN=(WRITER_THREADS=2, trace=disk:[directory]tracefile.
trace)/LOG DATABASE FILENAM.RBF

Each writer thread for a backup operation or reader thread for a restore operation manages its own stream of data. Therefore, each thread uses a unique backup file name generated from the backup file name specified on the command line. A number is incremented and added to the end of each backup file name specified to the archive (except for the first) representing a unique data stream. This number is the equivalent of the volume number associated with non SBT RMU backups and restores.

For the above example, the backup file data stream names FILENAME, FILENAME02 are specified to the archive to identify the two streams of data stored in the archive by the two writer threads, which together represent the stored database. When

$RMU/RESTORE/LIBRARIAN=(READER_THREADS=2, trace=disk:[directory]trace
file.trace)/LOG FILENAM.RBF

is specified to restore the database these same two data stream backup file names, one name specified by each of the two reader threads, will be generated by RMU and sent to the archive application to retrieve all the data associated with the database. If the number of reader threads is less than the number of backup writer threads one or more restore reader threads will restore more than one data stream.

For example, reader threads can be equal to, less than or more than the number of writer threads.

$RMU/RESTORE/LIBRARIAN=(READER_THREADS=1, trace=disk:[directory]tracefile.
trace)/LOG FILENAM.RBF
$RMU/RESTORE/LIBRARIAN=(READER_THREADS=4, trace=disk:[directory]tracefile.
trace)/LOG FILENAM.RBF

The user does not have to specify the same number of reader threads on the restore as writer threads specified on the backup. If a smaller number of reader threads on the restore is specified than the number of writer threads specified in the backup of the database, the data streams to be retrieved will be divided among the specified reader threads using an algorithm which assigns the data streams so that each thread will have an approximately equal amount of work to do. If a larger amount of reader threads is specified on the restore than was specified on the backup, the number of reader threads will be automatically changed to equal the number of writer threads used in the backup. This is done to prevent an error, which would occur if more data streams were requested than were stored using SBT by the backup or if threads were created with no work to do.

$RMU/RESTORE/LIBRARIAN=(READER_THREADS=1, trace=disk:[directory]tracefile.
trace)/LOG/DIRECTORY= disk:[directory1] FILENAM.RBF

During restore, /DIRECTORY qualifier can be used to specifY the destination for the restored database files. The files are restored to the directory specified.

$RMU/RESTORE/ONLY_ROOT/LIBRARIAN=(trace=disk:[directory]tracefile.
trace)/LOG/DIRECTORY= disk:[directory1] FILENAM.RBF

RMU/RESTORE/ONLY_ROOT command rebuilds only the database root file from a backup file, produced earlier by an RMU/BACKUP command, to the condition the database root file was in when the backup was performed.

The /VOLUMES qualifier cannot be used on the RMU/RESTORE command if the /LIBRARIAN qualifier is used. RMU automatically determines the number of data streams stored using SBT based on the backup file name specified for the restore command and sets the volume number to the actual number of stored data streams. This makes sure that all data streams, which represent the database, are retrieved.

The default for both WRITER_THREADS and READER_THREADS is "1". The WRITER_THREADS parameter can only be specified with the /LIBRARIAN qualifier for the RMU/BACKUP database command. The READER_THREADS parameter can only be specified with the /LIBRARIAN qualifier for the RMU/RESTORE database commands.

All other RMU commands that accept the /LIBRARIAN qualifier only use one writer thread or one reader thread representing one archive data stream.

In addition to the /LIBRARIAN qualifier used with existing RMU commands, there are new commands as follows:

$RMU/LIBRARIAN/LIST=(OUTPUT=disk:[directory]listfile.ext) FILENAME.RBF

RMU/LIBRARIAN/LIST command to list data streams stored using SBT that have been created by RMU from a backup filename.

"/LIST" used alone will display to the default output device. If the "OUTPUT" option is used output will be displayed to the specified file. All data steams existing in the SBT that was generated for the specified backup name will be listed.

$RMU/LIBRARIAN/REMOVE=([NO]CONFIRM) FILENAME.RBF

RMU/LIBRARIAN/REMOVE command to delete data streams stored using SBT that have been created by RMU from a backup filename.

"/REMOVE" deletes all data steams stored using SBT that were generated for the specified backup name.

The "CONFIRM" option is the default. It will prompt the user to confirm that he wants to delete the backup from the ABS. The user can then reply "Y(ES)" to do the deletion or "N(O)" to exit the command without doing the deletion if he wants to confirm that a more recent backup for the database exists in the SBT that was generated using a different backup name. The user must specify the “NOCONFIRM" option if he does not want to be prompted. In this case the deletion will be done with no confirmation prompt.

The /LIBRARIAN qualifier can be used for parallel backup operations where backup threads can execute in multiple processes. The database backup command can be invoked as a parallel command which uses multiple processes but the other RMU commands which accept the /LIBRARIAN qualifier do not support parallel processes but execute in one process. RDB V7.1 SQL/Services is required to be installed for RMU parallel backup operations.

The following lines in the backup PLAN file used to specify the parameters for parallel backup operations relate directly to ABS SBT.

Backup File = MF_PERSONNEL.RBF

Style = Librarian

Librarian_trace_file = FILE.TRACE

Writer_threads = #

The backup file name must be the same file name specified for the restore and the style must be set to "Librarian" indicating a backup to the LIBRARIAN. "Librarian_trace_file =FILE.TRACE" are optional parameters specified with the /LIBRARIAN qualifier and passed to SBT to be used for diagnostic purposes. If the backup is a parallel operation a PLAN file is created and executed as part of the existing RMU/BACKUP/PARALLEL and RMU/BACKUP/PLAN command syntax. The following is an example of a parallel backup and non parallel restore (the restore is always non parallel and executes in a single process) using the /LIBRARIAN qualifier.

$RMU/BACKUP/PARALLEL=EXECUTOR=2/LIBRARIAN=WRITER_THREADS=1-
/LIST_PLAN=FILENAME.PLAN/NOEXECUTE/LOG DATABASE FILENAM.RBF
$RMU/BACKUP/PLAN FILENAME.PLAN
$RMU/RESTORE/LIBRARIAN=(READER_THREADS=2)/LOG FILENAME

In this example the first backup command creates the PLAN file for a parallel backup but does not execute it. The second backup command executes the parallel backup using the PLAN file. Note that 2 worker processes will be used and each process will use the 1 writer threads specified with the /LIBRARIAN qualifier. Each writer thread in each process will write one stream of backup data using SBT. Therefore 2 streams will be written to the LIBRARIAN archive. The streams will be given the names FILENAME, FILENAME02.

To retrieve the same 2 data streams which represent the backed up Rdb database on the non parallel restore a READER_THREADS=2 parameter can be specified with the /LIBRARIAN qualifier to use 2 threads to execute the restore, or if a READER_THREADS value specified is less than 2 (1 is the default), RMU will determine the number of data streams actually stored by querying the SBT distribute the data streams among the requested reader threads. If a READER_THREADS value is specified that is greater than "2" RMU will set it to "2" so that the restore does not attempt to retrieve data streams which do not exist.

Since all data stream names representing the database are generated based on the backup file name specified for the RMU backup command used with the /LIBRARIAN qualifier, the user must use a different backup file name to store the next backup of the database using SBT.

The user can incorporate the date or some other unique identifier in the backup file name to make it unique if he wants to avoid deleting a previous backup to SBT, which used the same backup file name.

$ SEARCH SYS$STARTUP:MDMS$SYSTARTUP.COM MDMS$SBT_TRACE_LEVEL
%SEARCH-I-NOMATCHES, no strings matched

$ !
$ !
$ ! The MDMS$SBT_TRACE_LEVEL log name controls what is written to the
$ ! Oracle trace file for SBT. The trace level can be controlled by
$ ! this logical separately from the trace level in the Oracle parameters.
$ !
$ TR_ERROR = %X00000000 ! Always trace errors, cannot be changed
$ TR_SBTENTRY = %X00000001 ! Entry and exit of oracle called SBT functions
$ TR_SBTPARAM = %X00000002 ! Trace oracle called SBT functions parameters
$ TR_SBTRWENTRY = %X00000004 ! Trace of SBTREAD/SBTWRITE entry
$ TR_SBTRWPARAM = %X00000008 ! Trace of parameters for SBTREAD/SBTWRITE
$ TR_GENINFO = %X00000010 ! Trace general information like backup file name
$ TR_MEDINFO = %X00000020 ! Trace media movement information
$ TR_TAPSTAT = %X00000040 ! Trace tape/disk transfer stats
$ TR_COMENTRY = %X00000080 ! Entry and exit for common functions
$ TR_COMPARAM = %X00000100 ! Trace parameters for common functions
$ TR_MEDENTRY = %X00000200 ! Entry and exit for media functions
$ TR_MEDPARAM = %X00000400 ! Trace parameters for media functions
$ TR_CATENTRY = %X00000800 ! Entry and exit for catalog functions
$ TR_CATPARAM = %X00001000 ! Trace parameters for catalog functions
$ TR_TAPENTRY = %X00002000 ! Entry and exit for VMSTAPE functions
$ TR_TAPPARAM = %X00004000 ! Trace parameters for VMSTAPE functions
$ TR_VOLENTRY = %X00008000 ! Entry and exit for VOLSET functions
$ TR_VOLPARAM = %x00010000 ! Trace parameters for VOLSET functions
$ tracefilter = TR_GENINFO .OR. TR_MEDINFO
$ DEFINE/SYSTEM/NOLOG MDMS$SBT_TRACE_LEVEL 'tracefilter'
$!

The two VMS logicals are to be defined for use with SBT. These logicals need to be defined before the RMU backup or restore command is executed and should not be specified with the list of logicals specified with the /LIBRARIAN qualifier.

$DEFINE/PROCESS RMU$LIBRARIAN_PATH librarian_shareable_image.exe
$DEFINE/SYSTEM/EXEC RMU$LIBRARIAN_PATH librarian_shareable_image.exe

This logical must be defined and should point to the SBT shareable image to be loaded and called by RMU backup and restore operations. For a parallel RMU backup RMU$LIBRARIAN_PATH should be defined as a system logical so that the multiple processes created by a parallel backup can all translate the logical.

The default catalog and archive used are ORACLE_DB and ORACLE_DB_ARCHIVE.

The list of process logical names, which SBT may use to specify particular catalogs or archives for storing or retrieving backup files are MDMS$SBT_ARCHIVE, MDMS$SBT_CATALOG.

$DEFINE MDMS$SBT_ARCHIVE REG_RMAN_ARCH
$DEFINE MDMS$SBT_CATALOG REG_ORACLE_DB

The following scenarios will cause backup not to complete:

An MDMS server can establish three types of listeners:

The Mailbox Listener is always enabled. The server receives user request through its mailbox described by logical MDMS$MAILBOX. Each user process has its own mailbox to receive the response from the server.

The DECnet Listener is enabled during server startup if DECnet is available on this node indicated by the existence of logical name SYS$NODE or logical SYS$NODE_FULL_NAME. Once the server had access to the database and DECNET is not defined in its TRANSPORT setting the server shuts down the DECnet Listener.

The TCPIP Listener is enabled during server startup if TCP/IP is available on this node indicated by the existence of logical names {UCX|TCPI}$INET_HOST and {UCX|TCPI}$INET_DOMAIN. Once the server had access to the database and TCPIP is not defined in its TRANSPORT setting the server shuts down the TCPIP Listener.

Startup and shutdown of the listeners is logged in the MDMS server logfile. Also the “MDMS SHOW SERVER” display shows the current servers network names at the top and its current TRANSPORT setting which reflects the active network listeners.

Even though a DB server has received a request via DECnet it could use TCPIP to request a remote operation (e.g. load volume) at a third node. It all depends on the TRANSPORT setting of the individual nodes.

MDMS uses the programming interface to the OpenVMS Queue Manager. A thread in the MDMS DB server submits due requests to the OpenVMS Queue Manager. The request will be submitted to batch queue ABS$<execution_node>. If the batch queue is available on the local node or is within the OpenVMS cluster the MDMS DB server calls the local Queue Manager. For remote nodes the MDMS DB server forwards the request to the remote MDMS serve on the execution node of the request. The remote MDMS server then submits the request to the local batch queue ABS$<execution_node>.

Failures to call the OpenVMS Queue Manager will be logged in the servers’ logfiles.

This option uses the same method as INT_QUEUE_MANAGER to schedule jobs locally or remote. But instead of calling the programming interface of the OpenVMS Queue Manager, a subprocess is created from the MDMS server process to run the command procedure MDMS$SYSTEM:MDMS$EXT_QUEUE_MANAGER.COM. The command procedure issues the DCL commands to create, delete, modify and show batch jobs. Also the command procedure has to return status about the commands and in some cases additional information. See the command procedure template file, MDMS$SYSTEM:ABS$EXT_QUEUE_MANAGER.TEMPLATE for more details.

Failures to execute the command procedure will be logged in the servers’ logfiles. Each activation of the command procedure creates a logfile of MDMS$LOG:MDMS$EXT_QUEUE_MANAGER_<request_name>.LOG. The request name portion of the logfile name maybe truncated to a valid OpenVMS file specification.

This option uses the same method as EXT_QUEUE_MANAGER to interface with the scheduler. A subprocess is created to run the command procedure ABS$SYSTEM: ABS$EXT_SCHEDULER.COM. The command procedure issues the DCL commands to create, delete, modify and show jobs for third party scheduler product. Also the command procedure has to return status about the commands and in some cases additional information. See the command procedure template file MDMS$SYSTEM:MDMS$EXT_SCHEDULER.TEMPLATE for more details. In contrast to option EXT_QUEUE_MANAGER, ABS assumes that the third party scheduler product reschedules all requests locally and remote. So MDBS will not call the scheduler if a request is due to run.

Failures to execute the command procedure will be logged in the servers’ logfiles. Each activation of the command procedure creates a logfile of MDBS$LOG:MDMS$EXT_SCHEDULER_<request_name>.LOG. The request name portion of the logfile name maybe truncated to a valid OpenVMS file specification.

TLE: This grows to the average size of how many save requests are active.

AOE: This grows to the number of files that are actively being backed up

AOE_INSNC or AOEI: This can grow very large.

As you can see from Example 11.4, catalogs can become quite large. Changing the backup schedule so that less files are saved and using shorter retention periods helps to maintain smaller catalogs. If this cannot be achieved extra disk space should be reserved for the ABS catalogs with space for future expansion.

The coordinator cleanup process (“ABS$COORD_CLEAN”) is responsible to cleanup after a failed save or restore request. It needs to run all the time to perform this task.

Each save or restore request enters a cleanup record into file ABS$SYSTEM: COORD_CLEANUP.DAT. The record contains:

The cleanup process reads this file every minute. If it finds an entry for which the PID field refers to a non-existent process it releases the volume set used in the archive so it can be used again.

To synchronize access to volumes in a volume set ABS keeps pseudo volume records in the volume database. The pseudo volume starts with “&+” and the volume ID of the first volume in the set. To show the pseudo volumes you have to use the /ABS_VOLSET qualifier. The fields in the volume record are used as follows:

The first step to checking the status of save and restore requests is by using the notification options in the environment object. You may set several levels of notification which include start, complete, warning, error and fatal. The notification may be sent by OPCOM or by mail. If you have notification options set, you will receive notification when problems occur with your save and restore requests (or a message about start or completion).

In the MDMS GUI, doing a show of the save or restore request will display the last status of the request. A green (success) or red (error) box will be displayed in the upper right corner of the show output.

Each save and restore request creates a log file in the ABS$LOG directory when it is run. The log file is named by the request name. This log contains information about the request, the media management activities, the backup command and any output from the backup process. If errors occur it also contains trace information about the error. The last error message generally contains the actual cause of the error.

There are some logical names which may be defined at a system level which will cause ABS to log more information in the request log files. You should not set these logical names unless advised to by a VSI customer support representative because the log files can grow quite large if you use them.

If you are running your save/restore request on an OpenVMS Alpha system and you see either ACCVIO or CMA-F-EXCCOP errors in the logs, there is a stack size variable which may eliminate the problem. ABS$COORD_ALPHA_STACKSIZE may be used to increase the stack size beyond the 65536 default. To use the logical, define it at system level to a value which is a multiple of 8192.

$ DEFINE/SYSTEM ABS$COORD_ALPHA_STACKSIZE 8192 * x

If you receive an ABS_SKIPMARKS_FAILED error there is a logical name which may be defined at system level which turns off the ABS fast skip methods. To disable fast skip do the following command on the affected system:

$ DEFINE/SYSTEM ABS_NO_FAST_SKIP TRUE