A program to print a label for all or just select media cataloged into the MEDIA DATABASE has been provided. This program is written in FORTRAN and the source code is available.

The program assumes that the printable area of the label is 35 characters across and 7 lines high. With an outside boundary of 38 characters by 11 lines. Please change the source as needed to meet the requirements of your site.

The code is stored in the following locations:

MEDIA_LIBRARY:PRINT_LABELS.FOR MEDIA_LIBRARY:PRINT_LABELS.EXE

To run this program and produce labels for all media in the database just enter:

$ RUN MEDIA_LIBRARY:PRINT_LABELS

To run this program and produce labels for just one volume or volumeset just enter:

$ LABEL := $MEDIA_LIBRARY:PRINT_LABELS $ LABEL MEDIUM_LABEL

The MEDIUM_LABEL above is the external ID of the medium, not including any ";0".

All output is routed via the FOR006 logical name. To obtain the labels in a file use the below type of statement.

$ DEFINE FOR006 LABELS.LIS $ RUN MEDIA_LIBRARY:PRINT_LABELS

The labels produced have the following format:

This routine can also be used to cause a label to be printed at the end of each MEDIA job. The following steps must be taken to enable this feature.

1. Enable an auxilary COM file. This is done by using the parameter AUX_COM_FILE. For example:

   MEDIAS> SET AUX_COM_FILE = "MEDIA_LIBRARY:AUX_OPS"

   
   The AUX_OPS file used in the above example is included in the distribution. This file is already set up to print these labels.

2. Add to this auxilary COM file the needed logic (in the provided COM file this has already been done) to run the PRINT_LABELS program after the DEALLOCATE step.
3. Define a system wide logical to indicate what print queue to place label print jobs into.

   $ DEFINE/SYSTEM MEDIA_LABELS_QUEUE MEDIA_LABELS

   
   This definition needs to be added to your system startup file.

A dynamic device is a device that does not exist until a command or command procedure is used to create it. Infoserver devices or DFS disks are examples of these. Typically these are devices that exist somewhere else in the network and are dynamically served over to the local node using software.

The MEDIA_SERVER process intercepts control at two important points during a MEDIA job. First, before a foreground allocate request is satisfied, a subprocedure is spawned and allowed to determine what the physical device to use. Second, after a deallocate request, a subprocedure is again spawned and allowed to release the device. The foreground job just uses the logical name MEDIA: (like all other jobs) to refer to the device set up by this process.

This appendix describes how to setup the needed command procedures to work with dynamic devices. A sample procedure is included in the MEDIA_LIBRARY directory call DYNAMIC.COM.

A dynamic device is set up by changing the device name portion of a type/device entry in the .VAR file to look like one of the following:

@com_file @com_file:param DISK0 = DISK,@DFSDISK:A TAPE0 = TAPE,@RMTDEV:MUA0,DENSITY=6250

The server interface provides several commands that deal with devices. In the example above the device names are "@DSFDISK:A" and "@RMTDEV:MUA0". For example to issue a reset operation to these devices would look as follows:

MEDIAS SET/DEVICE @DFSDISK:A/RESET MEDIAS SET/DEVICE @RMDEV:MUA0/RESET

This command file MUST be located in the MEDIA_LIBRARY: directory and have an extension of .COM.

This procedure is invoked as a subprocess to the MEDIA_SERVER process. A LOG file is created in the MEDIA_LIBRARY: directory having the same name as the COM file. Several parameters are passed to this process. The parameters are:

p1 = full dynamic device specification from VAR file p2 = ALLOCATE or DEALLOCATE p3 = media external id p4 = previously assigned physical device name

For example, if the dynamic device was specified as "@DYNAMIC:ABC" and an ALLOCATE request was issued, the following values would be passed:

p1 = "@DYNAMIC:ABC" p2 = "ALLOCATE" p3 = "9150" p4 = ""

The basic sequence of events that take place in the procedure are:

1. A MEDIA xxx ALLOCATE command is issued that requires the use of a dynamic device by a foreground process.
2. The MEDIA_SERVER spawns a subprocess to create/setup the needed device. The foreground waits for this to complete.
3. The device determined in step 2 is returned in the foreground process.
4. The foreground process then mounts, operates on and dismounts the device.
5. A MEDIA DEALLOCATE is then issued by the foreground,
6. A MEDIA_SERVER spawns a subprocess to deassign and remove the device created in step 2. The foreground is allowed to proceed before this completes.

