You are on page 1of 164

IEEE Std 1244.

1-2000

IEEE Standard for Media Management System (MMS) Architecture

Sponsor

Storage Systems Standards Committee of the IEEE Computer Society
Approved 21 June 2000

IEEE-SA Standards Board

Abstract: The architecture of a distributed, platform-independent system that manages removable media, including both disk and tape, using robotic and manual methods are specified. The general schema for managing media, the components of the software system, and the supporting data model used by the software system for managing this media are described by this standard. Details of major components of the system are specified by companion standards. Keywords: application independent, architecture, automated tape library, content neutral, data model, device manager, distributed, drive manager, fully scalable, heterogeneous environment, information access, interoperability, interoperable, language neutral, library management, library manager, media management, media neutral, middleware, opensource, operating system independent, platform-independent, protocol based, removable media, robotic tape library, secure, software, storage, storage management, storage system, system architecture

The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright © 2000 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 23 October 2000. Printed in the United States of America. Print: PDF: ISBN 0-7381-2506-7 ISBN 0-7381-2507-5 SH94862 SS94862

No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.

IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board. Members of the committees serve voluntarily and without compensation. They are not necessarily members of the Institute. The standards developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as well as those activities outside of IEEE that have expressed an interest in participating in the development of the standard. Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of all concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE-SA Standards Board 445 Hoes Lane P.O. Box 1331 Piscataway, NJ 08855-1331 USA Note: Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents for which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention.

IEEE is the sole entity that may authorize the use of certification marks, trademarks, or other designations to indicate compliance with the materials set forth herein. Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; (978) 750-8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center.

Introduction
[This introduction is not part of the IEEE Std 1244.1-2000, IEEE Standard for Media Management System (MMS) Architecture.]

This is one of five MMS standards balloted together under IEEE Project 1244 for Storage System Design: IEEE Std 1244.1-2000—IEEE Standard for Media Management System (MMS) Architecture IEEE P1244.2/D041900—Draft Standard for Media Management System (MMS) Session Security, Authentication, Initialization Protocol (SSAIP) IEEE Std 1244.3-2000—IEEE Standard for Media Management System (MMS) Media Management Protocol (MMP) IEEE Std 1244.4-2000—IEEE Standard for Media Management System (MMS) Drive Management Protocol (DMP) IEEE Std 1244.5-2000—IEEE Standard for Media Management System (MMS) Library Management Protocol (LMP) This MMS Architecture standard (IEEE Std 1244.1-2000) is best understood in the context of the others by reading the first sections of the Architecture. These five standards are the first in a suite of ten approved projects for the IEEE MMS, and all ten might well have been a single standard. However, their separation was maintained to make conformance easier and individual evolution possible. By permission of SGI™ this standard is based on the SGI™ OpenVault™ product, which SGI™ has released to the open source community.a However, the IEEE Media Management System, developed by the IEEE Storage System Standards Working Group (SSSWG), is a significant refinement and extension of OpenVault™. The IEEE Mass Storage System Reference Model (MSSRM) influenced OpenVault™ design before work began on the MMS, and the present OpenVault™ reflects strong influence in its development by the IEEE SSSWG. At the time this standard was completed, the Storage System Standards Working Group (SSSWG) had the following members: John L. (Jack) Cole, Chair
Curtis Anderson Samuel S. Coleman* R. Troy Eberlein Bruce K. Haddon T. Dixon Hutchinson * Denotes a charter member of the SSSWG Merritt E. Jones* Jan Klier Stuart Kreitman Paul Lockwood John Merrill Geoffrey G. Peck Alan Rollow Murali Sathyanarana Joel N. Williams*

Technical editors of these five standards are as follows: IEEE Std 1244.1-2000—IEEE Standard for Media Management System (MMS) Architecture —Geoffrey G. Peck (Primary Editor for Architecture) —Curtis Anderson —Murali Sathyanarayana (Primary Editor for the Data Model) —Curtis Anderson, Joel N. Williams, T. Dixon Hutchinson, Alan Rollow
aMore

information on OpenVault™ is available at http://www.sswg.org.

Copyright © 2000 IEEE. All rights reserved.

iii

Joel N. Jones (1993-2000) —John L. Authentication.IEEE P1244. C. Kearney Linda Kempster Charles M. Hardy P. Dixon Hutchinson Merritt Jones Michael P. Initialization Protocol (SSAIP) —Bruce K. Kennedy Ben Kobler Stuart K.Williams IEEE STD 1244.Williams (Primary Editor) —Murali Sathyanarayana IEEE Std 1244. Alan Rollow IEEE Std 1244.3-2000—IEEE Standard for Media Management System (MMS) Media Management Protocol (MMP) —Murali Sathyanarayana (Primary Editor) —Curtis Anderson. Gary Michael V. Dixon Hutchinson.Williams. Kreitman Paul Lockwood Geoffrey Peck Alan R. Cole Don Doerner Richard T. All rights reserved. Williams iv Copyright © 2000 IEEE. Huff T. Gagliano Mark R.Williams (Primary Editor) —Murali Sathyanarayana Sponsor chairs of this standard are as follows: —Merritt E. Haddon (Primary Editor. 2000–present) —Jan Klier (Primary Editor. (Jack) Cole (2000) The following members of the balloting committee voted on this standard: Curtis Anderson Brian A.4-2000—IEEE Standard for Media Management System (MMS) Drive Management Protocol (DMP) —Joel N. Eberlein Robert J. Rollow Murali Sathyanarayana Yoshitake Shinkai Bob Snead Robert Snively Joel N.2/D041900—Draft Standard for Media Management System (MMS) Session Security. Joel N. . 1998-2000) —Curtis Anderson. Berg Paul Buerger George B.5-2000—IEEE Standard for Media Management System (MMS) Library Management Protocol (LMP) —Joel N. Hariharan Ronald W. Cole John L.

TAB Representative Catherine K. Berger IEEE Standards Project Editor AMPEX is a registered trademark of AMPEX Corporation. it had the following membership: Donald N. Inc. Quantum DLT is a registered trademark of Quantum Corporation. Engmann Harold E. UNIX is a registered trademark in the United States and other countries. Copyright © 2000 IEEE. Chair James T. Robinson Akio Tojo Donald W. Gurney Richard J. Aggarwal Mark D. Vice Chair Judith Gorman. Munzner Ronald C. DST is a registered trademark of AMPEX Systems Corporation Exabyte is a registered trademark of Exabyte Corporation. DTF is a registered trademark of Sony Electronics. Lips L. Volzka. Carlo. Garzon *Member Emeritus James H. Peterson John B. Posey Gary S. Magstar is a registered trademark of International Business Machines Corporation. Landis Floyd Jay Forster* Howard M. Johnson Robert J. Kennelly Joseph L. NIST Representative Donald R. All rights reserved. OpenVault.When the IEEE-SA Standards Board approved this standard on 21 June 2000. DLT is a registered trademark of Quantum Corporation. Bruce McClung Daleep C. Frazier Ruben D. Heirman. Silicon Graphics. Moore Robert F. Bowman Gary R. Epstein H. IBM is a registered trademark of the International Business Machines Corporation. Mohla James W. licensed exclusively through X/Open Company Limited. Koepfinger* Peter H. Secretary Satish K. Petersen Gerald H. SGI. v . and IRIS FailSafe are trademarks of Silicon Graphics Incorporated. HACMP is a trademark of the International Business Machines Corporation. Holleman Lowell G. Windows NT is a registered trademark of Microsoft Corporation. STK is a trademark of Storage Technology Corporation. N. All other tradenames and trademarks in this standard are those of their respective owners. Zipse Also included is the following nonvoting IEEE-SA Standards Board liaison: Alan Cookson. DDS is a registered trademark of Sony Corporation.

Contents

1.

Overview.............................................................................................................................................. 1 1.1 Scope............................................................................................................................................ 1 1.2 Purpose......................................................................................................................................... 3 1.3 Conformance................................................................................................................................ 4

2. 3.

References............................................................................................................................................ 5 Definitions, abbreviations, and acronyms............................................................................................ 5 3.1 Definitions.................................................................................................................................... 5 3.2 Acronyms and abbreviations........................................................................................................ 7

4.

Functionality ........................................................................................................................................ 7 4.1 4.2 4.3 4.4 4.5 4.6 Interface protocols ....................................................................................................................... 8 Programming and command line interfaces ................................................................................ 9 Data transfer protocol and interface........................................................................................... 10 Operation of the MMS ............................................................................................................... 10 LM operational overview........................................................................................................... 16 System start-up, restart, and shutdown ...................................................................................... 18

5. 6.

Operation and matching model.......................................................................................................... 18 System model..................................................................................................................................... 19 6.1 6.2 6.3 6.4 Media ......................................................................................................................................... 19 Applications ............................................................................................................................... 23 Media Manager (MM) ............................................................................................................... 28 Library Managers (LMs) and Drive Managers (DMs) .............................................................. 29

7.

Protocols ............................................................................................................................................ 30 7.1 Language style ........................................................................................................................... 30 7.2 Language descriptions: extended BNF ...................................................................................... 31 7.3 Message sequencing within protocols ....................................................................................... 32 7.4 Security and authentication........................................................................................................ 33 7.5 Internationalization .................................................................................................................... 33 7.6 Overview of SSAIP.................................................................................................................... 37 7.7 Overview of MMP ..................................................................................................................... 37 7.8 Overview of DMP...................................................................................................................... 38 7.9 Overview of LMP ...................................................................................................................... 38 7.10 Overview of MMIP.................................................................................................................... 39 7.11 Overview of MMCIP ................................................................................................................. 39

8. 9.

Tokens................................................................................................................................................ 39 Data model—introduction ................................................................................................................. 39

vi

Copyright © 2000 IEEE. All rights reserved.

9.1 Clusters and objects ................................................................................................................... 40 9.2 Relationships between clusters .................................................................................................. 41 9.3 Data object list ........................................................................................................................... 44 10. Privilege levels, attribute types, and data types ................................................................................. 46 10.1 Application privilege levels ....................................................................................................... 46 10.2 Attribute types............................................................................................................................ 46 10.3 Summary of privileges and attribute types ................................................................................ 48 10.4 Data types................................................................................................................................... 48 10.5 Default values ............................................................................................................................ 49 11. 12. Object types ....................................................................................................................................... 49 Application cluster ............................................................................................................................. 50 12.1 Creation and deletion semantics ................................................................................................ 50 12.2 APPLICATION object............................................................................................................... 50 12.3 AI object..................................................................................................................................... 52 13. The library cluster .............................................................................................................................. 54 13.1 Creation and deletion semantics ................................................................................................ 54 13.2 The LIBRARY object ................................................................................................................ 55 13.3 The LM object............................................................................................................................ 57 13.4 BAY object ................................................................................................................................ 60 13.5 The SLOT object........................................................................................................................ 61 13.6 SLOTGROUP object ................................................................................................................. 64 13.7 SLOTCONFIG object................................................................................................................ 66 13.8 SLOTTYPE object..................................................................................................................... 68 14. Drive cluster....................................................................................................................................... 69 14.1 Creation and deletion semantics ................................................................................................ 70 14.2 DRIVE Object............................................................................................................................ 71 14.3 DRIVEGROUP object ............................................................................................................... 77 14.4 DRIVEGROUPAPPLICATION object..................................................................................... 78 14.5 DM object .................................................................................................................................. 79 14.6 DMBITFORMAT object ........................................................................................................... 82 14.7 DMBITFORMATTOKEN ........................................................................................................ 83 14.8 The DMCAPABILITYobject .................................................................................................... 85 14.9 The DMCAPABILITYTOKEN object...................................................................................... 86 14.10DMCAPABILITYDEFAULTTOKEN..................................................................................... 87 14.11DMCAPABILITYGROUP object ............................................................................................ 88 14.12DMCAPABILITYGROUPTOKEN ......................................................................................... 90 15. Cartridge cluster................................................................................................................................. 91 15.1 Creation and deletion semantics ................................................................................................ 91 15.2 The CARTRIDGE object........................................................................................................... 93 15.3 The CARTRIDGEGROUP object ............................................................................................. 97 15.4 The CARTRIDGEGROUPAPPLICATION object................................................................... 98 15.5 The CARTRIDGETYPE object................................................................................................. 99 15.6 The SIDE object....................................................................................................................... 102

Copyright © 2000 IEEE. All rights reserved.

vii

15.7 The PARTITION object .......................................................................................................... 104 15.8 The VOLUME object .............................................................................................................. 110 16. The mount cluster ............................................................................................................................ 113 16.1 The MOUNTLOGICAL object ............................................................................................... 113 16.2 The MOUNTPHYSICAL object ............................................................................................. 116 16.3 The DRIVECARTRIDGEACCESS object ............................................................................. 119 17. The session cluster ........................................................................................................................... 124 17.1 The CONNECTION object...................................................................................................... 124 17.2 The SESSION object ............................................................................................................... 126 18. The task cluster ................................................................................................................................ 129 18.1 The TASK object ..................................................................................................................... 130 18.2 The TASKCARTRIDGE object .............................................................................................. 132 18.3 The TASKDRIVE object......................................................................................................... 133 18.4 The TASKLIBRARY object.................................................................................................... 134 19. The system cluster............................................................................................................................ 135 19.1 The MESSAGE Object ............................................................................................................ 135 19.2 The REQUEST object.............................................................................................................. 137 19.3 The SYSTEM object................................................................................................................ 141 19.4 The STALEHANDLE object................................................................................................... 146 20. Tokens.............................................................................................................................................. 148 20.1 Instructions............................................................................................................................... 148 20.2 MMP mount modes.................................................................................................................. 149 20.3 Slot type names ........................................................................................................................ 150 20.4 Cartridge shape names ............................................................................................................. 151 20.5 Bit formats ............................................................................................................................... 152 20.6 Cartridge type names ............................................................................................................... 154 20.7 Partition names......................................................................................................................... 155 20.8 Attribute names........................................................................................................................ 156

viii

Copyright © 2000 IEEE. All rights reserved.

System and component vendors will be able to incorporate the MMS into their systems. The media managed by the MMS does not need to be formatted or labeled for the MMS. and this software will be portable to a wide number of platforms. to data centers. optical disk. as well as non-computer media such as audiotape and videotape. and CD-ROM. Systems that implement the MMS may target a range of customers. including computer media such as magnetic tape. to workgroups.IEEE Standard for Media Management System (MMS) Architecture 1. film. The MMS does not require any particular hardware or operating system. data model. Overview The IEEE Media Management System (MMS) is a distributed. 1 . and allows organizations that have diverse systems to manage the removable media that is used by these systems in a unified manner. nor do they provide a cookbook for implementation of an MMS. Software developers will be able to write software that takes advantage of the huge storage capacity of removable media much more easily. Systems based on the MMS may support many kinds of removable media.1 Scope The MMS standards published by the IEEE define the architecture. The MMS supports both automated (robotic) and non-automated handling of media. These standards are not intended as a tutorial or textbook. The IEEE MMS standards define a software component model for working with removable media as well as a number of protocols that define interfaces between the components. The MMS is scalable and both system and media neutral. and audio CDs and videodiscs. All rights reserved. proprietary solutions to manage removable media. existing media can be incorporated into an MMS-managed system with no modifications. multi-platform system for managing removable media. The MMS utilizes existing machinereadable label information such as bar codes or media labels if they are present. The standards are organized to be of use to several audiences: Copyright © 2000 IEEE. and interfaces that are required in any MMS implementation. to multinational corporations. The MMS and widely available implementations of the MMS will give users of removable media greater security and convenience of operation. from individual desktop computers. allowing greater interoperability and eliminating the need to implement costly. These standards enable vendors to construct applications that use removable media as well as components of an MMS that interoperate with other MMS components. 1.

8 P1244.3-2000 IEEE Std 1244.4-2000. and the components of an MMS implementation. Nevertheless.10 Draft Standard for C Language Procedural Interface Draft Standard for User Mount Commands Draft Standard for Standard Administrative and Operational Commands Data Transfer Protocol P1244. and fundamental information (including the data model) that is common to all related standards is communicated through that standard. Those interested in implementing applications that utilize the MMS will find this standard.1-2000. IEEE Std 1244.IEEE Std 1244.2/D041900. .1-2000 IEEE Standard for Media Management System (MMS) Architecture Native Protocols IEEE P1244.5-2000 Draft Standard for Session Security.1-2000. and IEEE Std 1244. the overall architecture of the IEEE MMS is described in IEEE 1244. The set of standards that comprise the IEEE MMS suite are listed in Table 1. IEEE Std 1244.11 Draft Standard for Media Data Mover — — — — — — — — MMIP MMCIP — — SSAIP MMP DMP LMP available available available available MMS available Acronym Document 1Information on references can be found in Clause 3. d) A suite of IEEE 1244 standards describes the MMS.6 P1244.3-20001 to be helpful. IEEE P1244. Authentication. to be essential. Those interested in implementing devices such as robotic libraries or drives will find IEEE Std 1244. Reference to the MMS Architecture is crucial in understanding the MMS.1-2000. though technical.7 Draft Standard for Media Manager Interchange Protocol Draft Standard for Media Manager Control Interface Protocol Programming and Command Line Interfaces P1244.2/ D041900 IEEE Std 1244. All rights reserved.9 P1244.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT a) b) c) Those interested in an introduction to the MMS and its capabilities will find this standard. IEEE Std 1244. Table 1—The IEEE MMS suite of standards Standard Description System Architecture IEEE Std 1244.1-2000. and allows a degree of independent evolution for the components of an IEEE MMS. Initialization Protocol IEEE Standard for Media Management Protocol IEEE Standard for Drive Management Protocol IEEE Standard for Library Management Protocol Interoperability Protocols P1244. This modular approach to standardizing an MMS permits a granularity of conformance not possible otherwise.4-2000 IEEE Std 1244. to be a reasonable. 2 Copyright © 2000 IEEE. and IEEE Std 1244. its associated standards.5-2000. Those interested in implementing the entire MMS will find all standards in the IEEE MMS suite of standards to be required reading. introduction to the system.

) The authors of the IEEE 1244 standards expect that additional publications that document aspects of the MMS will appear over time. 1. 3 . Until such time as an extension is transformed into an approved IEEE standard. such proprietary extensions may be proposed as additions to the IEEE standard. C++. it is not the IEEE’s intent to favor a specific implementation of the MMS. to broadcast television automation. educational or scientific institution. such as videotape or film. It is platform neutral and operating system independent to work with existing computer systems from multiple vendors with varying degrees of media-handling sophistication. these applications may be multiple instances of the same program. CD-ROMs. e) f) g) Copyright © 2000 IEEE.2 Purpose This standard describes the motivations for an overall architecture of the MMS. indeed. disks. and amplify the IEEE standards. It is content neutral. Over time. including devices that are physically connected to multiple hosts. it should be possible to implement the MMS in a number of ways. for example. Although the architecture may suggest a particular design or implementation. as you read. as well as non-computer media such as videotapes or reels of film. (Feel free. clarify. and as such. Clause 3 in this standard. ranging from a lightweight implementation in a scripting language such as Perl. disk media. and that these additional publications exist to explain. or of management of MMS sites. It is distributed to allow access to media and the devices that store and perform data transfer operations on the media by more than one system. It is intended that the IEEE MMS suite of standards be considered the definitive reference to the standard. and network communication is digitally signed so that it is extremely difficult to forge. It is expected that vendors will implement proprietary products that add value to systems that are based on the IEEE MMS. Connectivity between elements of the MMS requires the availability of standard TCP/IP. These proprietary products must not change the required aspects of the standard as addressed in the IEEE standards. The system has the following properties: a) b) c) d) It is media neutral to allow the management of computer tapes. Media belonging to multiple applications may be managed by a single MMS. it must not be referred to as a standard. and does not have any inherent understanding of the content of the media. may be organized in a manner that is not conducive to sequential reading. Indeed. or a full implementation written in a traditional programming language such as C.1-2000 Readers should be aware that these standards are primarily reference documents. optical disks. It is scalable to be comfortable in environments as small as a single individual’s office or home and as large as a multinational corporation. A single MMS may manage devices that are connected to many host computer systems. or government archives. to skim or skip ahead of the Definitions clause. All rights reserved. These products may significantly improve the functionality and usability of a standards-based system. The MMS is a software system for managing physical media. aspects of implementation. All parties are authenticated. or Java. It provides a reasonable degree of security and protection for access to the media by ensuring that specific media may be mounted only by those applications that have authority to access that media.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. It is application independent to provide appropriate media management functions for diverse applications ranging from backup and hierarchical storage management. the MMS many not even have access to the content of the media. with some media. or of different applications.

This is considered partial conformance. To conform to the MMS as a whole. [For example. this may be done only if the language name is changed. and extensions are not permitted. a system shall incorporate the basic software components that are described in this standard [Media Manager (MM). which would at some future date be incorporated into a standard version of the language. When a component generates a defined language or protocol. and then as new versions of the language are introduced. and Drive Manager (DM)] and these software components must have the functions described in these standards. If an experimental. because the MM cannot accommodate additional LMs or DMs since it does not implement Library Management Protocol (LMP) or Drive Management Protocol (DMP). and these are the only mechanisms that may be used to extend the standard environment.3 Conformance In order to ensure interoperability between applications and the MMS. . defined version of a language. modifications. It allows multiple implementations to interoperate seamlessly. so compliance is with a specific version of a specific language or protocol. a reduced-function MM that fully supports Media Management Protocol (MMP) may incorporate internal implementations of the LM and DM. it shall accept that language or protocol in its entirety—subsetting is not permitted. non-conforming version of a language is required. j) The key to the architecture of MMS is to clearly define the basic functionality that the MMS must provide. and between components that comprise an installation of the MMS. This mechanism should be used for experimental implementations of features. Note that the languages and protocols are versioned. indeed. This extension mechanism should not be used when an existing mechanism that may be used for the purpose (or a similar purpose) is present in this standard. Library Manager (LM). User-defined attributes and device-specific commands (cpattribute and cpshow) are permitted within the data model and the languages. it is required that MMS components adhere to this standard. to allow the MMS itself to be written in almost any programming language.IEEE Std 1244. This methodology allows unilateral extension of a language. it shall generate language or protocol that fully conforms to the specifications given in this standard—additions. flexible interfaces that can evolve over time. the component will continue to support older versions. 1. In general.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT h) i) It is designed to be modular to allow independent groups to work on components of the MMS independently. It is suggested that such an experimental version be a superset of an existing. and. All rights reserved. the modularity is provided by strong.] b) c) d) e) 4 Copyright © 2000 IEEE. All components must comply with the relevant clauses of the data model as defined in the standard. this is considered partial conformance with the MMS standard. a component is expected to start by supporting the current version of the language(s) it supports. It is language neutral to permit programmers to write applications that interact with the MMS in almost any programming language. It is permissible to create individual components that comply with one or more of the language standards but do not fit into a full MMS. and to declare specific points in the functionality to provide defined interfaces that allow independent components to interoperate. a) When a component accepts a defined language or protocol. These specifically allow a pair of components to incorporate exchanges that are not defined in the languages and protocols. but the extended language is no longer a part of this standard.

ISO 639:1988. All rights reserved.3 IEEE Std 1244. Piscataway.iso. Transmission Control Protocol (TCP). American National Standards Institute. Case Postale 56. Copyright © 2000 IEEE.org. UTF-8. NY 10036. abbreviations. IEEE Standard for Media Management System (MMS) Drive Management Protocol (DMP). IETF RFC 791-1981. Internet Protocol (IP). IEEE Std 1244. the revision shall apply. Switzerland/Suisse (http://www. 5 . and acronyms 3.ietf. 3. ISO publications are also available in the United States from the Sales Department. 4IEEE publications are available from the Institute of Electrical and Electronics Engineers.5-2000.6 IETF RFC 793-1981. Box 1331. New York.2 IEEE P1244.1 Definitions For the purposes of this standard. American National Standards Institute.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. P. Codes for the Representation of Names of Countries. Information Technology—Open Systems Interconnection—Application Context for Systems Management with Transaction Processing. USA (http://www.2/D041900.org/). Tags for the Identification of Languages.3-2000.1-2000 2. New York. ISO/IEC 10646-1:1999. Definitions. IETF RFC 2279-1988. For information about obtaining a draft. 3This IEEE standards project was not approved by the IEEE-SA Standards Board at the time this publication went to press. Information Technology—Universal Multiple-Octet Coded Character Set (UCS)— Part 1: Architecture and Basic Multilingual Plane. 6Internet Requests for Comments (RFCs) are available on the World Wide Web at the following site: www. 11 West 42nd Street. ISO/IEC 11578:1996. 13th Floor. IEEE Standard for Media Management System (MMS) Library Management Protocol (LMP). IETF RFC 1766-1995.ch/).5 ISO 3166:1993.4-2000. 11 West 42nd Street. CH-1211. 5ISO publications are available from the ISO Central Secretariat. Information Technology—SCSI-3 Primary Commands (SPC). USA (http://www. 1 rue de Varembé. Initialization Protocol (SSAIP). References This standard shall be used in conjunction with the following standards. NY 10036. the following terms apply: 2ANSI publications are available from the Sales Department. Draft Standard for Media Management System (MMS) Session Security.ansi.ansi.O. A transformation format of ISO 10646.4 IEEE Std 1244.301:1997. contact the IEEE. NJ 08855-1331.org/). Genève 20. IEEE Standard for Media Management System (MMS) Media Management Protocol (MMP). 445 Hoes Lane. 13th Floor. Code for the Representation of Names of Languages. When the following standards are superseded by an approved revision. ANSI X3. Authentication.

1. drives. 3. .1.11 load (v.1. nor is a data mover required for operation of the MMS.2.): A system program through which a client application accesses the data on media.12 media: Any readable or writable data storage area.1 administrative application: A program that is concerned with managing operational aspects of the Media Management System (MMS). a hierarchical storage manager. 3.4 client application: An application program that makes use of Media Management System (MMS) services to manage its media. or a port. 3. If a data mover is present. machine-readable. input/output ports and attachments to other libraries.1.1. 3. where a location is a slot.1.. a drive. side.2 in this standard for more information. as well as those concerned with allocation and policy management of an installation. or both. An administrative application may include an interface for administrative users. c) Mounting a side is the physical action of mounting a cartridge in a drive in a particular orientation.13 mount (v.1.1. an automated library or a vault.8 external label: A marking on the exterior of a cartridge that identifies it. A library may contain zero or more drives. All rights reserved. 3.1.7 drive (n.): The action of making a cartridge. and an application that allows individual users to mount their own tapes. d) Mounting a cartridge is the physical action of moving a cartridge to a drive and loading it into the drive.1. media. 6 Copyright © 2000 IEEE.): A piece of hardware that allows access to data that is stored on media.6 data mover (n. Examples of administrative applications include those that allow the addition and removal of applications.9 internal label: A record in a known format in a known position within a volume that identifies the volume. The external label may be human-readable. 3. Syn: physical cartridge layer. Examples of client applications include a backup program.2 automated library: A robotic (electromechanical) library. libraries.): The physical action of moving a cartridge from one location to another.14 move (v.5 compound cartridge: An ordered set of cartridges that may be treated atomically.1. the MMS provides appropriate interfaces and facilities for it to operate. and computer systems from the MMS.g. A data mover is not part of the Media Management System (MMS). e.IEEE Std 1244. 3.3 cartridge: A unit of physical media that contains one or more sides. A bar-code label is an example of an external label. b) Mounting a partition is a logical action that implies mounting the underlying side of a cartridge and engaging a software interface to gain access to that partition. and typically does not itself own media. or volume accessible. NOTE—See 6. 3. 3.10 library: An automated or manual cartridge-storing facility. partition. 3. 3.1. A set of devices such as RAID may be considered as a single drive.): The electromechanical actions of making cartridges ready for access in a drive. 3.1.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 3. a) Mounting a volume is a logical action that implies mounting the one or more partitions that make up the volume.1. 3.

e. human user of physical media. and now the Open Group’s DCE. 3. logical container of data. and references for generation of UUIDs abound.org for technical specifications and references.1. 3. Syn: external label.2.1. A site administrator or administrators who have policy responsibility for some group of media.15 operations application: A class of administrative application that provides an interface for the staff who operate a media library. 3. and problem situations. a shelf. A simple volume. these partitions may be on one or more physical cartridges.1-2000 3. actions.2.org for technical specifications and references. is represented as a single partition. NOTE—See http://www. The MMS itself does not understand individual human users—it is the responsibility of the application programs that “own” the media to provide an appropriate mapping between the application’s users and the data that an individual user may access on a piece of media.2 PCL: Physical cartridge label.3 UUID: Universally unique identifier. NOTE—See http://www.. 3. which is the common case. the application must also know how to verify the identity of a particular individual user if user verification is required. Operations staff who must deal with individual requests. which may be arranged in a number of different ways. 3. A complex volume utilizes multiple partitions to store its data.opengroup. a) b) c) d) An individual. Since the MMS has no knowledge of users.1. and a program that allows an operator to place a drive or robot in or out of service. A side contains one or more partitions. 7 . 3.1.16 partition: A portion of a side of a cartridge that is accessible as a unit.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. i.2. All rights reserved. MMS clients are application programs that run on one or more host computer systems.21 volume: A named. Various versions of UUIDs exist.20 vault: A non-automated (manual) library.1 DCE: Formerly the Open Software Foundation (OSF) Distributed Computing Environment (DCE).17 port: A physical entity that allows import or export of one or more cartridges from a library. The reader may wish to consider the functions of the MMS from a number of perspectives.1.19 side: The physical portion of a cartridge that is accessible by a drive after one mount operation.1.1.18 physical cartridge layer (PCL): See: external layer.2 Acronyms and abbreviations 3. Examples of operations applications include a program that directs operations staff to obtain a cartridge and load it into a drive.opengroup. 4. A program or group of programs that manage and/or store and retrieve information on physical media. 3. Functionality The MMS manages media at the request of clients. 3. In many cases. Copyright © 2000 IEEE. 3. the application may utilize an operating system to handle user verification.

