Converting to ABS/MDMS V4.0
-
D.1 Introduction
This appendix discusses the various conversion activities required when updating to ABS/MDMS V4.0.
SLS V2.x --> ABS/MDMS V4.0
SLS V2.x uses tapestart.com, volume and magazine databases, various data files, and SBK files to do backups. To go to ABS/MDMS V4.0, you may wish to convert your media information to MDMS databases and your SBK files into ABS/MDMS objects. Or you may decide to create all new information in ABS/MDMS V4.0 and skip the conversions. You may do one, both, or none of the conversions.
ABS/MDMS V2.x --> ABS/MDMS V4.0
ABS V2.x uses tapestart.com, volume and magazine databases, and various data files for media management and an ABS policy database for the ABS objects. You may wish to convert the media information into the MDMS databases or you may create new objects. In ABS/MDMS V4.0 the ABS Policy Engine has been moved into the MDMS Server. To upgrade to ABS V4.0 the ABS 2.x or 3.x Policy Database information must be exported to the MDMS Database. There are also some catalog modifications which must be done.
If you are using an ABS Rdb policy database, this must be converted to an RMS database before exporting the data to V4.0 format. The Rdb conversion must be done before updating to V4.0. See
See Converting ABS V2.x/V3.x RDB Policy Database to ABS V4.0 (MDMS Server Database)
ABS V3.0B and MDMS 2.x--> ABS/MDMS V4.0
MDMS V2.x uses tapestart.com, volume and magazine databases. You may wish to convert them to the MDMS databases or create new objects. ABS V3.0B uses the ABS policy databases which must be moved to the MDMS database.
ABS/MDMS V3.1x or 3.2x--> ABS/MDMS V4.0
MDMS V3.x needs no conversions to work with ABS/MDMS V4.0. ABS V3.1 or V3.2 use the ABS policy database which must be moved into the MDMS database.
This section describes how to convert the SLS/MDMS V2.X symbols and database to Media and Device Management Services Version 4 (MDMS). The conversion is automated as much as possible, however, you will need to make some corrections or add attributes to the objects that were not present in SLS/MDMS V2.X.
Before doing the conversion, you should read the chapter about Media Management in the Archive Backup System for OpenVMS Guide to Operations to become familiar with configuration requirements.
All phases of the conversion process should be done on the first database node on which you installed MDMS V4. During this process you will go through all phases of the conversion:
-
1. Convert the symbols in SYS$STARTUP:TAPESTART.COM into the following objects:
-
Locations
-
Domain
-
Nodes
-
Media types
-
Jukeboxes
-
Drives
-
2. Convert the database authorization file, VALIDATE.DAT, into node objects.
-
Convert the rest of the database files:
-
Pool Authorization file (POOLAUTH.DAT)
-
Slot Definition file (SLOTMAST.DAT)
-
Volume Database file (TAPEMAST.DAT)
-
Magazine Database file (SLS$MAGAZINE_MASTER_FILE.DAT)
When you install on any other node that does not use the same TAPESTART.COM as the database node, you only do the conversion of TAPESTART.COM
-
Executing the Conversion Command Procedure
To execute the conversion command procedure, type in the following command:
$ @MDMS$SYSTEM:MDMS$CONVERT_V2_TO_V3
The command procedure will introduce itself and then ask what parts of the SLS/MDMS V2.x you would like to convert.
During the conversion, the conversion program will allow you to start and stop the MDMS server. The MDMS server needs to be running when converting TAPESTART.COM and the database authorization file. The MDMS server should not be running during the conversion of the other database files.
During the conversion of TAPESTART.COM the conversion program generates the following file:
$ MDMS$SYSTEM:MDMS$LOAD_DB_nodename.COM
This file contains the MDMS commands to create the objects in the database. You have the choice to execute this command procedure or not during the conversion.
The conversion of the database files are done by reading the SLS/MDMS V2.x database file and creating objects in the MDMS V4 database files.
You must have the SLS/MDMS V2.x DB server shutdown during the conversion process. Use the following command to shut down the SLS/MDMS V2.x DB server:
$ @SLS$SYSTEM:SLS$SHUTDOWN
-
Resolving Conflicts During the Conversion
Because of the difference between SLS/MDMS V2.x and MDMS V4 there will be conflicts during the conversion. Instead of stopping the conversion program and asking you about each conflict, the conversion program generates the following file during each conversion:
$ MDMS$MDMS$LOAD_DB_CONFLICTS_nodename.COM
Where nodename is the name of the node you ran the conversion on. This file is not meant to be executed, it is there for you to look at and see what commands executed and caused a change in the database. This change is flagged because there was already an object in the database or this command changed an attribute of the object.
An example could be that you had two media types of the same name but one specified compressed and one other specified non compressed. This would cause a conflict. MDMS V4 does not allow two media types with the same name but different attributes. What you see in the conflict file would be the command that tried to create the same media type. You will have to create a new media type.
See Symbols in TAPESTART.COM shows the symbols in TAPESTART.COM file and what conflicts they may cause.
At the completion of the conversion of the database files, you will see a message that notes the objects that where in an object but not defined in the database. For example: the conversion program found a pool in a volume record that was not a pool object.
-
Symbols in TAPESTART.COM
|
TAPESTART.COM Symbol
|
MDMS V4 Attribute or Object
|
Possible conflict
|
|
ALLOCSCRATCH
|
If defined, adds the SCRATCH_TIME
attribute to the domain object.
|
If the ALLOCSCRATCH symbol is different in different TAPESTART.COM files a line is added to the conflict file.
|
|
DB_NODES
|
If defined, creates a node object for the nodes in the DB_NODES list.
|
A conflict can be generated if the node exists and an attribute changed with a different TAPESTART.COM file. Every drive and jukebox definition in the TAPESTART.COM can cause a node to be created with a /NODATABASE_SERVER qualifier. A DB node will change the attribute to database server, this can cause a line to be added to the conflict file.
|
|
DCSC_n_NODES
|
If defined, creates a node object and adds the node attribute to the DCSC jukebox.
|
All adds of nodes to jukeboxes cause a line to be added to the conflict file.
|
|
DCSC_DRIVES
|
If defined, creates a drive object for DCSC.
|
If an attribute is different when adding attributes a line is added to the conflict file.
|
|
DENS_x
|
If defined, adds the density or compaction attribute to a media type. If the value is COMP or NOCOMP then the compaction attribute is define: YES or NO. If the density is anything other than COMP or NOCOMP then the value is placed in the density attribute.
|
A line is added to the conflict file if the DENS_x is different.
|
|
FRESTA
|
If defined, adds the deallocate state attribute to the domain object.
|
If the FRESTA symbol is different in different TAPESTART.COM files a line is added to the conflict file.
|
|
LOC
|
Creates a location object and also sets the ONSITE_LOCATION attribute in domain object.
|
If the object exists or is different than the onsite location attribute in the domain object a line to be added to the conflict file. This can happen when you have different LOC symbol in two TAPESTART.COM files.
|
|
MAXSCRATCH
|
If defined, adds the maximum scratch time attribute to the domain object.
|
If the MAXSCRATCH symbol is different in different TAPESTART.COM files a line is added to the conflict file.
|
|
TAPESTART.COM Symbol
|
MDMS V4 Attribute or Object
|
Possible conflict
|
|
MTYPE_x
|
Creates a media type object for each MTYPE_x.
|
A line is added to the conflict file if a media type is already in the database and another one has the same name. In SLS/MDMS V2.x you could have the same media type name with compaction and nocompaction. In MDMS you cannot have two media types with the same name. You need to change the name of one of the media type and enter it into the database. You will also have to change ABS or HSM to reflect this. Also, you may have to change volume and drive objects.
|
|
NET_REQUEST_TIM EOUT
|
If defined, adds the NETWORK_TIMEOUT attribute to the domain object.
|
If the NET_REQUEST_TIMEOUT is different in different TAPESTART.COM files a line is added to the conflict file.
|
|
PROTECTION
|
Adds the default protection to the domain object.
|
A line is added to the conflict file if the protection is changed.
|
|
QUICKLOAD
|
When drives are created, this attribute is added as automatic reply.
|
A line is added to the conflict file if a drive's automatic reply is changed.
|
|
TAPE_JUKEBOXES
|
Creates a jukebox object for each jukebox in the list.
|
A line is added to the conflict file if a jukebox is already defined and any of the attributes change.
|
|
TAPEPURGE_MAIL
|
If defined, adds the mail attribute to the domain object.
|
If the TAPEPURGE_MAIL is different in different TAPESTART.COM files a line is added to the conflict file.
|
|
TOPERS
|
If defined, adds the Opcom class attribute to the domain object.
|
If the TOPERS symbol is different in different TAPESTART.COM files a line is added to the conflict file.
|
|
TRANS_AGE
|
If defined, adds the transition time attribute to the domain object.
|
If the TRANS_AGE symbol is different in different TAPESTART.COM files a line is added to the conflict file.
|
|
VLT
|
Creates a location object and also sets the OFFSITE_LOCATION attribute in domain object.
|
If the object exists or is different than the offsite location attribute in the domain object, a line is added to the conflict file. This can happen when you have different VLT symbol in two TAPESTART.COM files.
|
-
Things to Look for After the Conversion
Because of the differences between SLS/MDMS V2.x and MDMS V4 you should go through the objects and check the attributes and make sure that the objects have the attributes that you want.
See Things to Look for After the Conversion shows the attributes of objects that you may want to check after the conversion.
-
Things to Look for After the Conversion
|
Object
|
Attribute
|
Description
|
|
Drive
|
Drive
|
Make sure you have all of the drives defined. In the MDMS V4 domain, you can only have one drive with a given name. In SLS/MDMS V2.x you could have two drives with the same name if they were in different TAPESTART.COM files. You should make sure that all drives in your domain are in the database. You may have to create one drive with a name of say, DRIVE1 with a device name of $1$MUA520 and a node of NODE1. Then create another drive, DRIVE2, with a device name of $1$MUA520 and a node of NODE2.
A line is added to the conflict file every time a node is added to a drive. This flags you to check that the node really belongs to this drive of if you need to create another drive.
|
|
|
Description
|
Make sure this is the description you want for this drive. This attribute is not filled in during the conversion program.
|
|
|
Device
|
Make sure this device name does not have a node name as part of it.
|
|
|
Nodes
|
Make sure this list of nodes contains the nodes that can reach this drive.
|
|
|
Disabled
|
The conversion program enables all drives. If you want this drive disabled, then set this attribute to YES.
|
|
|
Shared
|
The conversion program sets this attribute to NO. NO means that MDMS does not have to compete with other applications for this device. If MDMS is supposed to share this device with other applications set this attribute to YES.
|
|
|
State
|
Make sure this drive is in the right state. If the drive is not in the right state, you can set this attribute to the right state or issue the following command:
$ MDMS SET DRIVE drive/CHECK
|
|
|
Automatic reply
|
The conversion program sets this attribute from the QUICKLOAD symbol. Make sure this is the way you want the drive to react.
|
|
|
RW media types
|
The conversion program added media types to this drive as it found them. Make sure these are the correct read-write media types for this drive.
|
|
|
RO Media Types
|
There are no read-only media types in SLS/MDMS V2.x so none is added to the drives during conversion. You may want to add some read-only media types to the drive object.
|
|
|
Access
|
The conversion program has no way of knowing what the access should be, therefore, it sets the access attribute to ALL. Make sure this is the access you want for this drive.
|
|
|
Jukebox
|
Make sure this is the jukebox that this drive is in.
|
|
|
Drive Number
|
Make sure this is the drive number for robot commands.
|
|
Object
|
Attribute
|
Description
|
|
Domain
|
Description
|
Make sure this is the description you want for your domain. The default is: Default MDMS Domain.
|
|
|
Mail
|
Make sure this is where you want mail sent when a volume reaches its scratch data and MDMS dellocates it. If you do not want mail sent, make the value blank.
The default is: SYSTEM.
|
|
|
Offsite location
|
Make sure this is the offsite location that you want for the default when you create objects. This was set to the value of VLT from TAPESTART.COM file. This could be different in each TAPESTART.COM file.
|
|
|
Onsite location
|
Make sure this is the onsite location that you want for the default when you create objects.
|
|
|
Default media type
|
Make sure this is the media type you want assigned to volumes that you do not specify a media type for, while creating.
|
|
|
Deallocate state
|
Make sure this is the default state you want volumes to go to after they have reached their scratch date. This could be changed each time that you convert the TAPESTART.COM file on a new node.
|
|
|
Opcom classes
|
Make sure these are the Opcom classes where you want MDMS OPCOM messages directed. This could be changed each time you convert the TAPESTART.COM file on a new node.
|
|
|
Protection
|
Make sure this is the default protection that you want assigned to volumes that you do not specify a protection for.
|
|
|
Maximum scratch time
|
Make sure this is the default maximum scratch time you want for volumes in your domain. This could be changed each time that you convert the TAPESTART.COM file on a new node.
|
|
|
Scratch time
|
Make sure this is the default scratch time you want for volumes in your domain. This could be changed each time that you convert the TAPESTART.COM file on a new node.
|
|
|
Transition time
|
Make sure this is the default transition time you want for volumes in your domain. This could be changed each time that you convert the TAPESTART.COM file on a new node.
|
|
|
Network timeout
|
Make sure this is the network timeout you want. This could be changed each time that you convert the TAPESTART.COM file on a new node.
|
|
Location
|
Description
|
Make sure this is the description you want for this location. This attribute is not filled in during the conversion program.
|
|
|
Spaces
|
The conversion program cannot fill in spaces so make sure you set the spaces attribute.
|
|
|
In location
|
The conversion program cannot fill in this attribute so make sure if this location is in a higher level location you set this attribute.
|
|
Object
|
Attribute
|
Description
|
|
Media type
|
Media type
|
Make sure you have all the media types that you had before. In the MDMS V4 you can only have on media type with the same name. If you had two media types in SLS/MDMS V2.x with the same name, the second one is not created in the MDMS V4 database.
|
|
|
Description
|
The conversion program does not add a description to this attribute. Type in a description for this attribute.
|
|
|
Density
|
The density attribute is only changed when the DENS_x symbol in the TAPESTART.COM file is something other than COMP or NOCOMP. Check to make sure this is correct.
|
|
|
Compaction
|
This attribute is set to YES if the DENS_x symbol in the TAPESTART.COM file is COMP. It is set to NO if the symbol is NOCOMP. Check to make sure this is right.
|
|
|
Capacity
|
This attribute is set to the value of DENS_X from the TAPESTART.COM file if it is not defined as COMP or NOCOMP. Check to make sure this right.
|
|
Jukebox
|
Description
|
The conversion program does not put a description for this attribute. Type in a description to this attribute.
|
|
|
Nodes
|
Make sure this list of nodes contains the nodes that can reach the robot.
|
|
|
Location
|
Make sure this is the location where this jukebox is located.
|
|
|
Disabled
|
The conversion program enables all jukeboxes. If you want this jukebox disabled, set this attribute to YES.
|
|
|
Shared
|
The conversion program sets this attribute to NO. NO means that MDMS does not expect to compete with other applications for this jukebox. If MDMS is supposed to share this jukebox with other applications set this attribute to YES.
|
|
|
Auto reply
|
The conversion program sets this attribute to NO. Make sure this is the way you want the jukebox to react.
|
|
|
Access
|
The conversion program has no way of knowing what the access should be, therefore, it sets the access attribute to ALL. Make sure this is the access you want for this jukebox.
|
|
|
Control
|
Make sure that the attribute is set to MRD if MRD controls the robot. If the robot is controlled by DCSC, this attribute should be set to DCSC.
|
|
|
Robot
|
Make sure this is the robot for this jukebox.
|
|
|
Slot count
|
You need to set the slot count. The conversion program has no way of finding out the slot count.
|
|
|
Usage
|
Make sure the usage is correct for the type of jukebox you have. The conversion program has no way of finding out if the jukebox uses magazines or not. If this jukebox uses magazines, you will need to configure it.
|
|
Magazine
|
Description
|
The conversion program does not add a description to this attribute. Type a description for this attribute.
|
|
Object
|
Attribute
|
Description
|
|
|
Offsite location
|
The old magazine record had no offsite location, so you need to add this attribute.
|
|
|
Offsite date
|
The old magazine record had no offsite date, so you need to add this attribute.
|
|
|
Onsite location
|
The old magazine record had no onsite location, so you need to add this attribute.
|
|
|
Offsite date
|
The old magazine record had no onsite date, so you need to add this attribute.
|
|
Node
|
Description
|
The conversion program does not put a description in this attribute. Type a description for this attribute.
|
|
|
DECnet-Plus fullname
|
TAPESTART.COM does not support DECnet-Plus, therefore the conversion program cannot put in the DECnet-Plus fullname attribute. If this node uses DECnet-Plus, you should set this attribute.
|
|
|
TCP/IP fullname
|
TAPESTART.COM does not support TCP/IP, therefore the conversion program cannot put in the TCP/IP fullname attribute. If this node uses TCP/IP, you should set this attribute.
|
|
|
Disabled
|
The conversion program sets the enabled attribute. Make sure you want this node enabled.
|
|
|
Database server
|
If this attribute is set to YES, this node has the potential to become a database server.
The logical MDMS$DATABASE_SERVERS must have this node name in is definition of nodes in the domain. This definition is defined in the SYS$STARTUP:MDMS$SYSTARTUP.COM file
|
|
|
Location
|
Make sure this is the location that this node is located in. During the conversion it could have been changed depending on the TAPESTART.COM file or what the default was in the domain object at the time of creation.
|
|
|
Opcom classes
|
This attribute is defined as the Opcom class in the domain object when the node was created. Make sure this is the Opcom class for this node.
|
|
|
Transports
|
Make sure this is the transport you want. The conversion program has no way of knowing the transports you want so it takes the defaults.
|
|
POOL
|
Description
|
Make sure this is the description you want for this pool. This attribute is not filled in during the conversion program.
|
|
|
Authorized users
|
Make sure that the comma separated list contains all of the authorized users for the pool. The users must be specified as NODE::user
|
|
|
Default users
|
You need to set this attribute because conversion program does not set this attribute. The users must be specified as node::user.
|
|
VOLUME
|
|
The conversion program fills in all needed attributes from the old record.
This is included so you will not think the volume object was forgotten.
|
-
Upgrading the Domain to MDMS V4
Upgrading your SLS/MDMS V2 domain starts with the nodes, which have been defined as database servers in symbol DB_NODES in file TAPESTART.COM. Refer to the Installation Guide for details on how to perform the following steps.
-
Step 1. Shut down all SLS/MDMS database servers in your SLS/MDMS domain.
-
Step 2. Install version MDMS V4 on nodes, which have been acting as database servers before.
-
Step 3. When the new servers are up-and-running check and possibly change the configuration and database entries so that it matches your previous SLS/MDMS V2 setup
-
Step 4. Edit SYS$MANAGER:MDMS$SYSTARTUP.COM and make sure that:
-
Logical name MDMS$DATABASE_SERVERS include this nodes DECnet (Phase IV) node name
-
Logical name MDMS$PREV3_SUPPORT is set to TRUE to enable the SLS/MDMS V2 support function in the new server
-
Logical name MDMS$VERSION3 is set to TRUE to direct ABS and/or HSM to use the new MDMS V4 interface
If you had to change any of the logical name settings above you have to restart the server using '@SYS$STARTUP:MDMS$STARTUP RESTART'. You can type the server's logfile to verify that the DECnet listener for object SLS$DB has been successfully started.
-
Step 5. To support load, unload and operator requests from old SLS/MDMS clients you have to edit SYS$MANAGER:TAPESTART.COM and change the line which defines DB_NODES to read like this:
$ DB_NODES = ""
This prevents a SLS/MDMS V2 server from starting the old database server process SLS$TAPMGRDB.
-
Step 6. Now you are ready to start up ABS or HSM.
-
Convert from MDMS Version 3 to a V2.X Volume Database
This section describes how to convert the MDMS V4 volume database back to a SLS/MDMS V2.X volume database.
If for some reason, you need to convert back to SLS/MDMS V2.X a conversion command procedure is provided. This conversion procedure does not convert anything other than the volume database. If you have added new objects, you will have to add these to TAPESTART.COM or to the following SLS/MDMS V2.X database files:
-
database authorization file (VALIDATE.DAT)
-
Pool Authorization file (POOLAUTH.DAT)
-
Slot Definition file (SLOTMAST.DAT)
-
Volume Database file (TAPEMAST.DAT)
-
Magazine Database file (SLS$MAGAZINE_MASTER_FILE.DAT)
To execute the conversion command procedure, type in the following command:
$ @MDMS$SYSTEM:MDMS$CONVERT_V3_TO_V2
After introductory information, this command procedure will ask you questions to complete the conversion.
-
D.3 SLS V2.x to ABS V4.0 Conversion Process
This chapter identifies the Conversion Process from SLS to ABS. First, the steps involved in converting from SLS to ABS are presented and explained. A Conversion Utility to help with the conversion is then presented.
-
Steps for Conversion
This section identifies the steps involved in converting a site's backup management from SLS to ABS. These steps are intended as guidelines, since each site has different requirements and need for their backup management.
-
Convert the MDMS Database
The first step in converting from SLS to ABS is to convert the volume, slot and magazine databases, and the media and device portions of TAPESTART.COM to MDMS databases. A command procedure is provided for this purpose and this procedure is documented in See Converting SLS/MDMS V2.X Symbols and Database . Please note that this version of ABS and all future versions require the accompanying version of MDMS included in the installation kit.
-
Determine your use of SLS
The next step in converting from SLS to ABS is to identify how you use SLS. There are three major uses of SLS:
-
System Backups
-
Standby Archiving
-
User Backups
ABS provides the same functionality as SLS System Backups and SLS User Backups. However, ABS cannot perform the same function as SLS Standby Archiving.
If you use SLS System Backups (as many sites do), then converting to ABS is fairly simple. If you use SLS User Backups, converting to ABS is slightly more involved, but is still fairly straightforward. If you use SLS Standby Archiving, ABS will not provide equivalent functionality.
-
Converting SLS System Backups to ABS
This section describes how to convert SLS System Backups (SBK files) into ABS Policy.
Determine valid SBK files
At many sites, only a few of the SBK files which reside in SLS$SYSBAK are actually used. The other SBK files are a result of experimentation, false starts at configuring SLS, or are obsolete.
In order to simplify the conversion of SLS System Backups, you should first identify the SBK files which you actually use. Usually, SBK Files are used at your site if:
-
They are scheduled regularly by SLS
-
They are manually executed by you or the Operator
A simple way of finding the SBK files which are scheduled by SLS is to search the SBK files for the DAYS_1 symbol. Any SBK file which does not define DAYS_1, or defines it as blank, is not scheduled by SLS for automatic execution. These SBK files are prime candidates for obsolete or unused files.
After identifying the SBK files which are not automatically scheduled, carefully determine which of the files may be invoked manually by you or the Operator.
Once you have identified the obsolete or unused SBK files, you can remove them from SLS$SYSBAK (after backing them up in case of mistakes, of course).
Convert the Valid SBK Files to ABS Policy
Once you have cleaned up your SLS$SYSBAK directory to only contain those SBK files you actually use, it is time to convert these SBK files to ABS Storage Classes (Archives), Execution Environments and Save Requests.
hp provides a utility to help in this conversion process. The conversion utility is called SLS_CONVERT.COM, and is included as an installation kit on the ABS Kit. To install the SLS to ABS Conversion utility, issue the command:
$ @SYS$UPDATE:VMSINSTAL SLSTOVABS041 ABS$SYSTEM: ! VAX System OR
$ @SYS$UPDATE:VMSINSTAL SLSTOAABS041 ABS$SYSTEM: ! Alpha System
This command will install the conversion utility into ABS$SYSTEM:SLS_CONVERT.COM, and will create a subdirectory under the ABS$ROOT called SLS_CONVERSION. In addition, a logical name, ABS$SLS_CONVERSION will be defined to point to the work directory for the conversion effort.
The conversion utility creates DCL Command Procedures which issues appropriate ABS DCL commands equivalent to each SBK file. No changes are made to your ABS Policy Configuration directly. This allows you to experiment with the conversion utility safely, without affecting either the execution of your SLS SBK files, or starting ABS Save Requests inadvertently.
Once you have installed the conversion utility, you can create ABS command procedures for all of your SBK files by issuing the command:
$ @ABS$SYSTEM:SLS_CONVERT *
The asterisk indicates you want to convert all SBK files to ABS DCL Commands. If you only want to convert one SBK file, you can specify the name of the SBK without the _SBK.COM or SLS$SYSBAK on the command line. For example, to convert NIGHTLY_SBK.COM, you would issue the command:
$ @ABS$SYSTEM:SLS_CONVERT NIGHTLY
Evaluate the ABS Conversion Command Files
After running the conversion utility, the ABS$SLS_CONVERSION directory will contain one ABS DCL Command Procedure for each SBK file converted. These output command files will contain:
-
Comments explaining the conversion process
-
ABS DCL Commands to create ABS Policy Objects
-
A Prolog and Epilog command to complete the functions performed by the SBK file
You should not execute these command procedures blindly. The conversion utility attempts to duplicate the backup policy reflected in each SBK file, but you should carefully examine each command file produced to ensure that errors were not made, and that the ABS Policy to be created correctly reflects the backup policy you expect.
The things you should check for in the produced command procedures are:
-
Naming conventions used in the conversion may not be what you want
-
Errors in converting the SBK policy
-
Possible ABS Policy Consolidation
The command procedure for each SBK file processed will contain the ABS DCL Commands to create one Storage Class (Archive), one Execution Environment and one or more Save Requests.
Naming Conventions Used
The name of the Storage Class (Archive) created for an SBK file will be the value of the CONTINUE symbol (if defined) followed by the suffix "_SC". If the CONTINUE symbol is not defined, the Storage Class (Archive) will be named the same as the SBK file with the "_SC" suffix.
The Environment created for an SBK will be named the same as the SBK file, but with an "_ENV" suffix. When a Save Request specifies a Storage Class (Archive) , the default Environment used will be the same name as the Storage Class (Archive), but with the "_ENV" suffix. Thus, the Environment created should be used by default.
Each SBK File will produce one or more ABS Save Requests. More than one ABS Save Request will be produced from an SBK file if all the following conditions are met:
-
There are more than one FILES_n is specified
-
The QUALIFIERS_n differ in the type of operation
-
More than eight include specifications are found in a single SBK file (This limit has been removed in ABS/MDMS V4.0, so you may want to include more than 8 includes in a save).
For example, if an SBK file has QUALIFIER_1 defined as "/IM" indicating an Image (or Full) backup operation, but QUALIFIERS_2 is defined as "/SINCE=BACKUP" indicating an Incremental operation, then ABS will need two separate Save Requests to implement this policy. This is because an ABS Save Request will only do Full, Incremental or Selective operations, not a mix of them.
If all QUALIFIERS_n specify the same movement type and there are fewer than eight FILES_n, then ABS can combine all the operations into a single Save Request.
The Save Requests created will be named the same as the SBK file, but with "_FULL", "_INC" or "_SEL" to indicate the data movement type included in the Save Request. For example, if the SBK file NIGHTLY_SBK.COM defines FILES_1 through FILES_20, and all qualifiers include the "/IM" Image qualifier, then the conversion tool will create three Save Requests, called NIGHTLY_FULL_1 through NIGHTLY_FULL_3. Because ABS has a limit of 8 operations per save request, NIGHTLY_FULL_1 and NIGHTLY_FULL_2 would perform 8 Full backup operations, and NIGHTLY_FULL_3 would perform the last four. This limit has been removed in ABS/MDMS V4.0, so you may wish to include more operations per save request.
Consolidate ABS Policy Objects
The Conversion Utility shipped with ABS is a very simple utility. It converts each SBK file into the appropriate ABS DCL Commands to create the Storage Classes (Archives), Execution Environments and Save Requests necessary to reflect the backup policy in the SBK file.
No attempt is made to consolidate the Storage Classes (Archives) and Execution Environments, or to overlay the Save Requests for more optimum performance.
Before executing the command procedures to create the ABS Policy objects, you should try to consolidate Storage Classes (Archives) and Execution Environments. Save Requests may be combined if warranted by the intended policy, but in some cases, breaking a Save Request into several is better for reducing nightly backup time, simplifying an overall backup policy, or backing up different objects at different intervals.
Consolidating Storage Classes (Archives)
Consolidating the Storage Classes (Archives) is done by comparing their parameters. For each pair of Storage Classes (Archives), you can determine whether they can be combined by using the See Storage Class (Archive) Parameter. Note that in all cases, you can decide that one or the other parameter is correct for both, and consolidate based upon that decision.
-
Storage Class (Archive) Parameter
|
Storage Class (Archive) Parameter
|
Matching Criteria
|
|
Name
|
Doesn't matter choose meaningful name
|
|
Media Type
|
Should match
|
|
Tape Pool
|
Should match
|
|
Media Location
|
Should match
|
|
Access Control
|
OK if different, choose best for intended Storage Class (Archive) use
|
|
Owner
|
Should both be ABS
|
|
Retention
|
OK if different, choose best for intended Storage Class (Archive) use
|
|
Volume Set Name
|
Not set, doesn't matter
|
|
Consolidation Criteria
|
OK if different, choose best for intended Storage Class (Archive) use
|
|
Catalog name
|
OK if different
|
|
Number of Streams
|
Always set to 1 from Conversion utility
|
|
Execution Node
|
Should match
|
|
Drive name
|
OK if different, choose best for intended Storage Class (Archive) use
|
Only the Administrator at a site can truly determine if two separate Storage Classes (Archives) can be consolidated based upon the intended use of the Storage Class (Archive).
Consolidating Execution Environments
Consolidating Execution Environments is again done by comparing the parameters of pairs of Environments, and then combining those Environments if your decisions indicate they can serve the same purpose.
Use See Execution Environment Parameter as a guide:
-
Execution Environment Parameter
|
Environment Parameter
|
Matching Criteria
|
|
Name
|
Doesn't Matter choose meaningful name
|
|
Data Safety options
|
OK if different choose best for intended Environment's use
|
|
Listing options
|
OK if different Digital recommends not producing listings
|
|
Span FileSystems
|
Should Match
|
|
Links Only
|
Should Match
|
|
Original object action
|
Should Match
|
|
User Profile
|
Will always be ABS from conversion utility, choose PRIVI LEGES best for intended Environment's use
|
|
Notification
|
OK if different choose best for intended Environment's use
|
|
Locking options
|
Should match
|
|
Number of drives
|
OK if different choose best for intended Environment's use
|
|
Retry options
|
OK if different choose best for intended Environment's use
|
|
Prolog and Epilog
|
Should match, or be combined
|
As with Storage Classes (Archives), only the Administrator at a site can truly determine if two separate Environments can be consolidated based upon the intended use of the Environment.
Implement ABS Policy
This section discusses the steps involved in implementing the ABS Policy as produced by the conversion utility and evaluated by the site Administrator.
Executing the Command Procedures
After you have examined the raw output command files from the conversion utility and done what consolidation or modifications seem appropriate, the command files can simply be executed using the at sign (@) operator at DCL. When each command procedure is invoked, it will:
-
Create a Storage Class (Archive)
-
Create an Execution Environment
-
Create one or more Save Requests and associated schedules.
-
Possibly create a Prolog command procedure
-
Possibly create an Epilog command procedure
Integrating the Prolog and Epilog Commands
There are several features of an SBK file which are not directly supported by ABS. The conversion utility creates a Prolog command file and an Epilog command file which implement some of these other features.
For example, ABS does not support the Offsite Date or Onsite Date in the SBK file directly. However, by issuing the appropriate MDMS SET VOLUME command, this can be implemented. The conversion utility writes these commands into the Prolog or Epilog command files.
When the conversion utility produces a Prolog and Epilog command procedure, they will be created in the ABS$SLS_CONVERSION directory, and will be called, the same name as the Save Request, but will have "_PROLOG" or "_EPILOG" appended. For example, if you convert the NIGHTLY_SBK.COM, you will end up with the Prolog and Epilog command files:
ABS$SLS_CONVERSION:NIGHTLY_ABS_PROLOG.COM
ABS$SLS_CONVERSION:NIGHTLY_ABS_EPILOG.COM
If you need the features implemented in the Prolog or Epilog command procedures, you should integrate these into your own Prolog and Epilog command procedures (if any). Both the Execution Environment and the Save Request may have Prolog and Epilog commands associated with them, which are usually the execution of a site specific command procedure. If you want the features implemented in the Prolog or Epilog command procedures produced by the conversion utility, you should invoke them from your site specific command procedure.
SBK Symbols and ABS Logicals
When executing an SBK file, SLS makes various DCL symbols accessible to the prolog and epilog command files you invoke. For example, SLS will define the DCL symbol DO_DISK as the name of the disk being backed up during an SBK execution. The objective is to allow the prolog or epilog commands to produce log messages, or perform other operations based upon the SBK file execution.
ABS provides logical names which provide similar functionality. For example, ABS defines the logical name ABS_OS_OBJECT_SET_1 as the set of files being backed up in the first data movement operation. Thus, it can be used in the place of the FILES_n symbol in an SBK file.
The conversion utility kit provides a command procedure, SLS_SYMBOLS.COM, which attempts to define many of the same DCL symbols as an SBK file does based upon the ABS logical names. For example, it defines the DO_DISK symbol based upon the ABS logical name ABS_OS_OBJECT_SET_1.
See ABS$SLS_CONVERSION:SBK_SYMBOLS.COM command procedure for details on the definition of each SBK symbol. Not all SLS DCL symbols defined are supported by the command procedure.
Disable the SLS SBK Files
It is very important to note that once you have executed the DCL Command procedures produced by the conversion utility, the ABS Save Requests will be executing according to their schedules. This means that you will be doing both SLS and ABS backups if you do not disable the SLS SBK files.
The SLS SBK files can be disabled by changing their DAYS_n and TIME_n qualifiers to empty. This causes SLS to no longer schedule the SBK files for execution.
Since SLS and ABS use different media management subsystems, it is highly recommended that you do not use both products on the same node. If you do, you will find that the SLS and MDMS volume databases may get out of synchronization, and there may be contention and other unexpected troubles with drives and jukeboxes. If you wish to stage your SLS to ABS conversion across your network, the following approach is recommended:
Define your database server as your first set of nodes to convert; these nodes will run the MDMS database server
Perform the MDMS conversion on these nodes - see See Converting SLS/MDMS V2.X Symbols and Database.
Perform the ABS conversion on these nodes
On other client nodes still running SLS, define the appropriate TAPESTART.COM to point to nodes in the ABS/MDMS database server in the symbol DB_NODES
At this point, your volume, magazine and slot databases are being managed by MDMS, but your client systems are still able to use SLS as the backup paradigm. It is recommended that you convert the remainder of your systems to ABS/MDMS as soon as practical, because some of the more unusual features of SLS/MDMS are not supported by the new MDMS database server.
-
Converting User Backup policy
The conversion utility does not convert User Backup policy automatically. It is only intended to make converting SBK files easier or automatic.
To allow a particular user to do their own backups, follow the steps as outlined in Section . Note that there is no automatic way to set up archives for the entire user population, or a large set of users except by creating a DCL command procedure issuing the correct ABS DCL commands.
-
Monitor ABS Activity
After implementing your backup policy in ABS, you should carefully monitor the activities of ABS until you are confident that your policy is being executed as intended.
There are three ways to monitor ABS activity:
-
Show the schedules (MDMS SHOW SCHEDULE, or MDMS SHOW SAVE *).
-
Set up Notification criteria on the Environments to send you mail when ABS operations complete. The mail will contain the name of the job and the final status.
-
Examine the ABS Log files. All ABS Log files are created in the ABS$LOG: directory, and are called the same name as the Save Request.
-
For catalog operations:
-
Monitor the Staging Log files
-
These are named ABS$LOG:<catalog_name>_<stream>.LOG
-
Monitor the Catalog cleanup log files
-
These are named ABS$LOG:ABS$CATALOG_CLEANUP.LOG
-
Restoring from SLS History Sets
ABS has the ability to restore data backed up by SLS. After you have implemented your backup policy using ABS, it may be necessary to restore data which was backed up using SLS prior to the conversion.
To restore from SLS history sets, you must create an ABS catalog for this purpose. These catalogs are not maintained by ABS and are used only for restore purposes.
ABS catalogs that are created for SLS provide the following features:
-
The ability to perform an ABS selective restore operation for data that was previously saved using SLS.
-
The ability to perform an ABS lookup operation to search for data objects in an existing SLS history file. The MDMS SHOW CATALOG/FILES command will not work with SLS catalogs.
-
The ability to specify wildcard characters, such as an asterisk (*) or percent sign (%), for an ABS operation that searches SLS history sets. You can also specify the ellipsis within square brackets ([...]).
Restrictions:
An ABS catalog created for SLS restore operations imposes the following restrictions:
-
You cannot restore Oracle Rdb databases saved using SLS.
-
You cannot perform a full restore operation on an image backup used by SLS.
-
You cannot perform an incremental restore operation that used SLS.
To create a catalog for restoring data that was saved using SLS, follow these steps:
-
Step 1. Create a new catalog using the MDMS CREATE CATALOG command.
-
Step 2. Specify the SLS history set name as the name of the catalog, for example: (name=MY_HIST). The catalog name must match the SLS history set name. For each SLS history set name for which you want to perform a lookup or restore operation, you must create a corresponding ABS catalog.
-
Step 3. Set the catalog type as SLS.
-
Step 4. Do not enable staging.
-
Step 5. If you plan to perform a restore operation, create an Archive which references the new catalog name, specifies a media type, and enables READ only access control. Do not enable WRITE access.
-
Conversion Utility Reference
-
Command Syntax
$ @ABS$SYSTEM:SLS_CONVERT <wildcard_SBK_spec> [<match1>] [<match2>...]
<wildcard_SBK_spec>
This parameter identifies the set of SBK files to be converted by this command. The string given should not include SLS$SYSBAK: or the _SBK.COM suffix. For example, if you want to convert the SBK file SLS$SYSBAK:NIGHTLY*_SBK.COM, you should issue the command:
$ @ABS$SYSTEM:SLS_CONVERT NIGHTLY*
<match1> ... <match7>
These optional parameters allow you to search the SBK files defined by the <wildcarded_SBK_spec> and only process those files which contain ALL of the given strings. The strings must all appear on the same line in the SBK file, since the SLS_CONVERT command procedure uses a /MATCH=AND on the Search command.
-
Output Command File naming and contents
The output of the SLS_CONVERT conversion utility is one DCL command procedure for each SBK file processed. The command procedures will be created in the ABS$SLS_CONVERSION directory.
Each command procedure will be named the same as the SBK file, but substituting "ABS" for "SBK". For example, if the SBK file SYSTEM_DISK_SBK.COM is converted, the output command procedure will be ABS$SLS_CONVERSION:SYSTEM_DISK_ABS.COM.
Although the command procedures can be executed immediately, it is highly recommended that you review their contents before executing them to ensure that the ABS Policy objects which will be created accurately reflect your intended backup policy.
Each output command file will contain:
-
A block of comments indicating that the file was produced by the conversion utility, and the date and time of the conversion.
-
The name of the SBK file represented in the command file
-
The list of SBK parameters which are not handled by the conversion utility, and the reason they are not.
-
An ABS Create Storage command to create a Storage Class (Archive). This corresponds to the MDMS create Archive command.
-
An ABS Create Environment command to create an Execution Environment.
-
One or more ABS Save commands and ABS Set Save commands to create Save Requests. See See Determine your use of SLS for information on why a single SBK file might produce multiple Save Requests.
-
The creation of a Prolog command file. The Prolog command file should be integrated with any site specific prolog command files to complete the functions defined by the SBK.
-
The creation of an Epilog command file. The Epilog command file should be integrated with any site specific epilog command files to complete the functions defined by the SBK.
-
SBK Symbols in ABS Terminology
See SBK Symbols in ABS Terminology, lists SBK Symbols in ABS Terminology.
-
SBK Symbols in ABS Terminology
|
SBK Symbol
|
ABS Equivalent
|
Meaning
|
|
DAYS_n
|
Save Request /SCHEDULE and /EXPLICIT
|
Defines how often the backup oper ations are performed
|
|
TIME_n
|
Save Request /START_TIME
|
Defines when the backup operation starts
|
|
NODE_n
|
Save Request /SOURCE_NODE
|
Defines the node in your network where the data resides
|
|
BACKUP_TYPE
|
Save Request /OBJECT_TYPE
|
Defines the type of data to be backed up or restored.
|
|
PRE_PROCESS_FIRST
|
Environment /PROLOG
|
Defines a command to be executed when the backup job starts
|
|
PRE_PROCESS_EACH
|
Save Request /PROLOG
|
Defines a command to be executed prior to each backup operation within a job
|
|
POST_PROCESS_EACH
|
Save Request /EPILOG
|
Defines a command to be executed when each operation within a job finishes
|
|
POST_PROCESS_LAST
|
Environment /EPILOG
|
Defines a command to be executed when the backup job completes.
|
|
NEXT_JOB
|
Use dependencies in current scheduler interface option if available
|
Defines what job to run next after the current job completes
|
|
SUMMARY_FILE
|
ABS REPORT SAVE/FULL and ABS Catalogs
|
Gives overview information about a save operation in a job.
|
|
PRIVS
|
Environment /PRO FILE=(PRIVS)
|
Defines the set of privileges to be used when executing the operation
|
|
FILES_n
|
Save Request Include Specifi cation
|
Defines the set of files or other data objects to be backed up or restored.
|
|
QUALIFIERS and
QUALIFIERS_n
|
Environment /ACTION, /LOCK and /DATA_SAFETY
Save Request /FULL/SINCE=BACKUP /SELECT
|
Defines characteristics of the save operation, such as the type of data movement, and options for execu tion of the backup.
|
|
MNTFLAGS
|
Not supported. ABS controls mounting of tapes.
|
Defines how tapes are mounted.
|
|
SAVESET_GEN
|
Not supported. ABS generates the saveset names.
|
Defines the name of the saveset stored on tape.
|
|
PROTECTION
|
Storage Class (Archive)/ACCESS
|
Defines what access is available to the backed up data.
|
|
MEDIA_TYPE
|
Storage Class (Archive) /TYPE_OF_MEDIA
|
Defines which MDMS media type is to be used for backup operations.
|
|
DENSITY
|
Density is an attribute of the MDMS media type object.
|
Defines the tape density to be used for backup operations.
|
|
REEL_SIZE
|
This maps to the length attribute of the MDMS media type object.
|
For 9 track tapes, defines the length of the tape (e.g. 2400 feet)
|
|
TAPE_POOL
|
Storage Class(Archive) /TAPE_POOL
|
Defines the MDMS pool from which tapes are drawn for backup operations.
|
|
QUICKLOAD
|
The MDMS drive attribute "AUTO_REPLY" can be specified on a per-drive basis to determine whether a drive comes on line.
|
Determines whether MDMS will automatically recognize when a tape drive comes online without opera tor intervention.
|
|
QUICKLOAD_RETRIES
|
Not supported
|
Defines how long a LOAD request should remain outstanding before being canceled.
|
|
PREALLOC
|
ABS allocates and manages volume sets automatically.
|
Determines the number of volumes to pre allocate before a backup begins, forming them into a volume set.
|
|
AUTOSEL
|
ABS always automatically selects new volumes to append to volume sets, if needed.
|
Determines whether SLS is allowed to automatically select new volumes from the volume database if needed.
|
|
CONTLOADOPT
|
Logical Name:
ABS$DISABLE_SCRATCH_ LOADS set to one. By default, ABS will request and accept scratch tapes. The logical can be defined to force specific tapes to be mounted.
|
Determines whether the operator can substitute a valid tape for the requested tape.
|
|
UNATTENDED_BACKUP S
|
ABS always attempts to per form the backup without oper ator intervention.
|
Determines whether SYSBAK should default responses to ques tions rather than require operator intervention.
|
|
CONTINUE
|
ABS Storage Class (Archive)Name. Each Storage Class (archive) manages one or more volume sets, and appends data to these volume sets until the Consolidation Criteria is exceeded.
|
Determines how data is consoli dated onto volume sets.
|
|
HISTORY_SET
|
Catalog Name
Storage Class (Archive)/CATALOG
|
Determines the catalog into which a record of the operations performed and the files backed up is written.
|
|
SBUPDT_Q
|
Not supported. If a catalog supports staging, ABS always performs the catalog update in a detached process.
|
Determines the Batch Queue in which the System history set update is performed.
|
|
SCRATCH_DAYS
|
Storage Class (Archive) /RETAIN
|
Determines how long data is saved before the tapes are recycled and catalog entries removed.
|
|
OFFSITE_DATE
ONSITE_DATE
|
MDMS volumes support OFFSITE_DATE and ONSITE_DATE attributes, and will automatically generate MOVE VOLUME commands when these dates are reached.
|
Determines when the volume sets are moved offsite or onsite (i.e. vaulting).
|
|
TAPE_LABELS
|
Not supported.
|
Determines if paper labels are printed for the volumes used in the backup
|
|
NOTES
|
The MDMS description field in the volume object is the equivalent attribute.
|
Store a free form text note in the volume record for the volumes used in the backup.
|
|
DRIVE_TYPE
|
Storage Class (Archive) /DRIVE_LIST
|
Determines the list of tape drives to be used. It is recommended that MDMS media types be set up cor rectly rather than using this field.
|
|
N_DRIVES
|
Environment /DRIVE_COUNT
|
Determines the number of tape drives to use during a backup opera tion.
|
|
PROGRESS
|
Not supported
|
Notifies the operator after a certain number of files have been backed up.
|
|
REPLY_MSG
|
Not supported. MDMS issues all OPCOM messages in a standard format
|
Determines the notification to be performed when each backup opera tion starts and ends.
|
|
STATUS_MAIL
|
Environment /NOTIFY
|
Determines who should be sent MAIL when the job completes.
|
|
LOG_FILE
|
Not supported. ABS generates a log file in ABS$LOG with the same name as the Save Request.
|
Determines the name of the log file for the operation.
|
|
LISTING_GEN
|
Environment /LISTING. ABS will generate listing files, but they are always located in ABS$LISTINGS, and are named the same as the Save Request and the operation number.
|
Determines the name of a backup listing file to be produced from each operation.
|
|
FULL
|
Environment /LIST ING=FULL
|
Determines if the listing file pro vides all information about backed up files, or only brief information.
|
|
PRINT_Q
|
Not supported.
|
Determines the Print queue on which the listing file is printed.
|
-
ABS Policy Attributes in SBK Terminology
See ABS Storage Class (Archives) and SLS SBK Equivalen, lists ABS Storage Class (Archive) object parameters and their SLS SBK Equivalents.
-
ABS Storage Class (Archives) and SLS SBK Equivalen
|
Storage Class (Archive) Parameter
|
SBK Equivalent
|
Meaning
|
|
Name
|
CONTINUE
|
A common name which can be referenced by multiple Save Requests
|
|
Primary Archive Loca tion
|
<None>
|
For on disk backups, this gives the disk and top level directory where the savesets will be stored.
|
|
Primary Archive Type
|
<None>
|
This determines whether the Storage Class (Archive) is tape based (type is TAPE) or disk based (type is DISK)
|
|
Owner
|
<None>
|
Determines the NODE::USER of the owner of the Storage Class (Archive). The owner always has CON TROL access.
|
|
ACL
|
PROTECTION
|
Determines the access to the backed up data. ABS provides full ACL based access, while SLS provides only OpenVMS-style system, owner, group and world access.
|
|
Tape Pool
|
TAPE_POOL
|
The MDMS pool from which volumes will be allocated for backups.
|
|
Type of Media
|
MEDIA_TYPE
|
The MDMS media type to be allocated for back ups.
|
|
Retain
|
SCRATCH_DAYS
|
The number of days the backed up data will be saved before the tapes are recycled. Note that a Save Request can specify a retention shorter or equal to the value in the Storage Class (Archive).
|
|
Consolidation Criteria
|
CONTINUE
|
This set of parameters determines how backup savesets will be consolidated onto tapes. For example, if the Consolidation Interval is set to 7 days, savesets will be appended onto a volume set for 7 days before a new volume set is created.
|
|
Catalog Name
|
HISTORY_SET
|
The name of the catalog which stores data about what files have been backed up, and where they are located.
|
|
Number of Streams
|
<None>
|
The number of simultaneous Save requests which can be writing into the Storage Class (Archive). Determines the number of MDMS volume sets simultaneously active in the Storage Class (Archive).
|
|
Media Location
|
<None>
|
The MDMS onsite location field to match for allocat ing volumes for backups.
|
|
Drive List
|
DRIVE_TYPE
|
The list of specific drives to be used for backup operations in this Storage Class (Archive). Normally, this should be managed through MDMS drive objects.
|
See ABS Execution Environment Parameter and SLS SBK Equivalent, lists ABS Execution Environment parameters and their SLS SBK Equivalents
-
ABS Execution Environment Parameter and SLS SBK Equivalent
|
Environment Parameter
|
SBK Equivalent
|
Meaning
|
|
Name
|
<None>
|
Identifies the Environment for reference by Save Requests
|
|
Owner and ACL
|
<None>
|
Identifies the owner and access to the Environment.
|
|
Data Safety Options
|
QUALIFIERS
|
A bitmask containing the data safety options to be applied during the backup. Data safety options include CRC checking, and full data verification.
|
|
Listing Options
|
LISTING_GEN
FULL
|
Determines whether a listing file is produced, and whether the listing is a "full" listing or a "brief" list ing.
|
|
Span Filesystem Options
|
<None>
|
For UNIX file systems, determines whether the entire filesystem is backed up, even if it crosses multiple physical devices.
|
|
Links Only
|
<None>
|
For UNIX file systems, determines whether ABS backs up only the logical links, or backs up the data as well.
|
|
Compression Options
|
<None>
|
For UNIX file systems, determines the type of com pression to be applied to the savesets.
|
|
Original Object Action
|
QUALIFIERS
|
Determines the action to be taken on the original data objects (e.g. the files backed up). Options include None, Record Backup Date, or Delete
|
|
User Profile
|
PRIVS
|
Determines the username, privileges and access rights used during the backup operation. The special keyword "<REQUESTER>" indicates the backup operations should be performed with the username, privileges and access rights of the person issuing the ABS Save Command.
|
|
Notification Criteria
|
REPLY_MSG
STATUS_MAIL
|
Determines when notification occurs, what method is used, and who is notified.
|
|
Locking Options
|
QUALIFIERS
|
Determines how much interlocking is done between the backup in progress and an active file system. Options include Ignore File Writers, and Hot Backup.
|
|
Number of Drives
|
N_DRIVES
|
Determines the number of tape drives to be used during the backup operations.
|
|
Retry Interval and Count
|
<None>
|
Determines how often and how many times a failed backup should be retried.
|
|
Prolog Command
|
PRE_PROCESS_FI RST
|
A command to be executed when the backup starts. Contrast to Save Request Prolog.
|
|
Epilog Command
|
POST_PROCESS_ LAST
|
A command to be executed when the backup com pletes. Contrast to Save Request Epilog.
|
See ABS Save Request Parameter and SLS SBK Equivalent, lists ABS Save Request parameters and their SLS SBK equivalents.
-
ABS Save Request Parameter and SLS SBK Equivalent
|
Save Request Parameter
|
SBK Equivalent
|
Meaning
|
|
Name
|
SBK File name
|
Identifies the group of backup operations to be per formed.
|
|
Movement Type
|
QUALIFIERS
|
Determines whether the operations are Full, Incre mental or Selective (i.e. individual file) operations.
|
|
Source Node
|
NODE_n
|
Node on which the data resides.
|
|
Include Specification
|
FILES_n
|
Identifies the data to be backed up. Multiple include specifications can be given on a single Save Request, and each can have a different Object Type.
|
|
Object Type
|
BACKUP_TYPE
|
Gives the type of the data. ABS Supports many dif ferent types of data, including OpenVMS Files, UNIX Files, Oracle RDB Databases, and so forth.
|
|
Agent Qualifiers
|
QUALIFIERS
|
Allows backup agent specific qualifiers to be added to the command used to backup the data.
|
|
Since and Before Date
|
QUALIFIERS
|
Determine whether data objects to be backed up should be selected based upon creation/modifica tion date.
|
|
Exclude Specification
|
QUALIFIERS
|
Determines selected data objects to be excluded from the backup.
|
|
Storage Class (Archive) Name
|
<None>
|
Gives the name of the Storage Class (Archive) into which the data is backed up.
|
|
Environment Name
|
<None>
|
Gives the name of the Execution Environment to be used for the backup operations.
|
|
Start Time
|
TIME_n
|
Indicates the time at which the Save Request should start each time it is scheduled. Note that
an SBK can provide multiple DAYS_n and TIME_n parameters, an ABS Save Request is restricted to a single Start Time and Interval.
|
|
Scheduling Option and Explicit
|
DAYS_n
|
Identifies the repeat interval for the Save Request. ABS provides a variety of predefined simple inter vals, such as Daily, Weekly, Monthly, as well as several "complex" intervals, such as Weekly Full with Daily Incremental, and log based schedules. See the information about "Log-n Backup Schedules"ABS for a full description of log based schedules.
|
|
Prolog Command
|
PRE_PROCESS_E ACH
|
A command to be executed before each backup operation within the Save Request starts. Contrast to Environment Prolog.
|
|
Epilog Command
|
POST_PROCESS_ EACH
|
A command to be executed after each backup oper ation within the Save Request completes. Contrast to Environment Epilog.
|
-
D.4 Converting ABS V2.x Catalogs to V4.0 Format
If you are upgrading from ABS V2.1, 2.1A or 2.1B, you must convert your catalog format before using them in V4.0.
The catalog upgrade utility upgrades catalogs from their previous format to the new V4.0 format and also deleted expired summary records from those catalogs. A log file named ABS_LOG:ABS_CATALOG_V22_UPGRADE.LOG is generated with information about all of the catalog entries it has modified or deleted.
The catalog upgrade has one update parameter: p1. The input to the p1 parameter is the name of the catalog you wish to upgrade.
You can use the catalog upgrade to upgrade a single ABS catalog or all ABS catalogs. To upgrade an ABS single catalog, specify the catalog name to the p1 parameter. To upgrade all catalogs, enter an asterisk (*) as the wildcard character, or do not supply anything to the p1 parameter.
To run the utility, use the following procedure:
1. Define the following symbol:
$ CATALOG_UPGRADE :== $ABS_SYSTEM:ABS$CATALOG_UPGRADE.EXE
2. Enter one of the following commands:
$ CATALOG_UPGRADE ! upgrades all ABS catalogs
$ CATALOG_UPGRADE * !equivalent to example above
$ CATALOG_UPGRADE ABS_CATALOG ! Upgrades a catalog named ABS_CATALOG
Restriction:
The ABS cagtalogs must be quiescent while executing the catalog upgrade utility. The catalog that is being upgraded will be locked; no save, restore, or lookup operations are allowed while the upgrade is occurring.
-
D.5 Converting ABS V2.x/V3.x RDB Policy Database to ABS V4.0 (MDMS Server Database)
If you are still using an Rdb Policy Database, the command procedure to convert it to RMS was included in previous versions of ABS. You will have to either pull this command procedure from those kits, or contact hp Customer Support for assistance.
This conversion must be done prior to updating to V4.0.
Conversion of ABS V2.x or 3.x RDB Policy Database is a two step process.
-
1. Convert the RDB Policy Database to RMS Policy Database using the conversion programs provided with ABS V3.1A or V3.2 before updating to V4.0.
$ @ ABS$SYSTEM:ABS$CONVERT_TO_RMS
-
2. Convert the RMS Policy Database to MDMS Database as described in See Converting ABS V3.x RMS Policy Database to ABS V4.0 (MDMS Server Database)
-
D.6 Converting ABS V3.x RMS Policy Database to ABS V4.0 (MDMS Server Database)
Before upgrading to V4.0, do ABS SHOW object_name/FULL of all your objects to an output file, for reference after the upgrade. Then upgrade to V4.0 and follow the steps below to convert the ABS policy database to V4.0.
Before running the conversion ensure that
-
1. The old ABS Policy database files (ABS$DATABASE:EPCOT.DB%) are not being currently used
-
2. ABS V4.0 and MDMS V4.0 are configured and running on all the Clients and Servers.
Run the SYS$SYSTEM: ABS$CONVERT_V3_TO_V4.EXE utility to convert the ABS 3.x database to MDMS Database.
The utility exports only the highest version of the policy object. Details of new MDMS objects created are logged in ABS$CONVERT_V3_TO_V4.LOG.
Sample Conversion:
$ RUN SYS$SYSTEM:ABS$CONVERT_V3_TO_V4.EXE
Enter the Path of ABS V3.x Policy Database Files [ABS$DATABASE:] :
Converting ARCHIVE Objects...
Converting ENVIRONMENT Objects...
Converting SAVE Objects...
Converting RESTORE Objects...
$
Index
Installation Guide
