To understand and control the amount of disk space used by the various ADR files that make up the VAULT Database, it is useful to understand what they contain. In general they are sequential files. One file header entry corresponds to a single record. The size of the record is directly related to the length of the file name and the number of attributes kept.

These files are written in a compressed format and cannot be read by an ordinary sequential file operation. The file is broken into the following sections.

1. Active file headers
2. Deleted file headers (can be /UNDELETED)
3. Erased file headers
4. Free space (always at the end of the file)

The VAULT/ADD command puts file entries in the free space area at the end of the file. When that space is exhausted new space is allocated for the file. Maximum speed is achieved if all new files added can be placed in the existing free space region.

The VAULT/SORT command places all files in alphanumeric and most recently vaulted first order. During this operation all erased file entries and free space is consolidated in a single section at the end of the file.

The VAULT/REMOVE command searches all directories for files that are associated with the specified medium and marks all such files as erased. No reconsolidation of erased entries is made.

The VAULT/DELETE and /PURGE commands mark all selected files as deleted. Any file marked as deleted can be brought back by use of the /UNDELETE qualifier (i.e. VAULT/DELETE/UNDELETE).

The /ERASE qualifier when used in conjunction with /DELETE or /PURGE will cause all selected files to be marked as erased not just deleted. Occasional use of the VAULT/PURGE/KEEP=n/ERASE command will reduce the amount of diskspace used by the database.

The /NEWFILE qualifier when used in conjunction with /REMOVE or /SORT will cause a new ADR file to be created which has no free space (or as close as possible) and no erased file headers. Creating new files or extending an existing one generates a lot of I/O activity. Thus maximum speed is achieved by not using the /NEWFILE. The trade off is more free space left in each .ADR file.

The /DEVICE qualifier when used in conjunction with the /REMOVE command will reduce the number of directories that are searched and thus speed up the remove process.

Each file entry is composed of the file name and extension along with all the file attributes. File attributes are added by use of the /ONLINE qualifier (i.e. VAULT/ADD/ONLINE) when the data is added to the database. These attributes add approximately 48 bytes to each file header. Additional I/O activity and CPU time is used to locate the additional information from the online copy of the file. For minimum disk space usage and maximum throughput in adding files to the database do not use the /ONLINE qualifier. The trade off is that only the file name, file extension and date written to tape will be known by the system.

3.6 Multi-CPU support

The Media Librarian is designed to be used in a variety of hardware configurations. To facilitate this, a variety of controls exist to vary the location of the data base files used by the system.

3.6.1 File positioning

The basic files that make up the librarian are:

Executable images: MEDIA_LIBRARY:MEDIA.EXE MEDIA_LIBRARY:MEDIAS.EXE MEDIA_LIBARAY:VAULT.EXE MEDIA_LIBRARY:BCKMGR.EXE MEDIA_LIBRARY:FORMAT.EXE Data files: MEDIA_LIBRARY:*.SDR,*.TDR,*.BJL MEDIA_LIBRARY:MEDIA.DAT VAULT_LIBRARY(or MEDIA_LIBRARY):*.ADR MEDIA_LIBRARY:BCKMGR.DAT SYS$MANAGER:MEDIA.VAR SYS$MANAGER:MEDIA2.VAR SYS$HELP:BCKMGR.HLB

The supplied locations are those set by the installation procedure.

All the data files that represent the central database for the librarian are located via the logical name MEDIA_LIBRARY. This name is the simplest way of placing all the data in a common location. As distributed, this is also the location of some of the supplied utility programs.

An alternate way of repositioning the relevant data files is to use the CENTRAL parameter. This will also disguise the location of the database from the user. The parameter CENTRAL will override the MEDIA_LIBRARY definition for the following files:

Media data base files: 'CENTRAL'*.SDR,*.TDR,*.BJL 'CENTRAL'MEDIA.DAT

The parameter file itself can be split into two pieces. The parameter files are:

Parameter data files: SYS$MANAGER:MEDIA.VAR SYS$SYSCOMMON[SYSMGR]:MEDIA2.VAR