because the text-oriented protocol is more platform-neutral. In addition to basic operations such as media allocation. Applications may allow a user to gain direct access to media. a corporate data center. and then send and receive information in one of the MMS-defined languages. and most of this information is available to application programs. Administration and operation functions for the MMS are handled by a set of applications. Sort-order comparison of strings (as opposed to equality comparison) is performed in very limited cases. To comply with an MMS interface. mounting. There may be specific operational considerations with manual libraries that are not addressed optimally by the present version of the MMS. Client application programs have a relatively rich set of operations provided to them by the MMS. This text-oriented metaphor was chosen for MMS instead of a binary interface such as DCE RPC. These interface languages are referred to as protocols. and localization support for collating sequence is provided in these cases.) The functionality provided by the MMS interface languages is comprehensive and flexible. The MMS is engineered primarily to handle automated robotic libraries. and for these applications to readily provide a degree of security consistent with the security model of the underlying computer system(s). All keywords are standardized and are not localized. as well as application-specific criteria. All rights reserved. Error and status messages are provided in a form that may be easily localized. the MMS includes functions that allow a client application to store metadata along with the online control information that is maintained for each piece of media. which are text oriented and have an asynchronous command-response style. This permits the implementation of interfaces that are appropriate for different environments: a single user. there should be little or no direct contact with the MMS. There are four primary protocols defined in the MMS architecture for managing media.) TCP/IP shall be used as the transport for MMS protocols whenever information is transferred between MMS components. The use of the ISO-10646 character set and other key parts of this standard ensure that systems that implement the IEEE MMS may be appropriately localized for use in different countries.8 will provide a standard definition of these interfaces. but specific user interfaces are not constrained by the MMS suite. the number and scope of which may grow over time. The MMS is structured to make it easy for these types of applications to exist. The text-oriented message scheme also does not require the licensing. as they directly correspond to common applicationlayer Internet protocols such as HyperText Transfer Protocol (http) and File Transfer Protocol (ftp). Database-style operations are provided that permit an application to locate a specific piece or pieces of media based on standard MMS-provided criteria. It may also be used to manage vaults (manual libraries). and installation of potentially complex underlying software. dismounting. and deallocation. (ieee-mms) and 695 (ieee-mms-ssl) are assigned to the MMS by the Internet Assigned Numbering Authority and one or the other port number. Implementers of the MMS may provide standard library code. 4. The MMS automatically maintains a moderate amount of metadata for each piece of media.IEEE Std 1244. a television broadcast operation. Core functions and levels of security are provided by the MMS architecture. a dairy farm. which make it as easy to utilize text-oriented interfaces as an RPC system. . similar to a database query language such as SQL. They are defined in terms of interface languages. (All currently defined MMS languages utilize text strings as the basis for information exchange. The user would then use the tar program to directly read or write the media. two components shall establish a connection via a network interface. The ISO-10646 character set (Unicode) encoded in UTF-8 is used as the character set. etc. They are as follows: 8 Copyright © 2000 IEEE. (IEEE P1244.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT From the perspective of an individual human user. or both. such as mounting a tape archive (tar) on a POSIX or UNIX system. The standard port numbers 651.1 Interface protocols The interfaces in the MMS are application-layer protocols as designated in the ISO model. are used for all connections between components of the MMS. implementation.

The MMP includes levels of privilege so that. All rights reserved.7—will define a protocol that permits interfacing the data management component of the MMS with existing library management systems.3-2000—is used by client and administrative applications to allocate. Authentication. or an operator console program cannot perform higher-level management functions. dismount. mount. particularly client.) A practical implementation will additionally include the DMP and LMP. The separate MMs might be present at several sites within a large organization. whereas the MMIP will allow off-line shipment of metadata between two instantiations of MMS. b) 4. and deallocate volumes.6—will define a protocol to allow interchange of information between autonomous MMs. for example. programming and command-line interfaces are defined as follows: a) C Language Procedural Interface—IEEE P1244. or they might be in different organizations.8 at a later date. and DMs.8—will define a set of standard programming interfaces that facilitate the construction of components of the MMS. and LMP are peer-to-peer. errors. The MMCIP will allow real-time coordination of metadata information between an MMS and another non-IEEE 1244 MMS. and Initialization Protocol (SSAIP)— IEEE P1244. The MM issues load and unload commands to the DM. and offered capabilities of the drive to the MM. An LM manages an automated library or a vault. Media Management Protocol (MMP)—IEEE Std 1244. The minimum functionality required to implement an MMS is the SSAIP and MMP.) Copyright © 2000 IEEE. Drive Management Protocol (DMP)—IEEE Std 1244. This protocol will facilitate the transfer of media between separate MMs by transferring all associated metadata that is associated with that media. DMP. and initial communication with the MM. administrative. 9 . asynchronous protocols. authority. The DM reports status. usage statistics.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. and operational applications.5-2000—defines the language by which the MM and an LM communicate.1-2000 a) Session Security. bi-directional. (The initial definition will be for the C programming language.4-2000—defines the language by which the MM and DM communicate.2 Programming and command line interfaces In addition to the protocols that specify the functionality of the MMS. additional languages such as C++ or Java could be added as additional standards or as an addition to IEEE P1244. The LM reports status. and to administer the system. LMs. The following additional protocols are defined to extend the MMS to interoperate with other MMSs: a) Media Manager Interchange Protocol (MMIP)—IEEE P1244. b) c) d) The MMP. The MM issues commands to the LM to move cartridges.2/D041900—is the initial handshake protocol used by all components of the MMS to establish identity. and the current contents and topology of the library to the MM. Library Management Protocol (LMP)—IEEE Std 1244. errors. Media Manager Control Interface Protocol (MMCIP)—IEEE P1244. (This would be a monolithic implementation that directly manages drives and libraries without using separate LM or DM programs. a client application cannot perform administrative functions.

and 4. or to allow an application program that is not written for an MMS to be adapted for use with an MMS. compatibility between media and drives. The fail-over mechanism is not defined by this standard. A data mover is not required to implement the basic functions of an MMS. or tcl/tk.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT b) MMS User Mount Commands—IEEE P1244. In a highavailability configuration. 10 Copyright © 2000 IEEE.2. 4. c) An implementation of the MMS does not require any of these interfaces.11—defines protocols and programming interfaces to allow remote and protected access to drives. persistent information stored by the MM must be preserved and made available to the entity that takes over the known TCP/IP address after failure.4 Operation of the MMS The MMS is designed to provide a high degree of independence between modules. minimally interactive interface for basic interaction with the MMS. The MM includes a persistent store. hosts. such as the POSIX or UNIX shell. The MM is accessed by other components of the system using a known TCP/IP address. Address take-over can be done using standard Internet Protocol (IP) fail-over technology such as IBM’s HACMP™ or Silicon Graphics’ IRIS FailSafe™. drives. All rights reserved. and utilizes its knowledge of the state of the site to perform resource allocation and operational actions. these commands could be used to construct interactive interfaces using scripting-based systems such as shell scripts. The MM receives requests from applications. unmount. nor is it required for operation of an MMS. Please refer to the front matter of this standard for details on trademarks. key to this characteristic. applications. connectivity between hosts and drives. If separately administered sets of media exist within an organization. Access control and protection for the drive. a) Media Data Mover—IEEE P1244. and implements the protection of label information on media.10—will define a set of standard administration and operation commands of an MMS.7 Commands may be embedded in scripts to produce more complex or custom functions. and the media loaded in the drive. The MM is the central program module of the MMS. MMS Standard Administrative and Operational Commands—IEEE P1244. there is a single instantiation of an MM that manages all the media for that site.3 are.1. These commands are specified as a part of a command line interface for systems that offer these interfaces. The primary modules of the MMS are depicted in Figure 1. nor is it required to be present. of course. mount. The architecture and protocols of the MMS are designed to accommodate failures of system components. 4.3 Data transfer protocol and interface This standard expects that input/output (I/O) between applications and devices will be performed locally on a machine. and deallocate media. and enabling an end user to mix and match modules written by different organizations. For a given installation. Perl. etc. it will be marked with either a ® or TM. Web CGI scripting. The standard interface protocols described in 4. or Windows NT® command-line interface. system-independent manner. It permits local and remote input-output operations to be performed in a portable. is controlled by the host operating system. using that machine’s host operating system primitives for I/O. multiple MMs could be used. Subsequent referrals to the trademark item will be capitalized only. which holds all relevant information about the site.IEEE Std 1244. including all media. . 4. The standard defines a commandline. 7The first time a trademarked product is listed in this standard. The only requirement is that the MM always have the same IP address. allowing parallel development by multiple organizations of these modules.9—will define a set of standard commands to allow a user to allocate.

Under certain circumstances. the MM performs any necessary control operations on the drive via the DMP to the DM associated with the drive. This allows rapid restart as well as the implementation of high-availability configurations of LMs and DMs. To move a cartridge to a drive. Typically. The LM performs whatever library-specific actions are required to cause the library to move the cartridge into the selected drive. the MM may need to communicate with more than one LM in order to move the selected cartridge into the selected drive. the MM may also verify the internal label(s) on the media. the MM utilizes the LMP.1-2000 One or more LMs and DMs carry out the actions requested by the MM. performing any necessary I/O via the DMP and the DM. Figure 1—Primary modules within the MMS—the Media Manager. such as a tape stored in a vault. communicating with the appropriate LM. the MM does not have knowledge of the specifics of the drive. the DMP provides a generic interface. and Drive Managers 4. All rights reserved. The intent is that the LM and DM be relatively simple programs. here is a relatively simple example that illustrates how the pieces of the system fit together. LM and DM components can be implemented so that any required dynamic state can either be obtained from the device or can be maintained in private persistent storage areas within the MM. the sequence of events is as follows: Copyright © 2000 IEEE.4. Optionally. which must be read by a drive that is attached to an automated library. In this example.1 Operational overview To put the system components and protocols into perspective.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. Library Managers. and the majority of complexity of the MMS be implemented in the MM. Once the cartridge has been loaded into the drive. As with the LM. 11 . and the DM specific to the selected drive performs any drive-dependent functions.

) This sign on process is slightly more complex than a typical interactive log-on because it establishes the identity of both parties. If the passwords match.2/D041900 for details. After the TCP/IP connection is established. see IEEE P1244. If the application did not require authentication.0 or 1. If the authentications do match. it remains open until the application is completely done with its interaction with the MM. it retrieves its copy of the private shared key specific to the Accounting instance of the Backup application. All further communication on the TCP/IP connection between the application and the MM is in the MMP language. but the SSAIP protocol is designed to permit an application to interact with more than one MM. it should open TCP port 652 on the MMs host. When the MM receives this message.1 of that language. it should open TCP port 651 on the MMs host. see the IEEE P1244.1 Application establishes connection with MM The application utilizes its network configuration information to establish a TCP/IP connection to the MMS on the system that is running the MM. the password clause would have been eliminated. and is capable of speaking either version 1. . The application causes the MMS to mount a tape. The application then states that it will be utilizing the MMP language. the application identifies itself to the server as the Accounting instance of the Backup application. In the example above. 4. If the authentication information does not match. the application should terminate the session. (For details of the SSAIP. If the passwords do not match. This example is not an authoritative description of each of the languages that are used within the example. Communication between the application and the MM is shown as well as communication between the MM and the DMs and LMs.1"] password["silverton"]. Application -> MM: hello client ["Backup"] instance ["Accounting"] language ["MMP"] versions ["1. the application is authenticated. consult the appropriate individual standard for the language for an authoritative description. while if it needs secure socket layer (SSL) encryption.IEEE Std 1244. Applications typically interact with only a single MM. 12 Copyright © 2000 IEEE. the MM has authenticated itself to the application.4. The application connects to the MM and is authenticated.1"] password["cablefree"]. and the MM replies with its name. Once the connection is established. the level of security to be used for the remainder of the connection. If the application does not need encryption of the session. The MM replies with the version of the language that will be utilized for this session and a password that the application can use to verify that it is talking to the real MM process. It also establishes an authenticated session using simple password authentication. The application exits. The application performs I/O directly to the tape. the application signs on to the MM using the SSAIP. and the language to be used for communication during the session. the client is refused access.1.2/D041900.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT a) b) c) d) e) f) An application program starts up. All rights reserved. MM -> Application: welcome version["1. The application utilizes the MMS to dismount the tape.0" "1.

side. slot 12" "AB1234" "side 1"] drive ["drive1"] drive["drive2"]. It currently resides in bay 2. and its location within the library. Copyright © 2000 IEEE. MM -> LM: mount task ["365"] slot ["bay 2. The MM would typically accept this command immediately. All rights reserved.1.4. so that the application could. 4. and language version. without this information.3 MM interacts with LM to mount physical media The MM is connected to the selected LM via a TCP/IP connection. Which drives within that library could be used to mount the cartridge. the cartridge is identified by the physical cartridge label AB1234 and is to be mounted on side 1. which requests that the volume usr990424 be mounted. or all possible drives on which the cartridge could be mounted are in use. The language used between the MM and the LM is LMP/M. The MM then consults its database to determine a) b) c) d) Whether or not this volume exists in the application’s name space."MountLogicalHandle"]. considering the cartridge’s type and the physical connectivity of drives to host computers.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. Once those resources are available. The task clause identifies this command and is used to correlate any responses from the MM with this specific request. The specific physical media (cartridge. the MM commences the physical task of getting the cartridge into the drive and making it ready for use. This connection was established when the LM and MM were brought up. if appropriate.3.1.4.4. In which library the requested cartridge resides. commands from the LM to the MM are in the LMP/L language. and remains established until one or both of these system components terminate. 13 . The command-accept-response model is described in 7. slot 12 of the library. and is to be mounted in either drive drive1 or drive drive2.1 is used to establish the applicationlevel connection. Application -> MM: mount task ["1"] volname ["usr990424"] report [MOUNTLOGICAL. If either the cartridge is in use. the application would have no idea how to access the media. An initialization exchange similar to the one shown in 4.1-2000 4. the request will be delayed until appropriate resources become available. The LM accepts the command as follows: LM -> MM: response task ["365"] accepted.2 Application requests a volume to be mounted The application sends a simple mount command to the MM. The report clause instructs the MM to return the logical device handle on which the volume is ultimately mounted. authentication protocol. In this example. at the LM’s option.1. issue further commands to the MM for processing while the following command executes: MM -> Application: response task ["1"] accepted. and partition) to which the volume refers.

This connection was established when the DM and MM were brought up. The MM requests that the DM ensure that the cartridge is loaded in the drive: MM -> DM: loadtask ["191"]. LM -> MM: config task ["982"] scope ["partial"] slot ["bay 2. and then the DM reports that the command has completed successfully. and utilizes the same physical connection to the drive that the application will use. 14 Copyright © 2000 IEEE.1 is used to establish the applicationlevel connection. slot 12" "bay 2" "AB1234" "DLT" "occupied" "accessible"] bay["bay 1" "DLT" "0"] freeslots["bay 1" "DLT" "0"] drive ["drive1" "bay 1" "AB1234" "occupied" "accessible"]. commands from the DM to the MM are in the DMP/D language. The MM requests that the DM make this drive available for read-write access.) Finally. LM -> MM: response task ["365"] success text ["bay 2.4. . both slot names and bay names are arbitrary strings. All rights reserved. authentication protocol. slot 12" "AB1234" "drive1"]. (The MM’s accepted and success responses to the config commands are omitted here.IEEE Std 1244. The language used between the MM and the DM is DMP/M. but implementers are strongly encouraged to choose names that have meaning to human operators. MM -> DM: attach task["192"] modename ["readwrite"]. The DM accepts the command: DM -> MM: response task ["191"] accepted. and language version. the LM updates the state of several internal tables in the MM.1. the LM tells the MM that the requested cartridge was mounted in drive DLT202.4. An initialization exchange similar to the one shown in 4. and return to the MM an appropriate device name to pass back to the application. The DM is located on the same physical computer as the application. DM -> MM: response task ["191"] success.4 MM interacts with DM to set up drive The MM is connected to the selected DM via a TCP/IP connection.1. The DM causes any physical activity that might be required to load the drive. and remains established until one or both of these system components terminate. (The MM maps the slot name in the MMP slot command to an associated bay name for the LM.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT The LM then causes the library to perform the physical action of moving the cartridge from the slot to the drive and mounting it in the drive.) Once this action has been successfully completed. 4.

performing other mounts. Once the physical actions are complete.1-2000 Readwrite is a standard token. unmounts.6 Application performs I/O to drive The application may now perform I/O to the drive.1.1.5 MM replies to application The MM replies to the application that the requested volume has been mounted on the node /dev/mmtape/ 8E927BD4: MM -> Application: response task ["1"] success text ["/dev/mmtape/8E927BD4"]. The MM then interacts with the DM and MM to physically unmount the cartridge.8 Application terminates connection with MM The application is free to continue interacting with the MM.. 15 . etc.1. The application terminates its interaction with the MM by issuing the goodbye command: Copyright © 2000 IEEE. The DM accepts the command: DM -> MM: response task ["192"] accepted. these interactions are similar to those shown in 4. Application .> MM: The MM accepts this command: MM -> Application: response task ["2"] accepted.4. 4. 4. and then replies to the MM with the software name of the device that the application will use to access the cartridge.4. until it is finished. and are omitted here for brevity. All I/O is performed through standard device mechanisms within the operating system on which the application is running. allocation.4.1.1. 4. This completes the execution of the application’s task 1 command.4.4. The DM creates any necessary device nodes. the DM created a one-time-only node named /dev/mmtape/8E927BD4 for access to the device. the MM informs the application: MM -> Application: response task ["2"] success.4. conditions the hardware and/or operating system software for the mode requested in the attach command. the base set of standard tokens appears as Clause 20 of this standard. unmount task ["2"] volname ["usr990424"]. DM -> MM: response task ["192"] success text ["/dev/mmtape/8E927BD4"]. 4. All rights reserved.1.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.7 Application requests volume to be unmounted The application sends an unmount command to the MM. which requests that the volume usr990424 be unmounted.3 and 4. In this example.4. reading and writing the media as it wishes.

each of which may require a somewhat different implementation strategy. simply dropping the connection doesn’t give the MM the opportunity to gracefully complete any commands that might be outstanding. see Clause 13 for details on the MMs representation of a library. If there are any pending actions that the MM must complete before the session can be terminated. nor to return status information to the application. For many sighted robots. cause the unmount to occur) by unilaterally closing the TCP/IP connection (this happens when an application crashes. it is a routine procedure to have the library physically inventory the contents of the library whenever the unit is powered up. etc. The LM may be implemented on a host system that controls the library via a local peripheral attachment (serial.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Application -> MM: The MM accepts this command: MM -> Application: goodbye task ["3"]. All rights reserved. SCSI.) or could be implemented in an embedded controller that is a part of the library. See 6. with the cooperation of the LM.) Libraries vary widely in their capabilities.5 LM operational overview Every LM implements the LMP. They are as follows: a) b) c) Robotic libraries with bar-code readers or other means of externally verifying the identity of a cartridge (sighted robots) Robotic libraries without bar-code readers or other means of externally verifying the identity of a cartridge (blind robots) Libraries that are operated by human beings (vaults) In all cases. The application then closes its TCP/IP connection to the MM. The implementers of an LM may choose to maintain no state locally within the LM and simply operate strictly using information contained in the commands that are received by the LM from the MM. Note that the application could also terminate (and indeed. For a blind robot. (We would expect that any required configuration of such a library would be performed by a few Web pages. for example). A library with an embedded controller would simply plug into the local area network and immediately be usable as part of an MMS.IEEE Std 1244. However. The config command in LMP is used to update the MMs databases whenever the state of the library changes. maintains a representation of the state of the library in its databases.2. as the library cannot tell the MMS the identity and location of individual 16 Copyright © 2000 IEEE. State includes such information as the physical configuration of the library. functions. or may elect to maintain a temporary copy of the state of the library. which allows a library to be controlled by the MM in a standard manner. the position within the library of each cartridge or open slot. etc. so LM implementations will differ from library to library. or whenever the unit has been opened in such a way that the contents might have been disturbed. the most authoritative representation of the state of the library is the physical world.6 for more details on abnormal termination. drives in the library. One key difference between sighted robots and both blind robots and vaults is the ease with which an inventory of the library may be obtained. there will be a delay before the MM’s final reply to the application: MM -> Application: response task ["3"] success. . and interfaces. 4. the MMS must rely on its stored database. response task ["3"] accepted. The MM. There are three broad categories of libraries.

respond. All rights reserved. several forms of which are possible. the MMS cannot have the DM verify that label at mount time. With a vault. The signature and signature type for each cartridge is stored in the MMs database. and that the application will reject the volume if it is not the one that was expected. utilizes one or more administrative applications and the operator interface commands in MMP (accept. in turn. the MMS cannot simply require that all cartridges have standard machine-readable labels (such as ANSI or IBM® standard labels). the mount is aborted by the MM. by which the LM may utilize the MM to interact with human operators. but operators do sometimes make mistakes. the request command in the LMP. When a cartridge is mounted. If the media ID does not match the one stored in the MMs database. the MMS provides an extensible mounttime verification scheme. Without standardized tape labels. it may be desirable for one or more libraries to share one or more operator consoles. move. Verification may be performed in one or more ways. listed as follows in order of precedence: a) If the library is a sighted robot with bar-code validation capability. (Some blind robots can determine whether or not a slot is empty. eject. If the bar code is verified. The MM.5.1-2000 cartridges.) 4. even those for which bar-code verification is available. release. MM uses the DMP’s identify command. It is assumed that the application will check to ensure that the correct volume has been loaded. and inject) to perform those interactions with the operator(s). otherwise.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.) The on-media identifier will be compared with the expected media ID that is stored in the MMs database in the PARTITION. the cartridge containing the desired partition) is actually present in the slot that the database says the cartridge is in.1 Mount verification A key issue with managing removable media is to ensure that the desired piece of media actually gets mounted in the desired drive. and robots may require. no further checking is performed. such as when the label information is at the end of the media. which includes the Copyright © 2000 IEEE. the LM will cause the mount to fail. (The on-media identifier is a device-dependent immutable identifier. if it is available on the cartridge and drive. an application-specific label may be used to identify a cartridge. A signature mechanism is used to do a best efforts check on the cartridge. The MMS is system independent. no further checking is performed. the DM will supply that identifier to the MM as part of the response to the load command. the probability of an error is higher. (An LM should not directly interact with an operator console. The MMS provides a mechanism. which is automatically encoded on the media by the drive. an operator will typically visually verify that the right cartridge and partition are obtained. 17 . then the on-media identifier [step b)] is checked (if that capability is available on the drive). because in larger installations. because the robot cannot verify that the desired cartridge (actually. With a blind robot. Some installations may be able to use handheld bar-code readers to speed this process. With a sighted robot. the probability that the operation is performed correctly is essentially 100%. but it is potentially a time-consuming operation. Since a number of popular operating systems such as UNIX® do not have any notion of standard tape labels. If the application has been administratively permitted to bypass the signature mechanism [step d)] and the application requests no verification at mount time. Vaults require. This check is performed for all mounts. it verifies the bar code on the cartridge as the cartridge is being mounted. If the cartridge and drive support an on-media identifier. interaction with a system operator. b) c) d) The signature is a short representation of the content of the cartridge—this may be a hash sum of the first megabyte of data on the cartridge or a tape label.) A manual inventory can be done in a vault.PartitionSignature field. Under certain rare circumstances. but a manual inventory is still not something that would be carried out frequently. Instead. If the bar code does not match the expected bar code.

4. or DM. DMP. This additional identify step can be bypassed for applications by identifying the unmount as clean. all applications. to cause the DM to return the cartridge’s signature after loading the cartridge and attaching the device. When a cartridge is unmounted. or the operator may choose to pre-identify media which the operator will then introduce into the library. which utilizes MMP’s inject command to instruct the MM to take one or more cartridges into the library. More detailed information on start-up.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT type of signature being requested.IEEE Std 1244. and DM components should reset themselves and attempt to re-establish a new connection with the MM. An application should do so only if it has either supplied the new signature directly to the MM by directly setting the PARTITION. In the event of unexpected termination of any system component. or should a network partition occur. as long as its static databases and its IP address are preserved. Detailed information on the command sequence is presented in IEEE Std 1244. Autonomous operation of applications. When the failed component is restarted. LMs. The MM utilizes the LMP’s inject command to cause the library to perform the physical operation.2/D041900) is used to establish and authenticate the identities of the two parties. restart. DMP. and to resolve the protocol that is to be used for further communications. The operator may choose to physically place the media in the library and then work with the MMS to appropriately identify the media. If the failed component is an application.PartitionSignature attribute or if no change to the signature portion of the partition was made by the application. The command specifies an action. or DM. If the MM should terminate unexpectedly. Further details on the mount-time media verification and signature mechanism are given in the identify command description in the DMP. The operator interface is an administrative application.3-2000. and DMs is prohibited. and shutdown Components of the system may be started in any order. the MM uses the identify command to obtain from the DM an updated signature for the cartridge prior to detaching and unloading the cartridge. LM. the SSAIP (IEEE P1244. or DM will sleep for some period of time and try again. and LMP languages consists of a command keyword followed by appropriate arguments.2 Introduction of media This subclause outlines how an operator may introduce media to a library and how the MMS handles this operation.5. LM. Resynchronization of state with the MM is left up to the application. . and recovery from failures is given in Clause 6 of this standard and in the individual language specifications for the MMP. LM. LM. When started. and LMP. all application. All rights reserved. the system component with which that component is communicating will be notified of the failure of that component by the networking subsystem. Operation and matching model Each statement in the MMP. the application. the MM will take appropriate action(s) to clean up any items that are in process. If no MM is available. If the MM is available. The MM may be restarted on the same or a different machine. 4. and the arguments express options or constraints on 18 Copyright © 2000 IEEE.6 System start-up. 5. LMs. and DMs attempt to contact the MM at a known network address (typically specified using a host name that is looked up via DNS to yield an IP address) on the assigned port number 651 (ieee_mms). termination. but no processing will occur until the MM is in operation. it will establish communication with the MM as described above.

SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. and the number clause selects particular records out of the results.x family. This clause describes the software and hardware components of the MMS.1 Media The purpose of the MMS is to manage the physical media associated with an installation. and audio CDs and videodiscs. To properly manage media. For example. regardless of the size of the installation. Thus. optical disk. and number clauses that are common to a number of commands in the MMP. including computer media such as magnetic tape. Clause 7 gives an overview of the protocols used for communication between the components. the mount command can specify the volume to be mounted explicitly by name. the MMS must understand a moderate amount of information about a physical piece of media. the Boolean expressions may operate not only on standard-defined metadata information that is stored in the MM’s database. This standard describes the data model that underlies the system as well. There is no system administrator – the user of the system relies on the MMS to keep track of the cartridges and to work with applications that use MMS services to request that the user mount or dismount a cartridge. tens of thousands of drives and computer systems. The order clause sorts the results of the match. The match clause takes a Boolean expression that selects one or more cartridges within the MM’s database. or by using a form of Boolean algebra to determine one or more candidate volumes to be mounted. film. This is true as well with the LM—the MM may make either totally specific requests or reasonably general requests to the LM. and even with respect to the library’s current state. 19 . detailed specifications of the individual protocols are given in other standards in the IEEE 1244. but the number of components and the implementation of these components is likely to differ depending on the size of the installation. as well as non-computer media such as audiotape and videotape. and tens of millions of cartridges. consider the match. System model A system that conforms to a standard IEEE MM may be used in a wide range of installations. An installation will contain the same basic software components. i. the system fulfills requests by finding good solutions to the declarative requests. regardless of its size. the MM may be thought of as a solution engine.e. For applications. An MM used by a global enterprise could include thousands of automated libraries and vaults. 6. An example of a small installation is a single PC on a desktop with a single removable-media drive. and CD-ROM. and interact with hundreds of distinct applications and thousands of users. such as the approximate percentage of a volume that is in use. but also on application-defined information. henceforth referred to as a cartridge. Thus. and a desk drawer containing a few cartridges. All rights reserved. 6. from very small to global enterprises. A general request allows the MM to make optimal choices using information that is specific to the make and model of library. order. communicate with dozens of human operators across a number of sites.1-2000 how the command proceeds. an application could select the three emptiest volumes of a specific cartridge type that belong to an application and cause those volumes to be mounted. Systems managed by the MMS will support a diverse range of removable media. The protocols used to communicate between the various components of the MMS are the same. As an example.. This MMS would be administered by full-time professional staff. using a match/order/number mechanism and an application-defined percent in use field. This information includes the following: Copyright © 2000 IEEE.

. many removable disk media. Also note that cartridge sets are not to be confused with cartridge groups. dates first and last written. This group of cartridges is represented as a cartridge set. Some cartridges have additional characteristics that are of importance to the MMS. or a group of cartridges. — Optical or magnetic disks may have more than one partition. recorded on the cartridge also determine the type(s) of drive in which the cartridge may be used. and a drive that handles media with multiple sides may allow access to only one or to all sides simultaneously. and the other side inaccessible. To use shared-access media with this version of the MMS. only one partition may be accessed at a time. both magnetic and optical. Also. The two sides can be treated as independent pieces of media except that they cannot be mounted simultaneously. any physical identification present on the outside of the cartridge. which are a separate object type in the data model. — Magnetic tapes may have more than one partition. the method used to record information on the cartridge. physical form factor. This version of the MMS architecture does not directly support multiple MMS client applications that simultaneously access a single cartridge. including partitions and sides. b) c) Many types of media can accommodate more than a single logical entity within a physical cartridge container. might reside on an MMS-managed volume on an optical disk. Note that cartridge sets are not supported by the initial MMS standard. or will be. In almost all cases. a user may wish to refer to a group of cartridges as a single entity. expected longevity. The media within the cartridge and the bit format that is. 6. including optical disks. and the drives in which the cartridge can physically fit. Some optical cartridges and DVDs have sides—they can be mounted with one side or the other accessible. and would encounter an end-of-file if an attempt were made to write past the end of the partition. typically. Ampex® DST® and some other tape media may be partitioned into multiple separate tapes.1. depending on the device. the two sides are bonded together. an intermediary application is 20 Copyright © 2000 IEEE. a partition within a cartridge. Similarly. The MMS allocates volumes (the logical entity that applications actually use) to partitions rather than to cartridges. applications and end users refer to MMS volumes. The location where the cartridge is normally stored. Disk devices. for example when using striped or other forms of redundant tape. such as its external. each of which has a pre-determined size. The MMS maps the named volume onto an appropriate cartridge or cartridges when performing physical operations. Usage and life cycle information. are frequently used by multiple users at the same time—a file system partition. A cartridge has an external shape that determines the slots of a library in which it can reside. They are as follows: — Optical or magnetic disks may have more than one side. for example.IEEE Std 1244.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT a) Physical characteristics. An application that has access to a drive in which a partitioned tape is loaded would be able to read and write only that partition. All rights reserved. may be partitioned into distinct partitions that have protected access characteristics. it may be practical to access multiple partitions simultaneously.1 Cartridges Cartridges are the physical media that the MMS manages. the type of media housed inside the external shell. such as the number of mounts. its current location if it is not in its normal location. if a two-sided piece of media is physically removed and transported. Sometimes. The notion of a volume in the MMS allows users to think in terms of a logical unit of information that corresponds to a single physical cartridge.

such as on a per-user basis. The mounting application would need to remain active until the filesystem was unmounted. media oxide type. as the MMS would then automatically reclaim the drive and the media. The major events in the life of a cartridge include the following: a) The physical and logical introduction of the cartridge into the system Copyright © 2000 IEEE.) The current MMS does not allow simultaneous access to multiple partitions on a single cartridge. bit format.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. and partition and side information are used to determine conformability of media with drives. not MMS interfaces. In the case of a simple cartridge (one side. The application is the only level of access control provided by MMS for volumes—any finer-grained protection. However. obtain access to all volumes within the MMS. A unique ID (UUID) is used internally within the MMS to identify the cartridge. one partition).2 Volumes The volume is the unit of logical information that an application manipulates with the MMS.6). 6. For example. other applications would use standard filesystem interfaces to access the media. once the disk is mounted. a) b) c) A physical cartridge label (PCL) plus the external cartridge shape (form factor or slot type) of a cartridge uniquely identify each cartridge in the system. a magneto-optical disk might contain a filesystem that could be mounted by an application.1. Detailed information on the data model for cartridges is in Clause 15 of this standard. and then mount the filesystem. which facilitates management of the life cycle of the cartridge. All rights reserved. (Note that the mounting application shall not terminate while the filesystem is in use. The mounting application would use MMS interfaces to mount the volume on which the filesystem resides. is also maintained with each cartridge. an administrative application may. even if the underlying hardware would permit this operation. defines a mechanism by which the history of a physical cartridge can be transferred between distinct IEEE MMS installations when the physical cartridge is transferred between installations. The external cartridge shape. 6. The Media Manager Interface Protocol. is expected to be provided by applications. A cartridge has a number of characteristics that describe the cartridge and allow the MMS to identify the cartridge and to determine where the cartridge may be mounted. Volume names are unique within an application: different applications may choose to have volumes with identical names.1-2000 required that acts as either a multiplexer or as a mounting service. 21 . through the use of references that are qualified with application names.3 Cartridge life cycle The life cycle of a cartridge is the sequence of states and events that describe the history of a physical cartridge from the time that it first becomes part of the MMS until it ceases to be a part of it. (IEEE P1244. there is a one-to-one correspondence between the volume that the application views and the physical cartridge. Volumes are named by applications using strings of the application’s choice. Applications have no visibility to volumes that are owned by other applications. at which point the mounting application would unmount the volume. Statistical information such as number of mounts.1. error counts.

22 Copyright © 2000 IEEE. This may happen via an administrative application. the cartridge moves to the allocated state. The MM utilizes a state model to describe its view of the life cycle of a cartridge. a cartridge must be introduced into the MMS: 1) 2) If a cartridge is introduced into a library (via an MMP inject command) and is otherwise unknown to the MM. When this application wishes to make a cartridge available for reuse. . A cartridge in the defined state optionally may be associated with an application.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT b) c) d) e) Assignment of ownership (who or what application gets to use the cartridge) Use of the cartridge by applications Recycling of a cartridge when one owner no longer needs it Disposal of the cartridge. or a defined cartridge is physically introduced into the system. When an application allocates the cartridge and associates a volume name with it (the volume name is actually associated with a partition within a side of a cartridge). causing it to be degaussed by an operator. The cartridge remains owned by the application until an administrative application processes it. it becomes an identified cartridge or an allocatable cartridge. When the application is finished with the volume (actually. Recycled and identified are distinct to differentiate cartridges that are newly introduced into the system. First. If a cartridge has been defined by an administrative application to the MM. or by removing it for disposal when the media reaches the end of its service life Certain information on a cartridge is maintained by the MM during its lifetime. an allocatable cartridge has been assigned to a particular cartridge group. A cartridge that is identified is not associated with a cartridge group. but has not yet been seen by the MM in any managed library. it is in the defined state. An error state is defined for a cartridge that temporarily cannot be used but should remain associated with an application. A cartridge may move from the allocated state to error. An identified cartridge becomes allocatable when it is assigned to a particular cartridge group. other information may be added to the data stored by the MM by administrative applications. These administrative applications may also utilize the information that is automatically maintained by the MM—for example. such as erasing headers. All rights reserved. or when an application requests allocation of an otherwise unassigned cartridge. it causes the cartridge to enter the recycled state. or even physically destroying the media. finished with all allocated volumes on a cartridge). writing the entire media. Once a located cartridge has information added by the administrative application. this state is equivalent to identified. 3) 4) 5) 6) The administrative application that processes deallocated cartridges may implement site-specific policies. it is in the located state. either by sending it to another system. Detailed information on the cartridge life cycle may be found in IEEE Std 1244.3-2000 (MMP).IEEE Std 1244. this information would allow a life cycle management application to locate cartridges that are in need of replacement either due to error statistics or due to number of uses. the cartridge becomes deallocated. and from error to either allocated or deallocated.

