A typical OPCOM mount request for a second volume where the second volume is known to the system appears as:

%%%%%%%%%%%% OPCOM 1-APR-1996 10:00:03.33 %%%%%%%%%%%% Request 34, from user SMITH MOUNT relative volume 2 (1202) on MTA1:

In this case you just mount the requested reel and the system will proceed.

A typical OPCOM mount request for a second volume where the second volume is UNKNOWN to the system appears as:

%%%%%%%%%%%% OPCOM 1-APR-1996 10:00:03.33 %%%%%%%%%%%% Request 34, from user SMITH MOUNT new relative volume 2 (120002) on MTA1:

In the above sample the first volume was 1200. VMS modified the name by appending the digits 02 to the 1200. ¹⁹ Here you must attach a new volume and reply correctly to the request. The correct response to this request is:

• Attach a second volume.

  $ MEDIA UNKNOWN ATTACH_TO/LOG 1200;0 1210 allocated 1210 attached to 1200;0

  
  

• Advise the file system of this.

  $ REPLY/INITIALIZE_TAPE=34 "''MEDIA_INT'" or $ REPLY/BLANK_TAPE=34 "''MEDIA_INT'"

  
  

If the requested volume has been identified in a previous OPERATOR request, just perform step two above. The DCL SYMBOL MEDIA_INT, after the execution of the UNKNOWN medium allocation, will contain the known internally recorded label of the tape. The REPLY/INITIALIZE will check all the access rights before initializing the tape. The REPLY/BLANK will assume that the tape is blank and just write a label. ²⁰

2.5.2 Extending a BACKUP tape

The VMS BACKUP program does all volume switching and labeling internally. The labels of all volumes that need to be used are passed to it via the /LABEL qualifier. When a backup overflows onto the second and later media the behavior is similar to the previous case of ANSI volumes.

A typical OPCOM ²² mount request for a second volume where the second volume is known to the system appears as:

%%%%%%%%%%% OPCOM 15-OCT-1996 14:49:59.49 %%%%%%%%%%% Request 4, from user SYSTEM on ISE Please mount volume 750 in device _ISE$MUA0: BACKUP requests: Saveset ISE1.BCK, Volume number 02, write ENABLED

In this case you just mount the request reel and the system will proceed.

A typical OPCOM mount request for a second volume where the second volume is UNKNOWN to the system appears as:

%%%%%%%%%%% OPCOM 15-OCT-1996 14:49:59.49 %%%%%%%%%%% Request 4, from user SYSTEM on ISE Please mount volume 750_02 in device _ISE$MUA0: BACKUP requests: Saveset ISE1.BCK, Volume number 02, write ENABLED

In the above sample the first volume was 750. VMS modified the name by appending _02 to the 750. Here you must attach a new volume and reply correctly to the request. The correct response to this request is:

• Allocate a second volume.

  $ MEDIA UNKNOWN SET/INTERNAL=750_02/STATUS=MOD_LABEL 756 allocated

  
  

• Attach the new volume to the end of the master volume.

  $ MEDIA 'MEDIA_EXT' ATTACH_TO 750;0 756;0 attached to 750;0

  
  

• Mount medium 756;0 on the drive. The BACKUP utility will then continue writing to the new medium.

This chapter is designed for those people who are assigned the responsibility of setting up and overall management of the MEDIA Librarian. Most questions come from the management of off-line tapes and disks. Therefore, this section concentrates on problems dealing with the MEDIA Librarian.

This chapter also features a description of how to set up MEDIA including the fundamentals of configuration and a description of DCL configuration.

To be a Media Manager you need the MANAGER privilege.¹

3.1 Useful concepts

The concepts mentioned in Section 2.1 are applicable to MANAGERS as well as operators. By reading that section first, the following concepts will be easier to understand.

3.1.1 TYPE category

Pools can be further subdivided into subpools by defining TYPE categories. The TYPE is a ten-character field in the MEDIA DATABASE that can be any alphanumeric word. This allows for

• Logical separation of media based on the physical and functional attributes.
• Automatic selection of an appropriate and available device.
• Automatic selection of a batch job to use for execution.

You can subdivide your media library by physical characteristics (i.e., nine-track tapes, TK50 and TU58 tape cartridges and disks). You can also subdivide the media based on function (i.e. USERTAPE and SYSTAPE). ² DEVICE parameter

You can use the TYPE category to associate a type with a device, so that whenever a user requests a device allocation for a medium, the correct type of drive is always allocated (i.e. a USERTAPE can be used on MTA0:, MUA0: or MFA0:).

Again, this subdivision is invisible to users and operators. MEDIA tracks the type categories that you define and makes sure that the appropriate medium is mounted on an appropriate drive. Jobs are submitted to an appropriate queue.

3.1.2 Volume sets

MEDIA can be attached together, so that the system considers them to be a single medium with several volumes. This can be very useful for organizational purposes.

While attached, the entire volume set can be addressed by the name of the first volume in the set, although the individual media do retain their separate names. A medium must be detached from the set before it can be released or independently overwritten. There are several commands to attach or detach a medium to or from a volume set. It is also possible for the operator to extend a volume as needed during a job execution.

