HP Archive Backup System for OpenVMS Guide to Operations
HP Archive Backup System for OpenVMS Guide to Operations HP Archive Backup System for OpenVMS Guide to Operations
Media Management 4.2 Domain 4.2.15 Request ID 4.2.16 Scheduler Type 4.2.17 Scratch Time 4.2.18 SYSPRV 4.2.19 Transition Time 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: • Internal - The default internal scheduler type uses MDMS schedule objects and OpenVMS batch queues. This option should be sufficient for most sites as the schedule object supports many custom scheduling options. • External - This option uses MDMS schedule objects and OpenVMS batch queue, but the scheduling is submitted through a command procedure. You can use this option if you have a need to modify the command procedure to perform site-specific operations. • Scheduler - This option uses an external scheduler product via command procedures. ABS supplies a template scheduler command procedure that you can modify to access your own scheduler product. You can also use this option to invoke the pre-V3.0 ABS DECScheduler V2.1B, as long as you have a license for that product. 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. Note If you wish to use the SYSPRV attribute from the MDMSView GUI, the user’s authorization file must have SYSPRV defined as a privilege and a default privilege. Having SETPRV is not sufficient as there is no way to set the SYSPRV privilege from the GUI. 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. 4-4 Media Management
4.2.20 User Rights 4.3 Drives 4.3.1 Access 4.3.2 Automatic Reply 4.3.3 Device 4.3.4 Disabled Media Management 4.3 Drives 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. A drive is a physical resource that can read and write data to tape volumes. Drives can be standalone requiring operator intervention for loading and unloading, in a stacker configuration that allows limited automatic sequential loading of volumes, or in a jukebox which provides full random-access automatic loading. Drives are named in MDMS using a unique name across the domain; it may or may not be the same as the OpenVMS device name, as these may not be unique across the domain. The following sections describe the attributes of a drive. 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: • All - Allows both local and remote access (default) • Local - Allows only local access (as defined above) • Remote - Allows only remote access using RDF 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. Media Management 4–5
- Page 21 and 22: 2 Overview This chapter provides an
- Page 23 and 24: Overview 2.2 ABS Objects Figure 2-1
- Page 25 and 26: 2.2.6 Schedules 2.3 ABS Catalogs Ov
- Page 27 and 28: Overview 2.5 Media, Device and Mana
- Page 29 and 30: 2.8.3 Groups 2.8.4 Jukeboxes Overvi
- Page 31 and 32: 2.8.8 Nodes 2.8.9 Pools 2.8.10 Volu
- Page 33 and 34: 3 Saving and Restoring Data 3.1 Arc
- Page 35 and 36: 3.1.5 Destination 3.1.6 Drives 3.1.
- Page 37 and 38: 3.1.12 Volume Sets Saving and Resto
- Page 39 and 40: 3.2.5 Staging 3.2.6 Catalog Save En
- Page 41 and 42: • Save Type - Copied from related
- Page 43 and 44: Example 3-4 Staging Information in
- Page 45 and 46: 3.4.3 Compression 3.4.4 Data Safety
- Page 47 and 48: Saving and Restoring Data 3.4 Envir
- Page 49 and 50: Saving and Restoring Data 3.5 Saves
- Page 51 and 52: Saving and Restoring Data 3.5 Saves
- Page 53 and 54: Table 3-3 Disk, File, Path and Data
- Page 55 and 56: Saving and Restoring Data 3.5 Saves
- Page 57 and 58: Saving and Restoring Data 3.5 Saves
- Page 59 and 60: • First disk/file specification p
- Page 61 and 62: 3.5.17.1 HOLIDAYS.DAT Record Format
- Page 63 and 64: Saving and Restoring Data 3.6 Selec
- Page 65 and 66: 3.7.2 Command 3.7.3 Restriction Sav
- Page 67: 3.7.5 Include and Exclude 3.7.6 Tim
- Page 70 and 71: Media Management 4.2 Domain 4.2.1 A
- Page 74 and 75: Media Management 4.3 Drives 4.3.5 D
- Page 76 and 77: Media Management 4.3 Drives 4.3.15
- Page 78 and 79: Media Management 4.5 Jukeboxes 4.5.
- Page 80 and 81: Media Management 4.5 Jukeboxes 4.5.
- Page 82 and 83: Media Management 4.7 Magazines 4.6.
- Page 84 and 85: Media Management 4.8 Media Types 4.
- Page 86 and 87: Media Management 4.11 Volumes 4.10.
- Page 88 and 89: Media Management 4.11 Volumes Table
- Page 90 and 91: Media Management 4.11 Volumes 4.11.
- Page 92 and 93: Media Management 4.11 Volumes neede
- Page 94 and 95: Media Management 4.11 Volumes • R
- Page 96 and 97: Media Management 4.11 Volumes 4.11.
- Page 99 and 100: 5 Security The security model used
- Page 101 and 102: Security 5.1 MDMS Rights Table 5-1
- Page 103 and 104: Table 5-4 Domain Access Control Opt
- Page 105 and 106: 6 User Interfaces ABS and MDMS supp
- Page 107 and 108: 6.1.3 Logging In User Interfaces 6.
- Page 109 and 110: User Interfaces 6.1 Graphical User
- Page 111 and 112: User Interfaces 6.1 Graphical User
- Page 113 and 114: Figure 6-5 Domain View Showing Expa
- Page 115 and 116: User Interfaces 6.1 Graphical User
- Page 117 and 118: 6.1.13 Viewing MDMS Audit and Event
- Page 119 and 120: 6.2.1 Syntax Overview User Interfac
- Page 121 and 122: User Interfaces 6.3 User Interface
4.2.20 User Rights<br />
4.3 Drives<br />
4.3.1 Access<br />
4.3.2 Au<strong>to</strong>matic Reply<br />
4.3.3 Device<br />
4.3.4 Disabled<br />
Media Management<br />
4.3 Drives<br />
The right MDMS_USER_RIGHTS is a high-level right that maps <strong>to</strong> a set of low level rights<br />
suitable <strong>for</strong> non-privileged users that per<strong>for</strong>m ABS or HSM operations. The default set of user<br />
rights allow <strong>for</strong> user activities such as creating and manipulating their own volumes and loading<br />
and unloading those volumes in<strong>to</strong> drives, showing their volumes. However, you can add or<br />
remove low level rights <strong>to</strong>/from the user rights as you wish.<br />
A drive is a physical resource that can read and write data <strong>to</strong> tape volumes. Drives can be standalone<br />
requiring opera<strong>to</strong>r intervention <strong>for</strong> loading and unloading, in a stacker configuration that<br />
allows limited au<strong>to</strong>matic sequential loading of volumes, or in a jukebox which provides full random-access<br />
au<strong>to</strong>matic loading. Drives are named in MDMS using a unique name across the<br />
domain; it may or may not be the same as the <strong>OpenVMS</strong> device name, as these may not be<br />
unique across the domain.<br />
The following sections describe the attributes of a drive.<br />
The access attribute controls whether the drive may be used from local access, remote access or<br />
both. Local access includes direct SCSI access, access via a controller such as the HSJ70, access<br />
via TMSCP, or access via Fibre Channel, and does not require use of the Remote Device Facility<br />
(RDF). Remote access is via a DECnet network requiring RDF. You can set the access <strong>to</strong> one of<br />
the following:<br />
• All - Allows both local and remote access (default)<br />
• Local - Allows only local access (as defined above)<br />
• Remote - Allows only remote access using RDF<br />
Au<strong>to</strong>matic reply is the capability of polling hardware <strong>to</strong> determine if an opera<strong>to</strong>r-assist action<br />
has completed. For example, if MDMS requests that an opera<strong>to</strong>r load a volume in<strong>to</strong> a drive,<br />
MDMS can poll the drive <strong>to</strong> see if the volume was loaded, and if so complete the OPCOM<br />
request without an opera<strong>to</strong>r reply. Set au<strong>to</strong>matic reply <strong>to</strong> enable this feature, and clear <strong>to</strong> require<br />
an opera<strong>to</strong>r response. Please note that some operations cannot be polled and always require an<br />
opera<strong>to</strong>r reply. The OPCOM message itself clearly indicates if a reply is needed or au<strong>to</strong>matic<br />
replies are enabled.<br />
The device attribute is the <strong>OpenVMS</strong> device name <strong>for</strong> the drive. In many cases you can set up<br />
the drive name <strong>to</strong> be the <strong>OpenVMS</strong> device name, and this is the default when you create a drive.<br />
However, the drive name must be unique within the domain, and since the domain can consist of<br />
multiple clusters there may be duplicate device names across the domain. In this case you must<br />
use different drive names from the <strong>OpenVMS</strong> device names. Also, you can specify simple or<br />
descriptive drive names which are used <strong>for</strong> most commands, and hide the <strong>OpenVMS</strong> device in<br />
the device name attribute.<br />
By default, drives are enabled, meaning that they can be used by MDMS and its applications.<br />
However, you may wish <strong>to</strong> disable a drive from use because it may need repair or be used <strong>for</strong><br />
some other application. Set the disable flag <strong>to</strong> disabled the drive, and clear the flag <strong>to</strong> enable the<br />
drive.<br />
Media Management 4–5