2 of this standard) defines a UMA interface that will be consistent across many different computer platforms. Data transfer applications utilize volumes.2 Applications The MMS is designed to work with one or more end-user applications that implement data I/O functions. Future versions of the MMS will allow multiple levels of privilege to be defined for MMP operations. All applications communicate with the MMS using the MMP. All rights reserved. There is a well-defined subset of the MMP that is used for nonprivileged applications. one that would normally be provided as a standard component of an MMS implementation. and that volume covers the entire user-accessible area of the cartridge. 6. Application development in scripting languages such as Perl may be performed using the MMS User Mount Commands. including the following: Copyright © 2000 IEEE. when written. It is possible to have an installation in which there are no I/O applications.2. A user mount application (UMA) is an another example of a standard application. Many functions that are necessary or helpful in a complete MMS are performed by administrative applications instead of by built-in. A future version of this standard will define a more detailed model for selectively granting access to specific features and capabilities within the MMS. and deallocate volumes.1-2000 6.9. The UMA is necessary because the MMS is not aware of the security requirements. mount.8. administrative applications have no restrictions on the operations they may perform. 6. rather than cartridges. which are physical entities. The UMA allows human users of a computer system to allocate. An overview of the MMP is provided in 7. or a system in which I/O applications are not computer programs. IEEE P1244.7. standardized components.3-2000.10. and deallocate volumes. IEEE P1244. The operations available in the subset are sufficient for applications engaged in common tasks such as data transfer and mounting user media. similar to the POSIX or UNIX super-user. user identity conventions. This model defines two levels of privilege within applications that utilize the MMP: application and administrative. there is only one volume per cartridge.1 User applications A typical application uses MMS services to allocate. such as video or audio tapes or discs. IEEE P1244. Specific interfaces for other programming languages may be defined in the future. These two standards. 23 . Administrative and operator interface applications are also responsible for providing all administrative and operational interfaces that may be required by an installation. unmount. or protection mechanisms of each specific type of computer system or operating system. unmount. the C-Language Procedural Interface. To aid development of applications using the MMP. will define command-language interfaces for user mounting and administrative and operational commands. will define a standard C-language programming interface that simplifies and standardizes the use of the MMP. Administrative applications are given a level of privilege that is analogous to the superuser privilege in POSIX or UNIX systems.2 Administrative applications Applications that are intended to change the parameters or configuration of the MMS are called administrative applications. mount. The MMS itself is concerned with applications. this would be a special case in which the MMS is used to manage non-computer media. These applications can perform essentially all allowable operations within the MMS. as defined in IEEE Std 1244. which are logical containers of information. The additional operators in the full MMP are intended to enable the creation of administrative applications.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.2. and ensures that applications only have control over media associated with the application requesting the media. IEEE P1244. Administrative applications span a wide range of needs. For most current tape technologies. and using the MMS Standard Administrative and Operational Commands.9 (see 4.

this is not recommended. an individual administrative application may accept responsibility for command or may release a request that it had previously accepted.10 (see 4. etc. The operator interface application informs the LM of the action taken via the MMP respond command. The design of the operations allowed for non-privileged applications should make this case highly unlikely. When the requested operation has been completed (or rejected).IEEE Std 1244. The LM for a vault receives an LMP mount requests and in turn generates LMP/L request commands for an operator to perform the necessary physical actions. allows the operator to act on them. accessible to which machines. LMs and DMs may utilize the request command of LMP/L or DMP/L to send a request to a human operator. An operator interface application removes requests from the pending queue.) Monitoring status of devices and media Causing drive cleaning to occur Adding and deleting application access to the MMS Obtaining current system status Prioritizing and/or canceling individual commands and requests Performing inventory.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT a) b) c) d) e) f) g) h) i) j) Operator interface for non-automated libraries (vaults) Operator interface for automated libraries Introduction and removal of media Changing the availability of hardware devices (drives and libraries. up and down.2. 6. . as it would not allow integration of this LM with other LMs in a single operator interaction environment. the administrative application uses the MMP’s respond command to send a response to the requesting DM or LM. Pending requests are held in a queue within the MM.2) will define an Administrative and Operational Command Interface that will be consistent across many different system platforms. and this queue may be examined and manipulated by one or more administrative applications. All rights reserved.3 Operator functions The MMS includes facilities that permit integrated dispatch management of functions that are performed by human operators. particularly of a non-automated library (vault) This list of typical administrative applications is not intended to be complete or comprehensive. and then obtains a response from the operator. 24 Copyright © 2000 IEEE. (one that is not normally accessible to a data transfer application). This interface will be useful for implementing administrative tools using scripting languages. but by doing so it would also grant full access to all privileged operations. IEEE P1244. and the LM can then complete (or refuse) the mount. Utilizing privileged commands in MMP. Although it is possible to write a vault LM that directly interacts with the operator. Accept and release could either occur by program logic or by manual operator selection through an interface provided by the administrative application. A site may grant administrative privilege to a data transfer application to permit this operation. Certain unusual requirements could require that a data transfer application have the ability to perform a privileged operation. One particular case of interest is a non-automated library (or vault).

2. as required. All rights reserved. The following five external policy agents are described in 6. or DM The private (secret) key that is used to authenticate the LM.5. Error and informational message texts may be added to the MMS database.5 External policy agents The MMS depends on administrative applications for some of the functionality of the overall system. and libraries. Their purpose is to allow the MMS supplier or the local site to make decisions about how certain aspects of the MMS operate without requiring changes to the MMS implementation. DM. or Drive The name of the Application Instance (AI). may define other external policy agents. This design goal is met by having a highly extensible set of data that is stored in the internal database.5. Since external policy agents must use the MMP interface. An MMS will function without external policy agents. they may be implemented in a variety of languages. is used to establish a few basic configuration parameters. Network configuration information. which resides outside the data model. This network configuration information includes the following: a) b) c) d) e) The network name (or IP address) of the machine on which the MM resides The name of the MM The name of the Application. Corresponding configuration information is stored in the MM’s internal database.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. Copyright © 2000 IEEE. so it is strongly recommended that this policy agent be present in all sites. LM. Libraries. and DMs. system operation will be cumbersome.1-2000 6. new types of cartridges. These administrative applications are called External Policy Agents. Library.2. 25 . a) b) c) d) e) Cartridge life cycle Drive cleaning support Drive load balancing Task queue management Event aggregation and chargeback MMS developers or local sites. 6.2. However. both to accommodate new equipment and to introduce new languages to the system.5. or application with the MM This standard does not address the method by which this network configuration information is generated or distributed to the individual components. One key design goal of the MMS was to minimize the amount of hard-wired static knowledge in the MMS. drives.1 through 6. each of which have characteristics that would not be known to the MMS beforehand. One or more administrative applications with appropriate internal security controls are used to manipulate the configuration information that is stored in the MM’s internal database. without a cartridge life cycle policy agent. For example. The most important of these are parameters for individual Applications.2.4 Configuration management The MMS has considerable configuration flexibility built into the data model described in this standard. can be defined by an installation.

Actions performed by the cartridge life cycle agent may range from a) b) c) d) Simply set the CARTRIDGE.5. and it only needs to do a mount operation of one of those cartridges to effect a drive cleaning. The DM announces that fact by the addition of a NEEDS_CLEANING attribute on the DRIVECARTRIDGEACCESS record created by the most recent unmount operation.2. 26 Copyright © 2000 IEEE. while another site might choose a policy that makes more intense use of the drives closer to the operator’s station.2.5.3 Drive load balancing The DRIVE. the cartridge is not made immediately available to be reused by another application. One site might choose to implement a drive usage policy that equalizes the amount of head wear across all equivalent drives.CartridgeState field to allocatable to allow the cartridge to be reused.IEEE Std 1244. 6.1 Cartridge life cycle When the last VOLUME is deallocated from a cartridge. but the drive selection policy will be unspecified. set the Erase or degauss the entire cartridge. it is given a default DrivePriority value. Some sites will want to perform special processing on the cartridge before letting it back into the set of unused cartridges.2. When each drive is first created. and then CARTRIDGE. each candidate drive in the system is examined and. The external policy agent may perform any site-specific action that is necessary for those cartridges. and delete the CARTRIDGE from the MMS database. Overwrite the beginning (label portion) of the cartridge. drive selection will occur.CartridgeState field to allocatable to allow the cartridge to be reused. A site might choose a policy that all drives of a particular make/model will be cleaned every 60 hours of use while all other drives will be cleaned when the DM announces that the drive has decided it needs to be cleaned. The policy agent is free to examine any information inside or outside of the MMS and then to set the DRIVE.2 Drive cleaning support The MMS depends on external policy agents in order to support automated drive cleaning. For each set of drives that has the same DrivePriority value.CartridgeState field to allocatable and allow the cartridge to be reused. among all drives that could be used. The intent is that the policy agent will be the owner of all cleaning cartridge in the MMS. This state will be set when the cartridge is owned by an application but does not have any VOLUMES associated with it. the MMS will choose to use the drive that has the lowest-valued DrivePriority field. cartridges will not be reused without operator intervention. crush and burn the cartridge. The policy agent is free to examine any information inside or outside of the MMS and then to decide that a given drive needs cleaning.CartridgeState field has the value recycled. drives will be used in an unspecified order. Eject the cartridge from the library. Note that the policy agent may need to use the WHERE[] clause on the mount command. .5. All rights reserved. When a mount request is being processed. An external policy agent shall query the MMS for all cartridges whose CARTRIDGE. If an external policy agent for cartridge life cycle management is not present. 6.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 6.DrivePriority fields of any or all of the drives to new values.DrivePriority field in all DRIVE objects is intended to be periodically set by an external policy agent as a means of controlling the amount of usage that each drive is subject to in the MMS. If no drive load balancing policy agent is present. and then set the CARTRIDGE.

All rights reserved. cartridges) that are held by the application. and will then take appropriate action. or the system on which the application resides crashes. which specifies the network name or address of the MM. on all TCP connections to active applications. When a resource becomes available. shutdown.5. 6. If the system on which the application is running crashes. When each task is first queued. aggregated statistics allow a site to notice and rectify potential wear and hardware problems. If the application terminates abnormally. and the MMS will select the task that has the lowest-valued TaskPriority field for execution. When an application starts up. the external policy agent may calculate and apportion usage costs based on site-specific formulae.2. The application then contacts the MM using TCP/IP. (The MM is constantly listening for activity.) The MM cleans up any state that is related to the application and releases any resources (drives. or stored in a system registry. the MM will detect this when the TCP connection is closed by the operating system of the application’s computer. it obtains its network configuration. while another site might choose a policy that lets the smallest tasks go first. those tasks will be executed in first-come-first-served order. 27 .2. The application should expect that any media that was mounted on its behalf would be unmounted by the MM. Note that the actions taken by the MM when an application terminates abnormally are identical to the actions it would take if the application unilaterally closed the TCP connection to the MM.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.TaskPriority fields of any or all of the tasks to new values. including a close operation. it might be in a per-application file. The policy agent is free to examine any information inside or outside of the MMS and then to set the TASK. for example. The MMS makes no attempt to enforce any usage limits.2. The delay occurs because the MMS relies on the keep-alive function of the TCP protocol to detect host failure. or the system on which the application resides crashes. and the secret key to be used when communicating with the MM. and abnormal termination Applications are initiated by user actions or by system actions on the computer on which the application executes. The method by which an application obtains its network configuration information is not specified by this standard.1-2000 6. and LMs. it is given a TaskPriority value based on the AI.5 Event aggregation and chargeback The MMS creates a DRIVECARTRIDGEACCESS object each time a cartridge is unmounted. which makes it impossible for the application and MM to communicate with each other.6 Application start-up. the registered name of the application and AI. the MM will detect this after some delay. The MM terminates abnormally. DMs.5. it will only record the actual usage and allow that information to be accessed by an external policy agent. An external policy agent is required to aggregate data on individual accesses to a cartridge or drives. 6. For tasks that have the same TaskPriority value. Those objects contain information on drive and cartridge performance (transfer and error counts). any pending tasks that can now be accommodated will be examined. and disconnects.4 Task queue management The TASK. The keep-alive mechanism indicates a disconnection when periodic keep- Copyright © 2000 IEEE. A network partition occurs. One site might choose to implement a scheduling policy that gives preference to the task that has been waiting longest (this would be the case if no external policy agent was supplied for task queue management). Also. says goodbye.DefaultPriority attribute.TaskPriority field in all TASK objects may be modified by an external policy agent to control the order of execution of tasks that are queued. utilizes the SSAIP and MMP to interact with the MM. The following are three cases that shall be considered: a) b) c) The application terminates abnormally.

and for each stale mount.2. The MMS expects the LM or DM to be restarted by infrastructure on the host.5-2000. the MM repeats this request periodically. All logical mounts are placed into a stale category. The MM will behave in accordance with the rules given above. A network partition that exceeds the keep-alive interval will cause forcible disconnection of the MM and the application. or it may simply notice a read or write failure when it attempts to communicate with the MM via the closed TCP connection. If the DM is unable to do so. the arbitration engine for competing demands on those resources. Short-duration network partitions are not noticed by the MMS.3 Media Manager (MM) At the center of the MMS architecture is the MM. it utilizes stored information about its state prior to the crash.4-2000) Library Manager Protocol (IEEE Std 1244.5-2000) 28 Copyright © 2000 IEEE. or if the machine on which the MM is running crashes. The MM shall have a persistent data store that can represent the information in the MMS Data Model as defined by this standard. as they are handled completely by the use of TCP. and administrators for a computer that runs the MM may wish to consider shortening the keep-alive interval to a period of only a few minutes. The request will eventually succeed when the application closes the drive. which would be the case if the application had the drive open. The application will not be affected in any way. When the MM comes up after a crash. the keep-alive interval may be tuned on a per-system basis. . All rights reserved.3-2000) Drive Manager Protocol (IEEE Std 1244. the MM will take the same actions as it does when an application crashes.IEEE Std 1244.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT alive packets are not acknowledged by the host operating system at the other end of the connection.4-2000 and IEEE Std 1244. Once a failed TCP connection is detected using the keep-alive mechanism. It is safe for the application to continue using the devices it allocated while the MM is down as long as these devices remain open by the application. The application may detect such a failure either by explicitly testing for a closed TCP connection (as the MM does). If the MM terminates abnormally. Note that the duration of the delay between the system crash and the detection of the crash by the MM is determined by the keep-alive interval on the host on which the MM is running. and the coordinator that sequences the operations of all the LMs and DMs in the MMS on behalf of the MMP clients. It is also the access control manager for the resources assigned to the MMS.7 Abnormal termination and restart of LMs and DMs If an LM or a DM abnormally terminates. Typically. placing allocated devices into a stale state and attempting to re-establish communication with the DM associated with each stale device. The MM shall be able to simultaneously support the syntax and semantics of the following three interface protocols: a) b) c) Media Manager Protocol (IEEE Std 1244. and the restarted LM or DM will re-establish connection with the MM. The MM is the central repository for metadata that describes the cartridges. the application may continue running and using the drives and media it was assigned while the MM was running. This process is explained in more detail in IEEE Std 1244. applications. drives. the MM requests that the DM that is associated with the drive attempt to open the drive for exclusive use. and usage history of the MMS. The application will simply disconnect from the MM and go on with its processing. 6. the application is not required to do anything. and this may be a long interval. 6. A network partition is generally considered one of the more difficult cases to handle in a distributed system. libraries.

as defined in IEEE Std 1244. Note that DLT drives are used here only as an example of drives belonging to a family.4-2000.32000). and to implement the operations that the MM asks for. Copyright © 2000 IEEE. The LM accepts those operations on the model and does whatever is needed to make the physical library do as close an approximation to that operation as is possible. of the cartridges. and to implement the operations that the MM asks for. A well-written DM would make the best operational use of all of the available features of the drive. The internal structure of an LM or DM is not visible to the MM. The job of a DM is to represent the capabilities of a drive to the MM. given the constraints of the drive’s capabilities.1-2000 An MM that can support the syntax and semantics of the MMP but cannot support the DMP and LMP protocols may be said to partially conform to this standard. The DM accepts those operations on the model and does whatever is needed to make the physical drive perform as close an approximation to operations as possible. Overviews of the LMP and DMP are provided in the paragraphs that follow. an LM or DM may be created to manage one of a family of similar devices. in terms defined by the LMP library model.5-2000. but it can also initiate operations that the MM must fulfill. Likewise. while a different DM might be required to handle a DLT7000 drive. The relationship between an LM or a DM and the MM is completely defined in their respective protocols. as defined in IEEE Std 1244. while a different LM might be required to handle that same company’s 240 slot automated library. Both protocols define the relationship to be much more of a peer-to-peer style than a master-slave style. in terms defined by the DMP drive model. providing as much value as possible to the local systems administration staff. The DMP defines an abstract model of a drive and then defines operations on that model. In order to accommodate the wide diversity of libraries and drives.4 Library Managers (LMs) and Drive Managers (DMs) The MMS makes use of one or more programs whose purpose is to manage a library or a drive on behalf of the MM. The LM must generate a description. The LMP also defines how the library and its contents are represented to the MM. An LM communicates with the MM via the LMP. of all the capabilities of the drive in order for the MM to know how this drive and its capabilities relate to the cartridges managed by the MM. providing as much value as possible to the local systems’ administration staff. The DM must generate a description. a single DM could be written to handle both a DLT2000 and a DLT4000 drive. given the constraints of the library’s structure. a unique LM or DM may be created for each make and model of library or drive. Such an MM would be a monolithic product with embedded LMs and DMs.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. These programs are intended to be relatively small and simple to create. A well-written LM would make the best operational use of all of the available features of the library. and storage locations contained in the library. The DMP also defines how the drive and its capabilities or characteristics are represented to the MM. As another example. a single LM could be written to handle both the 40 slot and the 80 slot models of a given company’s automated library. The LM or DM has the responsibility of implementing the MM’s commands. The job of an LM is to represent the capabilities and contents of a library to the MM. A DM communicates with the MM via the DMP. drives. For example. it would only support applications that conform to the MMP (IEEE Std 1244. All rights reserved. 6. nor is it relevant to the MMS as long as it abides by the protocol definition when it interacts with the MM. 29 . The LMP defines an abstract model of a library and then defines operations on that model.

smtp. and abnormal termination In general. in a few cases noted in the specification.) The specific sequence of operations that describes what an LM or DM does during start-up is detailed in the standards for LMs and DMs. an application can instruct the MM to make comparisons of strings based on a number of relational string comparison operators. an MMS drive or LM process should be started whenever the system on which the process runs on boots up. arguments to the clause). as all code that performs multicharacter-set comparisons resides in the MM. In some cases the strings must be of a particular format as specified in 10. and DMP) all have a common style. As the MMS evolves. All commands in these protocols use a single token as the command name.4. and there are common syntactic constructs. 30 Copyright © 2000 IEEE. rather than a simple command structure. have a set of clauses that follow the command. LMP. 7.1 Manager start-up. because the information being transferred across the MMS application-layer protocols is more complex than the information typically transferred using standard Internet protocols. may include subsidiary tokens and/or strings (for example. Note that starting an MMS process does not imply that the process will become active. Note that there are no architectural requirements that the three protocols use the same style.1 Language style The three languages (MMP. rather than a binary-encoded RPC paradigm. that process should be restarted as soon as possible. the clauses may be given in any order. Each clause begins with a reserved token and. but at present they are uniform in style. running over TCP/IP. the only operations performed on strings within the LMP or DMP are tests of equality and inequality with another string. This common language style greatly simplifies the internationalization of string handling. all three languages are text based and human readable. The interfaces are session-oriented.4. and nntp. ftp.4. one protocol might be changed to a different style—binary remote procedure call or XML-based. such as telnet. . shutdown. Using the MMP. using character-based encoding similar to well-known Internet protocols. The protocols are defined in a command-response manner. Typically. 7. the only operation that the MM will perform on a string is a test of byte-for-byte equality/inequality with another string. 6. and a statement terminator. All rights reserved. This structure was chosen as a compromise between human readability and computer efficiency.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 6. MMS protocols are defined in terms of a formal. phrase-structured language. Without a request for a relational comparison from an application. Protocols The interfaces between the major components of the MMS are defined as application-layer communication protocols. The only data type supported by these protocols is a string. (Consider libraries and drives that may be accessed by multiple hosts. each LM or DM is required to close its connection to the MMS and begin a new session. Similarly. for example—while the others remain in the current style. Should a manager process terminate or be terminated. clauses are executed sequentially and thus the order does make a difference. depending on the clause. and the TCP/IP connection is opened once and kept open throughout the session.2 Effect of abnormal termination and restart of system components on managers If the MM abnormally terminates.IEEE Std 1244.

Backus. All strings are quoted and all unquoted tokens must be literally defined in the protocol definition. In this example. W. These notations may be combined and used with standard BNF syntax. The meta-symbols of BNF8 are listed in Table 2. “The syntax and semantics of the proposed international algebraic language of the Zürich ACM-GAMM conference. Table 2—Meta-symbols of Backus-Naur Form (BNF) ::= | <> meaning “is defined as” meaning “or” angle brackets used to surround category names The angle brackets distinguish syntax rules names (also called nonterminal symbols) from terminal symbols. Additional operators have been defined to allow these constraints to be expressed. A BNF rule defining a nonterminal has the following form: nonterminal ::= sequence_of_alternatives consisting of strings of terminals or nonterminals separated by the meta-symbol | For example. and to. 31 . from. which are written exactly as they are to be represented. clauses can occur in any order. the BNF production for a mini-language is as follows: <program> ::= program <declaration_sequence> begin <statements_sequence> end . the move command is followed by three clauses: task. All rights reserved. for example: 8J. 7. A traditional BNF definition of the syntax of the MMS protocols is not capable of conveniently representing the fact that. Paris. Copyright © 2000 IEEE.1-2000 Here is an example. The extended BNF used in these standards adds constructs to standard BNF shown in Table 3. drawn from the LMP. where the reserved tokens and syntactic elements are shown in bold font and the string values are shown in italics: move task["226"] from["slot 12" "AB1234"] to["slot 14"] .SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.2 Language descriptions: extended BNF The IEEE MMS suite of standards use a modified version of Backus-Naur Form (BNF) to describe the syntax of languages. June 1959.” in Proceedings of the International Conference on Information Processing (ICIP). the keyword begin and the statements sequence. but there can be only one occurrence of that clause in the command. This example shows that a mini-language program consists of the keyword program followed by the declaration sequence. and finally the keyword end and a semicolon. in some cases.

b c a. Note that this definition of curly braces differs from the definition of these symbols in other extended BNF versions. One or more of a. b a c. e. <clauseY>. so this sequencing applies to both directions simultaneously. 7. possibly after many other commands have been sent. whereas the permutation operator is curly braces “{ }”.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Table 3—Extended BNF Symbols Representation [ a ] { a b c } Name Optional Permutation Zero or one of a. DMP.4. a response to the initial command will be received. Represents the components a b and c in any order. or nothing. All rights reserved. but the protocol definition allows the receiver to do so if necessary. it is checked for syntax errors and an acknowledgment is sent back. After each command is received at the other end. . At some point in the future. a b c. Zero or more of a. another command can be sent. and LMP all use a three-phase message sequencing style. <anothercommand> ::= action [ <clauseX> | <clauseY> ] defines <anothercommand> as the keyword action followed by a clause that could be <clauseX>. The receiver of a command is free to delay sending an acknowledgment if necessary. This sequencing style allows asynchronous execution of commands and receiver-controlled throttling of incoming command traffic. zero or more <clause2>. a c b. c a b. in any order. but an acknowledgment must be received for each command before the next one can be sent.1. Once the acknowledgment is received.. Restricting the sending of new commands in this way permits the implementer of a component to simplify the receiving code so that it 32 Copyright © 2000 IEEE. The receiver is not required to actually process those commands in parallel. Each of the three protocols is bi-directional.IEEE Std 1244. This can be used to control the rate at which the other end of the connection is generating commands. Note that the grouping operator is ordinary parentheses “( )”. Please refer to examples of message sequencing that are present in the examples of 4. The key here is that multiple commands can be sent without waiting for a response.g. as a new command may not be sent out until the acknowledgment of the prior command has been received. exactly one <clause1>. Commands are labeled with a TaskID. The fact that the acknowledgment of receipt is separate from the response to a command allows multiple commands to be outstanding at any instant.) The response will be labeled with the unique TaskID that was used when the original command was sent. Description ( a b ) Grouping a* a+ Repetition Repetition <mycommand> ::= verb { <clause1> <clause2>* <clause3>+ } defines <mycommand> to consist of the keyword verb followed by. (No response will occur if the original command was negatively acknowledged. Group the enclosed syntactic elements as a unit. or c b a. typically used with the or operator “|” and the repetition operators “*” and “+”.3 Message sequencing within protocols The MMP. and one or more <clause3>. The description below details how the sequencing works without reference to a particular protocol or a particular direction.

or to control resource loading in the receiver. language-independent manner. including tokens that represent the meaning of the message in a unique. but it is not required.5 Internationalization The MMS includes features that allow relatively easy localization (internationalization) of user-visible messages. the corresponding message catalog should be installed in the central message catalog.2/D041900. b) c) d) e) The defined tokens and syntactic elements in each protocol have been chosen from the US-ASCII subset. further details on SSAIP are found in IEEE P1244. and a vector of argument words that may be substituted in any order into a localized message for display to a human user. These strings are embedded in relevant parts of the IEEE MMS suite. Copyright © 2000 IEEE. language}. is the key to the localization of messages. so that in the event that a component of the system is upgraded and a language catalog has not been provided for that component in the desired language. including LMs and DMs. Failure to heed this restriction could result in deadlock. client. 7.1 shows how a session is initially established using SSAIP. The keys are tuples consisting of {host. Status messages are exchanged in a stylized format.1. The socket input buffers cannot be allowed to fill up while the process is waiting to send data out the socket. and incoming commands must be processed even though the process is waiting on a response from the other end. All rights reserved. instance. Each system component. yet permits the inclusion of all Unicode characters. The following features are provided to readily permit localization: a) All communication between MMS components utilizes the ISO-10646 character set (Unicode) encoded in UTF-8 character representation. a meaningful message can still be produced. which is part of the MM. These keys are used during the initial SSAIP authentication handshake. while the values contained in uninterpreted strings can be chosen from the full ISO-10646 character set (Unicode) encoded in UTF-8 character set. may add new messages in one or more languages to the central message catalog.4. In order to avoid a deadlock. This allows Western character sets to be represented in a compact manner. The central message catalog. English-language strings are defined for all messages.4 Security and authentication Each computer system that is a part of the MMS has a protected file or its equivalent that contains keys used for authentication. Centralized message catalogs are managed within the MM to allow different language localization to occur for different users of a single system.1-2000 does not need to actually support the asynchronous execution of commands.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. 33 . Implementers are encouraged to use this English-language text in their implementations. When a new LM or DM is installed. For messages that are a part of the IEEE MMS suite. 7. The example in 4. Text in an implementation-defined default language may be propagated along with individual messages. each end of the communications channel must be prepared to accept input from the channel without regard to whether it is waiting on a response or an acknowledgment from the other end—TCP throttling must not be used to control generation of new commands.

an affirmative response is sent to the client. Internationalization of localized messages is centralized in the MM. through the use of message catalogs.5. A message format string in the message catalog for the English version of this message might look as follows: The cartridge $pcl$ in slot $slot$ bay $bay$ is stuck.5. When a message format string is interpreted. All rights reserved. The tags may be in different orders in different languages. tags are defined using alphanumeric strings surrounded by dollar signs (e.g. See IETF RFC 1766-1995. Substitution of words within the message format string is performed using a tag construct. the tags refer to message arguments. a particular MM may or may not support sorting in a requested locale. and ISO 3166:1993. The following is a sample message in English: The cartridge AB9278 in slot 12 bay 4 is stuck. 34 Copyright © 2000 IEEE. an error response is returned. the message catalog is consulted to produce a version of the message in the language(s) requested by the Application using the locale command. If the MM has no messages stored in the requested language. Within the message format string. it must be escaped using a backslash character (\$).1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 7. 7. A client of the MM may request a change of language localization on a given connection using the localize command: localize locale['FR'] Multiple languages may also be requested: localize locale['FR' 'EN'] sort['UK'] If the MM has at least one message format stored in the requested language. The message format string consists of text plus a number of embedded tags.IEEE Std 1244. and the message format string is stored in multiple languages in the message catalog. $pcl$ or $drive2$).. .2 Localized messages The MMS includes a comprehensive scheme that allows system components to be developed in a local language. If it is desired to include a dollar sign in the message format string. When a message passes through the MM from an LM or DM to an Application. ISO 639:1988. A message format string describes each message. and for messages from that component to be readily translated to and displayed in a language appropriate to the site of an installed system. these tags are removed and replaced with values of the corresponding name-value attribute pair from the args clause. The two-character language identifier is selected using standard identifiers.1 Language selection The default language selection within the MM for a given installation is configurable. The sort clause of the localize command may also be used to select the sort order (character collating sequence) of certain operations: localize sort['FR'] Sort localization may not be supported by all MM implementations.

Taken together. A code that uniquely identifies the message within the message catalog. and the message catalog contained a message with the token cartridge_stuck in the language DE.e.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. If the message is defined in the IEEE MMS suite of standards.). the manufacturer identifier and model identifier are used to identify a message catalog. or the LM or DM may choose to not supply a loctext clause. care must be taken to ensure that non vendor-specific program logic rely only on IEEE 1244 defined message codes. Zero or more occurrences of the loctext clause may be present in a message clause. All rights reserved. The manufacturer defines the model identifier. 35 . the manufacturer identifier. Message versioning may be accomplished by either never reusing message identifiers and extending an existing message catalog. 9710. nor are they visible to any component of the MMS other than the MM.1-2000 If the MM was communicating with a client that had requested German (DE) localization of messages. and message ID (cartridge_stuck) uniquely identify the message in the catalog as follows: a) The manufacturer identifier identifies the organization that defines the message. and code uniquely identify the exact error condition and the particular message associated with this condition. When the MM produces the German message. The loctext clause contains fully localized. Messages are represented using the following message clause: message[ id['stk' '9710' 'cartridge_stuck'] arguments['slot' '12' 'bay' '4' 'pcl' 'AB9278'] ] Note that message format strings exist only in the message catalog. 9710a. Taken together. Die Bildplatte $pcl$ in dieser Position konnte nicht entfernt werden. The manufacturer identifier (stk). b) c) If it is necessary for program logic to take action based on a specific message. The optional arguments clause consists of tag-value pairs. or establishing a message catalog with a new catalog identifier (i. bay. the tags in this example are slot. the model shall be 1244. Notice that the keys in the German message are in a different order than in the English message. clear-text versions of a message. the stored format might be Es existiert ein Problem in Position $slot$/$bay$. Die Bildplatte AB9278 in dieser Position konnte nicht entfernt werden.. and pcl. model. The message originator (DM or LM) may supply a text clause in any desired language(s). etc. Manufacturer identifiers must be registered with the IEEE to ensure uniqueness. A manufacturer may choose to have one or more message catalogs to aid in software maintenance and distribution. If the message is defined in the IEEE MMS suite of standards. The MM will add and/or replace loctext clauses in the message with the language(s) requested by the application via the locale command to the message as it passes through the MM. Copyright © 2000 IEEE. it would be: Es existiert ein Problem in Position 12/4. which is managed by the MM—they are not transmitted as part of any language. the manufacturer identifier shall be ieee. catalog (9710). 9710b.

such as drives or small libraries.5. These messages may or may not be intended for eventual human use. b) c) The response command is defined as follows: <response-message> ::= "response" { <negative-response> | <accepted-response> | <command-response> } ". or error if the command terminated abnormally." <negative-response> ::= { "unacceptable" [ <message-clause> ] } <accepted-response> ::= { <task-clause> "accepted"} <command-response> ::= { <task-identifier> <final-response> [ <message-clause> ] } <final-response> ::= <response-success> | 36 Copyright © 2000 IEEE. this is the unacceptable response message. cancelled if a command was cancelled using the cancel command. To accept a command for processing—This is the accepted response message. the loctext clause may be omitted for messages that originate on hardware devices with limited resources.3 Response messages Response messages may be generated by any MMS component and passed to other MMS components. If the message originator generates only an id and arguments.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT message[ id['stk' '9710' 'cartridge_stuck'] arguments['slot' '12' 'bay' '4' 'pcl' 'AB9278'] loctext['EN' 'The cartridge AB9278 in slot 12 bay 4 is stuck. Response messages may occur a) To reject command input—This is typically because the input string cannot be parsed. To transmit the result of a command—This may be success in the case of a successful command completion. then it is essential that the language catalog loaded into the MM include the specified message. All rights reserved. or translation into a human-readable form will not be performed.IEEE Std 1244. '] ] Most LMs and DMs should include a formatted message (loctext) in a default language. . <message-clause> ::= "message" "[" { <id-clause> "[" <arg-clause> "]" <locale-text-clause>* } "]" <id-clause> ::= "id" "[" <manufacturer> <model> <messageid> "]" <arg-clause> ::= "arguments" "[" <arg-pair>+ "]" <arg-pair> ::= <arg-key> <arg-text> <locale-text-clause> ::= "loctext" "[" <language> <localized-string> "]" 7. or because input was received before acknowledgment of a prior command.