The first parameter file is required, the second is optional. If the same parameter is defined in both files the one in MEDIA.VAR will be used. On a cluster system, it is advantageous to put the CPU specific device characteristics in MEDIA.VAR, in the CPU specific manager directory, and place all the cluster wide queue definitions in MEDIA2.VAR, in the cluster common manager directory.

Certain data files used by the system can be positioned in an alternate location by defining any or all of the following logical names. The default locations are normally satisfactory.

File	Default Location	Logical name
MEDIA.DAT	MEDIA_LIBRARY:	MEDIADAT
SYSUAF.DAT	SYS$SYSTEM:	SYSUAF
BCKMGR.DAT	SYS$MANAGER:	BCKMGR

These definitions can be placed in any one of the process, job, group or system logical name tables.

3.6.2 DECnet systems

MEDIA_LIBRARY:*.SDR,*.TDR,*.BJL,MEDIA.DAT

On all other nodes, the parameter CENTRAL is added to the SYS$MANAGER:MEDIA.VAR file to point to the central node. For example:

CENTRAL = CTR"SYSTEM PASSWORD"::DRA0:[MEDIA]

The parameter file is tailored on each node to reflect the availability of tape and disk drives and their characteristics.

At sites where all the nodes and media are located at a single location, this procedure is adequate. But for geographically dispersed networks that want to maintain a central database, this is inappropriate.

For example; assume we have a network located in two buildings A and B. Half of the media are kept in each. It is necessary that jobs are not created at B that entail using media that are stored at A, and similarly for jobs at A. This can be done by using the media TYPE header field. By default, this is set to TAPE. By using two different words, for example, ATAPE and BTAPE, it is possible for the submit mechanism to determine if the job can be created on the current node. The queue descriptions contained in the parameter file at node A make reference to ATAPE devices. Those at B make reference to BTAPE devices. Allocation of media to users can also be controlled by using the /TYPE qualifier when making an allocation.

The parameter files for sites A and B would appear as follows:

Site A:

QUEUE0 = SYS$TAPE,ATAPE ATAPE0 = TAPE,MTA0:,LENGTH=2400,LOCK CENTRAL = B::MEDIA_LIBRARY: DEFAULT_TYPE = ATAPE

Site B:

QUEUE0 = SYS$TAPE,BTAPE BTAPE0 = TAPE,MSA0:,DENSITY=(1600,6250),LOCK DEFAULT_TYPE = BTAPE

The VAULT database should be kept separate for each node in a DECnet environment. It is important that the logical name VAULT_LIBRARY is then defined, or that the parameter VLT_CENTRAL is provided.

In a DECnet environment, it is important to place the MEDIASTRT command in the SYSTARTUP.COM file after the network is started.

3.6.3 HSC Controlled Devices

On systems using a HSC controller device names appear in a different fashion from those on a system with just local devices. This usually entails adding some parameters to the MEDIA.VAR parameter file.

For example, you have a system with a HSC tape drive the following parameters are needed for proper recording of error counts.

TAPE0 = TAPE,HSC007$MUA201,DENSITY=(1600,6250) MUA201 = HSC007$MUA201

In the case where you have a removable RA60 connected to two HSCs the following type of parameter settings are needed.

RA601 = DISK,$2$DJA0 HSC001$DJA0 = $2$DJA0 HSC002$DJA0 = $2$DJA0 DJA0 = $2$DJA0

3.6.4 Clustered systems

In a cluster configuration, it is possible to have an assortment of cluster and local devices. All the files can be centrally located and treated identically on all the systems.

In a cluster, there are two mechanisms for controlling where a Media job is to be executed. First, queue and device selections are controlled via the Media parameter file. Second, the VMS queue structure allows jobs to be selectively executed on specific CPU's.

Queue selection by the Media Librarian is based on the media type field. Run time device allocation is also based on the type field. This allows the job to be created on a node with no removable drives and then executed on a node which does have such drives. For example, if at node A we have no removable drives and we want all jobs just to be submitted into a queue SYS$TAPE which will execute on node B, the following parameter files will allow this:

Node A: MEDIA.VAR INTERACTIVE = 0 Node B: MEDIA.VAR TAPE0 = TAPE,_B$MMA0:,LOCK Common: MEDIA2.VAR QUEUE0 = SYS$TAPE,TAPE

Any attempt to execute a Media device command at node A will result in an error message.

3.6.5 Distributed data files

It is possible to distribute the data files. This is possible by using a search list for the definition of the logical name MEDIA_LIBRARY. For example; lets assume we want to keep archive contents files on one disk and more active files on another. The following will do this:

DEFINE/SYSTEM MEDIA_LIBRARY "DRA0:[MEDIA],DRB0:[OTHER]"

In this case, all new files added to the library by any update command will be placed in DRA0:[MEDIA] and all old files will remain in DRB0:[OTHER]. As such, it is useful to put all the old media contents file in DRB0:[OTHER]. In a DECnet or cluster environment, it could be useful to have slightly different definitions to allow media, local to a CPU, to be more readily accessed.

The media contents files can be spread out in this fashion as much as desired. The only important point to keep in mind is that only one MEDIA.DAT file can exist.

The functions described in this chapter are accessible only to MANAGERS (Level 3 Users) in MCL the MCL Work Center. These functions are consolidated into a single menu item in the top level Media Librarian menu in order to give immediate access to the management of pools, media locations and backup tape requirements. Emphasis was given to these functions because of their importance in media management and the fact that they are used frequently by MANAGERS.

4.1 Media pool management

The Media pool management option is for MANAGERS interested in quick access to all media for both reference and modification purposes. Media can be assigned to a user, released to a pool, deleted from a pool, re-used or added to a pool. In addition, reports on the media can either be displayed on screen or printed.

In order to perform media pool management functions, select Manager's express functions from the Media Librarian menu. The menu shown in Figure 4-1 will appear.

Figure 4-1 Media Manager Express Functions

Select Media pool management from the Manager's express functions menu. The menu shown in Figure 4-2 will appear.

Figure 4-2 Procedure for working with multiple media

The purpose of this option is to establish a list of media to view and/or modify based on pool status. For instance, if a MANAGER is interested in the media in the available pool, this option could be used to establish a list. The list could then be reviewed and edited and used for the pool operations shown on the lower half of the menu.

In order to establish a media list, choose Establish media list from the Media pool management menu. The form shown in Figure 4-3 will appear. Data entries are used to select media of a certain type, pool or date to create the list.

Figure 4-3 Search/Selection criteria for media records

The definitions of these fields are shown below.

Data	Description
Type	Specifies the base TYPE category for a medium. All TYPES are defined in the parameter file. Only predefined values can be entered here.
Pool	This field indicates which of the pool assignments for the medium: available, allocated or released.
Before	Standard VMS search facility designates the date that included media must have been created before. Only media created before the specified date will be included in the search results.
Username	This is the user name assigned to the medium. All entries in the allocated pool are owned by a user.

4.1.2 Display (unedited) list as report

In order to display the unedited list of media established in the previous option, select Display (unedited) list as report from the Media pool management menu. The menu shown in Figure 4-4 will appear.

Figure 4-4 Sort choices for report

The sort order of the report will be determined by selecting one of the options in this menu. A report similar to the one shown in Figure 4-5 will appear.

Data	Description
External ID	The external ID or serial number is the alphanumeric character string marked on the outside of the medium. It is used by the operator to identify the medium in the media library.
Pool	Indicates which of the pool assignments for the medium: available, allocated or released.
Media type	Specifies the base TYPE category for a medium. All TYPES are defined in the parameter file.
Expiration date	This is when the medium will be placed into the released pool.
Last used date	This is the last time the medium was used.

Figure 4-5 Sorted media report display

4.1.3 Submit/Print (unedited) list as report

The menu shown in Figure 4-4 will appear. The sort order of the report will be determined by selecting one of the options in this menu. When the sort order has been selected, the Control settings menu shown in Figure 4-6 will appear. The options in the Control settings menu are described in the following sections.

Figure 4-6 Control settings menu