Topics Map > University of Chicago > IT Services > Business Systems > Mainframe

Mainframe - Removable Media Manager (RMM) Manual

This document contains the user manual for the Removable Media Manager.


1.0 Overview

Reading or writing your data to a cartridge tape is no more complicated than using a 9-track round reel device. Because all of CSM’s rental cartridges are managed by RMM (a Removable Media Manager from IBM), there are a few new options.

In the past when you required a scratch tape to be used during execution of a job and then assigned to you:

  1. You coded the proper /*SETUP statement(s)
  2. The operator mounted one or more Standard-Label (SL) or Non-Label (NL) tapes as requested.
  3. The operator wrote an external label for each tape containing the project and person to whom it was assigned, the date, the creating job name, etc., and affixed the label to the tape.
  4. The operator filled out a two-part tape assignment card for each tape mounted. The green part was sent to the tape librarian who keeps both a machine readable and a manual database. The gold card was delivered to you.
  5. The rental tape remained assigned to you until you returned the completed gold card or otherwise let the tape librarian know that you no longer needed it.

RMM removes many of the manual steps that provided opportunities for human error. It also provides you, the user, with more control over:

  1. How many tapes are assigned to you.
  2. How long they remain assigned to you.

All CSM rental cartridges are Standard Label. Below are details on how to read and write to cartridge tapes and examples.

2.0 Reading a Dataset on a Cartridge Tape

In order to read a dataset on a cartridge, you need a /*SETUP statement to advise the operator of your intentions and a DD statement to point the operating system to your data.

2.1 The /*SETUP Statement

If your dataset is cataloged, the statement will look like this:

/*SETUP DSN=myprojct.mydsname

If your dataset is NOT cataloged, indicate the volume serial (vvvvvv) and the device type like this:

/*SETUP UNIT=3480,VOL=vvvvvv

/*SETUP UNIT=3480,VOL=(vvvvvv,wwwwww,xxxxxx)

2.2 The DD Statement

If the dataset is cataloged, point to it as you would any other cataloged dataset.

//ddname DD,DISP= ...

If the dataset is NOT cataloged, the unit name is 3480 and your DD statement looks like this

//ddname DD,VOL=SER=vvvvvv,
// UNIT=3480, DISP= ...

3.0 Acquiring and Writing To A Scratch Cartridge Tape

Now let us suppose you wish to create an output dataset on a scratch cartridge which you will then rent from CSM. You need a /*SETUP statement to advise the operator of your intentions and you also need a DD statement to point the operating system to the scratch cartridge. You also have to select a retention period or expiration date (i.e., tell RMM how long you wish to retain the volume).

3.1 The /*SETUP Statement

All of our 3480 cartridge drives are equipped with Automatic Cartridge Loaders (ACL). Several cartridges can be stacked up ready to be used without operator intervention. During most time periods, these units will be filled with scratch tapes. Use


to request a scratch from the ACL devices.

3.2 The DD Statement

The unit type on your DD statement should match your /*SETUP statement.

//ddname DD UNIT=ACL3480,DISP=(NEW, ...

3.3 Retention Period or Expiration Date

You can tell RMM how long you wish to RETAIN a volume or when the volume will EXPIRE. The goal is essentially the same, the difference is in how you prefer to look at things. Both functions may be specified either within the LABEL parameter on your DD statement or alone and are mutually exclusive.

3.3.1 LABEL=RETPD=nnnn

This is a standard IBM Retention Period facility. ìnnnnî indicates for how many days the tape on which the dataset resides should be retained. If a Retention Period is not specified, our local default of 14 days applies.

//ddname DD RETPD=nnnn, ...


//ddname DD LABEL=RETPD=nnnn, ...

Be aware that

//ddname DD RETPD=0, ...

is valid and means that the volume on which the dataset resides will be used during execution of the current job, but will not be kept. The tape will NOT be assigned to you. The tape remains in the scratch pool, available to another user.

3.3.2 LABEL=EXPDT=option

This includes the standard IBM Expiration Date facility plus several added options. Standard IBM values

//ddname DD EXPDT=yyddd
//ddname DD LABEL=EXPDT=yyddd
//ddname DD EXPDT=yyyy/ddd

//ddname DD LABEL=EXPDT=yyyy/ddd

Means the tape on which this dataset resides is to be retained until the julian date ìyydddî (ìyyyy/dddî is the newer notation) has passed. The tape is assigned to the user. Special Defined Values

Catalog Control

//ddname DD LABEL=EXPDT=99000

Means the tape on which this dataset resides is to be retained as long as the dataset is cataloged. The tape is assigned to the user.


//ddname DD LABEL=EXPDT=99365


//ddname DD LABEL=EXPDT=99366

Means the tape on which this dataset resides is never to be scratched, rewritten or appended to. The tape is assigned to the user

Foreign or Outside Volume

//ddname DD LABEL=EXPDT=98000

Means this tape is a "foreign" tape, not managed by the Tape Library System. RMM takes no responsibility for protecting this volume or any data it may contain. You would specify 98000 when reading a tape received from an outside source, or when creating a tape that will be sent elsewhere.

3.4 Sensitive Data Erasure

In cases of highly sensitive data, you may wish to indicate that when a cartridge expires, it must be erased before it is made available to another user.

//ddname DD LABEL=EXPDT=97000

Means that the tape will be retained by RMM for as long as the dataset is cataloged at which time the volume will be set for erasure before returning to SCRATCH status. This is the only way in which a tape may be set for erasure via JCL. Erasure may also be requested via the User Panels in RMM.

4.0 Examples

4.0.1 Ex. 1 – Using a Scratch Cartridge as a Work Tape

If your job requires the use of a cartridge, but you have no need to retain it after the job has ended, request a scratch cartridge in your /*SETUP statement. On the DD statement which describes the work dataset set UNIT=ACL3480 and the retention period to zero.

// EXEC PGM=myprog ...
//ddname DD UNIT=ACL3480,LABEL=RETPD=0, ...

4.0.2 Ex. 2 – Keeping an Output Dataset for a Limited Time

In this example, we create an output dataset to be kept for three weeks. Set the retention period to 21 days. After that time, it is no longer useful, the volume can be returned to the scratch pool.

//stepname EXEC PGM= ...
//myfile DD DSN=myprj.mydsname,DISP=(NEW, ...
// UNIT=ACL3480,
// RETPD=21

4.0.3 Ex. 3 – Creating a Permanent Output Dataset

Suppose you are creating a dataset which represents an entire year of work. It will require one or more 3480 cartridges. Once it is written, you want to keep indefinitely and will never write over it.


//stepname EXEC PGM= ...
//myfile DD DSN=myprj.mydsname,DISP=(NEW, ...
// UNIT=ACL3480,
// EXPDT=99365

4.0.4 Ex. 4 – Creating a Dataset Under Catalog Control

Perhaps you have a dataset to which you apply weekly updates. Just prior to updating, you routinely copy the dataset to a tape GDG.

By requesting RMM Catalog Control for expiration, you get a new volume for each new generation created. As long as that generation is cataloged, the cartridge on which it resides is yours. When that generation is no longer cataloged, RMM releases the volume, making it available as a scratch tape for another user. You select the number of generations retained when you create the GDG index.

//stepname EXEC PGM= ...
//output DD DSN=myprj.mybackup.GDG(+1),
//EXPDT=99000, UNIT=ACL3480,

4.0.5 Ex. 5 – Ensuring Volume Erasure Upon Expiration of Catalog Control

Because the two datasets created below contains confidential information, I want the volumes erased after I have finished with them but before they are returned to the scratch pool after passing out of catalog control.

//jobname JOB ...
//stepname EXEC PGM= ...
//MYDD1 DD DSN=myprj.secret.stuff1,
// EXPDT=97000, UNIT=ACL3480,
//MYDD2 DD DSN=myprj.secret.stuff2,
// EXPDT=97000, UNIT=ACL3480,


5.1 ACF2 Access Control System.

RMM interfaces with the ACF2 security system, providing a means of sharing tapes among users or projects by associating the dsname of the first recorded dataset on the tape volume with the tape volume itself. Thus an owner of the tape may grant access to the tape by writing ACF2 rules for the first dataset on the tape. As with all ACF2 rulesets, pattern matching may be used. The DFSMSrmm interface provides dsname validation during open/close/end-of-volume processing and RMM/ISPF inquiry/update validation. Note – this does not guarantee complete security for all datasets on the tape. If a user is allowed access to a tape he or she may access any dataset on the tape. RMM as is CA1 (which it replaces) is in reality a tape management system and security is only enforced at the volume level.

5.2 Volume Level Security in RMM.

Ownership of tape volumes managed by RMM will be determined by the logonid of the job creating the first dataset on the tape. An owner may read any dataset on the tape and may create new secondary files on the tape. Non-owner users of a tape who need read access to any dataset on that tape will require read access to the first file on that tape. Non-owner users of a tape who wish to create new secondary files will require write access to the first file.

5.2.1 For example:

The first dataset on the tape was created with dsname of: XYZ.SOME.DATA and we want user ABCJOHN to be allowed the privilege of creating secondary datasets on the tape, then the XYZ ruleset should look like:



We may add other rules, for example:


In this example ABCJOHN may create secondary datasets on any tape containing a first dataset named XYZ.SOME.DATA. Anyone in the XYZ project may read any dataset on those tapes. Note that ACF2 allows one to write a rule like ìREAD WRITEî, which would prevent a creator of a secondary dataset from reading it. So don't forget to put in the READ with the RITE rule.


The high order qualifier (the prefix) of the secondary datasets need not match the prefix of the primary. They may have prefixes in projects other than that of the first dataset. Thus the creator of a secondary dataset on the tape need not write rules giving the owner access to the secondary file.

5.3 RMM ISPF Session Security

Users may view their RMM volume and dataset records and those of any project in which they are enrolled via the RMM ISPF dialog (L.RMM in ISPF primary option menu.) However, they may only update volume records that they own or are granted update privileges by the same rules that grant them write access to the volumes. In other words to update an RMM record a non-owner user must have ACF2 WRITE privilege for the first dataset on the volume. For example, we may add a rule to the previous example ruleset allowing RMM update privilege to user XYZBOSS, as follows:


In this example XYZBOSS may update the RMM records for tapes containing a first dataset named XYZ.SOME.DATA. Also as a consequence this rule also grants XYZBOSS the option of creating secondary datasets on the tape.

5.4 FDR/ABR and RMM Security

FDR/ABR/DSF checks specifically for volume ownership on DASD volumes or dataset ownership if the user invoking FDR/ABR/DSF is not the DASD volume owner. RMM, on the other hand, controls tape volume ownership and controls datasets written to tape. These are separate and independent functions. Users backing up or restoring their own datasets should have no problems. Owners of private DASD volumes should review their DASD volume and allocate rules before attempting FDR/ABR/DSF functions.

5.5 Security Messages appearing in JOB log.

The security system normally issues one or more of the following messages in addition to any ACF2 ACF99900 logging messages whenever a tape is opened for processing:


In case of a violation it will issue one or more of the following in addition to any ACF2 ACF99913 error messages:


Keywords:cartridge tape   Doc ID:19475
Owner:Todd L.Group:University of Chicago
Created:2011-08-02 18:00 CSTUpdated:2016-07-25 07:47 CST
Sites:University of Chicago, University of Chicago - Sandbox
Feedback:  0   0