1-2000 <response-cancelled> | <response-error> <response-success> ::= { "success" <response-text>* } <response-cancelled> ::= "cancelled" <response-text> ::= text "[" <text-string>+ "]" <task-clause> ::= task "[" <task-identifier> "]" <response-error> ::= error "[" <class> <code> "]" Class and code are tokens that are defined in the MMP. If the command is syntactically correct.7 Overview of MMP The IEEE MMS MMP is the language that MMS client and administrative programs use to communicate with the MM. A is then free to send further commands to B. All rights reserved. such as language and language type. authentication of the client. 7. The MM manages media and provides access to media when requested.6 Overview of SSAIP The IEEE SSAIP is used by the IEEE MM when an MMS Client or an MMS Module wishes to connect to the MM. B sends an accepted response to A. If the command is syntactically incorrect or must be rejected immediately. If the command completes successfully. A is then free to send further commands to B. The SSAIP also establishes parameters of the communications between the MMS Client and the MMS Module thereafter. B sends an unacceptable response to A. and if desired. If the command is syntactically correct. The SSAIP provides identification. d) 7. B sends a success reply to A.4 Command sequencing The normal sequence of events when system component A sends a command to system component B is as follows: a) b) c) A sends the command to B. 37 . B must abort processing of the command.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. LMP. B sends a cancelled response to A. A message-clause should be present in any response message that might be intended for eventual human consumption. These tokens are intended for machine processing of a response message in a standardized manner. which is a requirement to obtain access to the services of the MM in compliance with the MMS security model.2/D041900 defines SSAIP. but before accepting the command. B sends an error reply to A. The MMP language provides capabilities in the following areas: Copyright © 2000 IEEE. An example of operation of the SSAIP is given in 4.4.1. and DMP. IEEE P1244. If the command fails to complete.5. 7.

4. which includes commands from the MM to the DM. eject*.IEEE Std 1244. message.8 Overview of DMP The DMP is the language that the MM uses to communicate with DMs. privilege. Operator Interaction functions for operations personnel to perform routine tasks. shutdown* Data Management: attribute. respond*. activate.4. locale. rename Session Management: hello. inject* An example of operation of the MMP is given in 4. The DMP defines the abstraction that the MMS utilizes for drive configuration and control. 38 Copyright © 2000 IEEE. The LMP defines the abstraction that the MMS utilizes for Library configuration and control. This common Library interface is used for all Libraries in the MMS. At the time this standard was published. and for applications to view and modify meta-data associated with the media. IEEE Std 1244.1. All rights reserved. Interface uniformity at the drive level allows for the simple addition of new managed drives without the necessity of re-compilation of any modules in the MM. unmount. allocate. delete* Device Management: cpattribute*. mount. Device Management functions for the control of devices. the DMP included the following commands: a) b) DMP/M: attach. end. load. private A brief example of operation of the DMP is given in 4. cancel DMP/D: config.1. and DMP/D. ready. At the time this standard was published. System Management functions for tuning the operation of the MM. reset. exit. Interface uniformity at the Library level allows for the simple addition of new managed Libraries without the necessity of re-compilation of any modules in the MM. cpshow*.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT a) b) c) d) e) f) Media Management functions for principals (applications) of the MMS to access and manage removable media. show. private. DMP consists of two languages: DMP/M. deallocate. which includes commands from the DM to the MM. This common drive interface is used for all drives in the MMS. create*. unload. 7. release*.3-2000 defines the MMP. move*. an asterisk (*) indicates that a command is privileged: — — — — — — Media Management: begin. goodbye Task Management: cancel. cpscan* Operator Interface: accept*. cpreset*. . 7.9 Overview of LMP The LMP is the language that the MM uses to communicate with LMs. detach.4-2000 defines the DMP. The IEEE Std 1244. the MMP included the following commands. Task Management functions for applications to control the system and the environment in which they operate. Data Management functions for implementing administrative-level capabilities.

scan. 7. ready. openport. etc. The MMCIP consists of a set of back-end database and control operations that the MMS will use to store common metadata information and to perform physical operations on cartridges that are managed by the external MM. both physical and logical. This standard defines the required components of the data model. private. which includes commands from the LM to the MM. move. 9. such as media management services running on an IBM mainframe. Unregistered tokens must use a prefix (e. Tokens The current. exit. the LMP included the following commands: a) b) LMP/M: mount. IEEE P1244.1.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. and LMP/L. 8. The metadata is extracted in a portable manner and may be sent by e-mail or by using magnetic media.6 will define the MMIP. which is operated by the IEEE Storage System Standards Committee (SSSC).org. IEEE P1244.g. which represents the tokens in existence at the time of publication of the standard.4. reset. If a new token is needed. A list of tokens is given in Clause 20. which can be sent along with the physical media. official registry of tokens is maintained on the Web site http://www. To register a token or a prefix. Copyright © 2000 IEEE. IEEE Std 1244. Possible choices for a particular implementation of the MMS might include an in-memory database. barrier. activate. but it does not require a particular implementation of the data model. wear. 39 . unmount.11 Overview of MMCIP The Media Manager Control Interface Protocol (MMCIP) defines a mechanism that allows an external MM. 7. to remain with media when it is moved from the control of one MMS to another. see the instructions on the Web site. At the time this standard was published. It is strongly encouraged that a new token be created only if the existing tokens. which includes commands from the MM to the LM.ieee-sssc. such as a floppy disk. relate to one another. All rights reserved. including what essential information is store.) that is registered. SGI_.1-2000 LMP consists of two languages: LMP/M. and how different components. it can be either unregistered or registered. or a grouping of them. private..10 Overview of MMIP The Media Manager Interchange Protocol (MMIP) defines a scheme for moving all metadata associated with one or more volumes and cartridges from one MM to another. SUN_.5-2000 defines the LMP.7 will define the MMCIP. cancel A brief example of operation of the LMP is given in 4. do not adequately cover the desired semantic. such as usage. cancel LMP/L: message. config. The MMIP allows critical life cycle information. Data model—introduction The data model defines the inner workings of the MMS. to be used to manage media in conjunction with an IEEE MMS. and error data.

This scheme correlates well with the relational model. for some tables. Related to libraries. Each row contains one data object—a tuple that describes a number of attributes that are part of that object. one particular model of tape drive may wish to store a value called “magnetic_flux_field” for each cartridge that it has written. and the semantics as described in this standard. would not be present for non-Acme cartridges. the Acme tape company. The MMS data model extends the standard relational model by allowing. DMCAPABILITYGROUP. DRIVEGROUPAPPLICATION. DM. DMCAPABILITYGROUPTOKEN Types of objects in that cluster Related to the definition and authorization of client programs. which are denoted by languages with names different from the standard IEEE language names. generally defined and updated by an LM. These user-defined attributes are one of the primary extension mechanisms within the MMS.1 Clusters and objects The 40 different types of objects that an MMS supports are subdivided into 8 different clusters of related objects. the data types. their names. SLOTCONFIG. Any such extensions shall not affect the standardized functioning of standard IEEE languages that are supported by an implementation. The manufacturer of this product. however. This standard specifies both an abstract model. LM. All rights reserved. BAY. An object may have both required and optional attributes. 40 Copyright © 2000 IEEE.IEEE Std 1244. DRIVEGROUP. there must be agreement on the objects. User-defined attributes need not be present for all rows in a table. generally defined and updated by a DM. The data model consists of a number of objects. AI LIBRARY. DMBITFORMAT. The internal representation of the attributes is not specified by this standard. The data types specified for the attributes of the objects constrain only the external representation of those attributes. Individual implementations may also need to add attributes to the data model. each object having a collection of attributes. as well as those parts of a concrete implementation of that model that are thought necessary to be standardized so that different components of the MMS may communicate with each other. and then place a value for this column in the tape cartridges that were written by Acme’s tape drive. Related to drives. DMBITFORMATTOKEN. In order for implementations of different components of the MMS from different vendors to communicate with each other. where each table has a number of columns and rows. Extensions to interface languages. DMCAPABILITY. DMCAPABILITYDEFAULTTOKEN.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT flat files. the attributes. SLOT. however. This column. 9. such additional attributes shall not affect the standardized functioning of the interfaces. For example. may require extensions to the data model. The clusters are summarized in Table 4. . could define a column as “_acme_magnetic_flux_field”. the addition of new attributes to a given object. SLOTGROUP. DMCABILITYTOKEN. SLOTTYPE DRIVE. Table 4—Clusters of objects an MMS supports Cluster name Application cluster Library cluster Drive cluster Object names APPLICATION. The clusters closely match the intuitively distinct pieces of an MMS. and a relational database.

Related to commands currently blocked and waiting for resources. 41 . then those two objects are unrelated. MOUNTLOGICAL. PARTITION. Session cluster Mount cluster Related to currently connected and/or active clients. REQUEST. Another way to say it is that the clusters have relationships to each other that are not dependent on any specified objects in those two clusters. Table 5 reveals the relationships of clusters of objects. All rights reserved.1-2000 Table 4—Clusters of objects an MMS supports (continued) Cluster name Cartridge cluster Object names CARTRIDGE.. CARTRIDGETYPE CONNECTION. Cluster names are shown in bold on a left-to-right descending diagonal (e. DRIVECARTRIDGEACCESS TASK. SIDE. Each successive cluster being considered effectively adds more layers of filtering (exclusion) on top of the restrictions that were there before. Related to currently mounted volumes and cartridges. SYSTEM. TASKCARTRIDGE. Given two objects. Task cluster System cluster 9. if the specified condition is not true. VOLUME.2 Relationships between clusters The relationship between any two objects in any two clusters is defined to be the same as any other two objects in those same clusters. STALEHANDLE Types of objects in that cluster Related to cartridges and what they contain. Related to system configuration. SESSION MOUNTPHYSICAL. When more than two clusters are discussed at the same time. The relationships can best be expressed as restrictions on the possible combinations of objects.g. the overall relationships are simply the sum of the relationships between each of the distinct pairs of clusters. “Application”). CARTRIDGEGROUPAPPLICATION. Copyright © 2000 IEEE. TASKDRIVE.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. TASKLIBRARY MESSAGE. CARTRIDGEGROUP.

. Cartridge is in the drive. Cartridge is being used in the session. Application submitted the command that started the task. Drive is being used by this mount. Application may use the drive. Drive is involved in executing the task. Drive is being used in the session. Application has a volume in or may allocate a volume in the cartridge. Session has caused this task to be performed. Drive Cartridge Session Mount Configuration 42 Copyright © 2000 IEEE. Library contains the cartridge. Library is involved in executing the task. All rights reserved. Application caused the mount. Application is being used in the session. Library is being used by the session. Cartridge is involved in executing the task. The task involves this mount.IEEE Std 1244.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Table 5—Relationships of clusters of objects Application may use a cartridge or drive in the library. Task Application Library Library contains the drive. Mount occurred on a drive in the library. Cartridge is being used by this mount. Session has caused this mount.

1-2000 Figure 2 illustrates the relationship between objects in the application cluster and the cartridge cluster. Figure 2—Relationship between objects in the application cluster and the cartridge cluster Copyright © 2000 IEEE. Each CartridgeGroupApplication (CartGroupApp) grants one application access to media in one CartridgeGroup (CartGroup). A volume is mapped to one partition on one side of a cartridge. Applications may be granted access to multiple CartridgeGroups. Sides contain one or more partitions. Cartridges contain one or more sides. Each cartridge belongs to only one CartridgeGroup at any point in time. Multiple applications may be granted access to the same CartridgeGroup.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. All rights reserved. 43 . CartridgeGroupApp A-A grants Application A access to media in CartridgeGroup A.

e.. Table 6—Types of objects in an MMS Object name APPLICATION AI LIBRARY LM BAY Authorized client programs Authorized instances of client programs Automated robots or manual vaults Library Control Programs Regions with a LIBRARY Description 44 Copyright © 2000 IEEE.g.ApplicationName. The following naming conventions apply: a) b) c) All names are case sensitive. . Each DriveGroupApplication (DriveGroupApp) grants one application access to drives in one DriveGroup..AttributeName.ApplicationName. the list of all names in the format. The name of an attribute of an object is of the form OBJECTNAME. Attribute names are mixed case. In this standard. These represent abstractions of physical or logical objects used in the MMS. Applications may be granted access to multiple DriveGroups. Each drive belongs to only one DriveGroup at any point in time. All rights reserved. APPLICATION. Multiple applications may be granted access to the same DriveGroup Figure 3—Relationship between applications and drives 9.3 Data object list Table 6 lists the different types of objects in an MMS.AttributeName may also be used to refer to the list of all the names in a category.IEEE Std 1244.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Figure 3 illustrates the relationship between applications and drives. All Object names are all upper case. a name of the form OBJECTNAME. e.g. APPLICATION.

.g.1-2000 Table 6—Types of objects in an MMS (continued) Object name SLOT SLOTCONFIG SLOTGROUP SLOTTYPE DRIVE DRIVEGROUP DRIVEGROUPAPPLICATION DM DMBITFORMAT DMBITFORMATTOKEN DMCAPABILITY DMCAPABILITYTOKEN DMCAPABILITYDEFAULTTOKEN DMCAPABILITYGROUP DMCAPABILITYGROUPTOKEN CARTRIDGE CARTRIDGEGROUP CARTRIDGEGROUPAPPLICATION CARTRIDGETYPE SIDE PARTITION VOLUME MOUNTPHYSICAL MOUNTLOGICAL DRIVECARTRIDGEACCESS CONNECTION SESSION TASK TASKCARTRIDGE Description Single storage locations within a BAY Summary counts of used/free slots in a LIBRARY Groups slots in order to represent ports or magazines within a library Valid physical shapes of SLOTs Devices to access the contents of a CARTRIDGE Groups of DRIVEs Linkages giving APPLICATIONs access to DRIVEGROUPs Drive Control Programs Named bit encodings that the DRIVE can support Tokens representing the capabilities required for the DRIVE to support a particular bitformat Named configuration modes that the DRIVE can support Tokens representing capabilities a DRIVE can support in a particular mode Tokens representing installation-specified default characteristics to be used for a DRIVE Named groups of capability tokens that the DRIVE can support Tokens in each capability group and whether it is the default for that group or not Removable media Groups of CARTRIDGEs Linkages giving APPLICATIONs access to CARTRIDGEGROUPs Valid types of CARTRIDGEs CARTRIDGEs may have more than one SIDE (e. All rights reserved. 45 .SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. magnetooptical disks) SIDEs may be divided into separately allocatable pieces Allocated PARTITIONs have APPLICATION-dependent names Currently mounted CARTRIDGEs Currently mounted VOLUMEs on the currently mounted CARTRIDGEs History of cartridges mounted in drives and error stats for each cartridge Currently connected clients Incompleted client contexts (may live beyond the life of the CONNECTION) Commands that are currently blocked waiting for resources CARTRIDGEs that might satisfy a blocked TASK Copyright © 2000 IEEE.

Subclause 10. attribute types. For example. 46 Copyright © 2000 IEEE. 10. 10. the libraries that contain those volumes. and the drives in which those volumes are currently mounted. An administrative application can create objects and modify the control attributes of any object. the application can view objects owned by this application or objects containing objects owned by this application. At this privilege level.2 Attribute types An attribute of an object must be of at least one of the following types: — Characteristic — Control — Status — Client In addition. which is essentially omnipotent. and data types This clause describes the privilege levels and the different attribute types and their relationships.2 refer to terms that are defined in both clauses.4 defines the external representation of the data. and delete system objects and attributes. All rights reserved. In general. Subclause 4. administrative applications attend to the operation of the MMS as a whole. certain attributes may be designated as key attributes.1 Application privilege levels There are two privilege levels for an application: standard and administrative. modification. create.3. and may perform operations on behalf of one or more applications. or deletion of some client attributes of certain objects. An administrative application has the administrative privilege level. All ordinary applications have the standard privilege level. The first allows a subset of the operations of the second. Privilege levels.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Table 6—Types of objects in an MMS (continued) Object name TASKDRIVE TASKLIBRARY MESSAGE REQUEST SYSTEM STALEHANDLE Description DRIVEs that might satisfy a blocked TASK LIBRARYs that might satisfy a blocked TASK Operational and error messages outputted by components pieces of the system Currently unsatisfied operator interactions Global configuration options for the system Mount handles allocated and in use when a DM crashed 10. This level of privilege allows only the creation.IEEE Std 1244. as noted in the description of those attributes. . and the results are summarized in 4.1 and subclause 10. The system itself has the system privilege level. It has the authority to modify. volumes owned by this application.

while in other instances the administrative level is required. Controls of this type are necessary to maintain database integrity. and must be specified when the object is created. If a characteristic attribute depends on another object.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. Neither the application that caused the mount nor any administrative application has any direct control over this object. and perhaps can also relate it to other objects. they may not be changed directly by an administrative application.*" indicates that an object will accept additional attributes beyond those that the standard has defined. These attributes may be changed.2. as described in 10. a CARTRIDGE has as one of its attributes CartridgeTypeName. whenever a volume is mounted. but not all characteristic attributes are key attributes. 47 .2 through 10. An administrative application may change control attributes by modifying the database or giving a command that causes the database to be modified. Since. 10. All rights reserved. The attributes of these objects are all status attributes. Except in the possible case of fixing corrupted data.2. 10. it depends on the CARTRIDGETYPE object. For example.5 Key attributes Key attributes constitute the minimal set of attributes of an object that defines it uniquely and that must be specified when an object is created. Key attributes are always characteristic attributes.1-2000 10. 10. are created automatically by the system usually for the purpose of monitoring activity. There are no commands directly to the database that may be used to create or delete an object of this type.3 Status attributes Status attributes represent the changing state of the object. Copyright © 2000 IEEE. It is deleted when that volume is dismounted.4 Client attributes Client attributes are essentially arbitrary attributes. then some instance of the other object must exist and have an attribute of the same attribute name and value. there must first be an instance of that object with a matching CartridgeTypeName before the CARTRIDGE may be created.2 Control attributes Control attributes define the behavior of the object.2. For example. The notation ". called status objects. 10.1 Characteristic attributes Characteristic attributes define the object.2. A control attribute assumes the default value when the object is created.2. This is a characteristic attribute and must be supplied when the CARTRIDGE object is created. Some objects. however. and are set by the system as a side effect of some operation.2. In some instances.5. Some client attributes are defined in this standard.2. they may be created and modified by an application that has the standard privilege level. an instance of the MOUNTLOGICAL object is created. such as mounting a cartridge. together with its attributes.

The attribute contains either "true" or "false". and DMP. The attribute may be one of a fixed number of values. The external representations are found in the messages of the MMP.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 10. without the quotes. The strings can contain null-characters as values that will not be interpreted as termination symbols and that must be escaped with the "\0" representation. Some of the strings are required to have a special format. Table 8—Formats for strings Data type String Description The attribute contains an uninterpreted non-zero length value. It is expected that counter values will exceed 231 or 232. There are no restrictions on the contents or internal structure of the value (within the defined character set of the system). The attribute contains a pattern of the form "[+-][0123456789][0123456789]*". In the attribute descriptions that follow. . All rights reserved. LMP. Table 8 describes the different formats for the strings. This attribute is case sensitive.IEEE Std 1244. Note that integers are represented as strings. Integer Boolean Enumerated 48 Copyright © 2000 IEEE. and thus the maximum precision required is not defined. so implementers must ensure that integer computations permit values larger than 32 bits. which in turn represent UNICODE characters. If the attribute is set to anything other than "true".4 Data types All attributes are externally represented as UTF-8 strings. without the quotes. the specific values will be specified. Table 7—Privileges and attribute types Privilege Application Administrative System Visible object types Those owned by the application All All Creation Some client attributes Any non-system object Any system object Deletion Some client attributes Any non-system object Any system object Modification Client attributes Any control attribute Any system attribute or object 10.3 Summary of privileges and attribute types Table 7 lists a summary of privileges and attribute types. depending on their semantics. This indicates an optional leading sign character and one or more digits. the new value will actually be interpreted to be "false".

spaceseparated fields. since their values are determined upon creation. and the timestamp consists of distinct. there are entries describing each of its attributes.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. this is simply one or more digits.1-2000 Table 8—Formats for strings (continued) Data type Description The attribute contains the date and time at which a particular action occurred. the year component will become five digits. Specifically. If an attribute does not exist for an object. For example: "1999 12 31 23 59 59 000". Unsetting a system-defined attribute returns it to its default value. 11. This is an uninterpreted hexadecimal token that is guaranteed to be unique across all space and time. 49 . The format is: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX where each "X" is taken from the set "0123456789abcdef". the other attributes will be set to the specified defaults unless specified upon creation. It has the form: YYYY MM DD HH MM SS UUU The time zone is defined to be UTC. The attribute contains a DCE standard format: UUID. this should not require changes to existing software. This format was chosen above others because the text representation directly sorts into increasing time order. Duration UUID The attribute contains a positive integer and records the time duration in seconds. All rights reserved.g. Unsetting a user-defined attribute causes the attribute to disappear. 10. then it will be represented as the unquoted token NULL when being reported in a text clause on a response command. Since attributes are variable-length strings. The Name for each attribute gives the attribute name. In this case. Copyright © 2000 IEEE. There are no null values. Object types The subclauses listed in Table 9 define the object types and their attributes. In the year 10 000. "2001" or "10203" January is "01" first day is "01" first hour is "00" first minute is "00" first second is "00" first millisecond is "000" It is permissible for the millisecond value to always be "000". For example: "de42ba54-9741-1020-8d13-0800690245c8". The substrings are separated by single spaces and are defined to be: Substring "YYYY" "MM" Timestamp "DD" "HH" "MM" "SS" "UUU" Time unit year month day of the month hour minute second millisecond Smallest value or example e. all of its characteristic attributes must be specified..5 Default values In order for an administrative application to create an object. There is no default value for user-defined attributes. For each object type in each cluster. There are no default values for attributes in status objects created by the system.

This is the primary holder of ownership in the MMS. In the following clauses. Provides a brief description. 12. A fully qualified name is of the form "OBJECTNAME. and "AttributeName" represents the name of the attribute. as defined in 10. 12. if any.AttributeName".IEEE Std 1244. Provides a list of values if it is an enumerated type.2 APPLICATION object An APPLICATION is a client program that has been authorized to use the system as a client of the MM. and the AI object differentiates one instance of the same application from another instance. This object is created by an administrative application in order to allow access to the system for this client program. Application cluster This cluster defines the application programs that use the MMS. Lists the data type. it can also be used to communicate configuration or status information between the various instances of the application. 12. Lists any objects where an instance of the object may not exist unless some value of this attribute exists for some instance of the first object. Lists the default value.1 Creation and deletion semantics An instance of the APPLICATION object shall be created before an AI object with the same ApplicationName can be created. All rights reserved.2. The APPLICATION object defines the application. as defined in 10.4. 50 Copyright © 2000 IEEE. The inverse of the "Depends On" relationship. where "OBJECTNAME" represents the name of some object. Applications can store user-defined attributes in this object as a way of obtaining persistent storage of configuration or option data. and includes the APPLICATION object and the AI object.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT relative to the object. The APPLICATION object cannot be deleted until all AI objects having the corresponding ApplicationName have been deleted. the object types are described cluster by cluster. Since this object and all of its attributes are available to all instances of this application. Table 9—Definitions of object types and their attributes Type Data type Description Allowed values Default Depends on Depended on by Lists the attribute type. . Lists the attributes of any objects that shall exist before this attribute can exist.

2 SignatureAlgorithm Name: SignatureAlgorithm Type: Characteristic Data Type: String Description: The name of the signature algorithm that this application uses. Allowed Values: "true". CARTRIDGEGROUPAPPLICATION. VOLUME 12.1.2. "false" Default: "false" Depends On: None Depended On By: None 12. SESSION. MOUNTLOGICAL.2.1.1 ApplicationName Name: ApplicationName Type: Characteristic.1 Attributes of the APPLICATION object 12.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. Allowed Values: Any Default: "undefined"—not all applications have a signature algorithm.4 BypassVerify Name: BypassVerify Type: Characteristic Copyright © 2000 IEEE. TASK.1.2.2.1. 51 . All rights reserved. Allowed Values: Any Default: None Depends On: None Depended On By: AI.1-2000 12.2.3 AllowRemoteMount Name: AllowRemoteMount Type: Characteristic Data Type: Boolean Description: Whether or not to allow this application to mount on a remote host machine. Depends On: None Depended On By: None 12. DRIVEGROUPAPPLICATION. CARTRIDGE. Key Data Type: String Description: The name of an application that is allowed to use the system.

Allowed Values: "true". SESSION. Since this object and all of its attributes are available to all instances of this application.3. then this must be set to "true".1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Data Type: Boolean Description: Whether or not to bypass the verification step. If SignatureAlgorithm is "undefined".3.3 AI object An AI is an instance of a client program that has been authorized to use the system. All rights reserved.1.1. it can also be used to communicate configuration or status information between the various instances of the application.IEEE Std 1244. Allowed Values: Any Default: None Depends On: None Depended On By: MOUNTLOGICAL.* Type: Client Data Type: Any Description: Any arbitrary attribute. . 12.1 AIName Name: AIName Type: Characteristic. TASK 52 Copyright © 2000 IEEE.5 User-defined attributes Name: . Allowed Values: Any Default: None Depends On: None Depended On By: None 12.1 Attributes of the AI object 12. AIs can store user-defined attributes in this object as a method of obtaining persistent storage of configuration or option data.2. Key Data Type: String Description: The name of this particular AI. This object is created by an administrative application in order to allow access to the system for this instance of the client program. "false" Default: "true" Depends On: None Depended On By: None 12. dependent on the application.

2 ApplicationName Name: ApplicationName Type: Characteristic. It is expected that a richer privilege model will be defined in a future version of the MMS.) Lower values indicate higher priority.ApplicationName Depended On By: See APPLICATION 12.4 DefaultPriority Name: DefaultPriority Type: Characteristic Data Type: Integer Description: Determines the default task priority for a task from this AI.5 User-Defined Attributes Name: .1-2000 12.3.1. 53 . Allowed Values: "true" or "false" Default: "false" Depends On: None Depended On By: None 12.3 PrivilegeChangeable Name: PrivilegeChangeable Type: Characteristic Data Type: Boolean Description: Determines whether or not an AI may change its privilege level from the application to the administrative level.1.* Type: Client Copyright © 2000 IEEE.3.3.1.ApplicationName Default: None Depends On: APPLICATION. Key Data Type: String Description: The name of the application of which this is an instance.3. (There is no run-level priority. The task priority is used to arbitrate between multiple blocked tasks. NOTE—This attribute reflects the simple two-level application/administrative privilege levels that are present in this version of the MMS. Allowed Values: One existing instance of APPLICATION.1. All rights reserved.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. Allowed Values: 0 through 1000 Default: 500 Depends On: None Depended On By: None 12.

. May only be created after all the SLOT objects have been created. and includes the objects listed in Table 10.1 and 13. Summarizes the storage locations in a bay of a library. Describes a particular slot in the library. Describes a collection of elements in the library.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Data Type: Any Description: Any arbitrary attribute.1. Allowed Values: Any Default: None Depends On: None Depended On By: None 13. such as those found in a magazine or a port. Note that the SLOTTYPE object has information on all of the libraries in the MMS.1. Table 10—Objects included in a library cluster LIBRARY object LM object BAY object SLOT object SLOTGROUP object SLOTCONFIG object SLOTTYPE object Describes the basic attributes of a library. All rights reserved. Table 11—Creation semantics LIBRARY object and at least one instance of the LM object BAY object Must be created first. Created by the system when all of the other objects in this cluster have been created. LIBRARY and BAY objects (with appropriate names) SLOTGROUP object SLOTCONFIG object 54 Copyright © 2000 IEEE. Note that these two objects depend on each other.1 Creation semantics Creation semantics are listed in Table 11. as opposed to merely one library.2. dependent on the application.IEEE Std 1244.1 Creation and deletion semantics The creation and deletion semantics for the library cluster are outlined in 13. Depends on the existence of a LIBRARY object with the specified LibraryName. 13.3. so once the LIBRARY has been created. Describes a group of slots. Describes the library management program that runs the library. There is further information in 7. Lists the available types of physical slots in the entire MMS. The library cluster This cluster defines a library in the MMS.1. 13. the BAY objects may be created. SLOTTYPE. Must be created before any SLOT objects are created.

All rights reserved. "temporary" Default: "false" Depends On: None Depended On By: None Copyright © 2000 IEEE. LM.2 The LIBRARY object The LIBRARY object is created by an administrative application in order to add a library to the MMS. Allowed Values: "true".1 Attributes of the LIBRARY object 13.2.2. or when the BAY has no SLOTs. "false".2.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. LIBRARYDRIVE.1-2000 13.1.1. Key Data Type: String Description: The name of the library. MOUNTPHYSICAL 13. 13. The LibraryOnline attribute is an administratively controlled enable/disable switch. 55 . May be deleted only when all of the BAYs have been deleted. 13. The LibraryStateHard and LibraryStateSoft fields show the current state of the library. Table 12—Deletion semantics SLOTTYPE object SLOTGROUP and BAY objects LIBRARY and LM objects SLOTCONFIG object May be deleted only when all SLOTs of that type have been deleted.2 Deletion semantics Deletion semantics are listed in Table 12. Allowed Values: Any Default: None Depends On: None Depended On By: CARTRIDGE.1 LibraryName Name: LibraryName Type: Characteristic.1. Deleted automatically by the system whenever the corresponding BAY has been deleted. DRIVE.2 LibraryDisabled Name: LibraryDisabled Type: Control Data Type: Enumerated Description: An administrative control used to enable/suspend/disable use of this library. May be deleted only when all of their SLOTs have been deleted.

2.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 13. "false" Default: "false" Depends On: None Depended On By: None 13.3 LibraryBroken Name: LibraryBroken Type: Status Data Type: Boolean Description: Has the Library Control Program reported that the library fails its own diagnostics? Allowed Values: "true".5 LibraryStateHard Name: LibraryStateHard Type: Status Data Type: Enumerated Description: This attribute is for future growth.6 LibraryStateSoft Name: LibraryStateSoft Type: Status Data Type: Enumerated 56 Copyright © 2000 IEEE.1. Allowed Values: One of the entries in LM. and before the LibraryOnline may be set to "true".2.IEEE Std 1244.2.LMName Default: None Depends On: LM. All rights reserved. Allowed Values: "unknown" Default: "unknown" Depends On: None Depended On By: None 13. there must have been an LM object created whose name matches this entry.4 LMName Name: LMName Type: Control Data Type: String Description: The instance name of the LMP currently controlling this library.LMName Depended On By: None 13.1.1.1. It is intended to reflect the status of the library device and is intended to be controlled by the LM. There may be several LMs that can control this library.2. .

1-2000 Description: This attribute is currently in place for future use. 57 . Finally set LIBRARY.3. 13. Only one LM may be active for a given LIBRARY at one time. and site-specific controls. The logical sequence is as follows: a) b) c) First create a LIBRARY object with an empty string value for LMName.3. and the LIBRARY object modified to reflect the active LM. Then LIBRARY.7 System-defined attributes Name: . See the private command in the LMP documentation.1 Attributes of the LM object 13. and with LibraryOnline set to "false".3 The LM object At least one LM object is created by an administrative application when a LIBRARY is added to the MMS. It might be used for a diagnostic application or an LM-specific application that might take control of the device and in order to perform things like re-calibration. diagnostics etc. The only value in use today is "ready".2.LibraryOnline to "true". Examples include comments. Additional LM objects may be created. All rights reserved. In future one might use "inuse". notes.* Type: Client (where in this case the client is an LM) Data Type: Any Description: An LM can add additional attributes to this record. Key Data Type: String Copyright © 2000 IEEE.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.1. thus defining one LMName. Allowed Values: "ready" Default: "inuse" Depends On: None Depended On By: None 13..1.1 LibraryName Name: LibraryName Type: Characteristic. and with the intent is of to allowing the MM to track use of the library by an application just in the same manner as a drive is.LMName may be given a non-empty value. providing that there are different LMs. Then create an LM object. Allowed Values: Any Default: None Depends On: None Depended On By: None 13.

