On the Road to Removable Media Manager (RMM)
By Roy W. Odom, Jr.
       
Roy W. Odom, Jr. is a lead systems programmer with Auburn University and is a
member of the DPMA SIG-Mainframe Board of Directors. With both B.S. and M.A.C.T.
degrees from Auburn, he has more than 18 years data processing experience and has
been involved in all aspects of that field in the insurance, manufacturing,
entertainment, transportation, credit reporting and education sectors.        

Callout:"What's so glamorous about RMM?" you ask. "Isn't it just another tape
[management] system?" 
      From a most rudimentary perspective the answer is, "Yes." But as with most
seemingly simple exchanges, we must look much further to understand its real
relevance.

Callout: Implementation of RMM requires the careful extraction of information
from your existing system. It also requires the conversion of said information
to a format that can be used to introduce that information into the RMM control
data set (CDS).

Callout: Obviously, RMM was named with more than just tape media in mind. Its
involvement with OAM might portend support of optical media. It is also the path
of support for SMS managed automated tape libraries (ATLs) of the 3495 variety.
RMM also provides interfaces for DFHSM and ADSM (a distributed storage management 
solution) to manage their own removable media volumes and volume pools.

      System managed storage (SMS); like it or not, it's here, it's useful and
there will come a time when you will wonder how you ever lived without it. 
      The most recent and welcome addition to the SMS family, which began in the
seemingly ancient days of the data facility product (DFP) now supplanted by DFSMS
(whether or not you choose to activate SMS), is a component known as the
removable media manager (RMM). Or more precisely, the rmm part of DFSMS known as
DFSMSrmm. 
      "What's so glamorous about RMM?" you ask. "Isn't it just another tape
[management] system?"  
      From a most rudimentary perspective the answer is, "Yes." But as with most
seemingly simple exchanges, we must look much further to understand its real
relevance. Before doing so, however, let's review the simple tape management
aspect of it. 
      RMM can and does provide all of the functions of the major tape management
packages available today and can replace those packages in a phased
implementation. This includes operation in manual, recording and protect modes. 
      During manual mode operation, the RMM subsystem is active but is not
updating the data base. Trial conversions, testing and familiarization with all
of the interfaces can be conducted concurrently with the continued, uninterrupted
use of other tape management systems.
      During recording mode operation, manual mode operation continues with the
addition of active recording of tape activity in the RMM data base. The existing
tape management system continues to operate independently of the RMM processing. 
      During warning mode operation, RMM acts as if it were in control of tape
management and protection in every way except that it does not block any usage
of tape volumes. Concurrently, with the continued and independent operation of
any previously acquired tape management systems, RMM records all tape activity
and issues warning messages in cases of tape activity that would be disallowed
if RMM was operating in protect mode. 
      Implementation of protect mode requires careful preparation during
operation in previous modes. Concurrent operation with predecessor systems in
this mode is not recommended. In protect mode, RMM is fully engaged to protect
tape volumes and data sets, control tape libraries, and manage tape volume
movement.

      Changing modes of operation as well as entering and withdrawing RMM in any
mode requires only simple MVS commands. No IPLing is required for these actions.
      Detailed information on RMM functions and implementation plans for
converting from existing systems can be found in manuals published by IBM.
Implementing and Customizing DFSMSrmm, publication number SC26-4932, and the
Planning Guide for Conversion to DFSMSrmm, publication number GG24-3988, address
specific, previously acquired tape management systems with detailed comparisons
of their functions. These manuals also provide conversion plans from specific,
previously acquired tape management systems.
      Implementation of RMM requires the careful extraction of information from
your existing system. It also requires the conversion of said information to a
format that can be used to introduce that information into the RMM control data
set (CDS). The CDS is frequently referred to as the master file.  
      The entry of the converted information into the RMM master file and
verification that the information has been validly transferred into the CDS must
also be completed. 
      DEXTRACT is a model program for extracting information from existing
systems. CONVERT is a model program for introducing the data into the CDS after
intermediate stages of processing the extracted information. The order of
presentation of information for entry into the CDS is crucial to a successful
conversion. 
      The conversion strategy can also rely completely upon data produced from
external reports of the current solution. The data can be processed into an
intermediate format, and TSO RMM commands can be produced and executed with the
RMM system active in manual mode. Verification of the resulting CDS contents can
be made by comparing external RMM reports against external reports of the
existing system. 
      Various stages of testing can be conducted after the successful production
of a CDS; first in manual mode, then in record mode, followed by warning and
protect modes. Extensive testing must be used to verify that planned RMM system
operation is compatible with the existing tape management solution. An
incremental update process can be incorporated as part of the verification
procedure. 
      During conversion of specifications of vital record retention policies from
the existing solution, a straightforward mapping of locations to accommodate the
limited number of RMM defined locations can be chosen.  
      The SHELF location can be associated with the HOME specification and the
traditional computer room tape storage in individual volume slots known to RMM
as "racks." LOCAL can be used for tapes in a nearby production control area.
DISTANT is appropriate for tapes sent to the highest volume off-site location.
REMOTE can be used for all other off-site locations.  
      Owner assignments can be used along with vital record specification (VRS)
volume entries to simulate the existing solution's out-of-service conditions.
These can define subsets of the various volumes that VRS data set name entries
move to the REMOTE RMM location. 
      More sophisticated use of less restrictive location names can be
implemented through the object access method (OAM) subsystem and SMS activation.
This facility involves the introduction of the tape configuration data base
(TCDB). The TCDB is a new type of ICF catalog known as a VOLCAT. It is maintained
with IDCAMS commands. 
      The TCDB relates tape libraries to volumes. The RMM CDS relates the volumes
to data sets, owners and all of the other RMM entities. The TCDB must be
synchronized with the CDS when it is used. 
      Initial testing can be performed without explicit security system
definitions other than those already in use. RMM makes extensive optional use of
a number of entities in the security system facility class when it is activated.
Most of this usage defaults to full access unless otherwise defined. 
      Two notable exceptions to the full access default are the ability to ignore
RMM during tape processing--also known as "EXPDT=98000" processing--and the
ability to reset the RMM subsystem interface, which deactivates RMM protection.
Both of these functions require access explicitly granted through security system
facility class definitions. 
      Parmlib-specified operational policies defined in a member named EDGRMMxx
can be modified by the MVS modify command. The suggested cataloged procedure name
is DFRMM. 
      Obviously, RMM was named with more than just tape media in mind. Its
involvement with OAM might portend support of optical media. It is also the path
of support for SMS managed automated tape libraries (ATLs) of the 3495 variety.
RMM also provides interfaces for DFHSM and ADSM (a distributed storage management 
solution) to manage their own removable media volumes and volume pools. 
      A variety of exits are available. An implementation of EDGUX100 can enable
ignore processing and provide for other job control language-driven options based
on the contents of the job file control block. The same exit can enforce reliance
on the MVS system catalog and VRS entries for volume retention. 
      Get used to seeing the EDG prefix and get on the road to RMM! 
            
Was this article of value to you? If so, please let us know by circling Reader
Response Card Number  .