The method used to modify the physical device that is associated with a dynamic device is:

1. Assign a device name:

   MEDIAS SET/DEVICE `P1' /NOSYNC/PHYSICAL=device_to_use

2. Deassign a device name:

   MEDIAS SET/DEVICE `P1' /NOSYNC/PHYSICAL=""

The /NOSYNC qualifier prevents this command from attempting to gain control of the device before modifying the /PHYSICAL attribute (the server process has control when this subprocess executes).

The DYNAMIC.COM sample procedure is listed below. This procedure assumes that the physical device name is always "$20$MUA201:".

$! $! ALLOCATE SECTION $! $do_allocate: $! $ MEDIAS SET/DEVICE 'P1'/NOSYNC/PHYSICAL=$20$MUA201: $ goto done $! $! DEALLOCATE SECTION $! $do_dealloate: $ MEDIAS SET/DEVICE 'P1'/NOSYNC/PHYSICAL="" $ goto done $! $! WRAP THINGS UP AND EXIT $! $done: $ PURGE/KEEP=10 MEDIA_LIBRARY:'F$PARSE - $ (F$ENVIRONMENT("procedure"),,,"name")'.LOG

In some installations the operator maintains a rack or cabinet set aside for "scratch" media. That is media that the operator knows can be used by any job on demand (i.e. they have been scratched). In this type of installation it is useful for the operator to prepare for a (for example a BACKUP) MEDIA job by just getting enough "scratch" media together and loading them one by one. Rather then identifying a specific list of external id.'s and getting them from the storage area.

D.1 Definition of SCRATCH template

A SCRATCH template is an entry in the MEDIA DATABASE that represents the desired characteristics of a scratch medium to be used when the job runs. A "scratch template" has STATUS=SCRATCH set in the MEDIA database.

The word "scratch" refers to a medium in the available pool. When a "scratch" medium mount is requested, the operator can decide what medium to actually mount. The medium the operator mounts must meet the criteria established in the "scratch template". If it does not, then the medium is reject and the request made again.

D.2 Selecting media using SCRATCH templates

When a job is created using a "scratch template" the job is entered into the designated batch job just like any other media job. The job name is the scratch medium name. When the job starts executing a message is sent to the operator requesting a scratch tape. The following characteristics of the "scratch template" are used to determine if the operator loaded "scratch" medium is acceptable:

1. The TYPE of the SCRATCH entry must be equal to the TYPE of the loaded medium.
2. The LOCATION (if not blank) of the SCRATCH entry must equal the LOCATION of the loaded medium.
3. The LENGTH (if not zero) of the SCRATCH entry must equal the LENGTH of the loaded medium.
4. The loaded medium must be in the AVAILABLE pool.

If a loaded medium is unacceptable an OPCOM message is generated indicating "scratch medium rejected". All the following are reasons why a loaded medium can be rejected:

1. The medium could not be found in the database.
2. The Internal and External names where not equal.
3. The medium is not in the available pool.
4. The medium does not have the requested type.
5. The medium does not from the requested location.
6. The medium is not of the requested length.

When a acceptable "scratch" medium is loaded the following attributes of the "scratch template" are copied over into the newly acquired medium.

1. All LABEL flags
2. All MOUNT flags & conditions (block, record, density)
3. All UPDATE flags
4. Protection settings (UIC, Map, ACL)
5. Comment

This implies that the first operation to such a volume MUST be an INITIALIZE operation.

D.4 Restrictions when using SCRATCH templates

Media that are to be processed using this "scratch template" method MUST have the following attributes:

1. The EXTERNAL and INTERNAL id's MUST BE EQUAL.
2. They must be initialized and NOT marked BLANK.
3. All BCKMGR jobs that use this must use Generation mode.

The behavior of some of the device commands are modified when a "scratch template" is used. A typical batch job created by one of the MEDIA job commands uses MEDIA device commands as follows:

MEDIA id ALLOCATE (1) MEDIA INITIALIZE (2) MEDIA MOUNT (3) do stuff MEDIA DISMOUNT MEDIA UPDATE MEDIA DEALLOCATE