"developer" Default: "error" Depends On: None Depended On By: None 13.3. "warning".3. SLOTCONFIG 13. LIBRARY. Allowed Values: "emergency".1. . Key Data Type: String Description: The name of an LM for the Library specified in LM.ConnectionClientHost Depended On By: None 58 Copyright © 2000 IEEE.1. "information". Allowed Values: One of the valid CONNECTION. "notice". "debug".LibraryName Depended On By: None 13.3. "critical". "alert". In the enumeration below. the number and level of detail of the messages increases from left to right.2 LMName Name: LMName Type: Characteristic.1. SLOT.LibraryName Default: None Depends On: LIBRARY.IEEE Std 1244.ConnectionClientHost Default: None—this is set on creation Depends On: CONNECTION.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Allowed Values: One of the entries in LIBRARY.4 LMHost Name: LMHost Type: Status Data Type: String Description: The network name of the host on which the LM is or was last known to be running.3 LMMessageLevel Name: LMMessageLevel Type: Control Data Type: Enumerated Description: The message level for logging.LibraryName. Allowed Values: Any Default: None Depends On: None Depended On By: BAY. All rights reserved. "error".

This LM is not yet a candidate for active processing. provided that there is no other LM that has already been chosen for activation of this device. implying that the LM is not ready to process normal LMP commands. The MM may choose such an LM to disable activation prior to activating another LM for the same device.3. "present"—Indicates that the LM has a connection to the MM. This occurs when the MM fails to process an LM config correctly. except when the LM pushes up a "ready broken" command. All rights reserved. (See LM. c) d) e) Note that when the LM sends MM a "ready broken" command. This occurs when the MM boots up and when the LM closes connection to the MM. "disconnected"—Indicates that the LM is not connected to its device. "not ready"—Indicates that the LM has a connection to the MM.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. The LM is activated for the device.6 LMStateSoft Name: LMStateSoft Type: Status Data Type: Enumerated Description: This attribute is primarily controlled by the MM. This occurs when the LM has just opened a connection but is yet to push up a new ready state.5 LMStateHard Name: LMStateHard Type: Status Data Type: Enumerated Description: This field is controlled by the LM. and is intended to reflect the operational status of the LM module only as opposed to the library. 59 . the value for this attribute is "broken".1.) Default: "absent" Copyright © 2000 IEEE. This occurs ONLY when the LM informs the MM that it is ready. but also reflects state information sent up to the MM by the LM through the ready command. The MM does not yet know if the LM is able to talk to the device. in which case. This occurs when the LM informs the MM through the "ready" command that it is no longer connected to its device. Allowed Values: "ready". Note that this is a normal state when the LM is booting up. however.LMStateHard. "broken" Default: "ready" Depends On: None Depended On By: None 13. By definition this will only occur after the LM has been activated by the MM and the LM has completed initialization procedures correctly. this indicates that the device may be inoperable. "ready"—Indicates that the LM is ready to process normal LMP commands. This value is always "ready". Note that this happens during a normal booting sequence. however the MM notes the fact that this LM is still the controlling LM for the device. The MM may choose to activate such an LM that is in this state.3.1-2000 13. It indicates whether the LM is ready to process LMP commands or not. Allowed Values: a) b) "absent"—Indicates that the LM is not yet connected to the MM.1.

1. See the private command in the LMP documentation. Key Data Type: String 60 Copyright © 2000 IEEE. If the LM has marked a bay as inaccessible. Allowed Values: Any Default: None Depends On: None Depended On By: None 13.1 Attributes of the BAY object 13. All BAY structures are created and deleted by the LM.1.7 System-defined attributes Name: . Allowed Values: Any Default: None Depends On: None Depended On By: SLOT. 13.3. and change whenever the LM updates its configuration. See the config command in the LMP documentation. notes. Key Data Type: String Description: The name of the BAY. All rights reserved.* Type: Client (where in this case the client is the LM) Data Type: Any Description: A Library Manger can add additional attributes to this record. SLOTCONFIG. The MM may give preference to drive/cartridge combinations where they are both in the same bay versus where they are not. SLOTGROUP 13.IEEE Std 1244. Examples include comments. and site-specific controls. then all the drives and slots in that bay are also inaccessible.4 BAY object A bay is a piece of a library that exhibits some locality.2 LibraryName Name: LibraryName Type: Characteristic. .4. DRIVEs and SLOTs are both "contained" in BAYs.4.4.1.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Depends On: None Depended On By: None 13.1 BayName Name: BayName Type: Characteristic.

LibraryName Depended On By: None 13. A SlotName is unique within a LIBRARY.LMName Depended On By: None 13. a slot would not be accessible if it was not configured into the library (and hence cannot be occupied). Allowed Values: "true". and change whenever the LM updates its configuration.5. A PCL shall be unique for all cartridges having the same SlotTypeName.3 LMName Name: LMName Type: Characteristic.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. All rights reserved.1. Key Data Type: String Description: The name of the LM in which this BAY resides.4 BayAccessible Name: BayAccessible Type: Status Data Type: Boolean Description: Determines whether or not the BAY may be operated upon by the current LM. Allowed Values: One of the entries in LM.1.1.1 Attributes of the SLOT object 13.LibraryName Default: None Depends On: LIBRARY. All SLOT structures are created and deleted on behalf of the LM. A slot can be any combination of SlotOccupied and/or SlotAccessible. but it might also be inaccessible if the robot arm was broken in such a way that the slot could not be reached even though it was occupied.4.1 SlotName Name: SlotName Copyright © 2000 IEEE. Allowed Values: One of the entries in LIBRARY. 13. 61 .5 The SLOT object A slot is one storage location inside a library.4.5. The SlotName is unique within the LIBRARY for a given LM.1-2000 Description: The name of the LIBRARY in which this BAY resides. "false" Default: "false" Depends On: None Depended On By: None 13.LMName Default: None Depends On: LM. For example.

Allowed Values: Any Default: None Depends On: None Depended On By: MOUNTPHYSICAL 13.3 LMName Name: LMName Type: Characteristic. Allowed Values: One of the entries in LM.LibraryName Default: None Depends On: LIBRARY. All rights reserved. Allowed Values: One of the values for BAY. Key Data Type: String Description: The name of the LIBRARY in which this slot resides.LibraryName Depended On By: None 13.LMName Depended On By: None 13.5.IEEE Std 1244.1.2 LibraryName Name: LibraryName Type: Characteristic. Key Data Type: String Description: The name of the SLOT. Allowed Values: One of the values for LIBRARY.5. .5. Key Data Type: String Description: The name of the LM in which this SLOT resides.LMName Default: None Depends On: LM.1.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Type: Characteristic.1.BayName 62 Copyright © 2000 IEEE.BayName Default: None Depends On: BAY.4 BayName Name: BayName Type: Characteristic Data Type: String Description: The name of the BAY in which this slot resides.

7 CartridgeID Name: CartridgeID Type: Status Data Type: UUID Description: The name of the cartridge in this slot.1.SlotGroupName Default: None Depends On: SLOTGROUP.8 CartridgePCL Name: CartridgePCL Type: Status Data Type: String Copyright © 2000 IEEE. All rights reserved.5.5.5. 63 . it is set to "empty".5 SlotGroupName Name: SlotGroupName Type: Characteristic Data Type: String Description: The name of the slot group with which this slot is associated.1. otherwise.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.6 SlotTypeName Name: SlotTypeName Type: Characteristic Data Type: String Description: The name of the slot type.1.CartridgeID Depended On By: None 13.CartridgeID Default: "empty" Depends On: CARTRIDGE.SlotGroupName Depended On By: None 13. Allowed Values: One of the values for CARTRIDGE.1. if any.5.1-2000 Depended On By: None 13. Allowed Values: One of the values for SLOTTYPE. Allowed Values: One of the values for SLOTGROUP.SlotTypeName Default: None Depends On: SLOTTYPE.SlotTypeName Depended On By: None 13.

1 SlotGroupName Name: SlotGroupName Type: Characteristic. A SLOTGROUP may be in only one BAY. from the rest of the slots.5.1.CartridgePCL.1 Attributes of the SLOTGROUP object 13.1.6. Allowed Values: One of the values for CARTRIDGE.9 SlotAccessible Name: SlotAccessible Type: Status Data Type: Boolean Description: Determines whether or not the slot is accessible. such as those found in magazines or ports. if any. Allowed Values: "true". "false" Default: "false" Depends On: None Depended On By: None 13.6 SLOTGROUP object This object differentiates special slots.CartridgePCL Depended On By: None 13. "false" Default: "false" Depends On: None Depended On By: None 13. All rights reserved.6. Allowed Values: "true".1. otherwise. Key Data Type: String 64 Copyright © 2000 IEEE.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Description: The PCL of the cartridge that is in the slot.10 SlotOccupied Name: SlotOccupied Type: Status Data Type: Boolean Description: Determines whether or not the slot is occupied. 13.IEEE Std 1244. Default: "empty" Depends On: CARTRIDGE. . The SLOTGROUP object partitions the set of all slots in a library into disjoint subsets. The SLOTGROUP names must be unique within the LIBRARY in which it is found.5. it is "empty".

All rights reserved.1-2000 Description: The name of this slotgroup. or ordinary. Other types of SLOTGROUPs do not. Allowed Values: "in".6. Key Data Type: String Description: The name of the LIBRARY in which this SLOTGROUP is found.1.LibraryName Depended On By: None Copyright © 2000 IEEE. Allowed Values: "port". "ordinary" Default: "ordinary" Depends On: None Depended On By: None 13.1. magazine.6. "both".6. 65 . "magazine".2 Direction Name: Direction Type: Characteristic Data Type: Enumerated Description: Ports have a direction associated with them.3 Type Name: Type Type: Characteristic Data Type: Enumerated Description: The type of SLOTGROUP: port. Non-port SLOTGROUPs have a direction of "none".4 LibraryName Name: Library Name Type: Characteristic. Allowed Values: Any Default: None Depends On: None Depended On By: None 13.1.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.LibraryName Default: None Depends On: LIBRARY. Allowed Values: One of the values for LIBRARY. "out". "none" Default: "none" Depends On: None Depended On By: None 13.

LibraryName.LMName Default: None Depends On: LM. Allowed Values: One of the values for LIBRARY.1.1 LibraryName Name: LibraryName Type: Characteristic.LMName Depended On By: None 66 Copyright © 2000 IEEE. Depended On By: None 13. BayName.1. This is a status object. Status. It gives a summary of the number of free and used slots of each type in each bay of the library.LMName Default: None Depends On: LIBRARY.LMName Depended On By: None 13. Allowed Values: Any Default: None Depends On: Must be one of the values of LIBRARY.2 LMName Name: LMName Type: Characteristic. . it is automatically created by the system for each LMName.6. Key Data Type: String Description: The name of the library for this slot configuration.7.7 SLOTCONFIG object The slot configuration object gives an overview of the storage locations in a BAY of a LIBRARY.1 Attributes of the SLOTCONFIG object 13.1. and SlotTypeName combination. All rights reserved.IEEE Std 1244. Key Data Type: String Description: The name of the LM controlling the library containing the slots to which this record refers. Allowed Values: One of the values for LM.7.7.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 13.5 LMName Name: LM Name Type: Characteristic. 13. Key Data Type: String Description: The name of the LM in which this SLOTGROUP is found.

4 SlotTypeName Name: SlotTypeName Type: Characteristic. Status.1.SlotTypeName Default: None Depends On: SLOTTYPE. Key Data Type: String Description: The name of the type of slots that to which this record refers to. Allowed Values: Any Default: None Depends On: None Depended On By: None 13. 67 . Status.BayName Depended On By: None 13.5 SlotConfigNumberFree Name: SlotConfigNumberFree Type: Status Data Type: Integer Description: The number of free slots of the given type in the given bay.1-2000 13.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. Allowed Values: Any Copyright © 2000 IEEE.1.3 BayName Name: BayName Type: Characteristic.7. Allowed Values: One of the values for BAY.BayName Default: None Depends On: BAY. Key Data Type: String Description: The name of the bay containing the slots to which this record refers.7. Allowed Values: One of the values for SLOTTYPE.7.1.6 SlotConfigNumberTotal Name: SlotConfigNumberTotal Type: Status Data Type: Integer Description: The total number of slots of the given type in the given bay.SlotTypeName Depended On By: None 13.7. All rights reserved.1.

1 SlotTypeName Name: SlotTypeName Type: Characteristic.1 Attributes of the SLOTTYPE object 13.IEEE Std 1244. This object provides a list of approved names for the purpose of consistency across implementations.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Default: None Depends On: None Depended On By: None 13.1.2 CartridgeShapeName Name: CartridgeShapeName Type: Characteristic. Slots reported by LMs whose SlotTypeName is not given in a SLOTTYPE record will be ignored.8.1. 13. in this case. All rights reserved.8 SLOTTYPE object The SLOTTYPE object is the combination of the external shape of a cartridge and the type of slot that can contain such a cartridge. Allowed Values: Any Default: None Depends On: None Depended On By: SLOT. An object of this type with the appropriate name must be created before a cartridge. the client is the system) Data Type: Any 68 Copyright © 2000 IEEE. Key Data Type: String Description: The type of slot as reported by the LM.3 System-defined attributes Name: . slot.8. . or slot configuration object may be created. SLOTCONFIG 13. Allowed Values: Any Default: None Depends On: None Depended On By: CARTRIDGE 13.This allows mapping of a type of slot to the shapes of cartridges that the slot can contain. Key Data Type: String Description: The external shape of the cartridge.1.* Type: Client (where.8.8.

SYSTEM (MMS) ARCHITECTURE

IEEE Std 1244.1-2000

Description: Additional attributes can be added by the system to this record. Examples include comments, notes and site-specific controls. Allowed Values: Any Default: None Depends On: None Depended On By: CARTRIDGE, SLOT, SLOTCONFIG

14. Drive cluster
The Drive cluster defines a drive in the MMS. The first set of objects, listed in Table 13, defines the drive and places it in a drive group so that applications are able to have a set of drives for their own use. Table 13—Objects that define the drive
DRIVE object DRIVEGROUP object DRIVEGROUPAPPLICATION object Describes the device used to access the contents of a cartridge. Describes a drive group, which is used to aggregate drives and to support access permissions and usage policy. Links an application to a drive group (together with the CARTRIDGEGROUPAPPLICATION object), thereby allowing different applications to share a library without interfering with each other. Describes the DMP for the drive.

DM object

The remaining objects, listed in Table 14, define the capabilities of a drive and control its use in a specific situation. Table 14—Objects that define the capabilities of the drive
DMBITFORMAT object Represents a set of capabilities that are required to get a certain bit encoding on the media when using a particular DM. Each DMBITFORMAT lists a set of capability tokens. Each token represents some characteristic of the drive that an application may request be used for any given mount. Specifies a capability token included with a DMBITFORMAT object. This object represents a particular mode offered by a DM. This object represents a single capability token offered by a DM as part of the DMCAPABILITY object. Describes the set of mutually exclusive capabilities that a particular DM offers. Lists tokens that specify characteristics available through a DM. Specifies a capability token provided by the site administrator that defines the definition of the default token in a DMCAPABILITYGROUP.

DMBITFORMATTOKEN object DMCAPABILITY object DMCAPABILITYTOKEN object DMCAPABILITYGROUP object DMCAPABILITYGROUPTOKEN object DMCAPABILITYGROUPDEFAULTTOKEN object

Copyright © 2000 IEEE. All rights reserved.

69

IEEE Std 1244.1-2000

IEEE STANDARD FOR MEDIA MANAGEMENT

14.1 Creation and deletion semantics
The creation and deletion semantics for a drive cluster are outlined in 14.1.1 and 14.1.2. 14.1.1 Creation semantics Creation semantics are listed in Table 15. Table 15—Creation semantics
DRIVE object DRIVEGROUPAPPLICATION object DM object DMBITFORMAT object DMBITFORMATTOKEN object May be created after the DRIVEGROUP and LIBRARY object have been created. May be created after the DRIVEGROUP and APPLICATION objects have been created. May be created after the DRIVE object is created. NOTE—The DM and DRIVE objects depend on each other. May be created after the DM object is created. May be created after the DMBITFORMAT object is created. NOTE—DMBITFORMATTOKEN is a member of DMBITFORMAT. May be created after the DM object is created. May be created after the DMCAPABILITY object is created. Note: DMBITFORMATTOKEN is a member of DMBITFORMAT. May be created after the DM object is created. May be created after the DMBCAPABILITYGROUP object is created. NOTE—DMCAPABILITYGROUPTOKEN object is a member of DMCAPABILITYGROUP. Default value of DMCAPABILITYGROUP. May be created after the DRIVE and DMCAPABILITYTOKEN objects have been created.

DMCAPABILITY object DMCAPABILITYTOKEN object DMCAPABILITYGROUP object DMCAPABILITYGROUPTOKEN object

DMCAPABILITYGROUPDEFAULTTOKEN object

14.1.2 Deletion semantics Deletion semantics are listed in Table 16. Table 16—Deletion semantics
DMCAPABILITYGROUP object DMBITFORMAT object DM object May be deleted after all of the DMCAPABILITYGROUPTOKEN objects that refer to it have been deleted. May be deleted after the DMBITFORMATTOKEN objects that refer to it have been deleted. May be deleted after all of the DMCAPABILITYGROUP, DMCAPABILITYGROUPDEFAULTTOKEN, and DMBITFORMAT objects that refer to it have been deleted. May be deleted after all the DM objects that refer to it have been deleted. May be deleted after all DRIVE objects that refer to it have been deleted.

DRIVE object DRIVEGROUP object

70

Copyright © 2000 IEEE. All rights reserved.

SYSTEM (MMS) ARCHITECTURE

IEEE Std 1244.1-2000

14.2 DRIVE Object
A drive is a device used to access the contents of a cartridge. See the DMP language definition for more detailed information. A drive is created by an administrative application. The DriveDisabled attribute is a way to stop or suspend using a drive even though all of the support for it is present and running. The DriveDisabled attribute is an administratively controlled switch. The DriveStateHard and DriveStateSoft fields show the current state of the drive. The LibraryName, BayName, and CartridgePCL attributes show the location and the contents of the drive, respectively. The DriveGroupName attribute is used to group drives and thereby to support an access permissions model. Each drive must belong to one DRIVEGROUP or another. DRIVEGROUPAPPLICATION records are used to allow applications to access particular DRIVEGROUPs. 14.2.1 Attributes of the DRIVE object 14.2.1.1 DriveName Name: DriveName Type: Characteristic, Key Data Type: String Description: The name of the drive. Allowed Values: Any Default: None Depends On: None Depended On By: DM, DMCAPABILITY, DMCAPABILITYTOKEN, DMCAPABILITYDEFAULTTOKEN, MOUNTLOGICAL, MOUNTPHYSICAL, TASKDRIVE 14.2.1.2 DriveGroupName Name: DriveGroupName Type: Control Data Type: String Description: The name of the drivegroup to which this drive belongs. Allowed Values: One of the values for DRIVEGROUP.DriveGroupName Default: None; must be set when the DRIVE object is created. Depends On: DRIVEGROUP.DriveGroupName Depended On By: None 14.2.1.3 DrivePriority Name: DrivePriority Type: Control Data Type: Integer Description: Priority of this drive. It is originally set to 1000, and may be modified by an administrative application. Lower values have higher priority in drive selection.

Copyright © 2000 IEEE. All rights reserved.

71

or "false" if no DM has been created for this drive.2.5 DriveDisabled Name: DriveDisabled Type: Control Data Type: Enumerated Description: An administrative control used to enable/suspend/disable use of this drive. Default: 1000 Depends On: None Depended On By: None 14.1. .IEEE Std 1244. "false" Default: "false" Depends On: None Depended On By: None 72 Copyright © 2000 IEEE.1.6 DriveBroken Name: DriveBroken Type: Status Data Type: Boolean Description: Has the DM reported that the drive fails its own diagnostics? Allowed Values: "true".DMName Depended On By: None 14.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Allowed Values: 0–1000.1. Allowed Values: One of the values for DM. "false". Allowed Values: "true". Default: "false" Depends On: DM. "temporary" Default: "false" Depends On: None Depended On By: None 14. All rights reserved.DMName.4 DMName Name: DMName Type: Control Data Type: String Description: The name of the DM currently controlling this drive.2.2.

"ready" Default: "ready" Depends On: None Depended On By: None 14.1-2000 14. whereas the DMStateHard attribute represents the status of the DM.8 DriveStateHard Name: DriveStateHard Type: Status Data Type: Enumerated Description: This attribute reflects the current operational status of the drive.1.9 DriveTimeCreated Name: DriveTimeCreated Type: Status Data Type: Timestamp Description: The date/time when this drive structure was created.1. Allowed Values: "in use".2. and indicates whether the drive is currently in use by an application. NOTE—The DriveStateHard attribute reflects the status of the device.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. "loading". 73 . "unloaded" Default: "unloaded" Depends On: None Depended On By: None 14.2.7 DriveStateSoft Name: DriveStateSoft Type: Status Data Type: Enumerated Description: This attribute is controlled entirely by the MM. All rights reserved. or if it is available for mounting. Allowed Values: "loaded". Allowed Values: Any Default: None—this must be set on creation Depends On: None Depended On By: None 14. "unloading".2.10 DriveTimeMountedLast Name: DriveTimeMountedLast Type: Status Copyright © 2000 IEEE.1.2.1.

13 DriveNumberMountsSinceCleaning Name: DriveNumberMountsSinceCleaning Type: Status Data Type: Integer Description: The number of mounts since the drive was cleaned.12 DriveNumberMounts Name: DriveNumberMounts Type: Status Data Type: Integer Description: The number of times this drive has been mounted. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 14. Allowed Values: Any Default: 0 Depends On: None Depended On By: None 14. All rights reserved.2. Allowed Values: Any Default: 0 Depends On: None Depended On By: None 74 Copyright © 2000 IEEE.1.IEEE Std 1244. .11 DriveTimeMountedTotal Name: DriveTimeMountedTotal Type: Status Data Type: Timestamp Description: The date/time when a cartridge was last mounted in this drive.1.2. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 14.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Data Type: Timestamp Description: The date/time when a cartridge was last mounted in this drive.1.2.

2. "false" Copyright © 2000 IEEE.14 LibraryName Name: LibraryName Type: Characteristic Data Type: String Description: The name of the library in which this drive is contained.BayName Default: None Depends On: BAY.LibraryName Default: None Depends On: LIBRARY. "false" Default: "false" Depends On: None Depended On By: None 14.BayName Depended On By: None 14.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.1. 75 .15 BayName Name: BayName Type: Characteristic Data Type: String Description: The name of the bay inside the library in which this drive is contained.1. All rights reserved.LibraryName Depended On By: None 14.1-2000 14.2.17 DriveLibraryOccupied Name: DriveLibraryOccupied Type: Status Data Type: Boolean Description: Does the LM believe that there is a cartridge in the drive? Allowed Values: "true".1. Allowed Values: One of values for BAY.2.2.1. Allowed Values: One of the values for LIBRARY.16 DriveLibraryAccessible Name: DriveLibraryAccessible Type: Status Data Type: Boolean Description: Does the LM believe that it can mount/unmount cartridges to/from this drive? Allowed Values: "true".

20 MaxMounts Name: MaxMounts Type: Status Data Type: Integer Description: The maximum number of mounts that may occur before the drive should be cleaned.2. When the specified number of mounts has occurred.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Default: "false" Depends On: None Depended On By: None 14.2. All rights reserved.1. c) "advisory"—Drive needs cleaning. Allowed Values: One of the values for SLOT.2.CartridgePCL. . or "no cartridge mounted". but may still allow mounting of cartridges. Default: "no cartridge mounted" Depends On: SLOT.IEEE Std 1244. d) "mandatory"—Drive will not accept mounts until it is cleaned. which indicates that the DriveNeedsCleaning will be set by another process Depends On: None Depended On By: None 76 Copyright © 2000 IEEE.1.1. Allowed Values: a) "true"—Drive needs cleaning. and how urgently. b) "false"—Drive does not need cleaning. this will cause the attribute DriveNeedsCleaning to be changed from "false" to one of the other values.18 CartridgePCL Name: CartridgePCL Type: Status Data Type: String Description: The PCL of the cartridge that is currently mounted in the drive. Default: "false" Depends On: None Depended On By: None 14.CartridgePCL Depended On By: None 14. depending on the drive technology. Allowed Values: Any Default: 0.19 DriveNeedsCleaning Name: DriveNeedsCleaning Type: Status Data Type: Enumerated Description: Specifies whether or not the drive needs cleaning.

2 DriveGroupUnloadTime Name: DriveGroupUnloadTime Type: Duration Data Type: Control Description: The default maximum time (in minutes) that an unneeded cartridge should be left in an unneeded drive before it is unmounted. 14. DRIVEGROUPAPPLICATION 14.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. Each drive must belong to one drivegroup or another.1.1 DriveGroupName Name: DriveGroupName Type: Characteristic.3.* Type: Client (where in this case the client is the system) Data Type: Any Description: Additional attributes can be added by the DM to this record.2. DRIVEGROUPs are used to aggregate drives. unmount immediately. notes. Allowed Values: Any Default: 60 Copyright © 2000 IEEE. and then to support both an access permissions model and a preferential usage policy.3.1 Attributes of the DRIVEGROUP object 14.3 DRIVEGROUP object The DRIVEGROUP object is a named group to which a drive can belong. DRIVEGROUPAPPLICATION objects are used to allow applications to access particular DRIVEGROUPS. and site-specific controls. This field is only used if the DRIVEGROUPAPPLICATION record contains a negative duration value.1.3. All rights reserved. If the drive or the cartridge is needed sooner.1-2000 14. Allowed Values: Any Default: None Depends On: None Depended On By: None 14. 77 .1. Allowed Values: Any Default: Characteristic Depends On: None Depended On By: DRIVE. Examples include comments.21 System-defined attributes Name: . Key Data Type: String Description: The name of this group of drives. See the private command in the DMP description.

Key Data Type: String 78 Copyright © 2000 IEEE.4. and site-specific controls.DriveGroupName Default: None Depends On: DRIVE. Key Data Type: String Description: The name of a drive. with the lowest value given preference.1 DriveGroupName Name: DriveGroupName Type: Characteristic.1 Attributes of the DRIVEGROUPAPPLICATION 14. This allows an administrator to set a preference sequence for drives for a particular application. Allowed Values: One of the values for DRIVEGROUP. Examples include comments. The groups are ordered by the DriveGroupApplicationPriority field.4 DRIVEGROUPAPPLICATION object This object provides a linkage allowing an application access to the drives in a DRIVEGROUP.3.4. The DRIVEGROUP object partitions the DRIVES into disjoint subsets. .1. Allowed Values: Any Default: None Depends On: None Depended On By: None 14.3 System-defined attributes Name: .1.* Type: Client Data Type: Any Description: Additional attributes can be added by the system to this record.IEEE Std 1244.4. notes.2 ApplicationName Name: ApplicationName Type: Characteristic. The DRIVEGROUPAPPLICATION object is used to allow applications to access particular DRIVEGROUPs without interfering with each other. 14.1.DriveGroupName Depended On By: None 14.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Depends On: None Depended On By: None 14. All rights reserved.

5.3 DriveGroupApplicationPriority Name: DriveGroupApplicationPriority Type: Control Data Type: Integer Description: The priority that the system should use for this drive when multiple drives are candidates.4. Allowed Values: Any Default: 60 Depends On: None Depended On By: None 14.ApplicationName Depended On By: None 14.1 DMName Name: DMName Type: Characteristic Data Type: String Copyright © 2000 IEEE. do not wait the full time.1. All rights reserved. Allowed Values: Any Default: 1000 Depends On: None Depended On By: None 14.1.ApplicationName Default: None Depends On: APPLICATION.1.1 Attributes of the DM object 14. then use the DriveGroupUnloadTime attribute of the DRIVEGROUP for this drive instead.4 DriveGroupApplicationUnloadTime Name: DriveGroupApplicationUnloadTime Type: Control Data Type: Duration Description: The maximum time (in minutes) that an unneeded cartridge should be left in an unneeded drive before it is unmounted. If the drive or the cartridge is needed sooner.5.4.5 DM object This object represents the DM.1-2000 Description: The name of an APPLICATION.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. 14. 79 . Allowed Values: One of the values for APPLICATION. It is created by an administrative application in order to add a new DMP to the MMS for a given drive. If this duration is negative.

1. "error". or "false" Default: "false" Depends On: CONNECTION. MOUNTLOGICAL 14. Allowed Values: One of the values for CONNECTION.5. "debug". "critical".2 DriveName Name: DriveName Type: Characteristic Data Type: String Description: The name of the DRIVE that this DM is capable of controlling.DriveName Default: None Depends On: DRIVE. "notice". Allowed Values: One of the values for DRIVE. .1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Description: The name of the drive manager for this drive. the number and level of detail of the messages increases from left to right. "warning".IEEE Std 1244.ConnectionClientHost. DMCAPABILITYDEFAULTTOKEN.5. "information".ConnectionClientHost Depended On By: None 14.3 DMHost Name: DMHost Type: Status Data Type: String Description: The name of the host on which the DM is running. DMCAPABILITYGROUP.4 DMMessageLevel Name: DMMessageLevel Type: Control Data Type: Enumerated Description: The level of message logging desired from this DM.1. "developer" Default: "error" Depends On: None 80 Copyright © 2000 IEEE. All rights reserved.1. "alert". DRIVE.5. In the enumeration below. Allowed Values: "emergency". Allowed Values: Any Default: None Depends On: None Depended On By: DMBITFORMAT. DMCAPABILITY.DriveName Depended On By: None 14.

is not yet a candidate for active processing. but also reflects state information sent up to the MM by the DM through the "ready" command. "broken" Default: "ready" Depends On: None Depended On By: None 14. "disconnected"—Indicates that the DM is not connected to its device. This occurs ONLY when the DM informs the MM that it is ready. By definition this will only occur after the DM has been activated by the MM and the DM has completed initialization procedures correctly. in which case the value for this attribute is "broken".1-2000 Depended On By: None 14.5. however.5 DMStateHard Name: DMStateHard Type: Status Data Type: Enumerated Description: This field is controlled by the DM and is intended to reflect the operational status of the DM module only (as opposed to the device it is controlling). "reserved"—In an environment where a drive can be used by multiple hosts. "not ready"—Indicates that the DM has a connection to the MM. implying that the DM is not ready to process normal DMP commands. All rights reserved. This is a special case of the ready state. The MM does not yet know if the DM is able to talk to the device. 81 . This occurs when the DM has just opened a connection but is yet to push up a new ready state. provided that there is no other DM that has already been chosen for activation of this device. Note that this is a normal state when the DM is booting up.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. This DM. The MM may choose such a DM to disable activation prior to activating another DM for the same device. The DM is activated for the device.1. "present"—Indicates that the DM has a connection to the MM. Control Data Type: Enumerated Description: This attribute is primarily controlled by the MM.6 DMStateSoft Name: DMStateSoft Type: Status. It indicates whether or not the DM is ready to process DMP commands.5. Allowed Values: a) b) "absent"—Indicates that the DM is not yet connected to the MM. this state is used to temporarily pin the drive to a particular DM. This occurs when the MM fails to process a DM config correctly. Note that this happens during a normal booting sequence. "ready"—Indicates that the DM is ready to process normal DMP commands. Allowed Values: "ready". This value is always "ready" except when the DM pushes up a "ready broken" command. This occurs when the DM informs the MM through the "ready" command that it is no longer connected to its device. c) d) e) f) Copyright © 2000 IEEE.1. This occurs when the MM boots up and when the DM closes the connection to MM. The MM may choose to activate such a DM that is in this state.