3.1.3 The Media server

The server process is a detached process that is continuously running on the system. The behavior of the MEDIA Server is controlled by a set of parameters. These parameters define the devices that MEDIA manages, the location of data files, the batch queues used for MEDIA jobs and default settings for a number of activities. The server uses the following files:

File name	Contents
MEDIA_LIBRARY:MEDIAS.EXE	Server executable image
MEDIA_LIBRARY:MEDIAS.LOG	Log file of all server events
SYS$MANAGER:MEDIA.VAR	Parameter file
SYS$COMMON:[SYSMGR]MEDIA2.VAR	Optional cluster common parameter file
MEDIA_LIBRARY:MEDIAS.DAT	Across cluster device coordination data

It monitors drive activities, creates batch jobs as scheduled, coordinates all medium access, and performs various related control functions. For example, it controls the allocations of drives on a least recently used basis. Only those drives listed in the controlling parameter file are affected.

The server maintains a log file that contains a list of all server events: allocations, mounts, dismounts, deallocations, job initiations and job completions. It contains a listing of any error messages generated while performing these functions.

If you experience odd or erratic behavior by server, look into this log file for any error messages.

3.1.4 System configurations

Your system may be composed of:

• A single node
• A networked system
• A clustered system
• A combination of clustered and networked systems

MEDIA supports any of these configurations.

3.1.4.1 Networked systems

Full support is provided for any degree of sharing across a network of multiple CPUs, each with its own associated drives. MEDIA maintains a central DATABASE. MEDIA ensures that jobs are not created at one site that requires reading a medium stored at another location. ³

3.1.4.2 OpenVMS clusters

1. Homogeneous systems have identical operating environments on each cluster member because there is a shared system disk for all member nodes.
2. Heterogeneous systems have a unique working environment on each system. Each VAX has its own system disk, user accounts, and system files.
3. Mixed systems combine the two types of clusters.

Full support is provided for any combination of VAX CPUs in a cluster. Any degree of sharing or separation can be maintained. Jobs are automatically placed in the right queue for the node with the correct type of tape or disk drive.⁴

3.1.5 The data files

The MEDIA DATABASE consists of the following files:

File name	Contents
MEDIA_LIBRARY:MEDIA.DAT	Main control file, contains header information.
MEDIA_LIBRARY:*.BJL	Contents information file, in BACKUP journal format.
MEDIA_LIBRARY:*.SDR	Contents information file, in expanded sequential format (MEDIA's internal format).
MEDIA_LIBRARY:*.TDR	Contents information file, in a sequential text file format.

There is usually only one MEDIA library per data center and it is shared across the cluster or network. It is an indexed file keyed by the medium external id. All of the data files for the MEDIA DATABASE are located using the logical name MEDIA_LIBRARY. In a networked environment, you can reposition the relevant data files using the parameter CENTRAL ⁵

3.1.5.2 BCKMGR data files

The BCKMGR DATABASE consists of the following files:

File name	Contents
BCKMGR.DAT	Main backup job data file
BCK_*.DAT	DCL command files for jobs containing more then 5 commands.

There is usually one BCKMGR DATABASE per batch queue structure. There is only one of these files in a cluster and thus only one BCKMGR database should exist. A networked node would have its own queue file and thus it should have its own BCKMGR database. The BCKMGR.DAT data file is an indexed file keyed by the job name. The parameter BGR_CENTRAL can be used to redirect the location of these files to any other directory other than MEDIA$LIBRARY:.

3.1.5.3 VAULT data files

The VAULT database consists of a group of ADR files.

File name	Contents
MEDIA_LIBRARY:000000000.ADR	Count file. Contains the number of the last ADR created.
MEDIA_LIBRARY:000000001.ADR	Device level dir ectory file.
MEDIA_LIBRARY:NNNNNNNNN.ADR	Directory file. Each one contains the file information from one DIR file.

These files are interconnected in a tree like fashion. This is identical to the way on-line directories and sub-directories are connected.

The placement of these files can be controlled by the use of the VDISK parameter. ⁶

3.1.6 The executable files

The executable and related files used by the system can be placed anywhere. The locations shown below are those set by the installation procedure.

3.1.6.1 MEDIA executable files

The files for MEDIA are:

File name	Contents
MEDIA_LIBRARY:MEDIA.EXE	Main command executable
MEDIA$LIBRARY:MEDIAS.EXE	Server executable
MEDIA_LIBRARY:FORMAT.EXE	FORMAT utility executable
MEDIA_LIBRARY:MEDIASHR.EXE	Call interface sharable image

3.1.6.2 BCKMGR executable files

The files for BCKMGR are:

File name	Contents
MEDIA_LIBRARY:BCKMGR.EXE	Main command executable
MEDIA_LIBRARY:BCKMGR.HLB	Help library file

3.1.6.3 VAULT executable files

The file for VAULT is:

File name	Contents
MEDIA$LIBRARY:VAULT.EXE	Main command executab le.