The ALLOCATE (1) operation selects a drive to use based on the attributes of the "scratch template". The INITIALIZE (2) will always be present since a "scratch" must always be initialized first to use. During the INITIALIZE (2) operation the operator has the opportunity of loading any acceptable "scratch" medium. After the INITIALIZE (2) has completed the loaded medium has been assigned to the current user and all the attributes of this new medium have been set up appropriately. All DCL symbols that control the job have also been changed so that all later (3) MEDIA commands will use this new medium.

D.6 Effects on operator mount messages

When a scratch template is used the OPCOM message is changed. A typical message appears below:

%%%%%%%%%%% OPCOM 16-MAY-1996 11:21:45.37 %%%%%%%%%%% Request 387, from user SYSTEM on ISE Please mount volume SCRATC in device _ISE$MSA0: Scratch SCRATCH(TK50), density 1600 bpi, for writing The "SCRATCH(TAPE)" indicates that the name of the scratch template is "SCRATCH" and it is of type "TK50". Medium rejection messages look like: %%%%%%%%%%% OPCOM 16-MAY-1996 11:25:10.33 %%%%%%%%%%% Scratch medium in ISE$MSA0: rejected. Scratch medium is not in available pool.

D.7 Patches to BACKUP

$ DEFINE BACKUP MEDIA_LIBRARY:MDBKP.EXE $ DEFINE MDBKPSHR MEDIA_LIBRARY:MDBKPSHR.EXE $ BACKUP .... (ALL STANDARD OPERATIONS WORK AS NORMAL)

To invoke the new features:

$ BACKUP ... ..../LABEL="&ABC"

The presence of the "&" in the label name invokes all the new features. Without it the program behaves as normal. The new features are:

1. All volume validation done via MEDIA
   • includes ability to process SCRATCH templates
   • all OPCOM messages formated by MEDIA
2. The current volume labels are picked up from DCL symbols

sym_1...n - external id. list sym_MAXIMUM - last volume number in id. list sym_CURRENT - current number being processed sym_START - first volume of current BACKUP

The "sym" is determined from the /LABEL qualifier. In the above example "sym" is "ABC".

D.8 Creating a BACKUP job using SCRATCH templates

The "backup mode" setting controls which version of backup a particular job uses. The various backup modes are:

Using VMS standard BACKUP 2. Incremental 3. Full Using patched version of BACKUP 4. Incremental - PBkp 5. Full - PBkp

All backup jobs are set up the same way. Use either the BCKMGR_MAINT procedure or use the MCL/BCKMGR functions to create a job and set up which disks to backup. To invoke the "scratch template" features first create a template (one per job) with the correct attributes. For example:

$ MEDIA SCRTK50 ADD/USER=SYSTEM/TYPE=TK50/STATUS=SCRATCH

Then assign this entry to the backup job. Only one "scratch template" to a job. This entry acts as a wildcard. It will always be left assigned to the job. As media get assigned they are inserted before this entry. To assign template to the job do:

$ BCKMGR ASSIGN MY_BACKUP SCRTK50

Any full backup job can be run using either mode 3 or 5. Any incremental backup job can be run using either mode 2 or 4. To take full advantage of "scratch templates" and allow MEDIA to manage the volume transitions during a BACKUP then it is important to use modes 4 or 5. If a "scratch template" is encountered in modes 2 or 3 it is left assigned to the job. But the job will behave as a plain GEN mode job, with media being assigned before the BACKUP command is issued.

D.9 Effects on BCKMGR commands

There are two BCKMGR commands effected. They are:

$ BCKMGR PICK_MEDIA/SYMBOL=PREFIX [JOB_NAME] [MASTER_MEDIUM] $ BCKMGR PICK_MEDIA/NOSCRATCH [JOB_NAME] [MASTER_MEDIUM] $ BCKMGR ADD_IN_JOURNAL/SYMBOL=PREFIX [JOB_NAME] [MASTER_MEDIUM]

The /SYMBOL qualifier instructs the program to look for a group of DCL symbols to identify which volumes are currently in use. The /NOSCRATCH allows backup modes 2 and 3 to suppress the "scratch templates" during medium selection.