DriveName Default: None Depends On: DRIVE. Examples include comments. changing whenever the DM sends a new DMP CONFIG command up to the MMS. The tokens list those characteristics that must be requested from the DM in order to get the desired bit encoding on the media. All rights reserved. however.5.7 System-defined attributes Name: . Default: "absent" Depends On: None Depended On By: None 14.DMName 82 Copyright © 2000 IEEE. and site-specific controls.4-2000).* Type: Client (DM) Data Type: Any Description: Additional attributes can be added by the system to this record.DriveName Depended On By: DMBITFORMATTOKEN.DMStateHard.1. 14.IEEE Std 1244.6 DMBITFORMAT object This object represents a set of capabilities that are required to get a specific bit encoding on the media when using this DM. Each DM offers a group of bitformats to the MMS.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Note that when the DM sends MM of a "ready broken" command. Allowed Values: Any Default: None Depends On: None Depended On By: None 14. .42000) for more detailed information. the MM notes the fact that this DM is still the controlling DM for the device. All DMBITFORMAT structures are created and deleted on behalf of the DM.6. Allowed Values: One of the values for DRIVE.6. notes.1 DriveName Name: DriveName Type: Characteristic. See the private command in the DMP description (IEEE Std 1244.1 Attributes of the DMBITFORMAT object 14.1. Each bitformat is composed of a set of DMBITFORMATTOKENs. See the DMP language definition (IEEE Std 1244. See DM. Key Data Type: String Description: The name of the drive for this DMBITFORMAT. this indicates that the device may be inoperable.

6. and are then compared for equality at run time. "compression" and "nocompression" are valid tokens. Each token is simply a text string. Allowed Values: Any Default: None Depends On: None Depended On By: DMBITFORMATTOKEN 14. The tokens are simply agreed upon in advance.7 DMBITFORMATTOKEN This object specifies a capability token that is included with a DMBITFORMAT.3 DMBitformatName Name: DMBitformatName Type: Characteristic Data Type: String Description: The name of this bitformat. Each DMBITFORMAT lists a set of capability tokens. See the DMP language definition (IEEE Std 1244. 83 . by virtue of being part of the MMS documentation set. Key Data Type: String Description: The name of the drive for this DMBITFORMATTOKEN. All rights reserved.1-2000 14. Allowed Values: One of the values for DM.2 DMName Name: DMName Type: Characteristic. but it represents some characteristic of the drive that an application may request be used for any given mount.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.1 DriveName Name: DriveName Type: Characteristic.1 Attributes of the DMBITFORMATTOKEN object 14. For example.7.6. 14.DMName Depended On By: DMBITFORMATTOKEN 14. All DMBITFORMATTOKEN structures are created and deleted on behalf of the DM.DriveName Copyright © 2000 IEEE.4-2000) for more detailed information. changing whenever the DM sends a new DMP CONFIG command up to the MMS.1.1. Allowed Values: One of the values for DMBITFORMAT.DMName Default: None Depends On: DM.7. Key Data Type: String Description: The name of the DM from which this bitformat was generated.1.

1.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Default: None Depends On: DMBITFORMAT.1. Key Data Type: String Description: The name of the DM from which this bitformat was generated.DriveName Depended On By: None 14.4 DMCapabilityToken Name: DMCapabilityToken Type: Characteristic.DMName Depended On By: None 14.IEEE Std 1244. . Key Data Type: String Description: The name of the bitformat for this object.2 DMName Name: DMName Type: Characteristic.DMName Default: None Depends On: DMBITFORMAT.7. Allowed Values: One of the values for DMBITFORMAT.3 DMBitformatName Name: DMBitformatName Type: Characteristic. Allowed Values: Any Default: None Depends On: None Depended On By: None 84 Copyright © 2000 IEEE.7.DMBitformatName Depended On By: None 14.1. All rights reserved. Allowed Values: One of the values for DMBITFORMAT.DMBitformatName Default: None Depends On: DMBITFORMAT.7. Key Data Type: String Description: A particular capability token associated with a given bitformat.

3 DMCapabilityName Name: DMCapabilityName Type: Characteristic. 85 .1.8 The DMCAPABILITYobject This object represents a particular mode of operation offered by a DM. and change whenever the DM sends a new DMP CONFIG command up to the MMS.8. Each DM offers a set of capabilities to the MMS.8. Allowed Values: One of the values for DM.DMName Default: None Depends On: DM. Each DMCAPABILITY is composed of a set of DMCAPABILITYTOKENs.DriveName Default: None Depends On: DRIVE. Key Data Type: String Description: The name of the DM to which this capability set applies.8.1. The capability information is used when performing the rendezvous between the application-desired capability tokens and the DM-offered capability tokens.4-2000) for more detailed information.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. All rights reserved. Key Data Type: String Description: The name of this capability.DriveName Depended On By: DMCAPABILITYTOKEN 14.8.1 DriveName Name: DriveName Type: Characteristic. All DMCAPABILITY structures are created and deleted on behalf of the DM.DMName Depended On By: DMCAPABILITYTOKEN 14.1-2000 14.1.1 Attributes of the DMCAPABILITY object 14. See the DMP language definition (IEEE Std 1244. Allowed Values: One of the values for DRIVE. 14.2 DMName Name: DMName Type: Characteristic. Key Data Type: String Description: The name of the drive for this DMCAPABILITY. Allowed Values: Any Default: None Depends On: None Depended On By: DMCAPABILITYTOKEN Copyright © 2000 IEEE.

4-2000) for more detailed information. Allowed Values: One of the values for DM. See the DMP language definition (IEEE Std 1244.1. All DMCAPABILITYGROUPTOKEN structures are created and deleted on behalf of the DM.4 Client-defined attributes Name: .9. 14.IEEE Std 1244.9.1 Attributes of the DMCAPABILITYTOKEN object 14. Examples include device performance parameters. Key Data Type: String Description: The name of the DM to which this capability token applies.DriveName Default: None Depends On: DRIVE.9.2 DMName Name: DMName Type: Characteristic. All rights reserved.1.* Type: Client Data Type: String Description: Additional attributes can be added to this record by the DM. Each DM offers a set of capabilities to the MMS.1 DriveName Name: DriveName Type: Characteristic. The capability tokens are used when performing the rendezvous between the application-desired capability tokens and the DM-offered capability tokens. Key Data Type: String Description: The name of the drive for this DMCAPABILITYTOKEN.1.8. Allowed Values: Any Default: None Depends On: None Depended On By: None 14.DMName Default: None 86 Copyright © 2000 IEEE.DriveName Depended On By: None 14. Allowed Values: One of the values for DRIVE. .1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 14.9 The DMCAPABILITYTOKEN object This object represents a single capability token offered by a DM as part of a DMCAPABILITY object. and change whenever the DM sends a new DMP config to the MM.

14. For example. but it represents some characteristic of the drive that an application may request be used for any given mount.1.1. by virtue of being part of the MMS documentation set. Key Copyright © 2000 IEEE. Key Data Type: String Description: The name of this capability. 87 .1.3 DMCapabilityName Name: DMCapabilityName Type: Characteristic. and are then compared for equality at run time. The tokens are simply agreed upon in advance. All DMCAPABILITYDEFAULTTOKEN structures are created and deleted by the site administrator.4 DMCapabilityToken Name: DMCapabilityToken Type: Characteristic.1 DriveName Name: DriveName Type: Characteristic.10.1 Attributes of the DMCAPABILITYDEFAULTTOKEN object 14. Allowed Values: Any Default: None Depends On: None Depended On By: None 14.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. All rights reserved.9. not by the DM.DMName Depended On By: None 14.9. Allowed Values: Any Default: None Depends On: None Depended On By: None 14. compression and nocompression are valid tokens. Each DMCAPABILITYDEFAULT contains a set of capability tokens. Each token is simply a text string.1-2000 Depends On: DM. Key Data Type: String Description: The token for this capability.10.10 DMCAPABILITYDEFAULTTOKEN This object specifies a capability token provided by the site administrator that sets the definition of the default token in a DMCAPABILITYGROUP.

Key Data Type: String Description: The name of the DM that generated this DMCAPABILITYDEFAULTTOKEN. and change whenever the DM sends a new DMP CONFIG command up to the MMS. 88 Copyright © 2000 IEEE.10.DriveName Default: None Depends On: DRIVE.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Data Type: String Description: The name of the drive for this DMCAPABILITYDEFAULTTOKEN.DMName Default: None Depends On: DM. Allowed Values: One of the values for DM. All rights reserved. The capability group information is used when performing the rendezvous between the application-desired capability tokens and the DM-offered capability tokens.3 DMCapabilityToken Name: DMCapabilityToken Type: Characteristic Data Type: String Description: A particular capability token associated with a DM as the new default token for whatever capability group in which that token is found. See the DMP language definition (IEEE Std 1244.IEEE Std 1244. Allowed Values: Any Default: None Depends On: None Depended On By: None 14. .1.1.DriveName Depended On By: None 14. Each DM offers a set of capability groups to the MMS. Allowed Values: One of the values for DRIVE.2 DMName Name: DMName Type: Characteristic.DMName Depended On By: None 14.4-2000) for more detailed information.11 DMCAPABILITYGROUP object This object represents a group of mutually exclusive capabilities offered by a DM.10. All DMCAPABILITYGROUP structures are created and deleted on behalf of the DM. Each capability group is composed of a mutually exclusive set of DMCAPABILITYGROUPTOKENs.

1.2 DMName Name: DMName Type: Characteristic. Allowed Values: One of the values for DM.1 Attributes of the DMCAPABILITYGROUP object 14. Allowed Values: Any Default: None Depends On: None Depended On By: DMCAPABILITYGROUPTOKEN.DMName 14.DriveName Default: None Depends On: DRIVE. All rights reserved. Allowed Values: One of the values for DRIVE.DriveName Depended On By: DMCAPABILITYGROUPTOKEN.DMCapabilityGroupName 14. 89 .1 DriveName Name: DriveName Type: Characteristic.11. Key Data Type: String Description: The name of the drive for this DMCAPABILITYGROUP.1.DMName Depended On By: DMCAPABILITYGROUPTOKEN.11.1.11. Key Data Type: String Description: The name of this capability group.1.DriveName 14.11.3 DMCapabilityGroupName Name: DMCapabilityGroupName Type: Characteristic.1-2000 14.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. Key Data Type: String Description: The name of the DM to which this capability set applies.11.4 DMCapabilityGroupDefaultName Name: DMCapabilityGroupDefaultName Type: Characteristic Data Type: String Copyright © 2000 IEEE.DMName Default: None Depends On: DM.

14.1 The attributes of the DMCAPABILITYGROUPTOKEN object 14. by virtue of being part of the MMS documentation set. . Each token is simply a text string. All rights reserved. The tokens are simply agreed upon in advance. For example.1. "access" Default: access Depends On: None Depended On By: None 14. See the DMP language definition (IEEE Std 1244.IEEE Std 1244.5 DMCapabilityGroupType Name: DMCapabilityGroupType Type: Characteristic Data Type: Enumerated Description: The group can represent either capability tokens that affect the interchange of a cartridge between drive types ("interchange") or not ("access").12 DMCAPABILITYGROUPTOKEN A DMCAPABILITYGROUPTOKEN is a capability token included with a DMCAPABILITYGROUP. and change whenever the DM sends a new DMP CONFIG command up to the MMS. Allowed Values: "interchange".DriveName Default: None Depends On: DMCAPABILITYGROUP. Allowed Values: One of the values for DMCAPABILITYGROUP.DriveName Depended On By: None 90 Copyright © 2000 IEEE.1 DriveName Name: DriveName Type: Characteristic.12.4-2000) for more detailed information.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Description: The default capability token for this capability group. but it represents some characteristic of the drive that an application may request be used for any given mount.1. compression and nocompression are valid tokens. Allowed Values: Any Default: None Depends On: None Depended On By: None 14.12. Each DMCAPABILITYGROUP contains a set of capability tokens. All DMCAPABILITYGROUPTOKEN structures are created and deleted on behalf of the DM. and are then compared for equality at run time. Key Data Type: String Description: The name of the drive for this DMCAPABILITYGROUP.11.

2 DMName Name: DMName Type: Characteristic.1-2000 14.12.1.12.1.DMName Default: None Depends On: DMCAPABILITYGROUP. All rights reserved.1.1. Key Data Type: String Description: The name of this capability group.1. Allowed Values: One of the values for DMCAPABILITYGROUP. Allowed Values: One of the values for DMCAPABILITYGROUP. Copyright © 2000 IEEE.12.2. Key Data Type: String Description: The name of the DM to which this capability set applies. 91 . Cartridge cluster This cluster defines a cartridge in the MMS.3 DMCapabilityGroupName Name: DMCapabilityGroupName Type: Characteristic.DMName Depended On By: None 14.DMCapabilityGroupName Depended On By: None 14. and includes the objects listed in Table 17. 15.1 Creation and deletion semantics The creation and deletion semantics for a cartridge cluster are outlined in 15. Allowed Values: Any Default: None Depends On: None Depended On By: None 15.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.1 and 15. Key Data Type: String Description: A particular capability token associated with a given capability group.4 DMCapabilityToken Name: DMCapabilityToken Type: Characteristic.DMCapabilityGroupName Default: None Depends On: DMCAPABILITYGROUP.

1. Created by the system depending on the CARTRIDGETYPE object information.IEEE Std 1244. Unless the SIDE is pre-formatted. Describes the group to which this cartridge belongs. Creation of a cartridge simply makes an entry for the cartridge in the database. thereby (together with the DRIVEGROUPAPPLICATION object) allowing different applications to share a library without interfering with each other. 92 Copyright © 2000 IEEE.1 Creation semantics Creation semantics are listed in Table 18. May be created after the CARTRIDGEGROUP and APPLICATION objects have been created.1.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Table 17—Objects included in the cartridge cluster CARTRIDGE object CARTRIDGEGROUP object CARTRIDGEGROUPAPPLICATION object Describes the basic characteristics of a piece of removable media. Describes a partition on a side of a cartridge. Lists the types of cartridges available in the entire MMS.2 Deletion semantics Deletion semantics are listed in Table 19. then creates the PARTITION records inside the MMS to match those it created on the media. uses possibly device-specific control commands to lay out the partition information on the media. CARTRIDGETYPE object SIDE object PARTITION object VOLUME object 15. Table 18—Creation semantics CARTRIDGE object May not be created until its CARTRIDGETYPE is created. May not be deleted until all CARTRIDGE objects of that type have been deleted. Table 19—Deletion semantics CARTRIDGE object CARTRIDGETYPE object May not be deleted until all of the objects depending on it in the Cartridge Cluster are deleted. Relates the Cartridge Group to an Application. All rights reserved. Describes a volume on a partition. CARTRIDGEGROUPAPPLICATION object SIDE object (or objects) PARTITION objects 15. . It is not necessarily assigned to an APPLICATION or CARTRIDGEGROUP. Describes a side of a cartridge. these are created on a side by a special-purpose application that mounts a SIDE.

a CDROM or DVDROM. TASKCARTRIDGE.2 CartridgePCL Name: CartridgePCL Type: Characteristic Data Type: String Description: The PCL.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. All rights reserved. This could be a tape. MOUNTPHYSICAL. In order to support the wide range of removable media. SLOT Copyright © 2000 IEEE. shall be unique for all cartridges with the same SlotTypeName (implied by the CartridgeTypeName).1. etc. Subsequently. a magneto-optical disk. A new CartridgeID is automatically assigned when the cartridge is created.2. which shall be set when the cartridge is created. SIDE. The ApplicationName attribute records this association. When the first VOLUME is created on a cartridge. 93 . The system administrator creates the cartridge object in order to add a cartridge to the MMS. MOUNTPHYSICAL. SLOT.1 The attributes of the CARTRIDGE object 15. Allowed Values: Any Default: None Depends On: None Depended On By: MOUNTLOGICAL.2. an external marking on the cartridge that may be human. This information is used to automatically create the correct number of SIDE structures and to name each of them. Each PARTITION may contain zero or more VOLUMEs. only volumes owned by that same application may be created on that cartridge (if more that one volume can fit). Each CARTRIDGE is composed of one or more SIDEs. The CartridgePCL. PARTITION. Each SIDE is composed of zero or more PARTITIONs. Allowed Values: Any Default: None Depends On: None Depended On By: DRIVE.and/or machine-readable.2. A CartridgeTypeName shall be given when a cartridge is created. VOLUME 15.2 The CARTRIDGE object The CARTRIDGE object represents one piece of removable media. Key Data Type: UUID Description: Unique identifier generated by the system for this cartridge. the cartridge becomes owned by the application that owns the volume. 15.1.1 CartridgeID Name: CartridgeID Type: Characteristic.1-2000 15. the MMS has a fairly flexible view of the composition of a cartridge.

2.IEEE Std 1244. See IEEE Std 1244.1.2.1.2. 94 Copyright © 2000 IEEE. Default: "defined" Depends On: None Depended On By: None 15.CartridgeGroupName. "identified". "error".1.3 CartridgeState Name: CartridgeState Type: Status Data Type: Enumerated Description: The name of the state for this cartridge. Allowed Values: One of the values for CARTRIDGETYPE.CartridgeTypeName Depended On By: None 15.1.2.CartridgeTypeName Default: None Depends On: CARTRIDGETYPE. "allocated".3-2000 for a definition of these terms. "deallocated".4 CartridgeTypeName Name: CartridgeTypeName Type: Characteristic Data Type: String Description: The type of cartridge. . or "false" Default: "false" Depends On: CARTRIDGEGROUP. "recycled". All rights reserved.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 15.5 CartridgeGroupName Name: CartridgeGroupName Type: Control Data Type: String Description: The name of the CARTRIDGEGROUP for this cartridge Allowed Values: One of the values for CARTRIDGEGROUP.CartridgeGroupName Depended On By: None 15. Allowed Values: One of the following: "defined". "allocatable".6 CartridgeTimeCreated Name: CartridgeTimeCreated Type: Status Data Type: Timestamp Description: The date/time when this cartridge record was created.

Allowed Values: Any Default: 0 Depends On: None Depended On By: None Copyright © 2000 IEEE.1.2.1-2000 Allowed Values: Any Default: None—this value is set when the cartridge is created Depends On: None Depended On By: None 15.2. All rights reserved.1. 95 .SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.2. Allowed Values: Any Default: 0 Depends On: None Depended On By: None 15. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 15.8 CartridgeTimeMountedTotal Name: CartridgeTimeMountedTotal Type: Status Data Type: Duration Description: The total amount of time that the cartridge has been mounted since it was created.7 CartridgeTimeMountedLast Name: CartridgeTimeMountedLast Type: Status Data Type: Timestamp Description: The date/time when this cartridge was last mounted in a drive.1.9 CartridgeNumberMounts Name: CartridgeNumberMounts Type: Status Data Type: Integer Description: The total number of times that the cartridge has been mounted since it was created.

ApplicationName Depended On By: None 15.* Type: Client Data Type: String Description: Additional attributes can be added to this record by the application that owns the cartridge. notes.LibraryName Depended On By: None 15. Allowed Values: One of the values for APPLICATION.IEEE Std 1244.1.1. Allowed Values: Any Default: 0 Depends On: None Depended On By: None 15.2.2.11 ApplicationName Name: ApplicationName Type: Status Data Type: String Description: The name of the application that owns the cartridge.2.13 Client-defined attributes Name: .1.1. Examples include comments.10 CartridgeNumberVolumes Name: CartridgeNumberVolumes Type: Status Data Type: Integer Description: The total number of volumes that currently exist on all sides/partitions of this cartridge. . 96 Copyright © 2000 IEEE.2. if any.12 LibraryName Name: LibraryName Type: Status Data Type: String Description: The name of the library that currently contains this cartridge.ApplicationName Default: "false" Depends On: APPLICATION.LibraryName Default: None—this attribute is set when the cartridge object is created Depends On: LIBRARY. All rights reserved. Allowed Values: One of the values for LIBRARY. and site-specific controls.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 15.

CARTRIDGEGROUPs are used to aggregate cartridges.3. Allowed Values: Any Default: 1000 Depends On: None Depended On By: None Copyright © 2000 IEEE. All rights reserved. Each cartridge must belong to only one CARTRIDGEGROUP.1 CartridgeGroupName Name: CartridgeGroupName Type: Characteristic.1. Allowed Values: Any Default: None Depends On: None Depended On By: CARTRIDGE.1. CARTRIDGEGROUPAPPLICATIONs records are used to allow applications to access particular CARTRIDGEGROUPs.1 The attributes of the CARTRIDGEGROUP object 15. Key Data Type: String Description: The name of the cartridge group. and then to support both an access permissions model and a preferential usage policy.3.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.3. 97 . 15.2 CartridgeGroupPriority Name: CartridgeGroupPriority Type: Control Data Type: Integer Description: The default priority that the application places on cartridges in the named group if the CARTRIDGEGROUPAPPLICATION record specifies a negative priority.1-2000 Allowed Values: Any Default: None Depends On: None Depended On By: None 15.3 The CARTRIDGEGROUP object A named group to which cartridges can belong. CARTRIDGEGROUPAPPLICATION 15.

ApplicationName Depended On By: None 15.4.4.ApplicationName Default: None Depends On: APPLICATION.1. This link lets allows an administrator to set a preference sequence for cartridges when allocating volumes for a particular application.1 The attributes of the CARTRIDGEGROUPAPPLICATION object 15. Examples include comments.4 The CARTRIDGEGROUPAPPLICATION object The CARTRIDGEGROUPAPPLICATION object represents a linkage that allows an application access to a cartridge group.3.CartridgeGroupName 98 Copyright © 2000 IEEE.* Type: Client Data Type: String Description: Additional attributes can be added to this record by the application that owns the cartridge group. Key Data Type: String Description: The name of the application getting access to the cartridge group.2 CartridgeGroupName Name: CartridgeGroupName Type: Characteristic. A cartridge may belong to only one CARTRIDGEGROUP. Key Data Type: String Description: The name of the cartridge group to which the application has been given access.3 Client-defined attributes Name: . and site-specific controls. Allowed Values: One of the values for CARTRIDGEGROUP. 15. Allowed Values: Any Default: None Depends On: None Depended On By: None 15. All rights reserved.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 15. with the lowest value being given preference.1. CARTRIDGEGROUPAPPLICATIONs records are used to allow applications to access particular CARTRIDGEGROUPs. notes. Allowed Values: One of the values for APPLICATION.IEEE Std 1244.4.1.1 ApplicationName Name: ApplicationName Type: Characteristic. The groups are ordered by the CartridgeGroupApplicationPriority field. .

3 CartridgeGroupApplicationPriority Name: CartridgeGroupApplicationPriority Type: Control Data Type: Integer Description: The priority that the application places on cartridges in the named group..1-2000 Default: None Depends On: CARTRIDGEGROUP. the first side would take its name from the value of the attribute called Side1Name.CartridgeGroupName Depended On By: None 15. 1. Key Data Type: String Description: The name of this type of cartridge. Allowed Values: Any Default: None Depends On: None Depended On By: CARTRIDGE Copyright © 2000 IEEE. 2. 15.4. Allowed Values: Any Default: 1000 Depends On: None Depended On By: None 15.5.1 The attributes of the CARTRIDGETYPE Object 15.1.1 CartridgeTypeName Name: CartridgeTypeName Type: Characteristic.. since the Side?Name attribute is actually a group of attributes where the ? in the attribute name is replaced by a positive integer number. For example.5 The CARTRIDGETYPE object The CARTRIDGETYPE object represents a class of cartridges. There is one attribute of this type for each side. n. the system will automatically create the number of SIDEs that this CARTRIDGETYPE record shows that type of cartridge should have. Various constant characteristics of each type of cartridge are defined in this one place. All rights reserved. This object has a variable number of attributes. The name given to each SIDE that is created is the value of one of the corresponding attributes here. where n is the number of sides. while the second side would take its name from the value of the attribute called Side2Name. .. When a CARTRIDGE is created.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. 99 .5.1.

Allowed Values: a) b) c) d) e) "data"—A data cartridge. Default: None Depends On: None Depended On By: None 100 Copyright © 2000 IEEE.1. .4 CartridgeTypeMediaType Name: CartridgeTypeMediaType Type: Characteristic Data Type: Enumerated Description: The type of media contained in this type of cartridge.1.IEEE Std 1244.5.1. "diagnostic"—A cartridge used to run diagnostic programs for the drive.5. "cleaning"—A cartridge used to clean the drive heads.5.2 CartridgeTypeNumberSides Name: CartridgeTypeNumberSides Type: Characteristic Data Type: Integer Description: The number of sides for this type of cartridge. Allowed Values: Any Default: None Depends On: None Depended On By: None 15. Allowed Values: Any Default: 1 Depends On: None Depended On By: None 15.3 CartridgeTypeMediaLength Name: CartridgeTypeMediaLength Type: Characteristic Data Type: Integer Description: The length of the media for this type of cartridge.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 15. "microcode"—A cartridge used to update the drive’s microcode. All rights reserved. "alignment"—A cartridge used to test or correct the drive’s alignment.

This is actually a group of attributes where the ? in the attribute name is replaced by a positive integer.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.1.5.) Type: Characteristic Data Type: String Description: The name(s) used by each SIDE of the cartridge. Side2Name. Allowed Values: One of the values for SLOTTYPE.5.1. All rights reserved.5 MaxUseCount Name: MaxUseCount Type: Client Data Type: String Description: An advisory field indicating suggested maximum usage count.5. Allowed Values: Any non-negative numeric value Default: None Depends On: None Depended On By: None 15. etc.CartridgeShapeName Default: None Depends On: SLOTTYPE.* Type: Client Data Type: String Copyright © 2000 IEEE.1.5.1-2000 15.7 Side?Name Name: Side?Name (Side1Name.6 CartridgeShapeName Name: CartridgeShapeName Type: Characteristic Data Type: String Description: The external shape of the cartridge. Allowed Values: Any Default: None Depends On: None Depended On By: None 15.CartridgeTypeName Depended On By: None 15. 101 .8 System-defined attributes Name: .1.

CartridgeID Default: None Depends On: CARTRIDGE. VOLUME 102 Copyright © 2000 IEEE.6. Allowed Values: One of the values for CARTRIDGETYPE. The name given to each SIDE that is created is the value of the corresponding CARTRIDGETYPE. Key Data Type: UUID Description: The UUID of the cartridge. Tape media will very likely only have one side.1.1 CartridgeID Name: CartridgeID Type: Characteristic.IEEE Std 1244.CartridgeID Depended On By: None 15. and site-specific controls.2 SideName Name: SideName Type: Characteristic. Key Data Type: String Description: The name of this side of the given cartridge. the system will automatically create the number of SIDEs that the corresponding CARTRIDGETYPE record shows this type of cartridge should have. When a CARTRIDGE is created. Allowed Values: One in the values for CARTRIDGE. All rights reserved.Side?Name Depended On By: MOUNTLOGICAL. PARTITION.6.6. notes.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Description: Additional attributes can be added to this record by the system.6 The SIDE object A SIDE is the portion of a cartridge that may be accessed during a given physical mount. Examples include comments. while magneto-optical disk media will likely have two sides. MOUNTPHYSICAL. Allowed Values: Any Default: None Depends On: None Depended On By: None 15.1 The attributes of the SIDE object 15.Side?Name attribute.Side?Name Default: None Depends On: CARTRIDGETYPE. 15.1. .

6 SideTimeMountedTotal Name: SideTimeMountedTotal Type: Status Data Type: Duration Copyright © 2000 IEEE. 103 . All rights reserved.6. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 15.1-2000 15.5 SideTimeMountedLast Name: SideTimeMountedLast Type: Status Data Type: Timestamp Description: The date/time when this side was last mounted.1.4 SideTimeCreated Name: SideTimeCreated Type: Status Data Type: Timestamp Description: The date/time when this side was created Allowed Values: Any Default: None—this must be set when the side is created Depends On: None Depended On By: None 15.3 SideNumberMounts Name: SideNumberMounts Type: Status Data Type: Integer Description: The number of times that this side has been mounted.6.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.6.1.1. Allowed Values: Any Default: 0 Depends On: None Depended On By: None 15. Note that this includes all the times that partitions and volumes on this side have been mounted.1. Note that this includes all the times that partitions and volumes on this side have been mounted.6.

a volume is created through the MMP allocate command). notes. On some systems. The PARTITION record of a non-blank partition is typically created with the PartitionBitformat set to the appropriate bitformat. 104 Copyright © 2000 IEEE. Most disk drivers require that some form of partition information is laid out on the media. Default: None Depends On: None Depended On By: None 15.IEEE Std 1244. while magneto-optical disk media will likely have more than one partition per side. The PartitionBitFormat and PartitionAllocatable attributes are both set/modified by the system during normal operation. Examples include comments.. The value of this field will remain "false" even after the deallocation of the volume mapped to the partition. All rights reserved.e. and can be set by an administrative application. uses (possibly) device-specific control commands to lay out the partition information on the media.e. mount the volume mapped to the partition) for writing. Note that this includes all the times that partitions and volumes on this side have been mounted. Unless the SIDE is pre-partitioned. The PARTITION record for a blank partition is typically created with the PartitionBitformat field unset.. Allowed Values: Any. Tape media will very likely only have one partition per side (although some tapes support partitions).7 Client-defined attributes Name: . random access media such as magneto-optical disks are supported by a disk driver rather than a tape driver. and site-specific controls. until such time the cartridge is recycled. the PARTITION objects are created on a side by a special-purpose application that mounts a SIDE. . The ALLOCATE PartitionAllocatable field is set to "false" when a volume is mapped to an unallocated partition (i.1.7 The PARTITION object A partition is one portion of a side of a cartridge.6. The MMS will set this field the first time an application mounts the partition (i. Command will set both fields when it creates a VOLUME record for a partition.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Description: The total time this side has been mounted. Default: 0 Depends On: None Depended On By: None 15. and then creates the PARTITION records inside the MMS to match those it created on the media.* Type: Client Data Type: String Description: Additional attributes can be added to this record by the Application that owns the cartridge. Allowed Values: The total amount of time that this side has been mounted.

7. 15. It is possible for an administrative application to create multiple VOLUME records for different applications that all point to the same PARTITION record.1 CartridgeID Name: CartridgeID Type: Characteristic.CartrdigeID Default: None Depends On: CARTRIDTE.Side?Name Default: None Depends On: SIDE. Key Data Type: String Description: The name of the side on which this partition is located. This is how PARTITIONs are shared between applications. Allowed Values: One of the values for SIDE. 105 . Allowed Values: Any Default: None Depends On: None Depended On By: VOLUME Copyright © 2000 IEEE.1.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. Allowed Values: One of the values for CARTRIDGE. Key Data Type: UUID Description: The UUID of the cartridge on which this partition is located.2 SideName Name: SideName Type: Characteristic.3 PartitionName Name: PartitionName Type: Characteristic.Side?Name Depended On By: None 15.1 The attributes of the PARTITION object 15. Key Data Type: String Description: The name of this partition.1.7. All rights reserved.1-2000 A VOLUME record maps onto an entire partition and provides an application defined name for that partition.CartridgeID Depended On By: None 15.7.1.7.

Allowed Values: One of the values for DMBITFORMAT. "false" Default: "true" Depends On: None Depended On By: None 15.1.7 PartitionSignature Name: PartitionSignature Type: Client Data Type: String Description: The value of the partition signature. All rights reserved.1.6 PartitionAllocatable Name: PartitionAllocatable Type: Status Data Type: Boolean Description: Determines whether or not this partition can be allocated to a requesting application. if any.7.7. Allowed Values: "true".DMBitformatName Depended On By: None 15.7.IEEE Std 1244.7. .1.5 PartitionBitFormat Name: PartitionBitFormat Type: Characteristic Data Type: String Description: The name of the recording technique used for writing to this partition.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 15. Allowed Values: Any Default: 0 Depends On: None Depended On By: None 15.DMBitformatName Default: None Depends On: DMBITFORMAT.4 PartitionSize Name: PartitionSize Type: Characteristic Data Type: Integer Description: The number of megabytes that can be stored on this partition. The partition signature may be written either by the client that owns the partition (and the client should do so whenever rewriting the portion of the partition that 106 Copyright © 2000 IEEE.1.

and in the event of certain abnormal termination conditions such as a power failure. "unknown"—PartitionSignature must be "undefined". "application"—The application provided the signature.9 PartitionSignatureAlgorithm Name: PartitionSignatureAlgorithm Type: Characteristic Data Type: String Description: The name of the Algorithm used to generate the partition signature. g) Allowed Values: Any Default: "unimplemented" Depends On: None Depended On By: None 15. it is rewritten whenever a partition that was mounted write-enabled is unmounted. 107 . "sysactive"—The DM generated the signature.7.1-2000 is covered by the signature). or it may be managed automatically by the MMS.1.7. "appactive"—The application provided the signature. If it is managed automatically. "system"—The DM generated the signature. the signature might not match the media.8 PartitionSignatureState Name: PartitionSignatureState Type: Characteristic Data Type: Enumerated Description: a) b) c) d) e) f) "unimplemented"—PartitionSignature must be "undefined". "uninitialized"—The partition is blank. The media is currently in use. All rights reserved. the signature might not match the media. Allowed Values: Any Default: "undefined" Depends On: None Depended On By: None 15. and in the event of certain abnormal termination conditions such as a power failure.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. The media is currently in use. in which case PartitionSignature must be "undefined". Allowed Values: Any Default: "undefined" Depends On: None Depended On By: None Copyright © 2000 IEEE.1.

IEEE Std 1244.1-2000

IEEE STANDARD FOR MEDIA MANAGEMENT

15.7.1.10 PartitionMediaSerial Name: PartitionMediaSerial Type: Characteristic Data Type: String Description: The value of the partition media serial. Allowed Values: Any Default: "undefined" Depends On: None Depended On By: None 15.7.1.11 PartitionMediaSerialState Name: PartitionMediaSerialState Type: Characteristic Data Type: Enumerated Description: The state of the partition media serial. Allowed Values: a) b) c) d) "unknown"—The serial is unknown. "uninitialized"—The tape is blank. "known"—There is a value for the PartitionMediaSerial. "unimplemented"—This feature is not supported.

In all cases except "known", the value of PartitionMediaSerial shall be "undefined". Default: "unknown" Depends On: None Depended On By: None 15.7.1.12 PartitionNumberMounts Name: PartitionNumberMounts Type: Status Data Type: Integer Description: The number of times that this partition has been mounted. Allowed Values: Any Default: 0 Depends On: None Depended On By: None

108

Copyright © 2000 IEEE. All rights reserved.

SYSTEM (MMS) ARCHITECTURE

IEEE Std 1244.1-2000

15.7.1.13 PartitionTimeCreated Name: PartitionTimeCreated Type: Status Data Type: Timestamp Description: The date/time when this partition was created. Allowed Values: Any Default: None—this is set when the partition is created Depends On: None Depended On By: None 15.7.1.14 PartitionTimeMountedTotal Name: PartitionTimeMountedTotal Type: Status Data Type: Duration Description: The total amount of time that this partition has been mounted. Allowed Values: Any Default: 0 Depends On: None Depended On By: None 15.7.1.15 PartitionTimeMountedLast Name: PartitionTimeMountedLast Type: Status Data Type: Timestamp Description: The date/time when this partition was last mounted. Allowed Values: Any Default: None—this is updated whenever the partition is mounted. Depends On: None Depended On By: None 15.7.1.16 Client-defined attributes Name: .* Type: Client Data Type: String Description: Additional attributes can be added to this record by the application that owns the partition. Examples include comments, notes, and site-specific controls.

Copyright © 2000 IEEE. All rights reserved.

109

IEEE Std 1244.1-2000

IEEE STANDARD FOR MEDIA MANAGEMENT

Allowed Values: Any Default: None Depends On: None Depended On By: None

15.8 The VOLUME object
A VOLUME is an application defined name for a partition. When an application issues the allocate command, the end result is a new VOLUME record pointing to a previously unused PARTITION. Various CARTRIDGEGROUPAPPLICATION, CARTRIDGEGROUP, CARTRIDGE, and PARTITION records come into play and may be modified during this process. A VOLUME record maps onto an entire partition and provides an application-defined name for that partition. It is possible for an administrative application to create multiple VOLUME records for different applications that all point to the same PARTITION record. This is how VOLUMEs are shared between applications. 15.8.1 The attributes of the VOLUME object 15.8.1.1 ApplicationName Name: ApplicationName Type: Characteristic, Key Data Type: String Description: The name of the application that owns this volume. Allowed Values: One of the values for APPLICATION.ApplicationName Default: None Depends On: APPLICATION.ApplicationName Depended On By: None 15.8.1.2 VolumeName Name: VolumeName Type: Characteristic, Key Data Type: String Description: The name of this volume. This name must be unique within the given application’s set of volumes, but may be non-unique globally. Allowed Values: Any Default: None Depends On: None Depended On By: MOUNTLOGICAL, MOUNTPHYSICAL

110

Copyright © 2000 IEEE. All rights reserved.

SideName Depended On By: None 15.1.3 CartridgeID Name: CartridgeID Type: Characteristic Data Type: UUID Description: The unique identifier for the cartridge on which this volume is located.SideName Default: None Depends On: PARTITION.PartitionName Default: None Depends On: PARTITION.8.8. Allowed Values: One of the values for PARTITION. 111 .CartridgeID Default: None Depends On: PARTITION.1-2000 15. Allowed Values: One of the values for PARTITION.8.4 SideName Name: SideName Type: Characteristic Data Type: String Description: The name of the side on which this volume is located.PartitionName Depended On By: None 15. Allowed Values: One of the values for PARTITION.5 PartitionName Name: PartitionName Type: Characteristic Data Type: String Description: The name of the partition in which this volume is located.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. All rights reserved.8.1.1.CartridgeID Depended On By: None 15.6 VolumeNumberMounts Name: VolumeNumberMounts Type: Status Data Type: Integer Description: The total number of times that this volume has been mounted.1. Allowed Values: Any Copyright © 2000 IEEE.

All rights reserved.1.* 112 Copyright © 2000 IEEE.IEEE Std 1244.8.10 Client-defined attributes Name: . Allowed Values: Any Default: 0 Depends On: None Depended On By: None 15. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 15.8 VolumeTimeMountedLast Name: VolumeTimeMountedLast Type: Status Data Type: Timestamp Description: The date/time when this volume was last mounted.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Default: 0 Depends On: None Depended On By: None 15.1. Allowed Values: Any Default: None—this attribute is set when the volume is created Depends On: None Depended On By: None 15.7 VolumeTimeCreated Name: VolumeTimeCreated Type: Status Data Type: Timestamp Description: The date/time when this volume was created.8.9 VolumeTimeMountedTotal Name: VolumeTimeMountedTotal Type: Status Data Type: Duration Description: The total time that this volume has been mounted.8. .8.1.1.

113 . Characteristic. 16. notes. All rights reserved. the application may want to access the volume in both compression and noncompression modes during one mount session. only one such access mode is allowed to be active at any one time. Table 20—Objects included in the mount cluster MOUNTLOGICAL object MOUNTPHYSICAL object STALEHANDLE object DRIVECARTRIDGEACCESS object Specifies the volumes that are currently mounted. Allowed Values: Any Default: None Depends On: None Depended On By: None 16. The MOUNTLOGICAL object is a system object that is created automatically whenever a volume is mounted. Describes which cartridges are currently mounted and their respective drives. All of the objects in this cluster are created by the system as the result of activities requested by clients of the system. Examples include comments. if the drive is a tape drive. and includes the following objects listed in Table 20.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.1-2000 Type: Client Data Type: String Description: Additional attributes can be added to this record by the application that owns the volume.2 ApplicationName Name: ApplicationName Type: Status.1.1. Key Copyright © 2000 IEEE. implying a close and subsequent reopen between access modes. More than one logical handle may be created for the same drive at the same time if the application has simultaneously requested multiple access modes at once. and site-specific controls. Note that on most systems. The mount cluster This cluster describes the currently mounted cartridges and volumes in the MMS. One instance of this record type is created for each logical handle created to a drive that is created. 16. For example. Describes handles that are left over after a crash.1 The attributes of the MOUNTLOGICALobject 16.1 The MOUNTLOGICAL object This object tracks which VOLUMEs are currently mounted. Specifies the error and usage statistics for currently mounted cartridges and their drives.

Allowed Values: One of the values for VOLUME.ApplicationName Default: None Depends On: VOLUME.2 PartitionName Name: PartitionName Type: Status.3 SideName Name: SideName Type: Status.SideName Depended On By: None 114 Copyright © 2000 IEEE.1 VolumeName Name: VolumeName Type: Status. Characteristic Data Type: String Description: The name of the partition that is mounted.1.ApplicationName Depended On By: None 16.1.SideName Default: None Depends On: VOLUME.IEEE Std 1244.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Data Type: String Description: The Name of the application that owns the mounted volume.2.PartitionName Default: None Depends On: VOLUME. .PartitionName Depended On By: None 16.2. Characteristic Data Type: String Description: The name of the side that is mounted. Characteristic.1. Key Data Type: String Description: The name of the volume that is mounted.2.VolumeName Depended On By: None 16. Note that this may be empty if this is a mount of a side. Allowed Values: One of the values for VOLUME. All rights reserved. Allowed Values: One of the values for VOLUME. Allowed Values: One of the values for VOLUME.VolumeName Default: None Depends On: VOLUME.

115 . Status Data Type: String Description: The name of the drive in which the cartridge is mounted.2.1.1.6 DMName Name: DMName Type: Characteristic.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.DriveName Depended On By: None 16.2.DMCapabilityName Copyright © 2000 IEEE. Allowed Values: One of the values for DM.5 DriveName Name: DriveName Type: Characteristic.2.4 CartridgeID Name: CartridgeID Type: Characteristic. Allowed Values: One of the values for DMCAPABILITY.1.1.DMName Default: None Depends On: DM.CartridgeID Depended On By: None 16.DMName Depended On By: None 16.DriveName Default: None Depends On: DM.CartridgeID Default: None Depends On: VOLUME.1-2000 16. Status Data Type: UUID Description: The UUID of the cartridge that is mounted. Status Data Type: String Description: The name of the DM controlling the drive in which the cartridge is mounted.2. All rights reserved. Allowed Values: One of the values for VOLUME.7 DMCapabilityName Name: DMCapabilityName Type: Status Data Type: String Description: The capability set that the drive is using for this mount. Allowed Values: One of the values for DM.

IEEE Std 1244.1-2000

IEEE STANDARD FOR MEDIA MANAGEMENT

Default: None Depends On: DMCAPABILITY.DMCapabilityName Depended On By: None 16.1.2.8 MountLogicalHandle Name: MountLogicalHandle Type: Status Data Type: String Description: The drive access handle that the client is using to access the drive. Allowed Values: Any Default: None Depends On: None Depended On By: None 16.1.2.9 MountLogicalTimeWhenMounted Name: MountLogicalTimeWhenMounted Type: Status Data Type: Timestamp Description: The date/time when the MOUNTLOGICAL handle above was created. Note that this might be different from the time when the cartridge was mounted. Allowed Values: Any Default: None—this is set on creation Depends On: None Depended On By: None

16.2 The MOUNTPHYSICAL object
This object represents a CARTRIDGE that is currently mounted in a DRIVE. This is a status object that is automatically created by the system when a cartridge is mounted. 16.2.1 The Attributes of the MOUNTPHYSICAL Object 16.2.1.1 ApplicationName Name: ApplicationName Type: Characteristic, Status, Key Data Type: String Description: The name of the application that requested the mount. Allowed Values: One of the values for APPLICATION.ApplicationName

116

Copyright © 2000 IEEE. All rights reserved.

SYSTEM (MMS) ARCHITECTURE

IEEE Std 1244.1-2000

Default: None Depends On: APPLICATION.ApplicationName Depended On By: None 16.2.1.2 DriveName Name: DriveName Type: Characteristic, Status, Key Data Type: String Description: The name of the drive in which the cartridge was mounted. Allowed Values: One of the values for DRIVE.DriveName Default: None Depends On: DRIVE.DriveName Depended On By: None 16.2.1.3 LibraryName Name: LibraryName Type: Characteristic, Status, Key Data Type: String Description: The name of the library for the drive. Allowed Values: One of the values for DRIVE.LibraryName Default: None Depends On: DRIVE.LibraryName Depended On By: None 16.2.1.4 CartridgeID Name: CartridgeID Type: Characteristic, Status, Key Data Type: UUID Description: The UUID of the cartridge that was mounted. Allowed Values: One of the values for CARTRIDGE.CartridgeID Default: None Depends On: CARTRIDGE.CartridgeID Depended On By: None

Copyright © 2000 IEEE. All rights reserved.

117

IEEE Std 1244.1-2000

IEEE STANDARD FOR MEDIA MANAGEMENT

16.2.1.5 CartridgePCL Name: CartridgePCL Type: Characteristic, Status Data Type: String Description: The PCL of the cartridge that was mounted. Allowed Values: One of the values for CARTRIDGE.CartridgePCL Default: None Depends On: CARTRIDGE.CartridgePCL Depended On By: None 16.2.1.6 SideName Name: SideName Type: Characteristic, Status, Key Data Type: String Description: The name of the side that was mounted. Allowed Values: One of the values for SIDE.SideName Default: None Depends On: SIDE.SideName Depended On By: None 16.2.1.7 SlotName Name: SlotName Type: Characteristic, Status Data Type: String Description: The SlotID that the cartridge was in just prior to being mounted. Allowed Values: One of the values for SLOT.SlotName Default: None Depends On: SLOT.SlotName Depended On By: None 16.2.1.8 MountPhysicalTimeWhenMounted Name: MountPhysicalTimeWhenMounted Type: Status Data Type: Timestamp Description: The date/time when the cartridge was mounted into the drive. Allowed Values: Any

118

Copyright © 2000 IEEE. All rights reserved.

DriveName Depended On By: None 16. 16.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. These records can also be used as the basis for a charge-back system.1.3. and the associated usage and error statistics.3 The DRIVECARTRIDGEACCESS object These objects keep track of which CARTRIDGEs were mounted in which DRIVEs.DMName Default: None Copyright © 2000 IEEE. and the usage and error statistics. This information can be used to monitor the error rate of a given drive by MATCHing on the drive name and ORDERing the results by time. A DRIVECARTRIDGEACCESS record is created to store the who/what/when of the mount. Allowed Values: One of the values for DM.1 The Attributes of the DRIVECARTRIDGEACCESS Object 16. All rights reserved.3. the DM forwards to the MMS several statistics about the utilization of the drive during that mount. System. They store the time a cartridge was mounted and the amount of data transferred by the application. Key Data Type: String Description: The name of the drive in which the cartridge was mounted. Allowed Values: One of the values for DM. The system will not automatically delete DRIVECARTRIDGEACCESS records. 119 .1.3.DriveName Default: None Depends On: DM. This status object is created by the system. System.2 DMName Name: DMName Type: Characteristic. When each cartridge is unloaded.1-2000 Default: None—this is set on creation Depends On: None Depended On By: None 16.1 DriveName Name: DriveName Type: Characteristic. It can also be used to monitor the error rate of a given cartridge by MATCHing on the CartridgeID and ORDERing the results by time. Key Data Type: String Description: The name of the DM that controlled the drive. it is dependent on an external administrative application to make use of the information if it desires.

Key Data Type: String Description: The name of the SIDE that was mounted.1.SideName Depended On By: None 16.DMName Depended On By: None 16.3 CartridgeID Name: CartridgeID Type: Characteristic. System.3.4 SideName Name: SideName Type: Characteristic.CartridgeID Default: None Depends On: PARTITION CartridgeID Depended On By: None 16. All rights reserved.3.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Depends On: DM.3.5 PartitionName Name: PartitionName Type: Characteristic.6 ApplicationName Name: ApplicationName Type: Characteristic.1. Allowed Values: One of the values for PARTITION.3. System. . Allowed Values: One of the values for PARTITION.1.1. Key Data Type: String Description: The name of the partition that was mounted. Key Data Type: UUID Description: The UUID of the cartridge that was mounted. System. Allowed Values: One of the values for PARTITION.IEEE Std 1244.PartitionName Default: None Depends On: PARTITION.PartitionName Depended On By: None 16. System 120 Copyright © 2000 IEEE.SideName Default: None Depends On: PARTITION.

The value may equal –1 if this information is not available from the device and/or host operating system. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 16.3. 121 . so implementers must ensure that integer representation permits values larger than 32 bits.8 DriveCartridgeAccessTimeUnmount Name: DriveCartridgeAccessTimeUnmount Type: Status Data Type: Timestamp Description: The date/time when the cartridge was unmounted from the drive. Allowed Values: Non-negative.1. Allowed Values: One of the values for APPLICATION. or –1 indicating information not available Default: –1 Copyright © 2000 IEEE.3.1-2000 Data Type: String Description: The name of the application that caused the mount. All rights reserved.7 DriveCartridgeAccessTimeMount Name: DriveCartridgeAccessTimeMount Type: Status.1.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.9 DriveCartridgeAccessByteReadCount Name: DriveCartridgeAccessByteReadCount Type: Status Data Type: Integer Description: A count of the number of bytes read during this use of this cartridge in this drive. Key Data Type: Timestamp Description: The date/time when the cartridge was mounted into the drive.ApplicationName Default: None Depends On: APPLICATION.ApplicationName Depended On By: None 16.3.1. Note that this and other counter values may exceed 231 or 232. Allowed Values: Any Default: None—this is set on creation Depends On: None Depended On By: None 16.

The value may equal –1 if this information is not available from the device and/or host operating system. or –1 indicating information not available Default: –1 Depends On: None Depended On By: None 16. Allowed Values: Non-negative.1. Individual devices are expected to provide more detailed information via devicedefined attributes in the DriveCartridgeAccess object.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Depends On: None Depended On By: None 16. The value may equal –1 if this information is not available from the device and/or host operating system. The value may equal –1 if this information is not available from the device and/or host operating system. .IEEE Std 1244. or –1 indicating information not available Default: –1 Depends On: None Depended On By: None 122 Copyright © 2000 IEEE.11 DriveCartridgeAccessHardReadErrorCount Name: DriveCartridgeAccessHardReadErrorCount Type: Status Data Type: Integer Description: A count of the number of non-recoverable hard errors encountered while reading during this use of this cartridge in this drive.12 DriveCartridgeAccessSoftReadErrorCount Name: DriveCartridgeAccessSoftReadErrorCount Type: Status Data Type: Integer Description: A count of the number of recoverable soft errors encountered while reading during this use of this cartridge in this drive.10 DriveCartridgeAccessByteWriteCount Name: DriveCartridgeAccessByteWriteCount Type: Status Data Type: Integer Description: A count of the number of Bytes Write during this use of this cartridge in this drive.1.3. Individual devices are expected to provide more detailed information via device-defined attributes in the DriveCartridgeAccess object.3.1. Allowed Values: Non-negative. or –1 indicating information not available Default: –1 Depends On: None Depended On By: None 16. All rights reserved.3. Allowed Values: Non-negative.

Allowed Values: Non-negative.13 DriveCartridgeAccessHardWriteErrorCount Name: DriveCartridgeAccessHardWriteErrorCount Type: Status Data Type: Integer Description: A count of the number of nonrecoverable hard errors encountered while writing during this use of this cartridge in this drive.1. The value may equal –1 if this information is not available from the device and/or host operating system.1. or –1 indicating information not available Default: –1 Depends On: None Depended On By: None 16. All rights reserved. Individual devices are expected to provide more detailed information via device-defined attributes in the DriveCartridgeAccess object. 123 . total bytes written. Examples include total bytes read. Allowed Values: Non-negative. No user attributes may be added.3.14 DriveCartridgeAccessSoftWriteErrorCount Name: DriveCartridgeAccessSoftWriteErrorCount Type: Status Data Type: Integer Description: A count of the number of recoverable soft errors encountered while writing during this use of this cartridge in this drive. The value may equal –1 if this information is not available from the device and/or host operating system.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.3.1-2000 16. but from the user’s point of view they are read-only.15 System-defined attributes Name: System-defined attributes Type: Status Data Type: String Description: Additional attributes may be written by the system. Allowed Values: Any Default: None Depends On: None Depended On By: None Copyright © 2000 IEEE. Individual devices are expected to provide more detailed information via devicedefined attributes in the DriveCartridgeAccess object. and total corrected errors.3.1. or –1 indicating information not available Default: –1 Depends On: None Depended On By: None 16.

1 The attributes of the CONNECTION object 17. Status. 17. Each of those connections implies an open socket.1. Describes the current active connections. 17. Every client program and control program that connects to the MMS will have an active CONNECTION record. Allowed Values: Any defined version of the language Default: None Depends On: None Depended On By: None 124 Copyright © 2000 IEEE. System. . Table 21—Objects included in the session cluster SESSION object CONNECTION object Specifies which applications have active session contexts.1.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 17. All of the objects in this cluster are created by the system as the result of activities requested by clients of the system.2 Version Name: Version Type: Characteristic.1 Language Name: Language Type: Characteristic. the CONNECTION record will go away.1. and all instances of DMs and LMs. Key Data Type: String Description: The version of the language being used over this socket. created and deleted by the system.1 The CONNECTION object CONNECTION Objects represent the clients that are connected to the MM. Allowed Values: Any one of the defined language names Default: None Depends On: None Depended On By: None 17.1. When the socket closes. Key Data Type: String Description: The name of the language being used over this socket. All rights reserved. and which ones are connected. and includes the objects listed in Table 21.IEEE Std 1244. The session cluster This cluster describes the current sessions.1. This includes both administrative and non-administrative clients. This is a system object.

1.1. Allowed Values: Any name in the values for APPLICATION. Key Data Type: String Description: The AI name or device control program name for the client. Key Data Type: String Description: The application or device name for the client on this socket.4 ConnectionClientInstance Name: ConnectionClientInstance Type: Characteristic.1.LMName.LibraryName.DMName Default: None Depends On: AI.3 ConnectionClientName Name: ConnectionClientName Type: Characteristic.ApplicationName.1-2000 17. or DM.LibraryName.DMName Depended On By: None 17.DriveName Default: None Depends On: APPLICATION. or DM. LIBRARY. Allowed Values: Any Default: None Depends On: None Depended On By: None 17.ApplicationName.1. LM. Client.AIName.AIName. Key Data Type: String Description: The hostname for the client side of this socket. System. All rights reserved.6 ConnectionClientPort Name: ConnectionClientPort Type: Characteristic. Status. Copyright © 2000 IEEE. Allowed Values: One of the values for AI.1. System.1. or DRIVE. LIBRARY.1.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. 125 .LMName. LM. or DRIVE.5 ConnectionClientHost Name: ConnectionClientHost Type: Characteristic. Key Data Type: Integer Description: The TCP port number used for the client side of this socket.DriveName Depended On By: None 17.1.

When a CONNECTION is established for a client.1. Allowed Values: Any Default: None Depends On: None—this is set on creation Depended On By: None 17. there is no SESSION object associated with a LIBRARY or a DRIVE.. a SESSION record is also created.1.2 The SESSION object The SESSION object represents the clients that have active contexts. All dynamic resources (e.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Allowed Values: Any Default: None Depends On: None Depended On By: None 17. They are tracked separately from resources associated with other SESSIONs. 126 Copyright © 2000 IEEE. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 17.IEEE Std 1244. drives) that an application accumulates during a session are associated with the SESSION record. whether connected or not. This status object is created and deleted by the system.8 ConnectionTimeLastActive Name: ConnectionTimeLastActive Type: Status Data Type: Timestamp Description: The date/time when bytes were last passed through this socket. The SESSION record is deleted after the MM has released all of the dynamic resources that were not freed before the CONNECTION closed. All rights reserved.7 ConnectionTimeCreated Name: ConnectionTimeCreated Type: Status Data Type: Timestamp Description: The date/time when this socket was first opened. Only AIs have SESSIONs. .1.g. The SESSION record has a lifetime only slightly longer than the CONNECTION record.1.

2.1. Key Data Type: UUID Description: The unique identifier for this session.2 ApplicationName Name: ApplicationName Type: Characteristic. Allowed Values: Any Default: None Depends On: None Depended On By: REQUEST. Status Data Type: String Description: The name of the instance of the application that created this session.ApplicationName Default: None Depends On: APPLICATION. Allowed Values: One of the values for AI.1 The attributes of the SESSION object 17. 127 .1.1.1 SessionID Name: SessionID Type: Characteristic.1-2000 17. Status. CONNECTION 17.AIName Default: None Depends On: None Depended On By: None 17.2.2.2.2.3 AIName Name: AIName Type: Characteristic. Status Data Type: String Copyright © 2000 IEEE. All rights reserved.4 Language Name: Language Type: Characteristic. Allowed Values: One of the values for APPLICATION.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.ApplicationName Depended On By: None 17.1. Status Data Type: String Description: The name of the application that created this session.

Allowed Values: "true". Allowed Values: Any language defined by the standard for an application Default: None Depends On: None Depended On By: None 17.1.ConnectionClientPort Depended On By: None 128 Copyright © 2000 IEEE. "false" Default: "true" Depends On: None Depended On By: None 17. Allowed Values: One of the values for CONNECTION. Allowed Values: One of the values for CONNECTION.1.6 SessionClientHost Name: SessionClientHost Type: Characteristic. Status Data Type: Integer Description: The IP port number used by the client when it created this session.2.ConnectionClientHost Depended On By: None 17.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Description: The name of the language being used.7 SessionClientPort Name: SessionClientPort Type: Characteristic.1.ConnectionClientHost Default: None Depends On: CONNECTION.2.IEEE Std 1244. All rights reserved.ConnectionClientPort Default: None Depends On: CONNECTION. . Status Data Type: String Description: The network name of the host on which the client was located when it created this session.5 SessionAttached Name: SessionAttached Type: Status Data Type: Boolean Description: Specifies whether or not the client is currently connected.2.

All of the objects in this cluster are created by the system as the result of activities requested by clients of the system.1. 129 . Allowed Values: Any Default: None—this is set on creation Depends On: None Depended On By: None 17.8 SessionTimeCreated Name: SessionTimeCreated Type: Status Data Type: Timestamp Description: The date/time when this session was created.1-2000 17.2. Examples include comments.1.2.1. Copyright © 2000 IEEE. The task cluster This cluster describes the tasks generated by a command that is currently active.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. notes.2. All rights reserved.* Type: Client (where in this case the client is the system) Data Type: Any Description: Additional attributes can be added to this record by the user.9 SessionTimeLastActive Name: SessionTimeLastActive Type: Status Data Type: Timestamp Description: The date/time when the last activity occurred for this session. Allowed Values: Any Default: None Depends On: None Depended On By: None 18. and includes the objects listed in Table 22. and site-specific controls. Allowed Values: Any Default: First set to time of creation.10 User-defined attributes Name: . then updated whenever there is activity Depends On: None Depended On By: None 17.

Allowed Values: Any one of the command names Default: None Depends On: None Depended On By: None 18. Lists the libraries that are currently candidates for a current task. Key Data Type: UUID Description: The unique identifier for this task. either running or waiting for resources.IEEE Std 1244. "mount".1.1. Allowed Values: Any Default: None Depends On: None Depended On By: None 18.1.1.1 The attributes of the TASK object 18.1.3 TaskArrivalTime Name: TaskArrivalTime Type: Status Data Type: Timestamp Description: The date/time when the task was first submitted into the system.1.2 TaskType Name: TaskType Type: Characteristic. e. Status.1 TaskID Name: TaskID Type: Characteristic. . Lists the cartridges that are candidates for current tasks. 130 Copyright © 2000 IEEE.1 The TASK object A TASK object represents an MM command that is currently active..1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Table 22—Object included in the task cluster TASK object TASKCARTRIDGE object TASKDRIVE object TASKLIBRARY object Lists the current tasks.1. Lists the drives that are candidates for a current task.g. All rights reserved. 18. 18. Status Data Type: String Description: The command name for the task.

Allowed Values: One in the values for APPLICATION. Lower numbers are processed first.ApplicationName Depended On By: None 18.ApplicationName Default: None Depends On: APPLICATION.1.1.1.1.6 AIName Name: AIName Type: Characteristic.5 ApplicationName Name: ApplicationName Type: Characteristic. and persist after any particular execution of an AI.1-2000 Allowed Values: Any Default: None—this is set on creation Depends On: None Depended On By: None 18.1.1. 131 . All rights reserved. AI names are predefined by an administrative application.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. This task is initially always set to a system-wide default. Allowed Values: One of the values for AI.AIName Depended On By: None Copyright © 2000 IEEE. System Data Type: String Description: The name of the application that submitted this task.AIName Default: None Depends On: AI. Allowed Values: Any positive integer Default: 1000 Depends On: None Depended On By: None 18. Control Data Type: Integer Description: The priority of this task relative to other tasks competing for the same resources.4 TaskPriority Name: TaskPriority Type: System. but may be modified by an administrative application to effect a dynamic priority or scheduling environment. System Data Type: String Description: The name of the AI that submitted this task. Tasks with lower values for this attribute will be serviced before tasks with higher values.

if the task has started execution Default: None Depends On: None Depended On By: None 18. waiting for some resource.1.1.IEEE Std 1244.8 TaskState Name: TaskState Type: Status Data Type: Enumerated Description: Current status of the task.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 18.7 TaskStatement Name: TaskStatement Type: Status Data Type: String Description: The text of the command.2 The TASKCARTRIDGE object This object represents a cartridge that is a candidate for a current TASK.1.1. . All rights reserved.1.1.9 ClientTaskID Name: ClientTaskId Type: Status Data Type: String Description: The task ID supplied by the client when the task is sent to the MM. as sent to the MM. 132 Copyright © 2000 IEEE. if the task is blocked. but they should be unique for a given client Default: None Depends On: None Depended On By: None 18. "dispatched". Allowed Values: Any Default: None Depends On: None Depended On By: None 18. Allowed Values: Any. Allowed Values: "blocked".

1 TaskID Name: TaskID Type: Characteristic. Key Data Type: UUID Description: The unique identifier for this task.TaskID Default: None Depends On: TASK.1 TaskID Name: TaskID Type: Characteristic.TaskID Depended On By: None 18.CartridgeID Default: None Depends On: CARTRIDGE.3 The TASKDRIVE object This object represents a drive that is a candidate for a current TASK.1 The attributes of the TASKDRIVE 18.3.1. All rights reserved.2.1-2000 18. Key Data Type: UUID Description: The unique identifier for the task. System. Status. Key Data Type: UUID Description: The unique identifier of the cartridge that is a candidate for use in the given task. Allowed Values: One of the values for TASK.TaskID Depended On By: None Copyright © 2000 IEEE.1.CartridgeID Depended On By: None 18. Characteristic. 18.TaskID Default: None Depends On: TASK.1 The attributes of the TASKCARTRIDGE object 18.2.2.3.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. Allowed Values: One of the values for TASK. 133 . Allowed Values: One of the values for CARTRIDGE.1.2 CartridgeID Name: CartridgeID Type: System.

1.IEEE Std 1244. Status.LibraryName Default: None Depends On: LIBRARY.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 18. 18.4. Key Data Type: UUID Description: The unique identifier for the task.DriveName Depended On By: None 18.DriveName Default: None Depends On: DRIVE.1. All rights reserved.4. Status. Status. .TaskID Depended On By: None 18.TaskID Default: None Depends On: TASK.3. Key Data Type: String Description: The name of a library that is a candidate for use in the task. Allowed Values: One of the values for LIBRARY.1. Allowed Values: One of the values for TASK.4 The TASKLIBRARY object This object represents a library that is a candidate for a current TASK.LibraryName Depended On By: None 134 Copyright © 2000 IEEE.2 LibaryName Name: LibaryName Type: Characteristic.4.1 TaskID Name: TaskID Type: Characteristic.1 Attributes of the TASKLIBRARY object 18. Key Data Type: Description: The name of the drive that is a candidate for use in the given task.2 DriveName Name: DriveName Type: Characteristic. Allowed Values: One of the values for DRIVE.

The system cluster This cluster describes the general state of the system.'SystemLogLevel' controls the severity of messages generated by pieces of the MMS.1.1.1-2000 19. This object is a status object generated by the system. a DM. can be set to generate different levels of severity of messages that they will generate.1. The LM.LMMessageLevel and DM. respectively. Contains the message log. 19.'SystemMessageAcceptLevel' controls the severity of messages that are accepted into the FIFO message queue in the catalog. generated by the MM.1 The MESSAGE Object The MESSAGE object controls a log of error or informational messages generated by some component of the system. 19. Records all device handles that have been handed out to applications but have not been able to be cleaned up after a machine failure. The SYSTEM.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. Table 23—Objects included in the system cluster SYSTEM object MESSAGE object REQUEST object STALEHANDLE Defines the value of the basic system parameters. Contains the current requests.1 The attributes of the MESSAGE object 19. All messages that are generated will be appended to the log file on disk. All rights reserved.1 MessageID Name: MessageID Type: Characteristic. as well as the MM. 135 . The SYSTEM. and includes the objects listed in Table 23. Out of all the messages that are generated. Each LM and DM. only those messages that are at or above a specified level of severity will be added to the FIFO message queue in the catalog. The MessageSenderType will distinguish between messages from each of the following sources: an LM. Key Data Type: UUID Description: The unique identifier for this message. Allowed Values: Any Default: None Depends On: None Depended On By: None Copyright © 2000 IEEE. All of the objects in this cluster except the SYSTEM object are created by the system as the result of activities requested by clients of the system. or the MM.DMMessageLevel attributes control the severity level of severity of messages generated by LMs and DMs. Status. The MMS supports both a log file on disk and a FIFO message queue in the catalog of the last set of messages.

to represent the Library Manager. Default: None Depends On: None Depended On By: None 19. or "MM" for the Media Manager Default: None Depends On: LM. or "MM" for the Media Manager Default: None Depends On: LM.LibraryName or Drive.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 19.4 MessageSenderInstance Name: MessageSenderInstance Type: Characteristic. System Data Type: String Description: Instance of the external client in relation to which message is being generated.DriveName. Status Data Type: String Description: The name of the external client.1. Allowed Values: "LM". This may be "MM" if the message is not in connection with any external client. Status Data Type: Enumerated Description: The type of object that generated the message.LMName.3 MessageSenderName Name: MessageSenderName Type: Characteristic.1.LMName or DM.LibraryName. or "MM". This may be "MM" if the message is not in connection with any external client.1. Drive Manager.2 MessageSenderType Name: MessageSenderType Type: Characteristic. or DM. or DM. "DM".1.IEEE Std 1244. in relation to which message is being or has been generated.1.DMName Depended On By: None 19.1. All rights reserved. Allowed Values: One of the values for LM.1. or Media Manager respectively. Allowed Values: One of the values for LIBRARY. .DriveName Depended On By: None 19.1.DMName.5 MessageLevel Name: MessageLevel Type: Status 136 Copyright © 2000 IEEE.

1. Allowed Values: Any Default: None—this is set on creation Depends On: None Depended On By: None 19.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. "warning".6 MessageText Name: MessageText Type: Status Data Type: String Description: The text of the message. "alert". a REQUEST record is created. "information".1. An LM or DM can ask for an operator interaction via the "message" command in the LMP or DMP languages. "debug".1. When such a command arrives.2 The REQUEST object The REQUEST object contains entries for requests generated by LMs and DMs that require some sort of action to be performed by an operator or an administrator. "critical". "developer" Default: None Depends On: None Depended On By: None 19. One or more administrative applications will be polling the list of REQUEST records and displaying some subset of them for an operator. Copyright © 2000 IEEE.1. 137 . Allowed Values: "emergency". Allowed Values: Any Default: None Depends On: None Depended On By: None 19. In the enumeration below. "error".1-2000 Data Type: Enumerated Description: The level of severity of this message. All rights reserved. the number and level of detail of the messages increases from left to right.7 MessageTimeCreated Name: MessageTimeCreated Type: Status Data Type: Timestamp Description: The date/time when the message was generated. "notice". This object represents the current state of an interaction with the operator.

2. Allowed Values: The two values for LM.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 19. . The UUID is generated by the MM.1 The attributes of the REQUEST object 19.2.3 RequestingClient Name: RequestingClient Type: Characteristic.4 RequestingInstance Name: RequestingInstance Type: Characteristic.TaskID Depended On By: None 19.1.LibraryName or DM.TaskID Default: None Depends On: TASK.DriveName Depended On By: None 19.1 RequestID Name: RequestID Type: Status.1. Characteristic. for the Media Manager Default: None Depends On: LM.2 RequestingTaskID Name: RequestingTaskID Type: Characteristic. Status Data Type: String Description: The device name of the client making this request.DriveName.2. Status 138 Copyright © 2000 IEEE. Allowed Values: One of the values for TASK. or "MM". DM. Allowed Values: Any Default: None Depends On: None Depended On By: None 19. Key Data Type: UUID Description: The unique identifier of a request sent by a DM or LM.2.LibraryName.1.IEEE Std 1244.2.1. Status Data Type: UUID Description: The unique identifier for the task identified for this request. All rights reserved.

SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.6 RequestPriority Name: RequestPriority Type: Characteristic Data Type: Number Description: Numeric value giving the priority of the request.DMName Default: None Depends On: LM.2. Allowed Values: One of the values for LM.1-2000 Data Type: String Description: The device instance name of the client making this request. 139 . Allowed Values: "pending" "accepted" Default: "pending" Depends On: None Depended On By: None Copyright © 2000 IEEE. All rights reserved. with lower numbers indicating higher priority Default: None Depends On: None Depended On By: None 19.7 RequestState Name: RequestState Type: Status Data Type: Enumerated Description: This attribute indicates whether or not an operator has already accepted and is working on this request. Allowed Values: "LM" or "DM" to represent the Library Manager or Drive Manager respectively Default: None Depends On: None Depended On By: None 19.1. System Data Type: String Description: The type of client making this request.2. and DM.5 RequestingClientType Name: RequestingClientType Type: Characteristic.LMName.1.1.LMName.DMName Depended On By: None 19. or DM. Allowed Values: 0–1000.2.

Allowed Values: One of the values for SESSION.e. Allowed Values: Any Default: None Depends On: None Depended On By: None 19. System Data Type: UUID Description: This is the session ID of the operator application that has accepted and is processing the request. then this attribute is "undefined". application) has yet accepted the request.1.11 RequestTimeCreated Name: RequestTimeCreated Type: Status Data Type: Timestamp 140 Copyright © 2000 IEEE.1.IEEE Std 1244. This is generated by the application or operator that fields the request.2.1. if no operator (i.2.10 ResponseText Name: ResponseText Type: Characteristic Data Type: String Description: The text of the response to this request.9 AcceptingSessionID Name: AcceptingSessionID Type: Characteristic.1. . Allowed Values: Any Default: None Depends On: None Depended On By: None 19. or if the accepting session is closed.2.2. and sent to the LM or DM by the MM..8 RequestText Name: RequestText Type: Status Data Type: String Description: This is actual text of the request for viewing by the operator/administrator. All rights reserved. Obviously.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 19.SessionID Default: "undefined" Depends On: SESSION.SessionID Depended On By: None 19.

Allowed Values: Any Default: None—this is set on creation Depends On: None Depended On By: None 19. Privilege Levels: System Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 19. Each LM and DM. It contains global configuration options and status information.2.DMMessageLevel attributes control the severity level of messages generated by LMs and DMs. respectively.13 RequestTimeResponded Name: RequestTimeResponded Type: Status DataType: Timestamp Description: The date/time at which a response was made to the request. The MMS supports both a log file on disk and a FIFO message queue in the catalog of the last set of messages.1.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. All messages that are generated will be appended to the log file on disk.2.12 RequestTimeAccepted Name: RequestTimeAccepted Type: Status Data Type: Timestamp Description: The date/time when the request was picked up by a client who intended to respond to the request. as well as the MMS. can be set to generate different levels of message severity of messages that they will generate. The SystemLogLevel controls the severity level of messages Copyright © 2000 IEEE.LMMessageLevel and DM. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 19. Out of all the messages that are generated. 141 .3 The SYSTEM object There is only one record of this type in an MMS. All rights reserved.1-2000 Description: The date/time when the request entered the system. The LM. only those messages that are at or above a specified level of severity will be added to the FIFO message queue in the catalog.1.

"critical". of this severity or higher will be appended to the message FIFO in the catalog.1 Administrator Name: Administrator Type: Control Data Type: String Description: The name or e-mail address of the person responsible for this MMS installation.3. from any source in the MMS. Allowed Values: Any Default: "unknown" Depends On: None Depended On By: None 19. "developer" Default: None Depends On: None Depended On By: None 19.IEEE Std 1244. "notice". All messages. . "information".2 SystemLogLevel Name: SystemLogLevel Type: Control Data Type: Enumerated Description: The severity level of messages to be generated by components of the MMS.3. "error". The SystemAcceptLevel controls the severity level of messages that are accepted into the FIFO message queue in the catalog. there are no key attributes.3. 19. All rights reserved. Allowed Values: "emergency". Since there is only one object of this type.3. This is 142 Copyright © 2000 IEEE.3 SystemAcceptLevel Name: SystemAcceptLevel Type: Control Data Type: Enumerated Description: The severity of messages to be stored in the catalog message FIFO. This is different from the SystemAcceptLevel so that detailed logs can be kept on one component without flushing the message FIFO of other content. Controls what log messages get added to the log file.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT generated by pieces of the MMS. This field is for human use only and is intended to be viewed by an operator/administrator.1 The attributes of the SYSTEM object 19. "alert". there are no dependencies on other fields in the catalog. "debug". and no use is made of this field other than to show it to humans. In the enumeration below.1.1.1. All messages of this severity or higher will be appended to the log file. "warning". the number and level of detail of the messages increases from left to right.

6 SystemMessageCount Name: SystemMessageCount Type: Control Data Type: Integer Copyright © 2000 IEEE. "notice". Allowed Values: "emergency".1. 143 . In the enumeration below. All rights reserved. "information".4 SystemLogFile Name: SystemLogFile Type: Control Data Type: String Description: The pathname of the log file to which all messages should be appended. "developer" Default: None Depends On: None Depended On By: None 19. The MMS will automatically create the file again and start using the new one. it will be created. "critical".1-2000 different from the SystemLogLevel so that detailed logs can be kept on one component without flushing the message FIFO of other content. the number and level of detail of the messages increases from left to right. "alert". "error". Log rotation can be accomplished by simply moving or renaming the existing log file out of the way.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.3. Controls what log messages are visible via the MMP language.1.5 SystemMessageLimit Name: SystemMessageLimit Type: Control Data Type: Integer Description: The maximum number of messages to be stored in the catalog message FIFO. The old log file will then be free for compaction archival or other disposal.3. Note that this does not affect the number of messages stored in the log file.1. "debug". Allowed Values: Any Default: None Depends On: None Depended On By: None 19. "warning".3. If this file does not exist. Allowed Values: Any Default: 100 Depends On: None Depended On By: None 19.

1. . All rights reserved. Note that this does not include the number of requests for which there has not yet been a response. Note that this does not show the number of messages in the log file. Allowed Values: Any Default: None Depends On: None Depended On By: None 19. Allowed Values: Any Default: None Depends On: None Depended On By: None 19. it only limits the number of historical request structures that are kept on hand.8 SystemRequestCount Name: SystemRequestCount Type: Control Data Type: Integer Description: The current number of requests that are stored in the catalog request FIFO. Allowed Values: Any Default: 1000 144 Copyright © 2000 IEEE.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Description: The current number of messages that are stored in the catalog message FIFO.3.IEEE Std 1244. Note that this does not include the number of requests for which there has not yet been a response.1.9 SystemSyncLimit Name: SystemSyncLimit Type: Control Data Type: Integer Description: The maximum number of transactions to be executed before writing out a new catalog file and truncating the log file.3.1. Allowed Values: Any Default: 100 Depends On: None Depended On By: None 19.7 SystemRequestLimit Name: SystemRequestLimit Type: Control Data Type: Integer Description: The maximum number of requests to be stored in the catalog request FIFO.3.

1-2000 Depends On: None Depended On By: None 19.3.* Type: Client Data Type: String Description: Additional attributes added by an administrative application.12 System-defined attributes Name: . Allowed Values: Any Default: 100 Depends On: None Depended On By: None 19. Allowed Values: Any Default: None Depends On: None Depended On By: None 19.1. Allowed Values: Any Default: None Depends On: None Depended On By: None Copyright © 2000 IEEE.10 SystemDCALimit Name: SystemDCALimit Type: Control Data Type: Integer Description: The maximum number of DRIVECARTRIDGEACCESS (DCA) records to be stored in the DCA FIFO.11 SystemDCACount Name: SystemDCACount Type: Status Data Type: Integer Description: The current number of DRIVECARTRIDGEACCESS (DCA) records that are stored in the DCA FIFO.1.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.3. 145 . Note that this limits the number of historical DCA structures that are kept on hand. All rights reserved.1.3.

4.1 The attributes of the STALEHANDLE object 19.ApplicationName Default: None Depends On: APPLICATION.4. All rights reserved.IEEE Std 1244.1.4. . This is required for handling partition mounts. Allowed Values: One of the entries in the list APPLICATION.2 VolumeName Name: VolumeName Type: Status Data Type: String Description: The name of the volume mounted.PartitionName Depended On By: None 146 Copyright © 2000 IEEE.1. Allowed Values: One of the entries in the list PARTITION.VolumeName Depended On By: None 19. The MM tracks this information so that it can effect recovery and prevent unauthorized access to data. Allowed Values: One of the list VOLUME.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT 19.4.1.PartitionName Default: None Depends On: PARTITION.1 ApplicationName Name: ApplicationName Type: Status Data Type: String Description: The name of the application that had the volume mounted.3 PartitionName Name: PartitionName Type: Status Data Type: String Description: The partition name.ApplicationName Depended On By: None 19.VolumeName Default: None Depends On: VOLUME. 19.4 The STALEHANDLE object This STALEHANDLE object reflects the state of MM-allocated mount handles that were in use when a DM crashed.

4 SideName Name: SideName Type: Status Data Type: String Description: The side name.7 DMName Name: DMName Type: Status Data Type: String Description: The name of the controlling DM. This is required for handling side mounts.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. All rights reserved.1-2000 19.DriveName Default: None Depends On: DRIVE.DMName Copyright © 2000 IEEE.4. Allowed Values: One of the entries in the list SIDE.CartridgeID Depended On By: None 19. Allowed Values: One of the entries in the list DM.DriveName Depended On By: None 19.SideName Depended On By: None 19.5 CartridgeID Name: CartridgeID Type: Status Data Type: UUID Description: The cartridge that was mounted. 147 .4.1.1.4.CartridgeID Default: None Depends On: CARTRIDGE.1. Allowed Values: One of the entries in the list CARTRIDGE.6 DriveName Name: DriveName Type: Status Data Type: String Description: The name of the drive.SideName Default: None Depends On: SIDE.4.1. Allowed Values: One of the entries in the list DRIVE.

Allowed Values: Any Default: None Depends On: None Depended On By: None 19.DMName Depended On By: None 19. Allowed Values: Any Default: None—this is set on creation Depends On: None Depended On By: None 20.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Default: None Depends On: DM..1. mount path. i.1.8 MountLogicalHandle Name: MountLogicalHandle Type: Status Data Type: String Description: The mount access handle.4.4. .1 Instructions By following these instructions. All rights reserved.e. The IEEE SSSWG maintains optional registries of MMS tokens for the following token types: — — — — — — — MMP mount modes Slot type names Cartridge shape names Bit formats Cartridge type names Partition names Attribute names made to specific products in this clause are for information only and are not meant to show endorsement by the IEEE. registered and unregistered tokens may be used without collision. 9Examples 148 Copyright © 2000 IEEE.9 MountLogicalTimeWhenMounted Name: MountLogicalTimeWhenMounted Type: Status Data Type: Timestamp Description: The time when the mount occurred. Tokens9 20.IEEE Std 1244.

For example. A final draft of the standard is available for reference only at ftp://ftp. and their use is entirely at the discretion of the vendor or organization.t10. New vendor or organization names may be registered according to the NCITS T10 approved standard SPC. These are the vendor or organizational names used by the NCITS T10 technical committee. The MMS matches those requested tokens against the list of tokens that are supported by the drives that could be used to access the cartridge. and is frequently updated by the NCITS T10 committee. An example of an unregistered token belonging to the ACME Technology Corporation might be "_ACME_OverTemp".pdf.org).org/ for a complete list of updated tokens. it has the ability to ask that the resulting access to the cartridge have certain characteristics.org/lists/2vid.301:1997. followed by another underscore character.t10.org/t10/drafts/spc2/vid-alph. All rights reserved. that user may employ an unregistered token using a registered vendor or organization name as a mandatory pre-fix. Tokens shown in this clause are registered.SYSTEM (MMS) ARCHITECTURE IEEE Std 1244.htm. All of the information in this clause is described at the IEEE SSSWG Web site (http://www. ANSI X3.10 10Tokens are consistently being updated. The registration authority provided by the NCITS T10 committee shall be used for the purpose of defining vendor or organization names used as pre-fixes of unregistered MMS tokens.ssswg. These vendor or organization names are for the exclusive use of the vendor or organization registering them. but will advise the submitter of collisions.t10. Information on how to register a token can also be found at that website. The MMP Mount Modes tokens are simple text strings that the application provides in the ACCESSMODE and/or the FIRSTMOUNT clauses of the MMP MOUNT command. then that drive cannot be used for this MOUNT operation. 20. The official list of vendor or organization names is available at ftp://ftp. followed by the rest of the attribute name. 149 . Directions for obtaining a copy of this standard may be found at the following URL: http:/ /www. and all may use them without concern for collision or incompatibility.txt. if any. followed by the text of the vendor or organization name with all trailing blanks removed. To register a vendor or organization name that is not already registered.t10. Only those modes of access to a given drive that provide matching MMP Mount Mode tokens are considered candidates. “rewind the media when the device is closed” and “enable drive-based data compression. Tokens identified at this writing for MMP mount modes are shown in Table 24.” The mechanism that the application uses to indicate those desired characteristics to the MMS is the MMP Mount Modes tokens. which develops standards and technical reports on I/O interfaces. Unregistered tokens shall be composed of an underscore character. particularly the series of Small Computer System Interface (SCSI) standards. If a drive has no modes of access with matching MMP Mount Mode tokens.2 MMP mount modes When an application requests that a cartridge be mounted.1-2000 If a user of this standard does not choose to use a token or tokens from one or more of the IEEE SSSWG registries. A registry of vendor or organizational names is kept under the authority and responsibility of the National Committee for Information Technology Standards (NCITS).org/t10/drafts /spc/spc-r11a. Copyright © 2000 IEEE. The IEEE SSSWG will not judge the merit of tokens submitted for registration.org/pubs. These are the tokens in existence at the time this standard was published. use the information provided at http://www. with existing tokens.htm. Please go to http://www.ssswg.

If the drive is connected via a parallel SCSI connection. Client or administrative applications may also use SlotTypeNames for informational or administrative purposes.org/ for a complete list of updated tokens. . Attempt to compress the data stream. The CartridgeShapeName field in those objects provides a linkage to CARTRIDGETYPE objects that share the same CartridgeShapeName value. Please go to http://www.3 Slot type names This is a list of possible values for the database field "SLOTTYPE. When there are multiple instances of SLOTTYPE objects that share a common SlotTypeName. The MMS is free to make use of this mapping information when deciding if a given cartridge will fit into a given slot.SlotTypeName". block littleendian bigendian Interchange Interchange Interchange 20. They are the names given to types of slots in removable media libraries an MMS. The size of a block on the media may vary from one block to the next and will be equal to the number of bytes transferred by the application on a write. All rights reserved. sequential bytes are put on the bus with the first byte on the upper 8 bits of the bus. sequential bytes are put on the bus with the first byte on the lower 8 bits of the bus. Do not rewind the media when the mount point is closed. 150 Copyright © 2000 IEEE. Rewind the media when the mount point is closed. Do not attempt to compress the data stream. For example. indirectly telling the MMS which types of cartridges can fit into that slot. Tokens identified at this writing for slot types are shown in Table 25.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Table 24—Tokens for MMP mount modes Token readwrite readonly rewind norewind compression nocompression variable Type access access access access Interchange Interchange Interchange Description The mount point will allow reading and writing of the media. the CartridgeShapeName fields in those objects provide a many-to-many mapping to CARTRIDGETYPE objects. Note that some types of slots in some removable media libraries may take more than one shape of cartridge. Each SLOTTYPE object contains both a SlotTypeName field and a CartridgeShapeName field. some libraries can now manage DLT shaped cartridges or 3480 shaped cartridges in the same slots. If the drive is connected via a parallel SCSI connection. The mount point will allow only reading of the media. The LM will send to the MM as part of the CONFIG command a SlotTypeName value for each of the slots that exist in the library that the LM controls. The values show the shape of cartridges that the drive can accept in each mode of operation.11 11Tokens are consistently being updated. The DM will send SlotTypeName values to the MM in its DMP CONFIG command for each mode of access that the drive supports.IEEE Std 1244. Blocks on the media will be a fixed size independent of the number of bytes of data transferred by the application. The value shows the type of that slot.ssswg.

Metrum® Description or usage 20. Each SLOTTYPE object contains both a SlotTypeName field and a CartridgeShapeName field.4 Cartridge shape names This is a list of possible values for the database field "CARTRIDGETYPE. DVDRAM 12 inch vinyl audio recording Any generic 8 mm shell e.g.g. 3490. 3480. STK® 4480/4490. the CartridgeShapeName fields in those objects provide a many-to-many mapping to CARTRIDGETYPE objects.. and 3590 cartridges all share the same CartridgeShapeName of "3480". When there are multiple instances of SLOTTYPE objects that share a common SlotTypeName. Note that many different CARTRIDGETYPE objects might share the same value for their CartridgeShapeName fields.g. All rights reserved. They are the names given to the external shapes of cartridges in an MMS.ssswg.g. Copyright © 2000 IEEE. indirectly telling the MMS which types of cartridges can fit into that slot.CartridgeShapeName".. For example. The CartridgeShapeName field in those objects provides a linkage to CARTRIDGETYPE objects that share the same CartridgeShapeName value..org/ for a complete list of updated tokens.12 12Tokens are consistently being updated.g.. The LM will send to the MM as part of the CONFIG command a SlotTypeName value for each of the slots that exist in the library that the LM controls. 20 GB cartridges from Sony® e. DLT7000) May take 3480 or DLT® cartridges e.. DVDROM. Compact III (i. Tokens identified at this writing for cartridge shapes are shown in Table 26.1-2000 Table 25—Tokens for slot types Token 8mm 3480 DLT DLTor3480 DAT D2-S D2-M D2-L DTF VHS QIC CDROM LP33 e. IBM 3480/3490/3495. 151 .SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. The MMS is free to make use of this mapping information in deciding if a given cartridge will fit into a given slot.e. DLT2000).. e. Please go to http://www.e. CDROM. Client or administrative applications may also use SlotTypeNames for informational or administrative purposes. The value shows the type of that slot.g. Compact IV (i. DDS2 "small" DST® cartridges (25 GB capacity) "medium" DST cartridges (75 GB capacity) "large" DST cartridges (165 GB capacity) e...

while a 3480 drive can only access data written in 3480 format. If the bytes are put on the bus in little-endian ordering when writing to the cartridge but are later read off on a system that assumes the bytes are in big-endian ordering. A 3490 drive has the ability to read or write data on a cartridge in the format of a 3480 as well as in its native 3490 format.g. CDROM. DDS2 "small" DST cartridges (25 GB capacity) "medium" DST cartridges (75 GB capacity) "large" DST cartridges (165 GB capacity) e.g. All rights reserved. 20 GB cartridges from Sony e.g. . Each mode of access that a drive supports specifies a BitFormatName that that mode of access supports. They are the names given to the different recording formats of data on media managed by an MMS. etc. but it is also possible to record bits on that media in the format that a 3480 drive uses natively. the MMS needs to know both the exact format the data is recorded in. e.DMBitFormatName".. One of the better-known cases is that of a 3490 cartridge.g.IEEE Std 1244. but cannot write data in DLT2000 compressed format..g. DVDRAM 12 inch vinyl audio recording Any generic 8 mm shell e. DLT7000) e..e.e. Thus. On drives that attach using a parallel-SCSI interconnect and that negotiate for "wide" (16 bit) access to the bus. Compact IV (i.5 Bit formats This is a list of possible values for the database field "DMBITFORMAT. A different BitFormatName for each case shall be used in order to know if access can be accomplished without a byte-swap operation or not.. STK 4480/4490.. Note that data written on a DLT2000 drive using drive-based data compression must be labeled as a different BitFormat from data written using the same drive but without drive-based data compression. The format of the bits that are recorded on the media is independent of the type of cartridge and sometimes even the external shape of the cartridge. and the data formats that each potentially useful drive can access. It is possible to record bits onto a piece of 3490 media in the format that a 3490 drive uses natively.. Metrum Description or Usage 20.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Table 26—Tokens for cartridge shapes Token 8mm 3480 DLT DAT D2-S D2-M D2-L DTF VHS QIC CDROM LP33 e. IBM 3480/3490/3495. DVDROM. Compact III (i. the ordering of bytes on the bus will impact the ability to interchange that cartridge with drives attached to other computer systems. the cartridge can be used in either a 3480 drive or a 3490 drive.. In order to pick a drive that can successfully read the contents of a cartridge that already has data on it. DLT2000). A DLT7000 drive can read DLT2000 data in compressed or uncompressed format. The "BitFormatName" is the token that links the data format 152 Copyright © 2000 IEEE.. the net effect is a swapping of bytes.g. the "BitFormatName".

SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. big endian STK Timberline® native STK Redwood® native.1-2000 on the cartridge with the data format supported by the drive and allows the MM to know that a given drive can access the data on a given cartridge. so the little-endian versus big-endian issue becomes relevant. Tokens identified at this writing for BIT formats are shown in Table 27. big endian DLT2000 native DLT2000 compressed DLT4000 native DLT7000 native DLT7000 compressed DLT4000 compressed The Redwood drive will negotiate for 16-bit "wide" access to a SCSI bus. Description 13Tokens are consistently being updated. little endian IBM Magstar compressed. All rights reserved. little endian IBM Magstar native. little endian STK Redwood compressed.ssswg.org/ for a complete list of updated tokens. The Magstar drive will negotiate for 16-bit "wide" access to a SCSI bus. big endian IBM Magstar compressed. little endian STK Redwood native. so the little-endian versus big-endian issue becomes relevant.13 Table 27—Tokens for BIT formats Token 8200 8200c 8500 8500c 8900 8900c 3480 3490 3490E 3590le 3590be 3590lec 3590bec 4480 SD-3le SD-3be SD-3lec SD-3bec DLT2000 DLT2000c DLT4000 DLT4000c DLT7000 DLT7000c DDS1 DDS2 DDS3 Exabyte® 8200 native Exabyte 8200 native Exabyte 8500 native Exabyte 8500 compressed Exabyte mammoth native Exabyte mammoth compressed 3480 native 3490 native 3490E native IBM Magstar® native. Please go to http://www. big endian STK Redwood compressed. Copyright © 2000 IEEE. 153 .

big endian The Ampex drive will negotiate for 16-bit "wide" access to a SCSI bus. Tokens identified at this writing for cartridge type names are shown in Table 28. so the little-endian versus big-endian issue becomes relevant. . The names of those types of cartridges shall be unique within an MMS installation.14 Table 28—Tokens for cartridge types Token 8mm-12m 8mm-60m 8mm-90m 8mm-112m 8mm-160m 8900 3480 3490 3490E 3590 4480 4490 DLT-Compact-I DLT-Compact-II DLT-Compact-III DLT-Compact-IV 12 m 8mm 60 m 8mm 90 m 8mm 112 m 8mm 160 m 8mm Exabyte mammoth 3480 3490 3490E IBM Magstar native STK Timberline native STK Redwood native Digital TK50 Digital TK70 DLT2000 and DLT2000XT (also TK85. little endian Ampex DST compressed. 154 Copyright © 2000 IEEE. The CARTRIDGETYPE object records various pieces of information about each type of cartridge known to the MMS. 20.1-2000 IEEE STANDARD FOR MEDIA MANAGEMENT Table 27—Tokens for BIT formats (continued) Token D2le D2be D2lec D2bec ISO9660 Description Ampex DST native. TK86) DLT4000.IEEE Std 1244. All rights reserved. and to allow interchange of cartridge information between MMS installations.CartridgeTypeName". they should be common to all installations.6 Cartridge type names This is a list of possible values for the database field "CARTRIDGETYPE.ssswg. big endian Ampex DST compressed. little endian Ampex DST native. DLT7000 Product name or description 14Tokens are consistently being updated.org/ for a complete list of updated tokens. Please go to http://www.

As one might expect. 8.1-2000 Table 28—Tokens for cartridge types (continued) Token DDS1 DDS2 DDS3 D2-S D2-M D2-L DTF CDROM DVDROM DVDRAM DAT DAT DAT Ampex DST-310 small format Ampex DST-310 medium format Ampex DST-310 165GB large format Sony GY-10 CDROM DVDROM DVDRAM Product name or description 20. and 10. On a non-linear media such as a disk. not partition 6. 155 . Each type of partitioned media may have its own unique designations for each partition. On a linear media such as a tape. On a nonlinear media such as a disk. Copyright © 2000 IEEE. The ATTACH command that is sent by the MM to the DM includes an indication of which partition the DM should grant access to..SYSTEM (MMS) ARCHITECTURE IEEE Std 1244. The DM Protocol assumes a standard set of names is used for partitioned media.. Part2 Part3 15Tokens are consistently being updated. it refers to the next partition. the pattern continues. For example. Part2 is defined to be the second lowest numbered or lettered partition.15 Table 29—Tokens for partitions Token Part1 Description The first partition on the media. 6. using whatever standard partitioning mechanism exists on that media. Part2 is defined to be the one immediately following Part1 on the media. using whatever standard partitioning mechanism exists on that media. On a linear media such as a tape. Please go to http://www. The second partition on the media. Partition names from Table 29 will be sent by the MM as part of a DMP ATTACH command and it is up to the DM to map those into the natively defined nomenclature for partitions on its supported media types. a disk drive might define partitions 1 through 16 but only normally use partitions 1.PartitionName". Part1 is defined to be the one closest to the physical beginning of the media. Tokens identified at this writing for partition names are shown in Table 29.ssswg. All rights reserved. Note that Part2 does not refer to the next partition that is in use.org/ for a complete list of updated tokens. Part2 would refer to partition 2.7 Partition names This is a list of possible values for the database field "PARTITION. but the MM needs to be able to refer to those partitions in a uniform way independent of the type of media. Part1 is defined to be the lowest numbered or lettered partition.

IEEE Std 1244. 156 Copyright © 2000 IEEE. and is defined to be the total real time to execute a large number of cartridge load/ move operations randomly spread through the physical space of the library divided by the number of such operations performed.ssswg. in bytes LoadTime DMCAPABILITY Numeric. .e. WriteBandwidth DMCAPABILITY Numeric. or back. its meaning. in seconds LoadTime LIBRARY Numeric. in bytes per second Description The total effective bandwidth that an application should be able to sustain when reading from that drive using the given capability set. its allowable values. The total effective bandwidth that an application should be able to sustain when writing to that drive using the given capability set. This is analogous to the nominal seek time of a disk drive. The total storage capacity of the cartridge that an application should be able to expect when accessing that drive using the given capability set.8 Attribute names Attributes can be attached to many of the object types in the MMS Data Model. The I/O size that would best utilize the drive/cartridge combination when using that drive with the given capability set.org/ for a complete list of updated tokens. i. the Attribute Name registry contains the name of the attribute. in megabytes Blocksize DMCAPABILITY Numeric.. they will have separate entries in the Attribute Name registry. so that they can be used and understood by more than the person or group who defined them. Note that two attributes attached to different types of objects can have the same attribute name. in bytes per second Capacity DMCAPABILITY Numeric. For each registered attribute. not including drive load/unload time. The approximate time it will take for the library to move a cartridge from its home location to a drive. Tokens identified at this writing for attribute names are shown in Table 30. in seconds 16Tokens are consistently being updated. All rights reserved. The number of seconds between the time a cartridge is first inserted into a drive and the time that the drive is ready to read/ write data.16 Table 30—Tokens for attributes Attribute name ReadBandwidth Object name DMCAPABILITY Value Numeric. It is desirable to register the names and allowable values of those attributes so that they can be used by anyone who is interested in the information that the attribute embodies. Please go to http://www. and the object it can be attached to.1-2000 20.