MMS Standard

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 specied. 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 specied 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 ve years for revision or reafrmation. When a document is more than ve years old and has not been reafrmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reect 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 afliation 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 specic 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 certication 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 ve MMS standards balloted together under IEEE Project 1244 for Storage System Design: IEEE Std 1244.1-2000IEEE Standard for Media Management System (MMS) Architecture IEEE P1244.2/D041900Draft Standard for Media Management System (MMS) Session Security, Authentication, Initialization Protocol (SSAIP) IEEE Std 1244.3-2000IEEE Standard for Media Management System (MMS) Media Management Protocol (MMP) IEEE Std 1244.4-2000IEEE Standard for Media Management System (MMS) Drive Management Protocol (DMP) IEEE Std 1244.5-2000IEEE 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 rst sections of the Architecture. These ve standards are the rst 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 signicant renement and extension of OpenVault. The IEEE Mass Storage System Reference Model (MSSRM) inuenced OpenVault design before work began on the MMS, and the present OpenVault reects strong inuence 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 ve standards are as follows: IEEE Std 1244.1-2000IEEE 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
IEEE P1244.2/D041900Draft Standard for Media Management System (MMS) Session Security, Authentication, Initialization Protocol (SSAIP) Bruce K. Haddon (Primary Editor, 2000present) Jan Klier (Primary Editor, 1998-2000) Curtis Anderson, Joel N.Williams IEEE STD 1244.3-2000IEEE Standard for Media Management System (MMS) Media Management Protocol (MMP) Murali Sathyanarayana (Primary Editor) Curtis Anderson, Joel N.Williams, Dixon Hutchinson, Alan Rollow IEEE Std 1244.4-2000IEEE Standard for Media Management System (MMS) Drive Management Protocol (DMP) Joel N.Williams (Primary Editor) Murali Sathyanarayana IEEE Std 1244.5-2000IEEE Standard for Media Management System (MMS) Library Management Protocol (LMP) Joel N.Williams (Primary Editor) Murali Sathyanarayana Sponsor chairs of this standard are as follows: Merritt E. Jones (1993-2000) John L. (Jack) Cole (2000) The following members of the balloting committee voted on this standard:
Curtis Anderson Brian A. Berg Paul Buerger George B. Cole John L. Cole Don Doerner Richard T. Eberlein Robert J. Gagliano Mark R. Gary Michael V. Hardy P. C. Hariharan Ronald W. Huff T. Dixon Hutchinson Merritt Jones Michael P. Kearney Linda Kempster Charles M. Kennedy Ben Kobler Stuart K. Kreitman Paul Lockwood Geoffrey Peck Alan R. Rollow Murali Sathyanarayana Yoshitake Shinkai Bob Snead Robert Snively Joel N. Williams
iv
When the IEEE-SA Standards Board approved this standard on 21 June 2000, it had the following membership: Donald N. Heirman, Chair James T. Carlo, Vice Chair Judith Gorman, Secretary
Satish K. Aggarwal Mark D. Bowman Gary R. Engmann Harold E. Epstein H. Landis Floyd Jay Forster* Howard M. Frazier Ruben D. Garzon *Member Emeritus James H. Gurney Richard J. Holleman Lowell G. Johnson Robert J. Kennelly Joseph L. Koepnger* Peter H. Lips L. Bruce McClung Daleep C. Mohla James W. Moore Robert F. Munzner Ronald C. Petersen Gerald H. Peterson John B. Posey Gary S. Robinson Akio Tojo Donald W. Zipse
Also included is the following nonvoting IEEE-SA Standards Board liaison:

Alan Cookson, NIST Representative Donald R. Volzka, TAB Representative
Catherine K. N. Berger IEEE Standards Project Editor
AMPEX is a registered trademark of AMPEX Corporation. DDS is a registered trademark of Sony Corporation. DTF is a registered trademark of Sony Electronics, Inc. DLT is a registered trademark of Quantum Corporation. DST is a registered trademark of AMPEX Systems Corporation Exabyte is a registered trademark of Exabyte Corporation. HACMP is a trademark of the International Business Machines Corporation. IBM is a registered trademark of the International Business Machines Corporation. Magstar is a registered trademark of International Business Machines Corporation. Quantum DLT is a registered trademark of Quantum Corporation. SGI, Silicon Graphics, OpenVault, and IRIS FailSafe are trademarks of Silicon Graphics Incorporated. STK is a trademark of Storage Technology Corporation. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Limited. Windows NT is a registered trademark of Microsoft Corporation. All other tradenames and trademarks in this standard are those of their respective owners.
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 modelintroduction ................................................................................................................. 39
vi
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
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
IEEE Standard for Media Management System (MMS) Architecture
1. Overview
The IEEE Media Management System (MMS) is a distributed, multi-platform system for managing removable media. The IEEE MMS standards dene a software component model for working with removable media as well as a number of protocols that dene interfaces between the components. These standards enable vendors to construct applications that use removable media as well as components of an MMS that interoperate with other MMS components. Systems based on the MMS may support many kinds of removable media, including computer media such as magnetic tape, optical disk, and CD-ROM, as well as non-computer media such as audiotape and videotape, lm, and audio CDs and videodiscs. The MMS supports both automated (robotic) and non-automated handling of media. The MMS is scalable and both system and media neutral. Systems that implement the MMS may target a range of customers, from individual desktop computers, to workgroups, to data centers, to multinational corporations. The MMS does not require any particular hardware or operating system, and allows organizations that have diverse systems to manage the removable media that is used by these systems in a unied manner. The media managed by the MMS does not need to be formatted or labeled for the MMS; existing media can be incorporated into an MMS-managed system with no modications. The MMS utilizes existing machinereadable label information such as bar codes or media labels if they are present. The MMS and widely available implementations of the MMS will give users of removable media greater security and convenience of operation. Software developers will be able to write software that takes advantage of the huge storage capacity of removable media much more easily, and this software will be portable to a wide number of platforms. System and component vendors will be able to incorporate the MMS into their systems, allowing greater interoperability and eliminating the need to implement costly, proprietary solutions to manage removable media.
1.1 Scope
The MMS standards published by the IEEE dene the architecture, data model, and interfaces that are required in any MMS implementation. These standards are not intended as a tutorial or textbook, nor do they provide a cookbook for implementation of an MMS. The standards are organized to be of use to several audiences:
IEEE Std 1244.1-2000
IEEE STANDARD FOR MEDIA MANAGEMENT
a) b) c)
Those interested in an introduction to the MMS and its capabilities will nd this standard, IEEE Std 1244.1-2000, to be a reasonable, though technical, introduction to the system. Those interested in implementing applications that utilize the MMS will nd this standard, IEEE Std 1244.1-2000, and IEEE Std 1244.3-20001 to be helpful. Those interested in implementing devices such as robotic libraries or drives will nd IEEE Std 1244.1-2000, IEEE P1244.2/D041900, IEEE Std 1244.4-2000, and IEEE Std 1244.5-2000, to be essential. Those interested in implementing the entire MMS will nd all standards in the IEEE MMS suite of standards to be required reading.
d)
A suite of IEEE 1244 standards describes the MMS. This modular approach to standardizing an MMS permits a granularity of conformance not possible otherwise, and allows a degree of independent evolution for the components of an IEEE MMS. Nevertheless, the overall architecture of the IEEE MMS is described in IEEE 1244.1-2000, and fundamental information (including the data model) that is common to all related standards is communicated through that standard. Reference to the MMS Architecture is crucial in understanding the MMS, its associated standards, and the components of an MMS implementation. The set of standards that comprise the IEEE MMS suite are listed in Table 1. Table 1The IEEE MMS suite of standards
Standard Description System Architecture IEEE Std 1244.1-2000 IEEE Standard for Media Management System (MMS) Architecture Native Protocols IEEE P1244.2/ D041900 IEEE Std 1244.3-2000 IEEE Std 1244.4-2000 IEEE Std 1244.5-2000 Draft Standard for Session Security, Authentication, Initialization Protocol IEEE Standard for Media Management Protocol IEEE Standard for Drive Management Protocol IEEE Standard for Library Management Protocol Interoperability Protocols P1244.6 P1244.7 Draft Standard for Media Manager Interchange Protocol Draft Standard for Media Manager Control Interface Protocol Programming and Command Line Interfaces P1244.8 P1244.9 P1244.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.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.
SYSTEM (MMS) ARCHITECTURE
IEEE Std 1244.1-2000
Readers should be aware that these standards are primarily reference documents, and as such, may be organized in a manner that is not conducive to sequential reading. (Feel free, for example, to skim or skip ahead of the Denitions clause, Clause 3 in this standard, as you read.) The authors of the IEEE 1244 standards expect that additional publications that document aspects of the MMS will appear over time. It is intended that the IEEE MMS suite of standards be considered the denitive reference to the standard, and that these additional publications exist to explain, clarify, and amplify the IEEE standards, aspects of implementation, or of management of MMS sites. It is expected that vendors will implement proprietary products that add value to systems that are based on the IEEE MMS. These proprietary products must not change the required aspects of the standard as addressed in the IEEE standards. These products may signicantly improve the functionality and usability of a standards-based system. Over time, such proprietary extensions may be proposed as additions to the IEEE standard. Until such time as an extension is transformed into an approved IEEE standard, it must not be referred to as a standard.
1.2 Purpose
This standard describes the motivations for an overall architecture of the MMS. Although the architecture may suggest a particular design or implementation, it is not the IEEEs intent to favor a specic implementation of the MMS. Indeed, it should be possible to implement the MMS in a number of ways, ranging from a lightweight implementation in a scripting language such as Perl, or a full implementation written in a traditional programming language such as C, C++, or Java. The MMS is a software system for managing physical media. The system has the following properties: a) b) c) d) It is media neutral to allow the management of computer tapes, disk media, disks, optical disks, CD-ROMs, as well as non-computer media such as videotapes or reels of lm. It is scalable to be comfortable in environments as small as a single individuals ofce or home and as large as a multinational corporation, educational or scientic institution, or government archives. It is platform neutral and operating system independent to work with existing computer systems from multiple vendors with varying degrees of media-handling sophistication. 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. A single MMS may manage devices that are connected to many host computer systems, including devices that are physically connected to multiple hosts. Connectivity between elements of the MMS requires the availability of standard TCP/IP. It provides a reasonable degree of security and protection for access to the media by ensuring that specic media may be mounted only by those applications that have authority to access that media. All parties are authenticated, and network communication is digitally signed so that it is extremely difcult to forge. It is content neutral, and does not have any inherent understanding of the content of the media; indeed, with some media, such as videotape or lm, the MMS many not even have access to the content of the media. It is application independent to provide appropriate media management functions for diverse applications ranging from backup and hierarchical storage management, to broadcast television automation. Media belonging to multiple applications may be managed by a single MMS; these applications may be multiple instances of the same program, or of different applications.
e)
f)
g)
IEEE Std 1244.1-2000
h) i)
It is designed to be modular to allow independent groups to work on components of the MMS independently; the modularity is provided by strong, exible interfaces that can evolve over time. It is language neutral to permit programmers to write applications that interact with the MMS in almost any programming language, and, indeed, to allow the MMS itself to be written in almost any programming language. It allows multiple implementations to interoperate seamlessly.
j)
The key to the architecture of MMS is to clearly dene the basic functionality that the MMS must provide, and to declare specic points in the functionality to provide dened interfaces that allow independent components to interoperate.
1.3 Conformance
In order to ensure interoperability between applications and the MMS, and between components that comprise an installation of the MMS, it is required that MMS components adhere to this standard. a) When a component accepts a dened language or protocol, it shall accept that language or protocol in its entiretysubsetting is not permitted. Note that the languages and protocols are versioned, so compliance is with a specic version of a specic language or protocol. In general, a component is expected to start by supporting the current version of the language(s) it supports, and then as new versions of the language are introduced, the component will continue to support older versions. When a component generates a dened language or protocol, it shall generate language or protocol that fully conforms to the specications given in this standardadditions, modications, and extensions are not permitted. All components must comply with the relevant clauses of the data model as dened in the standard. User-dened attributes and device-specic commands (cpattribute and cpshow) are permitted within the data model and the languages. These specically allow a pair of components to incorporate exchanges that are not dened in the languages and protocols, and these are the only mechanisms that may be used to extend the standard environment. 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. If an experimental, non-conforming version of a language is required, this may be done only if the language name is changed. It is suggested that such an experimental version be a superset of an existing, dened version of a language. This methodology allows unilateral extension of a language, but the extended language is no longer a part of this standard. This mechanism should be used for experimental implementations of features, which would at some future date be incorporated into a standard version of the language. To conform to the MMS as a whole, a system shall incorporate the basic software components that are described in this standard [Media Manager (MM), Library Manager (LM), and Drive Manager (DM)] and these software components must have the functions described in these standards. It is permissible to create individual components that comply with one or more of the language standards but do not t into a full MMS; this is considered partial conformance with the MMS standard. [For example, a reduced-function MM that fully supports Media Management Protocol (MMP) may incorporate internal implementations of the LM and DM. This is considered partial conformance, because the MM cannot accommodate additional LMs or DMs since it does not implement Library Management Protocol (LMP) or Drive Management Protocol (DMP).]
b)
c)
d)
e)
IEEE Std 1244.1-2000
2. References
This standard shall be used in conjunction with the following standards. When the following standards are superseded by an approved revision, the revision shall apply. ANSI X3.301:1997, Information TechnologySCSI-3 Primary Commands (SPC).2 IEEE P1244.2/D041900, Draft Standard for Media Management System (MMS) Session Security, Authentication, Initialization Protocol (SSAIP).3 IEEE Std 1244.3-2000, IEEE Standard for Media Management System (MMS) Media Management Protocol (MMP).4 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). ISO 639:1988, Code for the Representation of Names of Languages.5 ISO 3166:1993, Codes for the Representation of Names of Countries. ISO/IEC 10646-1:1999, Information TechnologyUniversal Multiple-Octet Coded Character Set (UCS) Part 1: Architecture and Basic Multilingual Plane. ISO/IEC 11578:1996, Information TechnologyOpen Systems InterconnectionApplication Context for Systems Management with Transaction Processing. IETF RFC 791-1981, Internet Protocol (IP).6 IETF RFC 793-1981, Transmission Control Protocol (TCP). IETF RFC 1766-1995, Tags for the Identication of Languages. IETF RFC 2279-1988, UTF-8, A transformation format of ISO 10646.
3. Denitions, abbreviations, and acronyms

3.1 Denitions
For the purposes of this standard, the following terms apply:
2ANSI
publications are available from the Sales Department, American National Standards Institute, 11 West 42nd Street, 13th Floor, New York, NY 10036, USA (http://www.ansi.org/). 3This IEEE standards project was not approved by the IEEE-SA Standards Board at the time this publication went to press. For information about obtaining a draft, contact the IEEE. 4IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331. 5ISO publications are available from the ISO Central Secretariat, Case Postale 56, 1 rue de Varemb, CH-1211, Genve 20, Switzerland/Suisse (http://www.iso.ch/). ISO publications are also available in the United States from the Sales Department, American National Standards Institute, 11 West 42nd Street, 13th Floor, New York, NY 10036, USA (http://www.ansi.org/). 6Internet Requests for Comments (RFCs) are available on the World Wide Web at the following site: www.ietf.org.
IEEE Std 1244.1-2000
3.1.1 administrative application: A program that is concerned with managing operational aspects of the Media Management System (MMS), and typically does not itself own media. An administrative application may include an interface for administrative users. Examples of administrative applications include those that allow the addition and removal of applications, drives, libraries, media, and computer systems from the MMS, as well as those concerned with allocation and policy management of an installation.
NOTESee 6.2.2 in this standard for more information.
3.1.2 automated library: A robotic (electromechanical) library. 3.1.3 cartridge: A unit of physical media that contains one or more sides. 3.1.4 client application: An application program that makes use of Media Management System (MMS) services to manage its media. Examples of client applications include a backup program, a hierarchical storage manager, and an application that allows individual users to mount their own tapes. 3.1.5 compound cartridge: An ordered set of cartridges that may be treated atomically. 3.1.6 data mover (n.): A system program through which a client application accesses the data on media. A data mover is not part of the Media Management System (MMS), nor is a data mover required for operation of the MMS. If a data mover is present, the MMS provides appropriate interfaces and facilities for it to operate. 3.1.7 drive (n.): A piece of hardware that allows access to data that is stored on media. A set of devices such as RAID may be considered as a single drive. 3.1.8 external label: A marking on the exterior of a cartridge that identies it. The external label may be human-readable, machine-readable, or both. A bar-code label is an example of an external label. Syn: physical cartridge layer. 3.1.9 internal label: A record in a known format in a known position within a volume that identies the volume. 3.1.10 library: An automated or manual cartridge-storing facility, e.g., an automated library or a vault. A library may contain zero or more drives, input/output ports and attachments to other libraries. 3.1.11 load (v.): The electromechanical actions of making cartridges ready for access in a drive. 3.1.12 media: Any readable or writable data storage area. 3.1.13 mount (v.): The action of making a cartridge, side, partition, or volume accessible. a) Mounting a volume is a logical action that implies mounting the one or more partitions that make up the volume. 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. c) Mounting a side is the physical action of mounting a cartridge in a drive in a particular orientation. d) Mounting a cartridge is the physical action of moving a cartridge to a drive and loading it into the drive. 3.1.14 move (v.): The physical action of moving a cartridge from one location to another, where a location is a slot, a drive, or a port.
IEEE Std 1244.1-2000
3.1.15 operations application: A class of administrative application that provides an interface for the staff who operate a media library. Examples of operations applications include a program that directs operations staff to obtain a cartridge and load it into a drive, and a program that allows an operator to place a drive or robot in or out of service. 3.1.16 partition: A portion of a side of a cartridge that is accessible as a unit. 3.1.17 port: A physical entity that allows import or export of one or more cartridges from a library. 3.1.18 physical cartridge layer (PCL): See: external layer. 3.1.19 side: The physical portion of a cartridge that is accessible by a drive after one mount operation. A side contains one or more partitions. 3.1.20 vault: A non-automated (manual) library, i.e., a shelf. 3.1.21 volume: A named, logical container of data. A simple volume, which is the common case, is represented as a single partition. A complex volume utilizes multiple partitions to store its data; these partitions may be on one or more physical cartridges, which may be arranged in a number of different ways.
3.2 Acronyms and abbreviations

3.2.1 DCE: Formerly the Open Software Foundation (OSF) Distributed Computing Environment (DCE), and now the Open Groups DCE.
NOTESee http://www.opengroup.org for technical specications and references.
3.2.2 PCL: Physical cartridge label. Syn: external label. 3.2.3 UUID: Universally unique identier. Various versions of UUIDs exist, and references for generation of UUIDs abound.
NOTESee http://www.opengroup.org for technical specications and references.
4. Functionality
The MMS manages media at the request of clients. MMS clients are application programs that run on one or more host computer systems. The MMS itself does not understand individual human usersit is the responsibility of the application programs that own the media to provide an appropriate mapping between the applications users and the data that an individual user may access on a piece of media. Since the MMS has no knowledge of users, the application must also know how to verify the identity of a particular individual user if user verication is required. In many cases, the application may utilize an operating system to handle user verication. The reader may wish to consider the functions of the MMS from a number of perspectives. a) b) c) d) An individual, human user of physical media. A program or group of programs that manage and/or store and retrieve information on physical media. A site administrator or administrators who have policy responsibility for some group of media. Operations staff who must deal with individual requests, actions, and problem situations.
IEEE Std 1244.1-2000
From the perspective of an individual human user, there should be little or no direct contact with the MMS. Applications may allow a user to gain direct access to media, such as mounting a tape archive (tar) on a POSIX or UNIX system. The user would then use the tar program to directly read or write the media. The MMS is structured to make it easy for these types of applications to exist, and for these applications to readily provide a degree of security consistent with the security model of the underlying computer system(s). Client application programs have a relatively rich set of operations provided to them by the MMS. In addition to basic operations such as media allocation, mounting, dismounting, and deallocation, 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. Database-style operations are provided that permit an application to locate a specic piece or pieces of media based on standard MMS-provided criteria, as well as application-specic criteria. The MMS automatically maintains a moderate amount of metadata for each piece of media, and most of this information is available to application programs. Administration and operation functions for the MMS are handled by a set of applications, the number and scope of which may grow over time. Core functions and levels of security are provided by the MMS architecture, but specic user interfaces are not constrained by the MMS suite. This permits the implementation of interfaces that are appropriate for different environments: a single user, a corporate data center, a television broadcast operation, a dairy farm, etc. The MMS is engineered primarily to handle automated robotic libraries. It may also be used to manage vaults (manual libraries). There may be specic operational considerations with manual libraries that are not addressed optimally by the present version of the MMS.
4.1 Interface protocols

The interfaces in the MMS are application-layer protocols as designated in the ISO model. They are dened in terms of interface languages, which are text oriented and have an asynchronous command-response style. These interface languages are referred to as protocols, as they directly correspond to common applicationlayer Internet protocols such as HyperText Transfer Protocol (http) and File Transfer Protocol (ftp). To comply with an MMS interface, two components shall establish a connection via a network interface, and then send and receive information in one of the MMS-dened languages. (All currently dened MMS languages utilize text strings as the basis for information exchange.) TCP/IP shall be used as the transport for MMS protocols whenever information is transferred between MMS components. The standard port numbers 651, (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, or both, are used for all connections between components of the MMS. This text-oriented metaphor was chosen for MMS instead of a binary interface such as DCE RPC, because the text-oriented protocol is more platform-neutral. The text-oriented message scheme also does not require the licensing, implementation, and installation of potentially complex underlying software. Implementers of the MMS may provide standard library code, which make it as easy to utilize text-oriented interfaces as an RPC system. (IEEE P1244.8 will provide a standard denition of these interfaces.) The functionality provided by the MMS interface languages is comprehensive and exible, similar to a database query language such as SQL. The ISO-10646 character set (Unicode) encoded in UTF-8 is used as the character set. 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. All keywords are standardized and are not localized. Error and status messages are provided in a form that may be easily localized. Sort-order comparison of strings (as opposed to equality comparison) is performed in very limited cases, and localization support for collating sequence is provided in these cases. There are four primary protocols dened in the MMS architecture for managing media. They are as follows:
IEEE Std 1244.1-2000
a)
Session Security, Authentication, and Initialization Protocol (SSAIP) IEEE P1244.2/D041900is the initial handshake protocol used by all components of the MMS to establish identity, authority, and initial communication with the MM. Media Management Protocol (MMP)IEEE Std 1244.3-2000is used by client and administrative applications to allocate, mount, dismount, and deallocate volumes, and to administer the system. The MMP includes levels of privilege so that, for example, a client application cannot perform administrative functions, or an operator console program cannot perform higher-level management functions. Drive Management Protocol (DMP)IEEE Std 1244.4-2000denes the language by which the MM and DM communicate. The MM issues load and unload commands to the DM. The DM reports status, errors, usage statistics, and offered capabilities of the drive to the MM. Library Management Protocol (LMP)IEEE Std 1244.5-2000denes the language by which the MM and an LM communicate. An LM manages an automated library or a vault. The MM issues commands to the LM to move cartridges. The LM reports status, errors, and the current contents and topology of the library to the MM.
b)
c)
d)
The MMP, DMP, and LMP are peer-to-peer, bi-directional, asynchronous protocols. The minimum functionality required to implement an MMS is the SSAIP and MMP. (This would be a monolithic implementation that directly manages drives and libraries without using separate LM or DM programs.) A practical implementation will additionally include the DMP and LMP. The following additional protocols are dened to extend the MMS to interoperate with other MMSs: a) Media Manager Interchange Protocol (MMIP)IEEE P1244.6will dene a protocol to allow interchange of information between autonomous MMs. This protocol will facilitate the transfer of media between separate MMs by transferring all associated metadata that is associated with that media. The separate MMs might be present at several sites within a large organization, or they might be in different organizations. Media Manager Control Interface Protocol (MMCIP)IEEE P1244.7will dene a protocol that permits interfacing the data management component of the MMS with existing library management systems. The MMCIP will allow real-time coordination of metadata information between an MMS and another non-IEEE 1244 MMS, whereas the MMIP will allow off-line shipment of metadata between two instantiations of MMS.
b)
4.2 Programming and command line interfaces

In addition to the protocols that specify the functionality of the MMS, programming and command-line interfaces are dened as follows: a) C Language Procedural InterfaceIEEE P1244.8will dene a set of standard programming interfaces that facilitate the construction of components of the MMS, particularly client, administrative, and operational applications, LMs, and DMs. (The initial denition will be for the C programming language; additional languages such as C++ or Java could be added as additional standards or as an addition to IEEE P1244.8 at a later date.)
IEEE Std 1244.1-2000
b)
MMS User Mount CommandsIEEE P1244.9will dene a set of standard commands to allow a user to allocate, mount, unmount, and deallocate media. These commands are specied as a part of a command line interface for systems that offer these interfaces, such as the POSIX or UNIX shell, or Windows NT command-line interface.7 Commands may be embedded in scripts to produce more complex or custom functions, or to allow an application program that is not written for an MMS to be adapted for use with an MMS. MMS Standard Administrative and Operational CommandsIEEE P1244.10will dene a set of standard administration and operation commands of an MMS. The standard denes a commandline, minimally interactive interface for basic interaction with the MMS; these commands could be used to construct interactive interfaces using scripting-based systems such as shell scripts, Web CGI scripting, Perl, or tcl/tk.
c)
An implementation of the MMS does not require any of these interfaces.
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, using that machines host operating system primitives for I/O. Access control and protection for the drive, and the media loaded in the drive, is controlled by the host operating system. a) Media Data MoverIEEE P1244.11denes protocols and programming interfaces to allow remote and protected access to drives. It permits local and remote input-output operations to be performed in a portable, system-independent manner, and implements the protection of label information on media. A data mover is not required to implement the basic functions of an MMS, nor is it required for operation of an MMS.
4.4 Operation of the MMS

The MMS is designed to provide a high degree of independence between modules, allowing parallel development by multiple organizations of these modules, and enabling an end user to mix and match modules written by different organizations. The standard interface protocols described in 4.1, 4.2, and 4.3 are, of course, key to this characteristic. The primary modules of the MMS are depicted in Figure 1. The MM is the central program module of the MMS. For a given installation, there is a single instantiation of an MM that manages all the media for that site. If separately administered sets of media exist within an organization, multiple MMs could be used. The MM includes a persistent store, which holds all relevant information about the site, including all media, drives, hosts, connectivity between hosts and drives, compatibility between media and drives, applications, etc. The MM receives requests from applications, and utilizes its knowledge of the state of the site to perform resource allocation and operational actions. The architecture and protocols of the MMS are designed to accommodate failures of system components. The MM is accessed by other components of the system using a known TCP/IP address. In a highavailability conguration, 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. Address take-over can be done using standard Internet Protocol (IP) fail-over technology such as IBMs HACMP or Silicon Graphics IRIS FailSafe. The fail-over mechanism is not dened by this standard, nor is it required to be present. The only requirement is that the MM always have the same IP address.
7The
rst time a trademarked product is listed in this standard, it will be marked with either a or TM. Subsequent referrals to the trademark item will be capitalized only. Please refer to the front matter of this standard for details on trademarks.
10
IEEE Std 1244.1-2000
One or more LMs and DMs carry out the actions requested by the MM. To move a cartridge to a drive, the MM utilizes the LMP, communicating with the appropriate LM. The LM performs whatever library-specic actions are required to cause the library to move the cartridge into the selected drive. Under certain circumstances, such as a tape stored in a vault, which must be read by a drive that is attached to an automated library, the MM may need to communicate with more than one LM in order to move the selected cartridge into the selected drive. Once the cartridge has been loaded into the drive, the MM performs any necessary control operations on the drive via the DMP to the DM associated with the drive. As with the LM, the MM does not have knowledge of the specics of the drive; the DMP provides a generic interface, and the DM specic to the selected drive performs any drive-dependent functions. Optionally, the MM may also verify the internal label(s) on the media, performing any necessary I/O via the DMP and the DM. The intent is that the LM and DM be relatively simple programs, and the majority of complexity of the MMS be implemented in the MM. Typically, 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. This allows rapid restart as well as the implementation of high-availability congurations of LMs and DMs.
Figure 1Primary modules within the MMSthe Media Manager, Library Managers, and Drive Managers 4.4.1 Operational overview To put the system components and protocols into perspective, here is a relatively simple example that illustrates how the pieces of the system t together. In this example, the sequence of events is as follows:
11
IEEE Std 1244.1-2000
a) b) c) d) e) f)
An application program starts up. The application connects to the MM and is authenticated. The application causes the MMS to mount a tape. The application performs I/O directly to the tape. The application utilizes the MMS to dismount the tape. The application exits.
Communication between the application and the MM is shown as well as communication between the MM and the DMs and LMs. This example is not an authoritative description of each of the languages that are used within the example; consult the appropriate individual standard for the language for an authoritative description. 4.4.1.1 Application establishes connection with MM The application utilizes its network conguration information to establish a TCP/IP connection to the MMS on the system that is running the MM. Once the connection is established, it remains open until the application is completely done with its interaction with the MM. After the TCP/IP connection is established, the application signs on to the MM using the SSAIP. (For details of the SSAIP, see IEEE P1244.2/D041900.) This sign on process is slightly more complex than a typical interactive log-on because it establishes the identity of both parties, the level of security to be used for the remainder of the connection, and the language to be used for communication during the session. If the application does not need encryption of the session, it should open TCP port 651 on the MMs host, while if it needs secure socket layer (SSL) encryption, it should open TCP port 652 on the MMs host. Application -> MM: hello client ["Backup"] instance ["Accounting"] language ["MMP"] versions ["1.0" "1.1"] password["cablefree"]; In the example above, the application identies itself to the server as the Accounting instance of the Backup application. The application then states that it will be utilizing the MMP language, and is capable of speaking either version 1.0 or 1.1 of that language. It also establishes an authenticated session using simple password authentication. If the application did not require authentication, the password clause would have been eliminated; see the IEEE P1244.2/D041900 for details. When the MM receives this message, it retrieves its copy of the private shared key specic to the Accounting instance of the Backup application. If the passwords do not match, the client is refused access. If the passwords match, the application is authenticated, and the MM replies with its name. 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. MM -> Application: welcome version["1.1"] password["silverton"];
All further communication on the TCP/IP connection between the application and the MM is in the MMP language. Applications typically interact with only a single MM, but the SSAIP protocol is designed to permit an application to interact with more than one MM. If the authentication information does not match, the application should terminate the session. If the authentications do match, the MM has authenticated itself to the application.
12
IEEE Std 1244.1-2000
4.4.1.2 Application requests a volume to be mounted The application sends a simple mount command to the MM, which requests that the volume usr990424 be mounted. Application -> MM: mount task ["1"] volname ["usr990424"] report [MOUNTLOGICAL."MountLogicalHandle"]; The task clause identies this command and is used to correlate any responses from the MM with this specic request. The report clause instructs the MM to return the logical device handle on which the volume is ultimately mounted; without this information, the application would have no idea how to access the media. The MM would typically accept this command immediately, so that the application could, if appropriate, issue further commands to the MM for processing while the following command executes: MM -> Application: response task ["1"] accepted;
The command-accept-response model is described in 7.3. The MM then consults its database to determine a) b) c) d) Whether or not this volume exists in the applications name space. The specic physical media (cartridge, side, and partition) to which the volume refers. In which library the requested cartridge resides, and its location within the library. Which drives within that library could be used to mount the cartridge, considering the cartridges type and the physical connectivity of drives to host computers.
If either the cartridge is in use, or all possible drives on which the cartridge could be mounted are in use, the request will be delayed until appropriate resources become available. Once those resources are available, the MM commences the physical task of getting the cartridge into the drive and making it ready for use. 4.4.1.3 MM interacts with LM to mount physical media The MM is connected to the selected LM via a TCP/IP connection. This connection was established when the LM and MM were brought up, and remains established until one or both of these system components terminate. An initialization exchange similar to the one shown in 4.4.1.1 is used to establish the applicationlevel connection, authentication protocol, and language version. The language used between the MM and the LM is LMP/M; commands from the LM to the MM are in the LMP/L language. In this example, the cartridge is identied by the physical cartridge label AB1234 and is to be mounted on side 1. It currently resides in bay 2, slot 12 of the library, and is to be mounted in either drive drive1 or drive drive2, at the LMs option. MM -> LM: mount task ["365"] slot ["bay 2, slot 12" "AB1234" "side 1"] drive ["drive1"] drive["drive2"]; The LM accepts the command as follows: LM -> MM: response task ["365"] accepted;
13
IEEE Std 1244.1-2000
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. (The MM maps the slot name in the MMP slot command to an associated bay name for the LM; both slot names and bay names are arbitrary strings, but implementers are strongly encouraged to choose names that have meaning to human operators.) Once this action has been successfully completed, the LM updates the state of several internal tables in the MM. LM -> MM: config task ["982"] scope ["partial"] slot ["bay 2, 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"]; (The MMs accepted and success responses to the cong commands are omitted here.) Finally, the LM tells the MM that the requested cartridge was mounted in drive DLT202. LM -> MM: response task ["365"] success text ["bay 2, slot 12" "AB1234" "drive1"];
4.4.1.4 MM interacts with DM to set up drive The MM is connected to the selected DM via a TCP/IP connection. This connection was established when the DM and MM were brought up, and remains established until one or both of these system components terminate. An initialization exchange similar to the one shown in 4.4.1.1 is used to establish the applicationlevel connection, authentication protocol, and language version. The language used between the MM and the DM is DMP/M; commands from the DM to the MM are in the DMP/D language. The DM is located on the same physical computer as the application, and utilizes the same physical connection to the drive that the application will use. The MM requests that the DM ensure that the cartridge is loaded in the drive: MM -> DM: loadtask ["191"];
The DM accepts the command: DM -> MM: response task ["191"] accepted;
The DM causes any physical activity that might be required to load the drive, and then the DM reports that the command has completed successfully. DM -> MM: response task ["191"] success;
The MM requests that the DM make this drive available for read-write access, and return to the MM an appropriate device name to pass back to the application. MM -> DM: attach task["192"] modename ["readwrite"];
14
IEEE Std 1244.1-2000
Readwrite is a standard token; the base set of standard tokens appears as Clause 20 of this standard. The DM accepts the command: DM -> MM: response task ["192"] accepted;
The DM creates any necessary device nodes, conditions the hardware and/or operating system software for the mode requested in the attach command, and then replies to the MM with the software name of the device that the application will use to access the cartridge. DM -> MM: response task ["192"] success text ["/dev/mmtape/8E927BD4"]; In this example, the DM created a one-time-only node named /dev/mmtape/8E927BD4 for access to the device. 4.4.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"]; This completes the execution of the applications task 1 command. 4.4.1.6 Application performs I/O to drive The application may now perform I/O to the drive, reading and writing the media as it wishes. All I/O is performed through standard device mechanisms within the operating system on which the application is running. 4.4.1.7 Application requests volume to be unmounted The application sends an unmount command to the MM, which requests that the volume usr990424 be unmounted. Application - > MM: The MM accepts this command: MM -> Application: response task ["2"] accepted; unmount task ["2"] volname ["usr990424"];
The MM then interacts with the DM and MM to physically unmount the cartridge; these interactions are similar to those shown in 4.4.1.3 and 4.4.1.4, and are omitted here for brevity. Once the physical actions are complete, the MM informs the application: MM -> Application: response task ["2"] success;
4.4.1.8 Application terminates connection with MM The application is free to continue interacting with the MM, performing other mounts, allocation, unmounts, etc., until it is nished. The application terminates its interaction with the MM by issuing the goodbye command:
15
IEEE Std 1244.1-2000
Application -> MM: The MM accepts this command: MM -> Application:
goodbye task ["3"];
response task ["3"] accepted;
If there are any pending actions that the MM must complete before the session can be terminated, there will be a delay before the MMs nal reply to the application: MM -> Application: response task ["3"] success;
The application then closes its TCP/IP connection to the MM. Note that the application could also terminate (and indeed, cause the unmount to occur) by unilaterally closing the TCP/IP connection (this happens when an application crashes, for example). However, simply dropping the connection doesnt give the MM the opportunity to gracefully complete any commands that might be outstanding, nor to return status information to the application. See 6.2.6 for more details on abnormal termination.
4.5 LM operational overview

Every LM implements the LMP, which allows a library to be controlled by the MM in a standard manner. The LM may be implemented on a host system that controls the library via a local peripheral attachment (serial, SCSI, etc.) or could be implemented in an embedded controller that is a part of the library. A library with an embedded controller would simply plug into the local area network and immediately be usable as part of an MMS. (We would expect that any required conguration of such a library would be performed by a few Web pages.) Libraries vary widely in their capabilities, functions, and interfaces, so LM implementations will differ from library to library. There are three broad categories of libraries, each of which may require a somewhat different implementation strategy. 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 most authoritative representation of the state of the library is the physical world. State includes such information as the physical conguration of the library, the position within the library of each cartridge or open slot, drives in the library, etc. The MM, with the cooperation of the LM, maintains a representation of the state of the library in its databases; see Clause 13 for details on the MMs representation of a library. The cong command in LMP is used to update the MMs databases whenever the state of the library changes. 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, or may elect to maintain a temporary copy of the state of 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. For many sighted robots, it is a routine procedure to have the library physically inventory the contents of the library whenever the unit is powered up, or whenever the unit has been opened in such a way that the contents might have been disturbed. For a blind robot, the MMS must rely on its stored database, as the library cannot tell the MMS the identity and location of individual
16
IEEE Std 1244.1-2000
cartridges. (Some blind robots can determine whether or not a slot is empty.) A manual inventory can be done in a vault, but it is potentially a time-consuming operation. Some installations may be able to use handheld bar-code readers to speed this process, but a manual inventory is still not something that would be carried out frequently. Vaults require, and robots may require, interaction with a system operator. The MMS provides a mechanism, the request command in the LMP, by which the LM may utilize the MM to interact with human operators. The MM, in turn, utilizes one or more administrative applications and the operator interface commands in MMP (accept, respond, release, move, eject, and inject) to perform those interactions with the operator(s). (An LM should not directly interact with an operator console, because in larger installations, it may be desirable for one or more libraries to share one or more operator consoles.) 4.5.1 Mount verication A key issue with managing removable media is to ensure that the desired piece of media actually gets mounted in the desired drive. With a sighted robot, the probability that the operation is performed correctly is essentially 100%. With a blind robot, the probability of an error is higher, because the robot cannot verify that the desired cartridge (actually, the cartridge containing the desired partition) is actually present in the slot that the database says the cartridge is in. With a vault, an operator will typically visually verify that the right cartridge and partition are obtained, but operators do sometimes make mistakes. The MMS is system independent. Since a number of popular operating systems such as UNIX do not have any notion of standard tape labels, the MMS cannot simply require that all cartridges have standard machine-readable labels (such as ANSI or IBM standard labels). Without standardized tape labels, the MMS cannot have the DM verify that label at mount time. Instead, the MMS provides an extensible mounttime verication scheme. Verication 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, it veries the bar code on the cartridge as the cartridge is being mounted. If the bar code does not match the expected bar code, the LM will cause the mount to fail. If the bar code is veried, then the on-media identier [step b)] is checked (if that capability is available on the drive); otherwise, no further checking is performed. If the cartridge and drive support an on-media identier, the DM will supply that identier to the MM as part of the response to the load command. (The on-media identier is a device-dependent immutable identier, which is automatically encoded on the media by the drive.) The on-media identier will be compared with the expected media ID that is stored in the MMs database in the PARTITION.PartitionSignature eld. This check is performed for all mounts, even those for which bar-code verication is available, if it is available on the cartridge and drive. If the media ID does not match the one stored in the MMs database, the mount is aborted by the MM. If the application has been administratively permitted to bypass the signature mechanism [step d)] and the application requests no verication at mount time, no further checking is performed. It is assumed that the application will check to ensure that the correct volume has been loaded, and that the application will reject the volume if it is not the one that was expected. A signature mechanism is used to do a best efforts check on the cartridge.
b)
c)
d)
The signature is a short representation of the content of the cartridgethis may be a hash sum of the rst megabyte of data on the cartridge or a tape label, several forms of which are possible. Under certain rare circumstances, an application-specic label may be used to identify a cartridge, such as when the label information is at the end of the media. The signature and signature type for each cartridge is stored in the MMs database. When a cartridge is mounted, MM uses the DMPs identify command, which includes the
17
IEEE Std 1244.1-2000
type of signature being requested, to cause the DM to return the cartridges signature after loading the cartridge and attaching the device. When a cartridge is unmounted, the MM uses the identify command to obtain from the DM an updated signature for the cartridge prior to detaching and unloading the cartridge. This additional identify step can be bypassed for applications by identifying the unmount as clean. An application should do so only if it has either supplied the new signature directly to the MM by directly setting the PARTITION.PartitionSignature attribute or if no change to the signature portion of the partition was made by the application. Further details on the mount-time media verication and signature mechanism are given in the identify command description in the DMP. 4.5.2 Introduction of media This subclause outlines how an operator may introduce media to a library and how the MMS handles this operation. The operator may choose to physically place the media in the library and then work with the MMS to appropriately identify the media, or the operator may choose to pre-identify media which the operator will then introduce into the library. The operator interface is an administrative application, which utilizes MMPs inject command to instruct the MM to take one or more cartridges into the library. The MM utilizes the LMPs inject command to cause the library to perform the physical operation. Detailed information on the command sequence is presented in IEEE Std 1244.3-2000.
4.6 System start-up, restart, and shutdown

Components of the system may be started in any order, but no processing will occur until the MM is in operation. When started, all applications, LMs, and DMs attempt to contact the MM at a known network address (typically specied using a host name that is looked up via DNS to yield an IP address) on the assigned port number 651 (ieee_mms). If no MM is available, the application, LM, or DM will sleep for some period of time and try again. If the MM is available, the SSAIP (IEEE P1244.2/D041900) is used to establish and authenticate the identities of the two parties, and to resolve the protocol that is to be used for further communications. In the event of unexpected termination of any system component, the system component with which that component is communicating will be notied of the failure of that component by the networking subsystem. If the failed component is an application, LM, or DM, the MM will take appropriate action(s) to clean up any items that are in process. When the failed component is restarted, it will establish communication with the MM as described above. Resynchronization of state with the MM is left up to the application, LM, or DM. If the MM should terminate unexpectedly, or should a network partition occur, all application, LM, and DM components should reset themselves and attempt to re-establish a new connection with the MM. The MM may be restarted on the same or a different machine, as long as its static databases and its IP address are preserved. Autonomous operation of applications, LMs, and DMs is prohibited. More detailed information on start-up, termination, and recovery from failures is given in Clause 6 of this standard and in the individual language specications for the MMP, DMP, and LMP.
5. Operation and matching model

Each statement in the MMP, DMP, and LMP languages consists of a command keyword followed by appropriate arguments. The command species an action, and the arguments express options or constraints on
18
IEEE Std 1244.1-2000
how the command proceeds. For example, the mount command can specify the volume to be mounted explicitly by name, or by using a form of Boolean algebra to determine one or more candidate volumes to be mounted. Thus, the MM may be thought of as a solution engine, i.e., the system fullls requests by nding good solutions to the declarative requests. This is true as well with the LMthe MM may make either totally specic requests or reasonably general requests to the LM. A general request allows the MM to make optimal choices using information that is specic to the make and model of library, and even with respect to the librarys current state. For applications, the Boolean expressions may operate not only on standard-dened metadata information that is stored in the MMs database, but also on application-dened information, such as the approximate percentage of a volume that is in use. As an example, consider the match, order, and number clauses that are common to a number of commands in the MMP. The match clause takes a Boolean expression that selects one or more cartridges within the MMs database. The order clause sorts the results of the match, and the number clause selects particular records out of the results. Thus, using a match/order/number mechanism and an application-dened percent in use eld, an application could select the three emptiest volumes of a specic cartridge type that belong to an application and cause those volumes to be mounted.
6. System model
A system that conforms to a standard IEEE MM may be used in a wide range of installations, from very small to global enterprises. An example of a small installation is a single PC on a desktop with a single removable-media drive, and a desk drawer containing a few cartridges. 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. An MM used by a global enterprise could include thousands of automated libraries and vaults, tens of thousands of drives and computer systems, and tens of millions of cartridges. This MMS would be administered by full-time professional staff, communicate with dozens of human operators across a number of sites, and interact with hundreds of distinct applications and thousands of users. The protocols used to communicate between the various components of the MMS are the same, regardless of the size of the installation. An installation will contain the same basic software components, regardless of its size, but the number of components and the implementation of these components is likely to differ depending on the size of the installation. This clause describes the software and hardware components of the MMS. Clause 7 gives an overview of the protocols used for communication between the components; detailed specications of the individual protocols are given in other standards in the IEEE 1244.x family. This standard describes the data model that underlies the system as well.
6.1 Media
The purpose of the MMS is to manage the physical media associated with an installation. Systems managed by the MMS will support a diverse range of removable media, including computer media such as magnetic tape, optical disk, and CD-ROM, as well as non-computer media such as audiotape and videotape, lm, and audio CDs and videodiscs. To properly manage media, the MMS must understand a moderate amount of information about a physical piece of media, henceforth referred to as a cartridge. This information includes the following:
19
IEEE Std 1244.1-2000
a)
Physical characteristics, such as its external, physical form factor; the type of media housed inside the external shell; the method used to record information on the cartridge; any physical identication present on the outside of the cartridge. Usage and life cycle information, such as the number of mounts, dates rst and last written, expected longevity. The location where the cartridge is normally stored, its current location if it is not in its normal location.
b) c)
Many types of media can accommodate more than a single logical entity within a physical cartridge container. They are as follows: Optical or magnetic disks may have more than one side, and a drive that handles media with multiple sides may allow access to only one or to all sides simultaneously. Optical or magnetic disks may have more than one partition; depending on the device, it may be practical to access multiple partitions simultaneously. Magnetic tapes may have more than one partition; typically, only one partition may be accessed at a time. Sometimes, a user may wish to refer to a group of cartridges as a single entity, for example when using striped or other forms of redundant tape. This group of cartridges is represented as a cartridge set. Note that cartridge sets are not supported by the initial MMS standard. Also note that cartridge sets are not to be confused with cartridge groups, which are a separate object type in the data model. 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, a partition within a cartridge, or a group of cartridges. In almost all cases, applications and end users refer to MMS volumes. The MMS maps the named volume onto an appropriate cartridge or cartridges when performing physical operations. 6.1.1 Cartridges Cartridges are the physical media that the MMS manages. A cartridge has an external shape that determines the slots of a library in which it can reside, and the drives in which the cartridge can physically t. The media within the cartridge and the bit format that is, or will be, recorded on the cartridge also determine the type(s) of drive in which the cartridge may be used. Some cartridges have additional characteristics that are of importance to the MMS, including partitions and sides. Some optical cartridges and DVDs have sidesthey can be mounted with one side or the other accessible, and the other side inaccessible. The two sides can be treated as independent pieces of media except that they cannot be mounted simultaneously. Also, if a two-sided piece of media is physically removed and transported, the two sides are bonded together. Ampex DST and some other tape media may be partitioned into multiple separate tapes, each of which has a pre-determined size. 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, and would encounter an end-of-le if an attempt were made to write past the end of the partition. Similarly, many removable disk media, both magnetic and optical, may be partitioned into distinct partitions that have protected access characteristics. The MMS allocates volumes (the logical entity that applications actually use) to partitions rather than to cartridges. Disk devices, including optical disks, are frequently used by multiple users at the same timea le system partition, for example, might reside on an MMS-managed volume on an optical disk. This version of the MMS architecture does not directly support multiple MMS client applications that simultaneously access a single cartridge. To use shared-access media with this version of the MMS, an intermediary application is
20
IEEE Std 1244.1-2000
required that acts as either a multiplexer or as a mounting service. For example, a magneto-optical disk might contain a lesystem that could be mounted by an application. The mounting application would use MMS interfaces to mount the volume on which the lesystem resides, and then mount the lesystem; once the disk is mounted, other applications would use standard lesystem interfaces to access the media, not MMS interfaces. The mounting application would need to remain active until the lesystem was unmounted, at which point the mounting application would unmount the volume. (Note that the mounting application shall not terminate while the lesystem is in use, as the MMS would then automatically reclaim the drive and the media.) The current MMS does not allow simultaneous access to multiple partitions on a single cartridge, even if the underlying hardware would permit this operation. 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. 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 unique ID (UUID) is used internally within the MMS to identify the cartridge. The external cartridge shape, media oxide type, bit format, and partition and side information are used to determine conformability of media with drives.
Statistical information such as number of mounts, error counts, is also maintained with each cartridge, which facilitates management of the life cycle of the cartridge. Detailed information on the data model for cartridges is in Clause 15 of this standard. 6.1.2 Volumes The volume is the unit of logical information that an application manipulates with the MMS. In the case of a simple cartridge (one side, one partition), 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 applications choice. Volume names are unique within an application: different applications may choose to have volumes with identical names. Applications have no visibility to volumes that are owned by other applications. However, an administrative application may, through the use of references that are qualied with application names, obtain access to all volumes within the MMS. The application is the only level of access control provided by MMS for volumesany ner-grained protection, such as on a per-user basis, is expected to be provided by applications. 6.1.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 rst becomes part of the MMS until it ceases to be a part of it. The Media Manager Interface Protocol, (IEEE P1244.6), denes 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 major events in the life of a cartridge include the following: a) The physical and logical introduction of the cartridge into the system
21
IEEE Std 1244.1-2000
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, either by sending it to another system, 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; 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 MMfor example, 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 MM utilizes a state model to describe its view of the life cycle of a cartridge. First, 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, it is in the located state. If a cartridge has been dened by an administrative application to the MM, but has not yet been seen by the MM in any managed library, it is in the dened state. A cartridge in the dened state optionally may be associated with an application. Once a located cartridge has information added by the administrative application, or a dened cartridge is physically introduced into the system, it becomes an identied cartridge or an allocatable cartridge. A cartridge that is identied is not associated with a cartridge group; an allocatable cartridge has been assigned to a particular cartridge group. An identied cartridge becomes allocatable when it is assigned to a particular cartridge group. This may happen via an administrative application, or when an application requests allocation of an otherwise unassigned cartridge. 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), the cartridge moves to the allocated state. When the application is nished with the volume (actually, nished with all allocated volumes on a cartridge), the cartridge becomes deallocated. The cartridge remains owned by the application until an administrative application processes it.
3)
4)
5)
6)
The administrative application that processes deallocated cartridges may implement site-specic policies, such as erasing headers, writing the entire media, causing it to be degaussed by an operator, or even physically destroying the media. When this application wishes to make a cartridge available for reuse, it causes the cartridge to enter the recycled state; this state is equivalent to identied. Recycled and identied are distinct to differentiate cartridges that are newly introduced into the system. An error state is dened 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, and from error to either allocated or deallocated. Detailed information on the cartridge life cycle may be found in IEEE Std 1244.3-2000 (MMP).
22
IEEE Std 1244.1-2000
6.2 Applications
The MMS is designed to work with one or more end-user applications that implement data I/O functions. It is possible to have an installation in which there are no I/O applications, or a system in which I/O applications are not computer programs; this would be a special case in which the MMS is used to manage non-computer media, such as video or audio tapes or discs. Administrative and operator interface applications are also responsible for providing all administrative and operational interfaces that may be required by an installation. All applications communicate with the MMS using the MMP, as dened in IEEE Std 1244.3-2000. An overview of the MMP is provided in 7.7. There is a well-dened subset of the MMP that is used for nonprivileged applications. The operations available in the subset are sufcient for applications engaged in common tasks such as data transfer and mounting user media. The additional operators in the full MMP are intended to enable the creation of administrative applications. This model denes two levels of privilege within applications that utilize the MMP: application and administrative; administrative applications have no restrictions on the operations they may perform, similar to the POSIX or UNIX super-user. Future versions of the MMS will allow multiple levels of privilege to be dened for MMP operations. To aid development of applications using the MMP, the C-Language Procedural Interface, IEEE P1244.8, will dene a standard C-language programming interface that simplies and standardizes the use of the MMP. Application development in scripting languages such as Perl may be performed using the MMS User Mount Commands, IEEE P1244.9, and using the MMS Standard Administrative and Operational Commands, IEEE P1244.10. These two standards, when written, will dene command-language interfaces for user mounting and administrative and operational commands. Specic interfaces for other programming languages may be dened in the future. 6.2.1 User applications A typical application uses MMS services to allocate, mount, unmount, and deallocate volumes. Data transfer applications utilize volumes, which are logical containers of information, rather than cartridges, which are physical entities. For most current tape technologies, there is only one volume per cartridge, and that volume covers the entire user-accessible area of the cartridge. A user mount application (UMA) is an another example of a standard application, one that would normally be provided as a standard component of an MMS implementation. The UMA allows human users of a computer system to allocate, mount, unmount, and deallocate volumes. The UMA is necessary because the MMS is not aware of the security requirements, user identity conventions, or protection mechanisms of each specic type of computer system or operating system. The MMS itself is concerned with applications, and ensures that applications only have control over media associated with the application requesting the media. IEEE P1244.9 (see 4.2 of this standard) denes a UMA interface that will be consistent across many different computer platforms. 6.2.2 Administrative applications Applications that are intended to change the parameters or conguration of the MMS are called administrative applications. Administrative applications are given a level of privilege that is analogous to the superuser privilege in POSIX or UNIX systems. These applications can perform essentially all allowable operations within the MMS. A future version of this standard will dene a more detailed model for selectively granting access to specic features and capabilities within the MMS. Many functions that are necessary or helpful in a complete MMS are performed by administrative applications instead of by built-in, standardized components. Administrative applications span a wide range of needs, including the following:
23
IEEE Std 1244.1-2000
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, accessible to which machines, etc.) 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, particularly of a non-automated library (vault)
This list of typical administrative applications is not intended to be complete or comprehensive. Certain unusual requirements could require that a data transfer application have the ability to perform a privileged operation, (one that is not normally accessible to a data transfer application). A site may grant administrative privilege to a data transfer application to permit this operation, but by doing so it would also grant full access to all privileged operations. The design of the operations allowed for non-privileged applications should make this case highly unlikely. IEEE P1244.10 (see 4.2) will dene an Administrative and Operational Command Interface that will be consistent across many different system platforms. This interface will be useful for implementing administrative tools using scripting languages. 6.2.3 Operator functions The MMS includes facilities that permit integrated dispatch management of functions that are performed by human operators. LMs and DMs may utilize the request command of LMP/L or DMP/L to send a request to a human operator. Pending requests are held in a queue within the MM, and this queue may be examined and manipulated by one or more administrative applications. Utilizing privileged commands in MMP, an individual administrative application may accept responsibility for command or may release a request that it had previously accepted. Accept and release could either occur by program logic or by manual operator selection through an interface provided by the administrative application. When the requested operation has been completed (or rejected), the administrative application uses the MMPs respond command to send a response to the requesting DM or LM. One particular case of interest is a non-automated library (or vault). 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. An operator interface application removes requests from the pending queue, allows the operator to act on them, and then obtains a response from the operator. The operator interface application informs the LM of the action taken via the MMP respond command, and the LM can then complete (or refuse) the mount. Although it is possible to write a vault LM that directly interacts with the operator, this is not recommended, as it would not allow integration of this LM with other LMs in a single operator interaction environment.
24
IEEE Std 1244.1-2000
6.2.4 Conguration management The MMS has considerable conguration exibility built into the data model described in this standard. Network conguration information, which resides outside the data model, is used to establish a few basic conguration parameters. The most important of these are parameters for individual Applications, Libraries, and DMs. This network conguration 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, Library, or Drive The name of the Application Instance (AI), LM, or DM The private (secret) key that is used to authenticate the LM, DM, or application with the MM
This standard does not address the method by which this network conguration information is generated or distributed to the individual components. Corresponding conguration information is stored in the MMs internal database. One or more administrative applications with appropriate internal security controls are used to manipulate the conguration information that is stored in the MMs internal database. One key design goal of the MMS was to minimize the amount of hard-wired static knowledge in the MMS. This design goal is met by having a highly extensible set of data that is stored in the internal database. For example, new types of cartridges, drives, and libraries, each of which have characteristics that would not be known to the MMS beforehand, can be dened by an installation. Error and informational message texts may be added to the MMS database, both to accommodate new equipment and to introduce new languages to the system. 6.2.5 External policy agents The MMS depends on administrative applications for some of the functionality of the overall system. These administrative applications are called External Policy Agents. 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. Since external policy agents must use the MMP interface, they may be implemented in a variety of languages. The following ve external policy agents are described in 6.2.5.1 through 6.2.5.5. 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, as required, may dene other external policy agents. An MMS will function without external policy agents. However, without a cartridge life cycle policy agent, system operation will be cumbersome, so it is strongly recommended that this policy agent be present in all sites.
25
IEEE Std 1244.1-2000
6.2.5.1 Cartridge life cycle When the last VOLUME is deallocated from a cartridge, the cartridge is not made immediately available to be reused by another application. Some sites will want to perform special processing on the cartridge before letting it back into the set of unused cartridges. An external policy agent shall query the MMS for all cartridges whose CARTRIDGE.CartridgeState eld has the value recycled. This state will be set when the cartridge is owned by an application but does not have any VOLUMES associated with it. The external policy agent may perform any site-specic action that is necessary for those cartridges. Actions performed by the cartridge life cycle agent may range from a) b) c) d) Simply set the CARTRIDGE.CartridgeState eld to allocatable and allow the cartridge to be reused. Overwrite the beginning (label portion) of the cartridge, and then CARTRIDGE.CartridgeState eld to allocatable to allow the cartridge to be reused. set the
Erase or degauss the entire cartridge, and then set the CARTRIDGE.CartridgeState eld to allocatable to allow the cartridge to be reused. Eject the cartridge from the library, crush and burn the cartridge, and delete the CARTRIDGE from the MMS database.
If an external policy agent for cartridge life cycle management is not present, cartridges will not be reused without operator intervention. 6.2.5.2 Drive cleaning support The MMS depends on external policy agents in order to support automated drive cleaning. 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. 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 DM announces that fact by the addition of a NEEDS_CLEANING attribute on the DRIVECARTRIDGEACCESS record created by the most recent unmount operation. The intent is that the policy agent will be the owner of all cleaning cartridge in the MMS, and it only needs to do a mount operation of one of those cartridges to effect a drive cleaning. Note that the policy agent may need to use the WHERE[] clause on the mount command. 6.2.5.3 Drive load balancing The DRIVE.DrivePriority eld 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. The policy agent is free to examine any information inside or outside of the MMS and then to set the DRIVE.DrivePriority elds of any or all of the drives to new values. When a mount request is being processed, each candidate drive in the system is examined and, among all drives that could be used, the MMS will choose to use the drive that has the lowest-valued DrivePriority eld. For each set of drives that has the same DrivePriority value, drives will be used in an unspecied order. When each drive is rst created, it is given a default DrivePriority value. One site might choose to implement a drive usage policy that equalizes the amount of head wear across all equivalent drives, while another site might choose a policy that makes more intense use of the drives closer to the operators station. If no drive load balancing policy agent is present, drive selection will occur, but the drive selection policy will be unspecied.
26
IEEE Std 1244.1-2000
6.2.5.4 Task queue management The TASK.TaskPriority eld in all TASK objects may be modied by an external policy agent to control the order of execution of tasks that are queued. The policy agent is free to examine any information inside or outside of the MMS and then to set the TASK.TaskPriority elds of any or all of the tasks to new values. When a resource becomes available, any pending tasks that can now be accommodated will be examined, and the MMS will select the task that has the lowest-valued TaskPriority eld for execution. For tasks that have the same TaskPriority value, those tasks will be executed in rst-come-rst-served order. When each task is rst queued, it is given a TaskPriority value based on the AI.DefaultPriority attribute. 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), while another site might choose a policy that lets the smallest tasks go rst. 6.2.5.5 Event aggregation and chargeback The MMS creates a DRIVECARTRIDGEACCESS object each time a cartridge is unmounted. Those objects contain information on drive and cartridge performance (transfer and error counts). An external policy agent is required to aggregate data on individual accesses to a cartridge or drives; aggregated statistics allow a site to notice and rectify potential wear and hardware problems. Also, the external policy agent may calculate and apportion usage costs based on site-specic formulae. The MMS makes no attempt to enforce any usage limits; it will only record the actual usage and allow that information to be accessed by an external policy agent. 6.2.6 Application start-up, shutdown, and abnormal termination Applications are initiated by user actions or by system actions on the computer on which the application executes. When an application starts up, it obtains its network conguration, which species the network name or address of the MM, the registered name of the application and AI, and the secret key to be used when communicating with the MM. The method by which an application obtains its network conguration information is not specied by this standard; it might be in a per-application le, or stored in a system registry, for example. The application then contacts the MM using TCP/IP, utilizes the SSAIP and MMP to interact with the MM, says goodbye, and disconnects. The following are three cases that shall be considered: a) b) c) The application terminates abnormally, or the system on which the application resides crashes. The MM terminates abnormally, or the system on which the application resides crashes. A network partition occurs, which makes it impossible for the application and MM to communicate with each other.
If the application terminates abnormally, the MM will detect this when the TCP connection is closed by the operating system of the applications computer. (The MM is constantly listening for activity, including a close operation, on all TCP connections to active applications, DMs, and LMs.) The MM cleans up any state that is related to the application and releases any resources (drives, cartridges) that are held by the application. 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. If the system on which the application is running crashes, the MM will detect this after some delay, and will then take appropriate action. The delay occurs because the MMS relies on the keep-alive function of the TCP protocol to detect host failure. The keep-alive mechanism indicates a disconnection when periodic keep-
27
IEEE Std 1244.1-2000
alive packets are not acknowledged by the host operating system at the other end of the connection. 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 this may be a long interval. Typically, the keep-alive interval may be tuned on a per-system basis, 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. Once a failed TCP connection is detected using the keep-alive mechanism, the MM will take the same actions as it does when an application crashes. If the MM terminates abnormally, or if the machine on which the MM is running crashes, the application may continue running and using the drives and media it was assigned while the MM was running. The application may detect such a failure either by explicitly testing for a closed TCP connection (as the MM does), or it may simply notice a read or write failure when it attempts to communicate with the MM via the closed TCP connection. 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. When the MM comes up after a crash, it utilizes stored information about its state prior to the crash. All logical mounts are placed into a stale category, and for each stale mount, the MM requests that the DM that is associated with the drive attempt to open the drive for exclusive use. If the DM is unable to do so, which would be the case if the application had the drive open, the MM repeats this request periodically. The request will eventually succeed when the application closes the drive. A network partition is generally considered one of the more difcult cases to handle in a distributed system. Short-duration network partitions are not noticed by the MMS, as they are handled completely by the use of TCP. A network partition that exceeds the keep-alive interval will cause forcible disconnection of the MM and the application. The MM will behave in accordance with the rules given above, placing allocated devices into a stale state and attempting to re-establish communication with the DM associated with each stale device. The application will simply disconnect from the MM and go on with its processing. 6.2.7 Abnormal termination and restart of LMs and DMs If an LM or a DM abnormally terminates, the application is not required to do anything. The MMS expects the LM or DM to be restarted by infrastructure on the host, and the restarted LM or DM will re-establish connection with the MM. The application will not be affected in any way. This process is explained in more detail in IEEE Std 1244.4-2000 and IEEE Std 1244.5-2000.
6.3 Media Manager (MM)

At the center of the MMS architecture is the MM. The MM is the central repository for metadata that describes the cartridges, applications, drives, libraries, and usage history of the MMS. It is also the access control manager for the resources assigned to the MMS, the arbitration engine for competing demands on those resources, and the coordinator that sequences the operations of all the LMs and DMs in the MMS on behalf of the MMP clients. The MM shall have a persistent data store that can represent the information in the MMS Data Model as dened by this standard. 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.3-2000) Drive Manager Protocol (IEEE Std 1244.4-2000) Library Manager Protocol (IEEE Std 1244.5-2000)
28
IEEE Std 1244.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. Such an MM would be a monolithic product with embedded LMs and DMs; it would only support applications that conform to the MMP (IEEE Std 1244.32000).
6.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. These programs are intended to be relatively small and simple to create. An LM communicates with the MM via the LMP, as dened in IEEE Std 1244.5-2000. A DM communicates with the MM via the DMP, as dened in IEEE Std 1244.4-2000. Overviews of the LMP and DMP are provided in the paragraphs that follow. The job of an LM is to represent the capabilities and contents of a library to the MM, and to implement the operations that the MM asks for, given the constraints of the librarys structure. The job of a DM is to represent the capabilities of a drive to the MM, and to implement the operations that the MM asks for, given the constraints of the drives capabilities. The relationship between an LM or a DM and the MM is completely dened in their respective protocols. Both protocols dene the relationship to be much more of a peer-to-peer style than a master-slave style. The LM or DM has the responsibility of implementing the MMs commands, but it can also initiate operations that the MM must fulll. The LMP denes an abstract model of a library and then denes operations on that model. 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. A well-written LM would make the best operational use of all of the available features of the library, providing as much value as possible to the local systems administration staff. The LMP also denes how the library and its contents are represented to the MM. The LM must generate a description, in terms dened by the LMP library model, of the cartridges, drives, and storage locations contained in the library. The DMP denes an abstract model of a drive and then denes operations on that model. 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. A well-written DM would make the best operational use of all of the available features of the drive, providing as much value as possible to the local systems administration staff. The DMP also denes how the drive and its capabilities or characteristics are represented to the MM. The DM must generate a description, in terms dened by the DMP drive model, 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. The internal structure of an LM or DM is not visible to the MM, nor is it relevant to the MMS as long as it abides by the protocol denition when it interacts with the MM. In order to accommodate the wide diversity of libraries and drives, a unique LM or DM may be created for each make and model of library or drive. Likewise, an LM or DM may be created to manage one of a family of similar devices. For example, a single LM could be written to handle both the 40 slot and the 80 slot models of a given companys automated library, while a different LM might be required to handle that same companys 240 slot automated library. As another example, a single DM could be written to handle both a DLT2000 and a DLT4000 drive, while a different DM might be required to handle a DLT7000 drive. Note that DLT drives are used here only as an example of drives belonging to a family.
29
IEEE Std 1244.1-2000
6.4.1 Manager start-up, shutdown, and abnormal termination In general, an MMS drive or LM process should be started whenever the system on which the process runs on boots up. Should a manager process terminate or be terminated, that process should be restarted as soon as possible. Note that starting an MMS process does not imply that the process will become active. (Consider libraries and drives that may be accessed by multiple hosts.) The specic sequence of operations that describes what an LM or DM does during start-up is detailed in the standards for LMs and DMs. 6.4.2 Effect of abnormal termination and restart of system components on managers If the MM abnormally terminates, each LM or DM is required to close its connection to the MMS and begin a new session.
7. Protocols
The interfaces between the major components of the MMS are dened as application-layer communication protocols, running over TCP/IP. The interfaces are session-oriented, and the TCP/IP connection is opened once and kept open throughout the session. The protocols are dened in a command-response manner, using character-based encoding similar to well-known Internet protocols, such as telnet, ftp, smtp, and nntp, rather than a binary-encoded RPC paradigm. MMS protocols are dened in terms of a formal, phrase-structured language, rather than a simple command structure, because the information being transferred across the MMS application-layer protocols is more complex than the information typically transferred using standard Internet protocols.
7.1 Language style

The three languages (MMP, LMP, and DMP) all have a common style; all three languages are text based and human readable, and there are common syntactic constructs. Note that there are no architectural requirements that the three protocols use the same style, but at present they are uniform in style. As the MMS evolves, one protocol might be changed to a different stylebinary remote procedure call or XML-based, for examplewhile the others remain in the current style. The only data type supported by these protocols is a string. In some cases the strings must be of a particular format as specied in 10.4. Using the MMP, an application can instruct the MM to make comparisons of strings based on a number of relational string comparison operators. Without a request for a relational comparison from an application, the only operation that the MM will perform on a string is a test of byte-for-byte equality/inequality with another string. Similarly, 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 simplies the internationalization of string handling, as all code that performs multicharacter-set comparisons resides in the MM. All commands in these protocols use a single token as the command name, have a set of clauses that follow the command, and a statement terminator. Typically, the clauses may be given in any order; in a few cases noted in the specication, clauses are executed sequentially and thus the order does make a difference. Each clause begins with a reserved token and, depending on the clause, may include subsidiary tokens and/or strings (for example, arguments to the clause). This structure was chosen as a compromise between human readability and computer efciency.
30
IEEE Std 1244.1-2000
Here is an example, 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"] ; In this example, the move command is followed by three clauses: task, from, and to. All strings are quoted and all unquoted tokens must be literally dened in the protocol denition.
7.2 Language descriptions: extended BNF

The IEEE MMS suite of standards use a modied version of Backus-Naur Form (BNF) to describe the syntax of languages. The meta-symbols of BNF8 are listed in Table 2.
Table 2Meta-symbols of Backus-Naur Form (BNF)

::= | <> meaning is dened as meaning or angle brackets used to surround category names
The angle brackets distinguish syntax rules names (also called nonterminal symbols) from terminal symbols, which are written exactly as they are to be represented. A BNF rule dening a nonterminal has the following form: nonterminal ::= sequence_of_alternatives consisting of strings of terminals or nonterminals separated by the meta-symbol | For example, the BNF production for a mini-language is as follows: <program> ::= program <declaration_sequence> begin <statements_sequence> end ; This example shows that a mini-language program consists of the keyword program followed by the declaration sequence, the keyword begin and the statements sequence, and nally the keyword end and a semicolon. A traditional BNF denition of the syntax of the MMS protocols is not capable of conveniently representing the fact that, in some cases, clauses can occur in any order, but there can be only one occurrence of that clause in the command. Additional operators have been dened to allow these constraints to be expressed. The extended BNF used in these standards adds constructs to standard BNF shown in Table 3. These notations may be combined and used with standard BNF syntax, for example:
8J. W. Backus, The syntax and semantics of the proposed international algebraic language of the Zrich ACM-GAMM conference, in Proceedings of the International Conference on Information Processing (ICIP), Paris, June 1959.
31
IEEE Std 1244.1-2000
Table 3Extended BNF Symbols

Representation [ a ] { a b c } Name Optional Permutation Zero or one of a. Represents the components a b and c in any order, e.g., a b c, a c b, b a c, b c a, c a b, or c b a. Note that this denition of curly braces differs from the denition of these symbols in other extended BNF versions. Group the enclosed syntactic elements as a unit; typically used with the or operator | and the repetition operators * and +. Note that the grouping operator is ordinary parentheses ( ). whereas the permutation operator is curly braces { }. Zero or more of a. One or more of a. Description
( a b )
Grouping
a* a+
Repetition Repetition
<mycommand> ::= verb { <clause1> <clause2>* <clause3>+ } denes <mycommand> to consist of the keyword verb followed by, in any order, exactly one <clause1>, zero or more <clause2>, and one or more <clause3>. <anothercommand> ::= action [ <clauseX> | <clauseY> ] denes <anothercommand> as the keyword action followed by a clause that could be <clauseX>, <clauseY>, or nothing.
7.3 Message sequencing within protocols

The MMP, DMP, and LMP all use a three-phase message sequencing style. This sequencing style allows asynchronous execution of commands and receiver-controlled throttling of incoming command trafc. Each of the three protocols is bi-directional, so this sequencing applies to both directions simultaneously. The description below details how the sequencing works without reference to a particular protocol or a particular direction. Please refer to examples of message sequencing that are present in the examples of 4.4.1. Commands are labeled with a TaskID. After each command is received at the other end, it is checked for syntax errors and an acknowledgment is sent back. Once the acknowledgment is received, another command can be sent. At some point in the future, possibly after many other commands have been sent, a response to the initial command will be received. (No response will occur if the original command was negatively acknowledged.) The response will be labeled with the unique TaskID that was used when the original command was sent. The key here is that multiple commands can be sent without waiting for a response, but an acknowledgment must be received for each command before the next one can be sent. 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 receiver is not required to actually process those commands in parallel, but the protocol denition allows the receiver to do so if necessary. The receiver of a command is free to delay sending an acknowledgment if necessary. This can be used to control the rate at which the other end of the connection is generating commands, as a new command may not be sent out until the acknowledgment of the prior command has been 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
IEEE Std 1244.1-2000
does not need to actually support the asynchronous execution of commands, or to control resource loading in the receiver. In order to avoid a deadlock, 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 endTCP throttling must not be used to control generation of new commands. The socket input buffers cannot be allowed to ll 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. Failure to heed this restriction could result in deadlock.
7.4 Security and authentication

Each computer system that is a part of the MMS has a protected le or its equivalent that contains keys used for authentication. The keys are tuples consisting of {host, client, instance, language}. These keys are used during the initial SSAIP authentication handshake. The example in 4.4.1.1 shows how a session is initially established using SSAIP; further details on SSAIP are found in IEEE P1244.2/D041900.
7.5 Internationalization
The MMS includes features that allow relatively easy localization (internationalization) of user-visible messages. 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. This allows Western character sets to be represented in a compact manner, yet permits the inclusion of all Unicode characters. Status messages are exchanged in a stylized format, including tokens that represent the meaning of the message in a unique, language-independent manner, and a vector of argument words that may be substituted in any order into a localized message for display to a human user. Centralized message catalogs are managed within the MM to allow different language localization to occur for different users of a single system. For messages that are a part of the IEEE MMS suite, English-language strings are dened for all messages. These strings are embedded in relevant parts of the IEEE MMS suite. Implementers are encouraged to use this English-language text in their implementations, but it is not required. Text in an implementation-dened default language may be propagated along with individual 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, a meaningful message can still be produced.
b)
c) d)
e)
The dened tokens and syntactic elements in each protocol have been chosen from the US-ASCII subset, while the values contained in uninterpreted strings can be chosen from the full ISO-10646 character set (Unicode) encoded in UTF-8 character set. The central message catalog, which is part of the MM, is the key to the localization of messages. Each system component, including LMs and DMs, may add new messages in one or more languages to the central message catalog. When a new LM or DM is installed, the corresponding message catalog should be installed in the central message catalog.
33
IEEE Std 1244.1-2000
7.5.1 Language selection The default language selection within the MM for a given installation is congurable. 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, an afrmative response is sent to the client. If the MM has no messages stored in the requested language, an error response is returned. The two-character language identier is selected using standard identiers. See IETF RFC 1766-1995, ISO 639:1988, and ISO 3166:1993. 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; a particular MM may or may not support sorting in a requested locale. 7.5.2 Localized messages The MMS includes a comprehensive scheme that allows system components to be developed in a local language, and for messages from that component to be readily translated to and displayed in a language appropriate to the site of an installed system. Internationalization of localized messages is centralized in the MM, through the use of message catalogs. When a message passes through the MM from an LM or DM to an Application, the message catalog is consulted to produce a version of the message in the language(s) requested by the Application using the locale command. A message format string describes each message, and the message format string is stored in multiple languages in the message catalog. The message format string consists of text plus a number of embedded tags; the tags refer to message arguments. The tags may be in different orders in different languages. The following is a sample message in English: The cartridge AB9278 in slot 12 bay 4 is stuck. 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. Substitution of words within the message format string is performed using a tag construct. Within the message format string, tags are dened using alphanumeric strings surrounded by dollar signs (e.g., $pcl$ or $drive2$). When a message format string is interpreted, these tags are removed and replaced with values of the corresponding name-value attribute pair from the args clause. If it is desired to include a dollar sign in the message format string, it must be escaped using a backslash character (\$).
34
IEEE Std 1244.1-2000
If the MM was communicating with a client that had requested German (DE) localization of messages, and the message catalog contained a message with the token cartridge_stuck in the language DE, the stored format might be Es existiert ein Problem in Position $slot$/$bay$. Die Bildplatte $pcl$ in dieser Position konnte nicht entfernt werden. Notice that the keys in the German message are in a different order than in the English message. When the MM produces the German message, it would be: Es existiert ein Problem in Position 12/4. Die Bildplatte AB9278 in dieser Position konnte nicht entfernt werden. 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, which is managed by the MMthey are not transmitted as part of any language, nor are they visible to any component of the MMS other than the MM. The manufacturer identier (stk), catalog (9710), and message ID (cartridge_stuck) uniquely identify the message in the catalog as follows: a) The manufacturer identier identies the organization that denes the message. Manufacturer identiers must be registered with the IEEE to ensure uniqueness. If the message is dened in the IEEE MMS suite of standards, the manufacturer identier shall be ieee. The manufacturer denes the model identier. A manufacturer may choose to have one or more message catalogs to aid in software maintenance and distribution. Taken together, the manufacturer identier and model identier are used to identify a message catalog. If the message is dened in the IEEE MMS suite of standards, the model shall be 1244. A code that uniquely identies the message within the message catalog. Taken together, the manufacturer identier, model, and code uniquely identify the exact error condition and the particular message associated with this condition.
b)
c)
If it is necessary for program logic to take action based on a specic message, care must be taken to ensure that non vendor-specic program logic rely only on IEEE 1244 dened message codes. Message versioning may be accomplished by either never reusing message identiers and extending an existing message catalog, or establishing a message catalog with a new catalog identier (i.e., 9710, 9710a, 9710b, etc.). The optional arguments clause consists of tag-value pairs; the tags in this example are slot, bay, and pcl. Zero or more occurrences of the loctext clause may be present in a message clause. The loctext clause contains fully localized, clear-text versions of a message. The message originator (DM or LM) may supply a text clause in any desired language(s), or the LM or DM may choose to not supply a loctext clause. 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.
35
IEEE Std 1244.1-2000
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. '] ] Most LMs and DMs should include a formatted message (loctext) in a default language; the loctext clause may be omitted for messages that originate on hardware devices with limited resources, such as drives or small libraries. If the message originator generates only an id and arguments, then it is essential that the language catalog loaded into the MM include the specied message, or translation into a human-readable form will not be performed. <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.5.3 Response messages Response messages may be generated by any MMS component and passed to other MMS components. These messages may or may not be intended for eventual human use. Response messages may occur a) To reject command inputThis is typically because the input string cannot be parsed, or because input was received before acknowledgment of a prior command; this is the unacceptable response message. To accept a command for processingThis is the accepted response message. To transmit the result of a commandThis may be success in the case of a successful command completion, cancelled if a command was cancelled using the cancel command, or error if the command terminated abnormally.
b) c)
The response command is dened as follows: <response-message> ::= "response" { <negative-response> | <accepted-response> | <command-response> } ";" <negative-response> ::= { "unacceptable" [ <message-clause> ] } <accepted-response> ::= { <task-clause> "accepted"} <command-response> ::= { <task-identifier> <final-response> [ <message-clause> ] } <final-response> ::= <response-success> |
36
IEEE Std 1244.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 dened in the MMP, LMP, and DMP. These tokens are intended for machine processing of a response message in a standardized manner. A message-clause should be present in any response message that might be intended for eventual human consumption. 7.5.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. If the command is syntactically incorrect or must be rejected immediately, B sends an unacceptable response to A. A is then free to send further commands to B. If the command is syntactically correct, B sends an accepted response to A. A is then free to send further commands to B. If the command is syntactically correct, but before accepting the command, B must abort processing of the command, B sends a cancelled response to A. If the command completes successfully, B sends a success reply to A. If the command fails to complete, B sends an error reply to A.
d)
7.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. The SSAIP provides identication, and if desired, authentication of the client, which is a requirement to obtain access to the services of the MM in compliance with the MMS security model. The SSAIP also establishes parameters of the communications between the MMS Client and the MMS Module thereafter, such as language and language type. An example of operation of the SSAIP is given in 4.4.1. IEEE P1244.2/D041900 denes SSAIP.
7.7 Overview of MMP

The IEEE MMS MMP is the language that MMS client and administrative programs use to communicate with the MM. The MM manages media and provides access to media when requested. The MMP language provides capabilities in the following areas:
37
IEEE Std 1244.1-2000
a) b) c) d) e) f)
Media Management functions for principals (applications) of the MMS to access and manage removable media. Task Management functions for applications to control the system and the environment in which they operate. Operator Interaction functions for operations personnel to perform routine tasks. Device Management functions for the control of devices. System Management functions for tuning the operation of the MM. Data Management functions for implementing administrative-level capabilities, and for applications to view and modify meta-data associated with the media.
The IEEE Std 1244.3-2000 denes the MMP. At the time this standard was published, the MMP included the following commands; an asterisk (*) indicates that a command is privileged: Media Management: begin, end, mount, unmount, allocate, deallocate, rename Session Management: hello, privilege, locale, goodbye Task Management: cancel, shutdown* Data Management: attribute, show, create*, delete* Device Management: cpattribute*, cpshow*, cpreset*, cpscan* Operator Interface: accept*, respond*, release*, move*, eject*, inject*
An example of operation of the MMP is given in 4.4.1.
7.8 Overview of DMP

The DMP is the language that the MM uses to communicate with DMs. The DMP denes the abstraction that the MMS utilizes for drive conguration and control. This common drive interface is used for all drives in the MMS. 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. DMP consists of two languages: DMP/M, which includes commands from the MM to the DM, and DMP/D, which includes commands from the DM to the MM. IEEE Std 1244.4-2000 denes the DMP. At the time this standard was published, the DMP included the following commands: a) b) DMP/M: attach, detach, load, unload, activate, reset, exit, private, cancel DMP/D: cong, message, ready, private
A brief example of operation of the DMP is given in 4.4.1.
7.9 Overview of LMP

The LMP is the language that the MM uses to communicate with LMs. The LMP denes the abstraction that the MMS utilizes for Library conguration and control. This common Library interface is used for all Libraries in the MMS. 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.
38
IEEE Std 1244.1-2000
LMP consists of two languages: LMP/M, which includes commands from the MM to the LM, and LMP/L, which includes commands from the LM to the MM. IEEE Std 1244.5-2000 denes the LMP. At the time this standard was published, the LMP included the following commands: a) b) LMP/M: mount, unmount, move, openport, scan, activate, reset, exit, barrier, private, cancel LMP/L: message, cong, ready, private, cancel
A brief example of operation of the LMP is given in 4.4.1.
7.10 Overview of MMIP

The Media Manager Interchange Protocol (MMIP) denes a scheme for moving all metadata associated with one or more volumes and cartridges from one MM to another. The metadata is extracted in a portable manner and may be sent by e-mail or by using magnetic media, such as a oppy disk, which can be sent along with the physical media. The MMIP allows critical life cycle information, such as usage, wear, and error data, to remain with media when it is moved from the control of one MMS to another. IEEE P1244.6 will dene the MMIP.
7.11 Overview of MMCIP

The Media Manager Control Interface Protocol (MMCIP) denes a mechanism that allows an external MM, such as media management services running on an IBM mainframe, to be used to manage media in conjunction with an IEEE MMS. 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. IEEE P1244.7 will dene the MMCIP.
8. Tokens
The current, ofcial registry of tokens is maintained on the Web site http://www.ieee-sssc.org, which is operated by the IEEE Storage System Standards Committee (SSSC). A list of tokens is given in Clause 20, which represents the tokens in existence at the time of publication of the standard. If a new token is needed, it can be either unregistered or registered. Unregistered tokens must use a prex (e.g., SGI_, SUN_, etc.) that is registered. To register a token or a prex, see the instructions on the Web site. It is strongly encouraged that a new token be created only if the existing tokens, or a grouping of them, do not adequately cover the desired semantic.
9. Data modelintroduction
The data model denes the inner workings of the MMS, including what essential information is store, and how different components, both physical and logical, relate to one another. This standard denes the required components of the data model, but it does not require a particular implementation of the data model. Possible choices for a particular implementation of the MMS might include an in-memory database,
39
IEEE Std 1244.1-2000
at les, and a relational database. Individual implementations may also need to add attributes to the data model; however, such additional attributes shall not affect the standardized functioning of the interfaces. Extensions to interface languages, which are denoted by languages with names different from the standard IEEE language names, may require extensions to the data model. Any such extensions shall not affect the standardized functioning of standard IEEE languages that are supported by an implementation. This standard species both an abstract model, 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. In order for implementations of different components of the MMS from different vendors to communicate with each other, there must be agreement on the objects, the attributes, their names, the data types, and the semantics as described in this standard. The data types specied for the attributes of the objects constrain only the external representation of those attributes. The internal representation of the attributes is not specied by this standard. The data model consists of a number of objects, each object having a collection of attributes. This scheme correlates well with the relational model, where each table has a number of columns and rows. Each row contains one data objecta tuple that describes a number of attributes that are part of that object. An object may have both required and optional attributes. The MMS data model extends the standard relational model by allowing, for some tables, the addition of new attributes to a given object. These user-dened attributes are one of the primary extension mechanisms within the MMS. User-dened attributes need not be present for all rows in a table. For example, one particular model of tape drive may wish to store a value called magnetic_ux_eld for each cartridge that it has written. The manufacturer of this product, the Acme tape company, could dene a column as _acme_magnetic_ux_eld, and then place a value for this column in the tape cartridges that were written by Acmes tape drive. This column, however, would not be present for non-Acme cartridges.
9.1 Clusters and objects

The 40 different types of objects that an MMS supports are subdivided into 8 different clusters of related objects. The clusters closely match the intuitively distinct pieces of an MMS. The clusters are summarized in Table 4. Table 4Clusters of objects an MMS supports
Cluster name Application cluster Library cluster Drive cluster Object names APPLICATION, AI LIBRARY, LM, BAY, SLOT, SLOTGROUP, SLOTCONFIG, SLOTTYPE DRIVE, DRIVEGROUP, DRIVEGROUPAPPLICATION, DM, DMBITFORMAT, DMBITFORMATTOKEN, DMCAPABILITY, DMCABILITYTOKEN, DMCAPABILITYDEFAULTTOKEN, DMCAPABILITYGROUP, DMCAPABILITYGROUPTOKEN Types of objects in that cluster Related to the denition and authorization of client programs. Related to libraries, generally dened and updated by an LM. Related to drives, generally dened and updated by a DM.
40
IEEE Std 1244.1-2000
Table 4Clusters of objects an MMS supports (continued)

Cluster name Cartridge cluster Object names CARTRIDGE, CARTRIDGEGROUP, CARTRIDGEGROUPAPPLICATION, SIDE, PARTITION, VOLUME, CARTRIDGETYPE CONNECTION, SESSION MOUNTPHYSICAL, MOUNTLOGICAL, DRIVECARTRIDGEACCESS TASK, TASKCARTRIDGE, TASKDRIVE, TASKLIBRARY MESSAGE, REQUEST, SYSTEM, STALEHANDLE Types of objects in that cluster Related to cartridges and what they contain.
Session cluster Mount cluster
Related to currently connected and/or active clients. Related to currently mounted volumes and cartridges. Related to commands currently blocked and waiting for resources. Related to system conguration.
Task cluster System cluster
9.2 Relationships between clusters

The relationship between any two objects in any two clusters is dened to be the same as any other two objects in those same clusters. Another way to say it is that the clusters have relationships to each other that are not dependent on any specied objects in those two clusters. When more than two clusters are discussed at the same time, the overall relationships are simply the sum of the relationships between each of the distinct pairs of clusters. Each successive cluster being considered effectively adds more layers of ltering (exclusion) on top of the restrictions that were there before. Table 5 reveals the relationships of clusters of objects. Cluster names are shown in bold on a left-to-right descending diagonal (e.g., Application). The relationships can best be expressed as restrictions on the possible combinations of objects. Given two objects, if the specied condition is not true, then those two objects are unrelated.
41
IEEE Std 1244.1-2000
Table 5Relationships of clusters of objects

Application may use a cartridge or drive in the library. Application may use the drive. Application has a volume in or may allocate a volume in the cartridge. Library contains the cartridge. Cartridge is in the drive. Application is being used in the session. Application caused the mount. Application submitted the command that started the task. Library is involved in executing the task. Drive is involved in executing the task. Cartridge is involved in executing the task. Session has caused this task to be performed. The task involves this mount. Task
Application
Library
Library contains the drive.
Library is being used by the session. Drive is being used in the session. Cartridge is being used in the session.
Mount occurred on a drive in the library. Drive is being used by this mount. Cartridge is being used by this mount. Session has caused this mount.
Drive
Cartridge
Session
Mount
Conguration
42
IEEE Std 1244.1-2000
Figure 2 illustrates the relationship between objects in the application cluster and the cartridge cluster. Each CartridgeGroupApplication (CartGroupApp) grants one application access to media in one CartridgeGroup (CartGroup). Applications may be granted access to multiple CartridgeGroups. Each cartridge belongs to only one CartridgeGroup at any point in time. Cartridges contain one or more sides. Sides contain one or more partitions. A volume is mapped to one partition on one side of a cartridge. Multiple applications may be granted access to the same CartridgeGroup. CartridgeGroupApp A-A grants Application A access to media in CartridgeGroup A.
Figure 2Relationship between objects in the application cluster and the cartridge cluster
43
IEEE Std 1244.1-2000
Figure 3 illustrates the relationship between applications and drives. Each DriveGroupApplication (DriveGroupApp) grants one application access to drives in one DriveGroup. Applications may be granted access to multiple DriveGroups. Each drive belongs to only one DriveGroup at any point in time. Multiple applications may be granted access to the same DriveGroup
Figure 3Relationship between applications and drives
9.3 Data object list

Table 6 lists the different types of objects in an MMS. These represent abstractions of physical or logical objects used in the MMS. The following naming conventions apply: a) b) c) All names are case sensitive. All Object names are all upper case. Attribute names are mixed case.
The name of an attribute of an object is of the form OBJECTNAME.AttributeName, e.g., APPLICATION.ApplicationName. In this standard, a name of the form OBJECTNAME.AttributeName may also be used to refer to the list of all the names in a category, e.g., the list of all names in the format, APPLICATION.ApplicationName. Table 6Types 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
IEEE Std 1244.1-2000
Table 6Types 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 conguration modes that the DRIVE can support Tokens representing capabilities a DRIVE can support in a particular mode Tokens representing installation-specied 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.g., 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
45
IEEE Std 1244.1-2000
Table 6Types 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 unsatised operator interactions Global conguration options for the system Mount handles allocated and in use when a DM crashed
10. Privilege levels, attribute types, and data types

This clause describes the privilege levels and the different attribute types and their relationships. Subclause 10.1 and subclause 10.2 refer to terms that are dened in both clauses, and the results are summarized in 4.3. Subclause 4.4 denes the external representation of the data.
10.1 Application privilege levels

There are two privilege levels for an application: standard and administrative. The rst allows a subset of the operations of the second. All ordinary applications have the standard privilege level. At this privilege level, the application can view objects owned by this application or objects containing objects owned by this application. For example, volumes owned by this application, the libraries that contain those volumes, and the drives in which those volumes are currently mounted. This level of privilege allows only the creation, modication, or deletion of some client attributes of certain objects, as noted in the description of those attributes. An administrative application has the administrative privilege level, which is essentially omnipotent. In general, administrative applications attend to the operation of the MMS as a whole, and may perform operations on behalf of one or more applications. An administrative application can create objects and modify the control attributes of any object. The system itself has the system privilege level. It has the authority to modify, create, and delete system objects and attributes.
10.2 Attribute types

An attribute of an object must be of at least one of the following types: Characteristic Control Status Client In addition, certain attributes may be designated as key attributes.
46
IEEE Std 1244.1-2000
10.2.1 Characteristic attributes Characteristic attributes dene the object, and must be specied when the object is created. These attributes may be changed. If a characteristic attribute depends on another object, as described in 10.2.2 through 10.2.5, then some instance of the other object must exist and have an attribute of the same attribute name and value. For example, a CARTRIDGE has as one of its attributes CartridgeTypeName. This is a characteristic attribute and must be supplied when the CARTRIDGE object is created. Since, however, it depends on the CARTRIDGETYPE object, there must rst be an instance of that object with a matching CartridgeTypeName before the CARTRIDGE may be created. Controls of this type are necessary to maintain database integrity. 10.2.2 Control attributes Control attributes dene the behavior of the object, and perhaps can also relate it to other objects. A control attribute assumes the default value when the object is created. An administrative application may change control attributes by modifying the database or giving a command that causes the database to be modied. 10.2.3 Status attributes Status attributes represent the changing state of the object, and are set by the system as a side effect of some operation, such as mounting a cartridge. Except in the possible case of xing corrupted data, they may not be changed directly by an administrative application. Some objects, called status objects, are created automatically by the system usually for the purpose of monitoring activity. The attributes of these objects are all status attributes. For example, an instance of the MOUNTLOGICAL object is created, together with its attributes, whenever a volume is mounted. It is deleted when that volume is dismounted. Neither the application that caused the mount nor any administrative application has any direct control over this object. There are no commands directly to the database that may be used to create or delete an object of this type. 10.2.4 Client attributes Client attributes are essentially arbitrary attributes. In some instances, they may be created and modied by an application that has the standard privilege level, while in other instances the administrative level is required. Some client attributes are dened in this standard. The notation ".*" indicates that an object will accept additional attributes beyond those that the standard has dened. 10.2.5 Key attributes Key attributes constitute the minimal set of attributes of an object that denes it uniquely and that must be specied when an object is created. Key attributes are always characteristic attributes, but not all characteristic attributes are key attributes.
47
IEEE Std 1244.1-2000
10.3 Summary of privileges and attribute types

Table 7 lists a summary of privileges and attribute types. Table 7Privileges 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 Modication Client attributes Any control attribute Any system attribute or object
10.4 Data types

All attributes are externally represented as UTF-8 strings, which in turn represent UNICODE characters. 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. The external representations are found in the messages of the MMP, LMP, and DMP. Some of the strings are required to have a special format, depending on their semantics. Table 8 describes the different formats for the strings. Table 8Formats for strings
Data type String Description The attribute contains an uninterpreted non-zero length value. There are no restrictions on the contents or internal structure of the value (within the dened character set of the system). The attribute contains a pattern of the form "[+-][0123456789][0123456789]*", without the quotes. This indicates an optional leading sign character and one or more digits. Note that integers are represented as strings, and thus the maximum precision required is not dened. It is expected that counter values will exceed 231 or 232, so implementers must ensure that integer computations permit values larger than 32 bits. The attribute contains either "true" or "false", without the quotes. If the attribute is set to anything other than "true", the new value will actually be interpreted to be "false". This attribute is case sensitive. The attribute may be one of a xed number of values. In the attribute descriptions that follow, the specic values will be specied.
Integer
Boolean
Enumerated
48
IEEE Std 1244.1-2000
Table 8Formats for strings (continued)

Data type Description The attribute contains the date and time at which a particular action occurred. It has the form: YYYY MM DD HH MM SS UUU The time zone is dened to be UTC. For example: "1999 12 31 23 59 59 000". The substrings are separated by single spaces and are dened 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.g., "2001" or "10203" January is "01" rst day is "01" rst hour is "00" rst minute is "00" rst second is "00" rst millisecond is "000"
It is permissible for the millisecond value to always be "000". This format was chosen above others because the text representation directly sorts into increasing time order. In the year 10 000, the year component will become ve digits. Since attributes are variable-length strings, and the timestamp consists of distinct, spaceseparated elds, this should not require changes to existing software. Duration UUID The attribute contains a positive integer and records the time duration in seconds. Specically, this is simply one or more digits. The attribute contains a DCE standard format: UUID. This is an uninterpreted hexadecimal token that is guaranteed to be unique across all space and time. The format is: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX where each "X" is taken from the set "0123456789abcdef". For example: "de42ba54-9741-1020-8d13-0800690245c8".
10.5 Default values

In order for an administrative application to create an object, all of its characteristic attributes must be specied. In this case, the other attributes will be set to the specied defaults unless specied upon creation. There are no default values for attributes in status objects created by the system, since their values are determined upon creation. There are no null values. Unsetting a user-dened attribute causes the attribute to disappear. Unsetting a system-dened attribute returns it to its default value. There is no default value for user-dened attributes. If an attribute does not exist for an object, then it will be represented as the unquoted token NULL when being reported in a text clause on a response command.
11. Object types

The subclauses listed in Table 9 dene the object types and their attributes. For each object type in each cluster, there are entries describing each of its attributes. The Name for each attribute gives the attribute name,
49
IEEE Std 1244.1-2000
relative to the object. A fully qualied name is of the form "OBJECTNAME.AttributeName", where "OBJECTNAME" represents the name of some object, and "AttributeName" represents the name of the attribute. In the following clauses, the object types are described cluster by cluster. Table 9Denitions of object types and their attributes
Type Data type Description Allowed values Default Depends on Depended on by Lists the attribute type, as dened in 10.2. Lists the data type, as dened in 10.4. Provides a brief description. Provides a list of values if it is an enumerated type. Lists the default value, if any. Lists the attributes of any objects that shall exist before this attribute can exist. The inverse of the "Depends On" relationship. Lists any objects where an instance of the object may not exist unless some value of this attribute exists for some instance of the rst object.
12. Application cluster

This cluster denes the application programs that use the MMS, and includes the APPLICATION object and the AI object. The APPLICATION object denes the application, and the AI object differentiates one instance of the same application from another instance.
12.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. The APPLICATION object cannot be deleted until all AI objects having the corresponding ApplicationName have been deleted.
12.2 APPLICATION object

An APPLICATION is a client program that has been authorized to use the system as a client of the MM. This object is created by an administrative application in order to allow access to the system for this client program. This is the primary holder of ownership in the MMS. Applications can store user-dened attributes in this object as a way of obtaining persistent storage of conguration or option data. Since this object and all of its attributes are available to all instances of this application, it can also be used to communicate conguration or status information between the various instances of the application.
50
IEEE Std 1244.1-2000
12.2.1 Attributes of the APPLICATION object 12.2.1.1 ApplicationName Name: ApplicationName Type: Characteristic, Key Data Type: String Description: The name of an application that is allowed to use the system. Allowed Values: Any Default: None Depends On: None Depended On By: AI, CARTRIDGE, CARTRIDGEGROUPAPPLICATION, DRIVEGROUPAPPLICATION, MOUNTLOGICAL, SESSION, TASK, VOLUME 12.2.1.2 SignatureAlgorithm Name: SignatureAlgorithm Type: Characteristic Data Type: String Description: The name of the signature algorithm that this application uses. Allowed Values: Any Default: "undened"not all applications have a signature algorithm. Depends On: None Depended On By: None 12.2.1.3 AllowRemoteMount Name: AllowRemoteMount Type: Characteristic Data Type: Boolean Description: Whether or not to allow this application to mount on a remote host machine. Allowed Values: "true", "false" Default: "false" Depends On: None Depended On By: None 12.2.1.4 BypassVerify Name: BypassVerify Type: Characteristic
51
IEEE Std 1244.1-2000
Data Type: Boolean Description: Whether or not to bypass the verication step. If SignatureAlgorithm is "undened", then this must be set to "true". Allowed Values: "true", "false" Default: "true" Depends On: None Depended On By: None 12.2.1.5 User-dened attributes Name: .* Type: Client Data Type: Any Description: Any arbitrary attribute, dependent on the application. Allowed Values: Any Default: None Depends On: None Depended On By: None
12.3 AI object
An AI is an instance of a client program that has been authorized to use the system. This object is created by an administrative application in order to allow access to the system for this instance of the client program. AIs can store user-dened attributes in this object as a method of obtaining persistent storage of conguration or option data. Since this object and all of its attributes are available to all instances of this application, it can also be used to communicate conguration or status information between the various instances of the application. 12.3.1 Attributes of the AI object 12.3.1.1 AIName Name: AIName Type: Characteristic, Key Data Type: String Description: The name of this particular AI. Allowed Values: Any Default: None Depends On: None Depended On By: MOUNTLOGICAL, SESSION, TASK
52
IEEE Std 1244.1-2000
12.3.1.2 ApplicationName Name: ApplicationName Type: Characteristic, Key Data Type: String Description: The name of the application of which this is an instance. Allowed Values: One existing instance of APPLICATION.ApplicationName Default: None Depends On: APPLICATION.ApplicationName Depended On By: See APPLICATION 12.3.1.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.
NOTEThis attribute reects the simple two-level application/administrative privilege levels that are present in this version of the MMS. It is expected that a richer privilege model will be dened in a future version of the MMS.
Allowed Values: "true" or "false" Default: "false" Depends On: None Depended On By: None 12.3.1.4 DefaultPriority Name: DefaultPriority Type: Characteristic Data Type: Integer Description: Determines the default task priority for a task from this AI. The task priority is used to arbitrate between multiple blocked tasks. (There is no run-level priority.) Lower values indicate higher priority. Allowed Values: 0 through 1000 Default: 500 Depends On: None Depended On By: None 12.3.1.5 User-Dened Attributes Name: .* Type: Client
53
IEEE Std 1244.1-2000
Data Type: Any Description: Any arbitrary attribute, dependent on the application. Allowed Values: Any Default: None Depends On: None Depended On By: None
13. The library cluster

This cluster denes a library in the MMS, and includes the objects listed in Table 10. Table 10Objects 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. Describes the library management program that runs the library. Describes a collection of elements in the library. Describes a particular slot in the library. Describes a group of slots, such as those found in a magazine or a port. Summarizes the storage locations in a bay of a library. Lists the available types of physical slots in the entire MMS, as opposed to merely one library.

The creation and deletion semantics for the library cluster are outlined in 13.1.1 and 13.1.2. 13.1.1 Creation semantics Creation semantics are listed in Table 11. Note that the SLOTTYPE object has information on all of the libraries in the MMS. Table 11Creation semantics
LIBRARY object and at least one instance of the LM object BAY object Must be created rst. Note that these two objects depend on each other. There is further information in 7.3. Depends on the existence of a LIBRARY object with the specied LibraryName, so once the LIBRARY has been created, the BAY objects may be created. Must be created before any SLOT objects are created. May only be created after all the SLOT objects have been created. Created by the system when all of the other objects in this cluster have been created.
SLOTTYPE, LIBRARY and BAY objects (with appropriate names) SLOTGROUP object SLOTCONFIG object
54
IEEE Std 1244.1-2000
13.1.2 Deletion semantics Deletion semantics are listed in Table 12. Table 12Deletion 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. May be deleted only when all of their SLOTs have been deleted. May be deleted only when all of the BAYs have been deleted. Deleted automatically by the system whenever the corresponding BAY has been deleted, or when the BAY has no SLOTs.
13.2 The LIBRARY object

The LIBRARY object is created by an administrative application in order to add a library to the MMS. The LibraryOnline attribute is an administratively controlled enable/disable switch. The LibraryStateHard and LibraryStateSoft elds show the current state of the library. 13.2.1 Attributes of the LIBRARY object 13.2.1.1 LibraryName Name: LibraryName Type: Characteristic, Key Data Type: String Description: The name of the library. Allowed Values: Any Default: None Depends On: None Depended On By: CARTRIDGE, DRIVE, LM, LIBRARYDRIVE, MOUNTPHYSICAL 13.2.1.2 LibraryDisabled Name: LibraryDisabled Type: Control Data Type: Enumerated Description: An administrative control used to enable/suspend/disable use of this library. Allowed Values: "true", "false", "temporary" Default: "false" Depends On: None Depended On By: None
55
IEEE Std 1244.1-2000
13.2.1.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", "false" Default: "false" Depends On: None Depended On By: None 13.2.1.4 LMName Name: LMName Type: Control Data Type: String Description: The instance name of the LMP currently controlling this library. There may be several LMs that can control this library, and before the LibraryOnline may be set to "true", there must have been an LM object created whose name matches this entry. Allowed Values: One of the entries in LM.LMName Default: None Depends On: LM.LMName Depended On By: None 13.2.1.5 LibraryStateHard Name: LibraryStateHard Type: Status Data Type: Enumerated Description: This attribute is for future growth. It is intended to reect the status of the library device and is intended to be controlled by the LM. Allowed Values: "unknown" Default: "unknown" Depends On: None Depended On By: None 13.2.1.6 LibraryStateSoft Name: LibraryStateSoft Type: Status Data Type: Enumerated
56
IEEE Std 1244.1-2000
Description: This attribute is currently in place for future use, 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. It might be used for a diagnostic application or an LM-specic 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". In future one might use "inuse". Allowed Values: "ready" Default: "inuse" Depends On: None Depended On By: None 13.2.1.7 System-dened attributes Name: .* Type: Client (where in this case the client is an LM) Data Type: Any Description: An LM can add additional attributes to this record. Examples include comments, notes, and site-specic controls. See the private command in the LMP documentation. Allowed Values: Any Default: None Depends On: None Depended On By: None
13.3 The LM object

At least one LM object is created by an administrative application when a LIBRARY is added to the MMS. The logical sequence is as follows: a) b) c) First create a LIBRARY object with an empty string value for LMName, and with LibraryOnline set to "false". Then create an LM object, thus dening one LMName. Then LIBRARY.LMName may be given a non-empty value. Finally set LIBRARY.LibraryOnline to "true".
Additional LM objects may be created, providing that there are different LMs, and the LIBRARY object modied to reect the active LM. Only one LM may be active for a given LIBRARY at one time. 13.3.1 Attributes of the LM object 13.3.1.1 LibraryName Name: LibraryName Type: Characteristic, Key Data Type: String
57
IEEE Std 1244.1-2000
Allowed Values: One of the entries in LIBRARY.LibraryName Default: None Depends On: LIBRARY.LibraryName Depended On By: None 13.3.1.2 LMName Name: LMName Type: Characteristic, Key Data Type: String Description: The name of an LM for the Library specied in LM.LibraryName. Allowed Values: Any Default: None Depends On: None Depended On By: BAY, LIBRARY, SLOT, SLOTCONFIG 13.3.1.3 LMMessageLevel Name: LMMessageLevel Type: Control Data Type: Enumerated Description: The message level for logging. In the enumeration below, the number and level of detail of the messages increases from left to right. Allowed Values: "emergency", "alert", "critical", "error", "warning", "notice", "information", "debug", "developer" Default: "error" Depends On: None Depended On By: None 13.3.1.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. Allowed Values: One of the valid CONNECTION.ConnectionClientHost Default: Nonethis is set on creation Depends On: CONNECTION.ConnectionClientHost Depended On By: None
58
IEEE Std 1244.1-2000
13.3.1.5 LMStateHard Name: LMStateHard Type: Status Data Type: Enumerated Description: This eld is controlled by the LM, and is intended to reect the operational status of the LM module only as opposed to the library. This value is always "ready", except when the LM pushes up a "ready broken" command, in which case, the value for this attribute is "broken". Allowed Values: "ready", "broken" Default: "ready" Depends On: None Depended On By: None 13.3.1.6 LMStateSoft Name: LMStateSoft Type: Status Data Type: Enumerated Description: This attribute is primarily controlled by the MM, but also reects state information sent up to the MM by the LM through the ready command. 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. This occurs when the MM boots up and when the LM closes connection to the MM. "present"Indicates that the LM has a connection to the MM. The MM does not yet know if the LM is able to talk to the device. This LM is not yet a candidate for active processing, however. This occurs when the LM has just opened a connection but is yet to push up a new ready state. "not ready"Indicates that the LM has a connection to the MM. The LM is activated for the device. The MM may choose such an LM to disable activation prior to activating another LM for the same device. This occurs when the MM fails to process an LM cong correctly, implying that the LM is not ready to process normal LMP commands. "disconnected"Indicates that the LM is not connected to its device. Note that this is a normal state when the LM is booting up. The MM may choose to activate such an LM that is in this state, provided that there is no other LM that has already been chosen for activation of this device. This occurs when the LM informs the MM through the "ready" command that it is no longer connected to its device. Note that this happens during a normal booting sequence. "ready"Indicates that the LM is ready to process normal LMP commands. This occurs ONLY when the LM informs the MM that it is ready. By denition this will only occur after the LM has been activated by the MM and the LM has completed initialization procedures correctly.
c)
d)
e)
Note that when the LM sends MM a "ready broken" command, this indicates that the device may be inoperable; however the MM notes the fact that this LM is still the controlling LM for the device. (See LM.LMStateHard.) Default: "absent"
59
IEEE Std 1244.1-2000
Depends On: None Depended On By: None 13.3.1.7 System-dened attributes Name: .* 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. Examples include comments, notes, and site-specic controls. See the private command in the LMP documentation. Allowed Values: Any Default: None Depends On: None Depended On By: None
13.4 BAY object

A bay is a piece of a library that exhibits some locality. DRIVEs and SLOTs are both "contained" in BAYs. If the LM has marked a bay as inaccessible, then all the drives and slots in that bay are also inaccessible. The MM may give preference to drive/cartridge combinations where they are both in the same bay versus where they are not. All BAY structures are created and deleted by the LM, and change whenever the LM updates its conguration. See the cong command in the LMP documentation. 13.4.1 Attributes of the BAY object 13.4.1.1 BayName Name: BayName Type: Characteristic, Key Data Type: String Description: The name of the BAY. Allowed Values: Any Default: None Depends On: None Depended On By: SLOT, SLOTCONFIG, SLOTGROUP 13.4.1.2 LibraryName Name: LibraryName Type: Characteristic, Key Data Type: String
60
IEEE Std 1244.1-2000
Description: The name of the LIBRARY in which this BAY resides. Allowed Values: One of the entries in LIBRARY.LibraryName Default: None Depends On: LIBRARY.LibraryName Depended On By: None 13.4.1.3 LMName Name: LMName Type: Characteristic, Key Data Type: String Description: The name of the LM in which this BAY resides. Allowed Values: One of the entries in LM.LMName Default: None Depends On: LM.LMName Depended On By: None 13.4.1.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: "true", "false" Default: "false" Depends On: None Depended On By: None
13.5 The SLOT object

A slot is one storage location inside a library. A slot can be any combination of SlotOccupied and/or SlotAccessible. For example, a slot would not be accessible if it was not congured into the library (and hence cannot be occupied), 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. A PCL shall be unique for all cartridges having the same SlotTypeName. All SLOT structures are created and deleted on behalf of the LM, and change whenever the LM updates its conguration. A SlotName is unique within a LIBRARY. The SlotName is unique within the LIBRARY for a given LM. 13.5.1 Attributes of the SLOT object 13.5.1.1 SlotName Name: SlotName
61
IEEE Std 1244.1-2000
Type: Characteristic, Key Data Type: String Description: The name of the SLOT. Allowed Values: Any Default: None Depends On: None Depended On By: MOUNTPHYSICAL 13.5.1.2 LibraryName Name: LibraryName Type: Characteristic, Key Data Type: String Description: The name of the LIBRARY in which this slot resides. Allowed Values: One of the values for LIBRARY.LibraryName Default: None Depends On: LIBRARY.LibraryName Depended On By: None 13.5.1.3 LMName Name: LMName Type: Characteristic, Key Data Type: String Description: The name of the LM in which this SLOT resides. Allowed Values: One of the entries in LM.LMName Default: None Depends On: LM.LMName Depended On By: None 13.5.1.4 BayName Name: BayName Type: Characteristic Data Type: String Description: The name of the BAY in which this slot resides. Allowed Values: One of the values for BAY.BayName Default: None Depends On: BAY.BayName
62
IEEE Std 1244.1-2000
Depended On By: None 13.5.1.5 SlotGroupName Name: SlotGroupName Type: Characteristic Data Type: String Description: The name of the slot group with which this slot is associated. Allowed Values: One of the values for SLOTGROUP.SlotGroupName Default: None Depends On: SLOTGROUP.SlotGroupName Depended On By: None 13.5.1.6 SlotTypeName Name: SlotTypeName Type: Characteristic Data Type: String Description: The name of the slot type. Allowed Values: One of the values for SLOTTYPE.SlotTypeName Default: None Depends On: SLOTTYPE.SlotTypeName Depended On By: None 13.5.1.7 CartridgeID Name: CartridgeID Type: Status Data Type: UUID Description: The name of the cartridge in this slot, if any; otherwise, it is set to "empty". Allowed Values: One of the values for CARTRIDGE.CartridgeID Default: "empty" Depends On: CARTRIDGE.CartridgeID Depended On By: None 13.5.1.8 CartridgePCL Name: CartridgePCL Type: Status Data Type: String
63
IEEE Std 1244.1-2000
Description: The PCL of the cartridge that is in the slot, if any; otherwise, it is "empty". Allowed Values: One of the values for CARTRIDGE.CartridgePCL. Default: "empty" Depends On: CARTRIDGE.CartridgePCL Depended On By: None 13.5.1.9 SlotAccessible Name: SlotAccessible Type: Status Data Type: Boolean Description: Determines whether or not the slot is accessible. Allowed Values: "true", "false" Default: "false" Depends On: None Depended On By: None 13.5.1.10 SlotOccupied Name: SlotOccupied Type: Status Data Type: Boolean Description: Determines whether or not the slot is occupied. Allowed Values: "true", "false" Default: "false" Depends On: None Depended On By: None
13.6 SLOTGROUP object

This object differentiates special slots, such as those found in magazines or ports, from the rest of the slots. The SLOTGROUP object partitions the set of all slots in a library into disjoint subsets. A SLOTGROUP may be in only one BAY. The SLOTGROUP names must be unique within the LIBRARY in which it is found. 13.6.1 Attributes of the SLOTGROUP object 13.6.1.1 SlotGroupName Name: SlotGroupName Type: Characteristic, Key Data Type: String
64
IEEE Std 1244.1-2000
Description: The name of this slotgroup. Allowed Values: Any Default: None Depends On: None Depended On By: None 13.6.1.2 Direction Name: Direction Type: Characteristic Data Type: Enumerated Description: Ports have a direction associated with them. Other types of SLOTGROUPs do not. Non-port SLOTGROUPs have a direction of "none". Allowed Values: "in", "out", "both", "none" Default: "none" Depends On: None Depended On By: None 13.6.1.3 Type Name: Type Type: Characteristic Data Type: Enumerated Description: The type of SLOTGROUP: port, magazine, or ordinary. Allowed Values: "port", "magazine", "ordinary" Default: "ordinary" Depends On: None Depended On By: None 13.6.1.4 LibraryName Name: Library Name Type: Characteristic, Key Data Type: String Description: The name of the LIBRARY in which this SLOTGROUP is found. Allowed Values: One of the values for LIBRARY.LibraryName Default: None Depends On: LIBRARY.LibraryName Depended On By: None
65
IEEE Std 1244.1-2000
13.6.1.5 LMName Name: LM Name Type: Characteristic, Key Data Type: String Description: The name of the LM in which this SLOTGROUP is found. Allowed Values: One of the values for LM.LMName Default: None Depends On: LM.LMName Depended On By: None
13.7 SLOTCONFIG object

The slot conguration object gives an overview of the storage locations in a BAY of a LIBRARY. It gives a summary of the number of free and used slots of each type in each bay of the library. This is a status object; it is automatically created by the system for each LMName, BayName, and SlotTypeName combination. 13.7.1 Attributes of the SLOTCONFIG object 13.7.1.1 LibraryName Name: LibraryName Type: Characteristic, Key Data Type: String Description: The name of the library for this slot conguration. Allowed Values: Any Default: None Depends On: Must be one of the values of LIBRARY.LibraryName. Depended On By: None 13.7.1.2 LMName Name: LMName Type: Characteristic, Status, 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 LIBRARY.LMName Default: None Depends On: LIBRARY.LMName Depended On By: None
66
IEEE Std 1244.1-2000
13.7.1.3 BayName Name: BayName Type: Characteristic, Status, Key Data Type: String Description: The name of the bay containing the slots to which this record refers. Allowed Values: One of the values for BAY.BayName Default: None Depends On: BAY.BayName Depended On By: None 13.7.1.4 SlotTypeName Name: SlotTypeName Type: Characteristic, Status, Key Data Type: String Description: The name of the type of slots that to which this record refers to. Allowed Values: One of the values for SLOTTYPE.SlotTypeName Default: None Depends On: SLOTTYPE.SlotTypeName Depended On By: None 13.7.1.5 SlotCongNumberFree Name: SlotCongNumberFree Type: Status Data Type: Integer Description: The number of free slots of the given type in the given bay. Allowed Values: Any Default: None Depends On: None Depended On By: None 13.7.1.6 SlotCongNumberTotal Name: SlotCongNumberTotal Type: Status Data Type: Integer Description: The total number of slots of the given type in the given bay. Allowed Values: Any
67
IEEE Std 1244.1-2000
Default: None Depends On: None Depended On By: None
13.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. An object of this type with the appropriate name must be created before a cartridge, slot, or slot conguration object may be created. This object provides a list of approved names for the purpose of consistency across implementations. 13.8.1 Attributes of the SLOTTYPE object 13.8.1.1 SlotTypeName Name: SlotTypeName Type: Characteristic, Key Data Type: String Description: The type of slot as reported by the LM. Slots reported by LMs whose SlotTypeName is not given in a SLOTTYPE record will be ignored. Allowed Values: Any Default: None Depends On: None Depended On By: SLOT, SLOTCONFIG 13.8.1.2 CartridgeShapeName Name: CartridgeShapeName Type: Characteristic, Key Data Type: String Description: The external shape of the cartridge.This allows mapping of a type of slot to the shapes of cartridges that the slot can contain. Allowed Values: Any Default: None Depends On: None Depended On By: CARTRIDGE 13.8.1.3 System-dened attributes Name: .* Type: Client (where, in this case, the client is the system) Data Type: Any
68
IEEE Std 1244.1-2000
Description: Additional attributes can be added by the system to this record. Examples include comments, notes and site-specic controls. Allowed Values: Any Default: None Depends On: None Depended On By: CARTRIDGE, SLOT, SLOTCONFIG
14. Drive cluster

The Drive cluster denes a drive in the MMS. The rst set of objects, listed in Table 13, denes 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 13Objects that dene 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, dene the capabilities of a drive and control its use in a specic situation. Table 14Objects that dene 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. Species 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. Species a capability token provided by the site administrator that denes the denition of the default token in a DMCAPABILITYGROUP.
DMBITFORMATTOKEN object DMCAPABILITY object DMCAPABILITYTOKEN object DMCAPABILITYGROUP object DMCAPABILITYGROUPTOKEN object DMCAPABILITYGROUPDEFAULTTOKEN object
69
IEEE Std 1244.1-2000

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 15Creation 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. NOTEThe 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. NOTEDMBITFORMATTOKEN 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. NOTEDMCAPABILITYGROUPTOKEN 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
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
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 denition 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 elds 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 modied by an administrative application. Lower values have higher priority in drive selection.
71
IEEE Std 1244.1-2000
Allowed Values: 01000. Default: 1000 Depends On: None Depended On By: None 14.2.1.4 DMName Name: DMName Type: Control Data Type: String Description: The name of the DM currently controlling this drive. Allowed Values: One of the values for DM.DMName, or "false" if no DM has been created for this drive. Default: "false" Depends On: DM.DMName Depended On By: None 14.2.1.5 DriveDisabled Name: DriveDisabled Type: Control Data Type: Enumerated Description: An administrative control used to enable/suspend/disable use of this drive. Allowed Values: "true", "false", "temporary" Default: "false" Depends On: None Depended On By: None 14.2.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", "false" Default: "false" Depends On: None Depended On By: None
72
IEEE Std 1244.1-2000
14.2.1.7 DriveStateSoft Name: DriveStateSoft Type: Status Data Type: Enumerated Description: This attribute is controlled entirely by the MM, and indicates whether the drive is currently in use by an application, or if it is available for mounting. Allowed Values: "in use", "ready" Default: "ready" Depends On: None Depended On By: None 14.2.1.8 DriveStateHard Name: DriveStateHard Type: Status Data Type: Enumerated Description: This attribute reects the current operational status of the drive.
NOTEThe DriveStateHard attribute reects the status of the device, whereas the DMStateHard attribute represents the status of the DM.
Allowed Values: "loaded", "loading", "unloading", "unloaded" Default: "unloaded" Depends On: None Depended On By: None 14.2.1.9 DriveTimeCreated Name: DriveTimeCreated Type: Status Data Type: Timestamp Description: The date/time when this drive structure was created. Allowed Values: Any Default: Nonethis must be set on creation Depends On: None Depended On By: None 14.2.1.10 DriveTimeMountedLast Name: DriveTimeMountedLast Type: Status
73
IEEE Std 1244.1-2000
Data Type: Timestamp Description: The date/time when a cartridge was last mounted in this drive. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 14.2.1.11 DriveTimeMountedTotal Name: DriveTimeMountedTotal Type: Status Data Type: Timestamp Description: The date/time when a cartridge was last mounted in this drive. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 14.2.1.12 DriveNumberMounts Name: DriveNumberMounts Type: Status Data Type: Integer Description: The number of times this drive has been mounted. Allowed Values: Any Default: 0 Depends On: None Depended On By: None 14.2.1.13 DriveNumberMountsSinceCleaning Name: DriveNumberMountsSinceCleaning Type: Status Data Type: Integer Description: The number of mounts since the drive was cleaned. Allowed Values: Any Default: 0 Depends On: None Depended On By: None
74
IEEE Std 1244.1-2000
14.2.1.14 LibraryName Name: LibraryName Type: Characteristic Data Type: String Description: The name of the library in which this drive is contained. Allowed Values: One of the values for LIBRARY.LibraryName Default: None Depends On: LIBRARY.LibraryName Depended On By: None 14.2.1.15 BayName Name: BayName Type: Characteristic Data Type: String Description: The name of the bay inside the library in which this drive is contained. Allowed Values: One of values for BAY.BayName Default: None Depends On: BAY.BayName Depended On By: None 14.2.1.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", "false" Default: "false" Depends On: None Depended On By: None 14.2.1.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", "false"
75
IEEE Std 1244.1-2000
Default: "false" Depends On: None Depended On By: None 14.2.1.18 CartridgePCL Name: CartridgePCL Type: Status Data Type: String Description: The PCL of the cartridge that is currently mounted in the drive. Allowed Values: One of the values for SLOT.CartridgePCL, or "no cartridge mounted". Default: "no cartridge mounted" Depends On: SLOT.CartridgePCL Depended On By: None 14.2.1.19 DriveNeedsCleaning Name: DriveNeedsCleaning Type: Status Data Type: Enumerated Description: Species whether or not the drive needs cleaning, and how urgently. Allowed Values: a) "true"Drive needs cleaning. b) "false"Drive does not need cleaning. c) "advisory"Drive needs cleaning, but may still allow mounting of cartridges. d) "mandatory"Drive will not accept mounts until it is cleaned. Default: "false" Depends On: None Depended On By: None 14.2.1.20 MaxMounts Name: MaxMounts Type: Status Data Type: Integer Description: The maximum number of mounts that may occur before the drive should be cleaned. When the specied number of mounts has occurred, this will cause the attribute DriveNeedsCleaning to be changed from "false" to one of the other values, depending on the drive technology. Allowed Values: Any Default: 0, which indicates that the DriveNeedsCleaning will be set by another process Depends On: None Depended On By: None
76
IEEE Std 1244.1-2000
14.2.1.21 System-dened attributes Name: .* 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. Examples include comments, notes, and site-specic controls. See the private command in the DMP description. Allowed Values: Any Default: None Depends On: None Depended On By: None
14.3 DRIVEGROUP object

The DRIVEGROUP object is a named group to which a drive can belong. DRIVEGROUPs are used to aggregate drives, and then to support both an access permissions model and a preferential usage policy. Each drive must belong to one drivegroup or another. DRIVEGROUPAPPLICATION objects are used to allow applications to access particular DRIVEGROUPS. 14.3.1 Attributes of the DRIVEGROUP object 14.3.1.1 DriveGroupName Name: DriveGroupName Type: Characteristic, Key Data Type: String Description: The name of this group of drives. Allowed Values: Any Default: Characteristic Depends On: None Depended On By: DRIVE, DRIVEGROUPAPPLICATION 14.3.1.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. If the drive or the cartridge is needed sooner, unmount immediately. This eld is only used if the DRIVEGROUPAPPLICATION record contains a negative duration value. Allowed Values: Any Default: 60
77
IEEE Std 1244.1-2000
Depends On: None Depended On By: None 14.3.1.3 System-dened attributes Name: .* Type: Client Data Type: Any Description: Additional attributes can be added by the system to this record. Examples include comments, notes, and site-specic controls. Allowed Values: Any Default: None Depends On: None Depended On By: None
14.4 DRIVEGROUPAPPLICATION object

This object provides a linkage allowing an application access to the drives in a DRIVEGROUP. The groups are ordered by the DriveGroupApplicationPriority eld, with the lowest value given preference. This allows an administrator to set a preference sequence for drives for a particular application. The DRIVEGROUP object partitions the DRIVES into disjoint subsets. The DRIVEGROUPAPPLICATION object is used to allow applications to access particular DRIVEGROUPs without interfering with each other. 14.4.1 Attributes of the DRIVEGROUPAPPLICATION 14.4.1.1 DriveGroupName Name: DriveGroupName Type: Characteristic, Key Data Type: String Description: The name of a drive. Allowed Values: One of the values for DRIVEGROUP.DriveGroupName Default: None Depends On: DRIVE.DriveGroupName Depended On By: None 14.4.1.2 ApplicationName Name: ApplicationName Type: Characteristic, Key Data Type: String
78
IEEE Std 1244.1-2000
Description: The name of an APPLICATION. Allowed Values: One of the values for APPLICATION.ApplicationName Default: None Depends On: APPLICATION.ApplicationName Depended On By: None 14.4.1.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. Allowed Values: Any Default: 1000 Depends On: None Depended On By: None 14.4.1.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, do not wait the full time. If this duration is negative, then use the DriveGroupUnloadTime attribute of the DRIVEGROUP for this drive instead. Allowed Values: Any Default: 60 Depends On: None Depended On By: None
14.5 DM object
This object represents the DM. It is created by an administrative application in order to add a new DMP to the MMS for a given drive. 14.5.1 Attributes of the DM object 14.5.1.1 DMName Name: DMName Type: Characteristic Data Type: String
79
IEEE Std 1244.1-2000
Description: The name of the drive manager for this drive. Allowed Values: Any Default: None Depends On: None Depended On By: DMBITFORMAT, DMCAPABILITY, DMCAPABILITYDEFAULTTOKEN, DMCAPABILITYGROUP, DRIVE, MOUNTLOGICAL 14.5.1.2 DriveName Name: DriveName Type: Characteristic Data Type: String Description: The name of the DRIVE that this DM is capable of controlling. Allowed Values: One of the values for DRIVE.DriveName Default: None Depends On: DRIVE.DriveName Depended On By: None 14.5.1.3 DMHost Name: DMHost Type: Status Data Type: String Description: The name of the host on which the DM is running. Allowed Values: One of the values for CONNECTION.ConnectionClientHost, or "false" Default: "false" Depends On: CONNECTION.ConnectionClientHost Depended On By: None 14.5.1.4 DMMessageLevel Name: DMMessageLevel Type: Control Data Type: Enumerated Description: The level of message logging desired from this DM. In the enumeration below, the number and level of detail of the messages increases from left to right. Allowed Values: "emergency", "alert", "critical", "error", "warning", "notice", "information", "debug", "developer" Default: "error" Depends On: None
80
IEEE Std 1244.1-2000
Depended On By: None 14.5.1.5 DMStateHard Name: DMStateHard Type: Status Data Type: Enumerated Description: This eld is controlled by the DM and is intended to reect the operational status of the DM module only (as opposed to the device it is controlling). This value is always "ready" except when the DM pushes up a "ready broken" command, in which case the value for this attribute is "broken". Allowed Values: "ready", "broken" Default: "ready" Depends On: None Depended On By: None 14.5.1.6 DMStateSoft Name: DMStateSoft Type: Status, Control Data Type: Enumerated Description: This attribute is primarily controlled by the MM, but also reects state information sent up to the MM by the DM through the "ready" command. It indicates whether or not the DM is ready to process DMP commands. Allowed Values: a) b) "absent"Indicates that the DM is not yet connected to the MM. This occurs when the MM boots up and when the DM closes the connection to MM. "present"Indicates that the DM has a connection to the MM. The MM does not yet know if the DM is able to talk to the device. This DM, however, is not yet a candidate for active processing. This occurs when the DM has just opened a connection but is yet to push up a new ready state. "not ready"Indicates that the DM has a connection to the MM. The DM is activated for the device. The MM may choose such a DM to disable activation prior to activating another DM for the same device. This occurs when the MM fails to process a DM cong correctly, implying that the DM is not ready to process normal DMP commands. "disconnected"Indicates that the DM is not connected to its device. Note that this is a normal state when the DM is booting up. The MM may choose to activate such a DM that is in this state, provided that there is no other DM that has already been chosen for activation of this device. This occurs when the DM informs the MM through the "ready" command that it is no longer connected to its device. Note that this happens during a normal booting sequence. "ready"Indicates that the DM is ready to process normal DMP commands. This occurs ONLY when the DM informs the MM that it is ready. By denition this will only occur after the DM has been activated by the MM and the DM has completed initialization procedures correctly. "reserved"In an environment where a drive can be used by multiple hosts, this state is used to temporarily pin the drive to a particular DM. This is a special case of the ready state.
c)
d)
e)
f)
81
IEEE Std 1244.1-2000
Note that when the DM sends MM of a "ready broken" command, this indicates that the device may be inoperable, however, the MM notes the fact that this DM is still the controlling DM for the device. See DM.DMStateHard. Default: "absent" Depends On: None Depended On By: None 14.5.1.7 System-dened attributes Name: .* Type: Client (DM) Data Type: Any Description: Additional attributes can be added by the system to this record. Examples include comments, notes, and site-specic controls. See the private command in the DMP description (IEEE Std 1244.4-2000). Allowed Values: Any Default: None Depends On: None Depended On By: None
14.6 DMBITFORMAT object

This object represents a set of capabilities that are required to get a specic bit encoding on the media when using this DM. Each DM offers a group of bitformats to the MMS. Each bitformat is composed of a set of DMBITFORMATTOKENs. The tokens list those characteristics that must be requested from the DM in order to get the desired bit encoding on the media. All DMBITFORMAT structures are created and deleted on behalf of the DM, changing whenever the DM sends a new DMP CONFIG command up to the MMS. See the DMP language denition (IEEE Std 1244.42000) for more detailed information. 14.6.1 Attributes of the DMBITFORMAT object 14.6.1.1 DriveName Name: DriveName Type: Characteristic, Key Data Type: String Description: The name of the drive for this DMBITFORMAT. Allowed Values: One of the values for DRIVE.DriveName Default: None Depends On: DRIVE.DriveName Depended On By: DMBITFORMATTOKEN.DMName
82
IEEE Std 1244.1-2000
14.6.1.2 DMName Name: DMName Type: Characteristic, Key Data Type: String Description: The name of the DM from which this bitformat was generated. Allowed Values: One of the values for DM.DMName Default: None Depends On: DM.DMName Depended On By: DMBITFORMATTOKEN 14.6.1.3 DMBitformatName Name: DMBitformatName Type: Characteristic Data Type: String Description: The name of this bitformat. Allowed Values: Any Default: None Depends On: None Depended On By: DMBITFORMATTOKEN
14.7 DMBITFORMATTOKEN
This object species a capability token that is included with a DMBITFORMAT. Each DMBITFORMAT lists a set of capability tokens. Each token is simply a text string, but it represents some characteristic of the drive that an application may request be used for any given mount. The tokens are simply agreed upon in advance, by virtue of being part of the MMS documentation set, and are then compared for equality at run time. For example, "compression" and "nocompression" are valid tokens. All DMBITFORMATTOKEN structures are created and deleted on behalf of the DM, changing whenever the DM sends a new DMP CONFIG command up to the MMS. See the DMP language denition (IEEE Std 1244.4-2000) for more detailed information. 14.7.1 Attributes of the DMBITFORMATTOKEN object 14.7.1.1 DriveName Name: DriveName Type: Characteristic, Key Data Type: String Description: The name of the drive for this DMBITFORMATTOKEN. Allowed Values: One of the values for DMBITFORMAT.DriveName
83
IEEE Std 1244.1-2000
Default: None Depends On: DMBITFORMAT.DriveName Depended On By: None 14.7.1.2 DMName Name: DMName Type: Characteristic, Key Data Type: String Description: The name of the DM from which this bitformat was generated. Allowed Values: One of the values for DMBITFORMAT.DMName Default: None Depends On: DMBITFORMAT.DMName Depended On By: None 14.7.1.3 DMBitformatName Name: DMBitformatName Type: Characteristic, Key Data Type: String Description: The name of the bitformat for this object. Allowed Values: One of the values for DMBITFORMAT.DMBitformatName Default: None Depends On: DMBITFORMAT.DMBitformatName Depended On By: None 14.7.1.4 DMCapabilityToken Name: DMCapabilityToken Type: Characteristic, Key Data Type: String Description: A particular capability token associated with a given bitformat. Allowed Values: Any Default: None Depends On: None Depended On By: None
84
IEEE Std 1244.1-2000
14.8 The DMCAPABILITYobject

This object represents a particular mode of operation offered by a DM. Each DM offers a set of capabilities to the MMS. Each DMCAPABILITY is composed of a set of DMCAPABILITYTOKENs. The capability information is used when performing the rendezvous between the application-desired capability tokens and the DM-offered capability tokens. All DMCAPABILITY structures are created and deleted on behalf of the DM, and change whenever the DM sends a new DMP CONFIG command up to the MMS. See the DMP language denition (IEEE Std 1244.4-2000) for more detailed information. 14.8.1 Attributes of the DMCAPABILITY object 14.8.1.1 DriveName Name: DriveName Type: Characteristic, Key Data Type: String Description: The name of the drive for this DMCAPABILITY. Allowed Values: One of the values for DRIVE.DriveName Default: None Depends On: DRIVE.DriveName Depended On By: DMCAPABILITYTOKEN 14.8.1.2 DMName Name: DMName Type: Characteristic, Key Data Type: String Description: The name of the DM to which this capability set applies. Allowed Values: One of the values for DM.DMName Default: None Depends On: DM.DMName Depended On By: DMCAPABILITYTOKEN 14.8.1.3 DMCapabilityName Name: DMCapabilityName Type: Characteristic, Key Data Type: String Description: The name of this capability. Allowed Values: Any Default: None Depends On: None Depended On By: DMCAPABILITYTOKEN
85
IEEE Std 1244.1-2000
14.8.1.4 Client-dened attributes Name: .* Type: Client Data Type: String Description: Additional attributes can be added to this record by the DM. Examples include device performance parameters. Allowed Values: Any Default: None Depends On: None Depended On By: None
14.9 The DMCAPABILITYTOKEN object

This object represents a single capability token offered by a DM as part of a DMCAPABILITY object. Each DM offers a set of capabilities to the MMS. The capability tokens are used when performing the rendezvous between the application-desired capability tokens and the DM-offered capability tokens. All DMCAPABILITYGROUPTOKEN structures are created and deleted on behalf of the DM, and change whenever the DM sends a new DMP cong to the MM. See the DMP language denition (IEEE Std 1244.4-2000) for more detailed information. 14.9.1 Attributes of the DMCAPABILITYTOKEN object 14.9.1.1 DriveName Name: DriveName Type: Characteristic, Key Data Type: String Description: The name of the drive for this DMCAPABILITYTOKEN. Allowed Values: One of the values for DRIVE.DriveName Default: None Depends On: DRIVE.DriveName Depended On By: None 14.9.1.2 DMName Name: DMName Type: Characteristic, Key Data Type: String Description: The name of the DM to which this capability token applies. Allowed Values: One of the values for DM.DMName Default: None
86
IEEE Std 1244.1-2000
Depends On: DM.DMName Depended On By: None 14.9.1.3 DMCapabilityName Name: DMCapabilityName Type: Characteristic, Key Data Type: String Description: The name of this capability. Allowed Values: Any Default: None Depends On: None Depended On By: None 14.9.1.4 DMCapabilityToken Name: DMCapabilityToken Type: Characteristic, Key Data Type: String Description: The token for this capability. Allowed Values: Any Default: None Depends On: None Depended On By: None
14.10 DMCAPABILITYDEFAULTTOKEN
This object species a capability token provided by the site administrator that sets the denition of the default token in a DMCAPABILITYGROUP. Each DMCAPABILITYDEFAULT contains a set of capability tokens. Each token is simply a text string, but it represents some characteristic of the drive that an application may request be used for any given mount. The tokens are simply agreed upon in advance, by virtue of being part of the MMS documentation set, and are then compared for equality at run time. For example, compression and nocompression are valid tokens. All DMCAPABILITYDEFAULTTOKEN structures are created and deleted by the site administrator, not by the DM. 14.10.1 Attributes of the DMCAPABILITYDEFAULTTOKEN object 14.10.1.1 DriveName Name: DriveName Type: Characteristic, Key
87
IEEE Std 1244.1-2000
Data Type: String Description: The name of the drive for this DMCAPABILITYDEFAULTTOKEN. Allowed Values: One of the values for DRIVE.DriveName Default: None Depends On: DRIVE.DriveName Depended On By: None 14.10.1.2 DMName Name: DMName Type: Characteristic, Key Data Type: String Description: The name of the DM that generated this DMCAPABILITYDEFAULTTOKEN. Allowed Values: One of the values for DM.DMName Default: None Depends On: DM.DMName Depended On By: None 14.10.1.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. Allowed Values: Any Default: None Depends On: None Depended On By: None
14.11 DMCAPABILITYGROUP object

This object represents a group of mutually exclusive capabilities offered by a DM. Each DM offers a set of capability groups to the MMS. Each capability group is composed of a mutually exclusive set of DMCAPABILITYGROUPTOKENs. The capability group information is used when performing the rendezvous between the application-desired capability tokens and the DM-offered capability tokens. All DMCAPABILITYGROUP structures are created and deleted on behalf of the DM, and change whenever the DM sends a new DMP CONFIG command up to the MMS. See the DMP language denition (IEEE Std 1244.4-2000) for more detailed information.
88
IEEE Std 1244.1-2000
14.11.1 Attributes of the DMCAPABILITYGROUP object 14.11.1.1 DriveName Name: DriveName Type: Characteristic, Key Data Type: String Description: The name of the drive for this DMCAPABILITYGROUP. Allowed Values: One of the values for DRIVE.DriveName Default: None Depends On: DRIVE.DriveName Depended On By: DMCAPABILITYGROUPTOKEN.DriveName 14.11.1.2 DMName Name: DMName Type: Characteristic, Key Data Type: String Description: The name of the DM to which this capability set applies. Allowed Values: One of the values for DM.DMName Default: None Depends On: DM.DMName Depended On By: DMCAPABILITYGROUPTOKEN.DMName 14.11.1.3 DMCapabilityGroupName Name: DMCapabilityGroupName Type: Characteristic, Key Data Type: String Description: The name of this capability group. Allowed Values: Any Default: None Depends On: None Depended On By: DMCAPABILITYGROUPTOKEN.DMCapabilityGroupName 14.11.1.4 DMCapabilityGroupDefaultName Name: DMCapabilityGroupDefaultName Type: Characteristic Data Type: String
89
IEEE Std 1244.1-2000
Description: The default capability token for this capability group. Allowed Values: Any Default: None Depends On: None Depended On By: None 14.11.1.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"). Allowed Values: "interchange", "access" Default: access Depends On: None Depended On By: None
14.12 DMCAPABILITYGROUPTOKEN
A DMCAPABILITYGROUPTOKEN is a capability token included with a DMCAPABILITYGROUP. Each DMCAPABILITYGROUP contains a set of capability tokens. Each token is simply a text string, but it represents some characteristic of the drive that an application may request be used for any given mount. The tokens are simply agreed upon in advance, by virtue of being part of the MMS documentation set, and are then compared for equality at run time. For example, compression and nocompression are valid tokens. All DMCAPABILITYGROUPTOKEN structures are created and deleted on behalf of the DM, and change whenever the DM sends a new DMP CONFIG command up to the MMS. See the DMP language denition (IEEE Std 1244.4-2000) for more detailed information. 14.12.1 The attributes of the DMCAPABILITYGROUPTOKEN object 14.12.1.1 DriveName Name: DriveName Type: Characteristic, Key Data Type: String Description: The name of the drive for this DMCAPABILITYGROUP. Allowed Values: One of the values for DMCAPABILITYGROUP.DriveName Default: None Depends On: DMCAPABILITYGROUP.DriveName Depended On By: None
90
IEEE Std 1244.1-2000
14.12.1.2 DMName Name: DMName Type: Characteristic, Key Data Type: String Description: The name of the DM to which this capability set applies. Allowed Values: One of the values for DMCAPABILITYGROUP.DMName Default: None Depends On: DMCAPABILITYGROUP.DMName Depended On By: None 14.12.1.3 DMCapabilityGroupName Name: DMCapabilityGroupName Type: Characteristic, Key Data Type: String Description: The name of this capability group. Allowed Values: One of the values for DMCAPABILITYGROUP.DMCapabilityGroupName Default: None Depends On: DMCAPABILITYGROUP.DMCapabilityGroupName Depended On By: None 14.12.1.4 DMCapabilityToken Name: DMCapabilityToken Type: Characteristic, Key Data Type: String Description: A particular capability token associated with a given capability group. Allowed Values: Any Default: None Depends On: None Depended On By: None
15. Cartridge cluster

This cluster denes a cartridge in the MMS, and includes the objects listed in Table 17.

The creation and deletion semantics for a cartridge cluster are outlined in 15.1.1 and 15.1.2.
91
IEEE Std 1244.1-2000
Table 17Objects included in the cartridge cluster

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

The CARTRIDGE object represents one piece of removable media. This could be a tape, a magneto-optical disk, a CDROM or DVDROM, etc. In order to support the wide range of removable media, the MMS has a fairly exible view of the composition of a cartridge. Each CARTRIDGE is composed of one or more SIDEs. Each SIDE is composed of zero or more PARTITIONs. Each PARTITION may contain zero or more VOLUMEs. The system administrator creates the cartridge object in order to add a cartridge to the MMS. A new CartridgeID is automatically assigned when the cartridge is created. A CartridgeTypeName shall be given when a cartridge is created. This information is used to automatically create the correct number of SIDE structures and to name each of them. The CartridgePCL, which shall be set when the cartridge is created, shall be unique for all cartridges with the same SlotTypeName (implied by the CartridgeTypeName). When the rst VOLUME is created on a cartridge, the cartridge becomes owned by the application that owns the volume. Subsequently, only volumes owned by that same application may be created on that cartridge (if more that one volume can t). The ApplicationName attribute records this association. 15.2.1 The attributes of the CARTRIDGE object 15.2.1.1 CartridgeID Name: CartridgeID Type: Characteristic, Key Data Type: UUID Description: Unique identier generated by the system for this cartridge. Allowed Values: Any Default: None Depends On: None Depended On By: MOUNTLOGICAL, MOUNTPHYSICAL, PARTITION, SIDE, SLOT, TASKCARTRIDGE, VOLUME 15.2.1.2 CartridgePCL Name: CartridgePCL Type: Characteristic Data Type: String Description: The PCL, an external marking on the cartridge that may be human- and/or machine-readable. Allowed Values: Any Default: None Depends On: None Depended On By: DRIVE, MOUNTPHYSICAL, SLOT
93
IEEE Std 1244.1-2000
15.2.1.3 CartridgeState Name: CartridgeState Type: Status Data Type: Enumerated Description: The name of the state for this cartridge. Allowed Values: One of the following: "dened", "identied", "allocatable", "allocated", "error", "deallocated", "recycled". See IEEE Std 1244.3-2000 for a denition of these terms. Default: "dened" Depends On: None Depended On By: None 15.2.1.4 CartridgeTypeName Name: CartridgeTypeName Type: Characteristic Data Type: String Description: The type of cartridge. Allowed Values: One of the values for CARTRIDGETYPE.CartridgeTypeName Default: None Depends On: CARTRIDGETYPE.CartridgeTypeName Depended On By: None 15.2.1.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, or "false" Default: "false" Depends On: CARTRIDGEGROUP.CartridgeGroupName Depended On By: None 15.2.1.6 CartridgeTimeCreated Name: CartridgeTimeCreated Type: Status Data Type: Timestamp Description: The date/time when this cartridge record was created.
94
IEEE Std 1244.1-2000
Allowed Values: Any Default: Nonethis value is set when the cartridge is created Depends On: None Depended On By: None 15.2.1.7 CartridgeTimeMountedLast Name: CartridgeTimeMountedLast Type: Status Data Type: Timestamp Description: The date/time when this cartridge was last mounted in a drive. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 15.2.1.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. Allowed Values: Any Default: 0 Depends On: None Depended On By: None 15.2.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. Allowed Values: Any Default: 0 Depends On: None Depended On By: None
95
IEEE Std 1244.1-2000
15.2.1.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. Allowed Values: Any Default: 0 Depends On: None Depended On By: None 15.2.1.11 ApplicationName Name: ApplicationName Type: Status Data Type: String Description: The name of the application that owns the cartridge, if any. Allowed Values: One of the values for APPLICATION.ApplicationName Default: "false" Depends On: APPLICATION.ApplicationName Depended On By: None 15.2.1.12 LibraryName Name: LibraryName Type: Status Data Type: String Description: The name of the library that currently contains this cartridge. Allowed Values: One of the values for LIBRARY.LibraryName Default: Nonethis attribute is set when the cartridge object is created Depends On: LIBRARY.LibraryName Depended On By: None 15.2.1.13 Client-dened attributes Name: .* Type: Client Data Type: String Description: Additional attributes can be added to this record by the application that owns the cartridge. Examples include comments, notes, and site-specic controls.
96
IEEE Std 1244.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. CARTRIDGEGROUPs are used to aggregate cartridges, and then to support both an access permissions model and a preferential usage policy. Each cartridge must belong to only one CARTRIDGEGROUP. CARTRIDGEGROUPAPPLICATIONs records are used to allow applications to access particular CARTRIDGEGROUPs. 15.3.1 The attributes of the CARTRIDGEGROUP object 15.3.1.1 CartridgeGroupName Name: CartridgeGroupName Type: Characteristic, Key Data Type: String Description: The name of the cartridge group. Allowed Values: Any Default: None Depends On: None Depended On By: CARTRIDGE, CARTRIDGEGROUPAPPLICATION 15.3.1.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 species a negative priority. Allowed Values: Any Default: 1000 Depends On: None Depended On By: None
97
IEEE Std 1244.1-2000
15.3.1.3 Client-dened attributes Name: .* Type: Client Data Type: String Description: Additional attributes can be added to this record by the application that owns the cartridge group. Examples include comments, notes, and site-specic controls. Allowed Values: Any Default: None Depends On: None Depended On By: None
15.4 The CARTRIDGEGROUPAPPLICATION object

The CARTRIDGEGROUPAPPLICATION object represents a linkage that allows an application access to a cartridge group. The groups are ordered by the CartridgeGroupApplicationPriority eld, with the lowest value being given preference. This link lets allows an administrator to set a preference sequence for cartridges when allocating volumes for a particular application. A cartridge may belong to only one CARTRIDGEGROUP. CARTRIDGEGROUPAPPLICATIONs records are used to allow applications to access particular CARTRIDGEGROUPs. 15.4.1 The attributes of the CARTRIDGEGROUPAPPLICATION object 15.4.1.1 ApplicationName Name: ApplicationName Type: Characteristic, Key Data Type: String Description: The name of the application getting access to the cartridge group. Allowed Values: One of the values for APPLICATION.ApplicationName Default: None Depends On: APPLICATION.ApplicationName Depended On By: None 15.4.1.2 CartridgeGroupName Name: CartridgeGroupName Type: Characteristic, Key Data Type: String Description: The name of the cartridge group to which the application has been given access. Allowed Values: One of the values for CARTRIDGEGROUP.CartridgeGroupName
98
IEEE Std 1244.1-2000
Default: None Depends On: CARTRIDGEGROUP.CartridgeGroupName Depended On By: None 15.4.1.3 CartridgeGroupApplicationPriority Name: CartridgeGroupApplicationPriority Type: Control Data Type: Integer Description: The priority that the application places on cartridges in the named group. Allowed Values: Any Default: 1000 Depends On: None Depended On By: None
15.5 The CARTRIDGETYPE object

The CARTRIDGETYPE object represents a class of cartridges. Various constant characteristics of each type of cartridge are dened in this one place. This object has a variable number of attributes, since the Side?Name attribute is actually a group of attributes where the ? in the attribute name is replaced by a positive integer number. There is one attribute of this type for each side, 1, 2, ..., n, where n is the number of sides. When a CARTRIDGE is created, the system will automatically create the number of SIDEs that this CARTRIDGETYPE record shows that type of cartridge should have. The name given to each SIDE that is created is the value of one of the corresponding attributes here. For example, the rst side would take its name from the value of the attribute called Side1Name, while the second side would take its name from the value of the attribute called Side2Name. 15.5.1 The attributes of the CARTRIDGETYPE Object 15.5.1.1 CartridgeTypeName Name: CartridgeTypeName Type: Characteristic, Key Data Type: String Description: The name of this type of cartridge. Allowed Values: Any Default: None Depends On: None Depended On By: CARTRIDGE
99
IEEE Std 1244.1-2000
15.5.1.2 CartridgeTypeNumberSides Name: CartridgeTypeNumberSides Type: Characteristic Data Type: Integer Description: The number of sides for this type of cartridge. Allowed Values: Any Default: 1 Depends On: None Depended On By: None 15.5.1.3 CartridgeTypeMediaLength Name: CartridgeTypeMediaLength Type: Characteristic Data Type: Integer Description: The length of the media for this type of cartridge. Allowed Values: Any Default: None Depends On: None Depended On By: None 15.5.1.4 CartridgeTypeMediaType Name: CartridgeTypeMediaType Type: Characteristic Data Type: Enumerated Description: The type of media contained in this type of cartridge. Allowed Values: a) b) c) d) e) "data"A data cartridge. "cleaning"A cartridge used to clean the drive heads. "diagnostic"A cartridge used to run diagnostic programs for the drive. "microcode"A cartridge used to update the drives microcode. "alignment"A cartridge used to test or correct the drives alignment.
Default: None Depends On: None Depended On By: None
100
IEEE Std 1244.1-2000
15.5.1.5 MaxUseCount Name: MaxUseCount Type: Client Data Type: String Description: An advisory eld indicating suggested maximum usage count. Allowed Values: Any non-negative numeric value Default: None Depends On: None Depended On By: None 15.5.1.6 CartridgeShapeName Name: CartridgeShapeName Type: Characteristic Data Type: String Description: The external shape of the cartridge. Allowed Values: One of the values for SLOTTYPE.CartridgeShapeName Default: None Depends On: SLOTTYPE.CartridgeTypeName Depended On By: None 15.5.1.7 Side?Name Name: Side?Name (Side1Name, Side2Name, etc.) Type: Characteristic Data Type: String Description: The name(s) used by each SIDE of the cartridge. This is actually a group of attributes where the ? in the attribute name is replaced by a positive integer. Allowed Values: Any Default: None Depends On: None Depended On By: None 15.5.1.8 System-dened attributes Name: .* Type: Client Data Type: String
101
IEEE Std 1244.1-2000
Description: Additional attributes can be added to this record by the system. Examples include comments, notes, and site-specic controls. Allowed Values: Any Default: None Depends On: None Depended On By: None
15.6 The SIDE object

A SIDE is the portion of a cartridge that may be accessed during a given physical mount. Tape media will very likely only have one side, while magneto-optical disk media will likely have two sides. When a CARTRIDGE is created, the system will automatically create the number of SIDEs that the corresponding CARTRIDGETYPE record shows this type of cartridge should have. The name given to each SIDE that is created is the value of the corresponding CARTRIDGETYPE.Side?Name attribute. 15.6.1 The attributes of the SIDE object 15.6.1.1 CartridgeID Name: CartridgeID Type: Characteristic, Key Data Type: UUID Description: The UUID of the cartridge. Allowed Values: One in the values for CARTRIDGE.CartridgeID Default: None Depends On: CARTRIDGE.CartridgeID Depended On By: None 15.6.1.2 SideName Name: SideName Type: Characteristic, Key Data Type: String Description: The name of this side of the given cartridge. Allowed Values: One of the values for CARTRIDGETYPE.Side?Name Default: None Depends On: CARTRIDGETYPE.Side?Name Depended On By: MOUNTLOGICAL, MOUNTPHYSICAL, PARTITION, VOLUME
102
IEEE Std 1244.1-2000
15.6.1.3 SideNumberMounts Name: SideNumberMounts Type: Status Data Type: Integer Description: The number of times that this side has been mounted. Note that this includes all the times that partitions and volumes on this side have been mounted. Allowed Values: Any Default: 0 Depends On: None Depended On By: None 15.6.1.4 SideTimeCreated Name: SideTimeCreated Type: Status Data Type: Timestamp Description: The date/time when this side was created Allowed Values: Any Default: Nonethis must be set when the side is created Depends On: None Depended On By: None 15.6.1.5 SideTimeMountedLast Name: SideTimeMountedLast Type: Status Data Type: Timestamp Description: The date/time when this side was last mounted. Note that this includes all the times that partitions and volumes on this side have been mounted. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 15.6.1.6 SideTimeMountedTotal Name: SideTimeMountedTotal Type: Status Data Type: Duration
103
IEEE Std 1244.1-2000
Description: The total time this side has been mounted. Allowed Values: The total amount of time that this side has been mounted. Note that this includes all the times that partitions and volumes on this side have been mounted. Default: 0 Depends On: None Depended On By: None 15.6.1.7 Client-dened attributes Name: .* Type: Client Data Type: String Description: Additional attributes can be added to this record by the Application that owns the cartridge. Examples include comments, notes, and site-specic controls. Allowed Values: Any. Default: None Depends On: None Depended On By: None
15.7 The PARTITION object

A partition is one portion of a side of a cartridge. Tape media will very likely only have one partition per side (although some tapes support partitions), while magneto-optical disk media will likely have more than one partition per side. On some systems, random access media such as magneto-optical disks are supported by a disk driver rather than a tape driver. Most disk drivers require that some form of partition information is laid out on the media. Unless the SIDE is pre-partitioned, the PARTITION objects are created on a side by a special-purpose application that mounts a SIDE, uses (possibly) device-specic control commands to lay out the partition information on the media, and then creates the PARTITION records inside the MMS to match those it created on the media. The PartitionBitFormat and PartitionAllocatable attributes are both set/modied by the system during normal operation, and can be set by an administrative application. The PARTITION record for a blank partition is typically created with the PartitionBitformat eld unset. The MMS will set this eld the rst time an application mounts the partition (i.e., mount the volume mapped to the partition) for writing. The PARTITION record of a non-blank partition is typically created with the PartitionBitformat set to the appropriate bitformat. The ALLOCATE PartitionAllocatable eld is set to "false" when a volume is mapped to an unallocated partition (i.e., a volume is created through the MMP allocate command). The value of this eld will remain "false" even after the deallocation of the volume mapped to the partition, until such time the cartridge is recycled. Command will set both elds when it creates a VOLUME record for a partition.
104
IEEE Std 1244.1-2000
A VOLUME record maps onto an entire partition and provides an application dened 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 PARTITIONs are shared between applications. 15.7.1 The attributes of the PARTITION object 15.7.1.1 CartridgeID Name: CartridgeID Type: Characteristic, Key Data Type: UUID Description: The UUID of the cartridge on which this partition is located. Allowed Values: One of the values for CARTRIDGE.CartrdigeID Default: None Depends On: CARTRIDTE.CartridgeID Depended On By: None 15.7.1.2 SideName Name: SideName Type: Characteristic, Key Data Type: String Description: The name of the side on which this partition is located. Allowed Values: One of the values for SIDE.Side?Name Default: None Depends On: SIDE.Side?Name Depended On By: None 15.7.1.3 PartitionName Name: PartitionName Type: Characteristic, Key Data Type: String Description: The name of this partition. Allowed Values: Any Default: None Depends On: None Depended On By: VOLUME
105
IEEE Std 1244.1-2000
15.7.1.4 PartitionSize Name: PartitionSize Type: Characteristic Data Type: Integer Description: The number of megabytes that can be stored on this partition. Allowed Values: Any Default: 0 Depends On: None Depended On By: None 15.7.1.5 PartitionBitFormat Name: PartitionBitFormat Type: Characteristic Data Type: String Description: The name of the recording technique used for writing to this partition. Allowed Values: One of the values for DMBITFORMAT.DMBitformatName Default: None Depends On: DMBITFORMAT.DMBitformatName Depended On By: None 15.7.1.6 PartitionAllocatable Name: PartitionAllocatable Type: Status Data Type: Boolean Description: Determines whether or not this partition can be allocated to a requesting application. Allowed Values: "true", "false" Default: "true" Depends On: None Depended On By: None 15.7.1.7 PartitionSignature Name: PartitionSignature Type: Client Data Type: String Description: The value of the partition signature, if any. 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
IEEE Std 1244.1-2000
is covered by the signature), or it may be managed automatically by the MMS. If it is managed automatically, it is rewritten whenever a partition that was mounted write-enabled is unmounted. Allowed Values: Any Default: "undened" Depends On: None Depended On By: None 15.7.1.8 PartitionSignatureState Name: PartitionSignatureState Type: Characteristic Data Type: Enumerated Description: a) b) c) d) e) f) "unimplemented"PartitionSignature must be "undened". "unknown"PartitionSignature must be "undened". "uninitialized"The partition is blank, in which case PartitionSignature must be "undened". "system"The DM generated the signature. "application"The application provided the signature. "sysactive"The DM generated the signature. The media is currently in use, and in the event of certain abnormal termination conditions such as a power failure, the signature might not match the media. "appactive"The application provided the signature. The media is currently in use, and in the event of certain abnormal termination conditions such as a power failure, the signature might not match the media.
g)
Allowed Values: Any Default: "unimplemented" Depends On: None Depended On By: None 15.7.1.9 PartitionSignatureAlgorithm Name: PartitionSignatureAlgorithm Type: Characteristic Data Type: String Description: The name of the Algorithm used to generate the partition signature. Allowed Values: Any Default: "undened" Depends On: None Depended On By: None
107
IEEE Std 1244.1-2000
15.7.1.10 PartitionMediaSerial Name: PartitionMediaSerial Type: Characteristic Data Type: String Description: The value of the partition media serial. Allowed Values: Any Default: "undened" 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 "undened". 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
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: Nonethis 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: Nonethis is updated whenever the partition is mounted. Depends On: None Depended On By: None 15.7.1.16 Client-dened 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-specic controls.
109
IEEE Std 1244.1-2000
Allowed Values: Any Default: None Depends On: None Depended On By: None
15.8 The VOLUME object

A VOLUME is an application dened 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 modied during this process. A VOLUME record maps onto an entire partition and provides an application-dened 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 applications set of volumes, but may be non-unique globally. Allowed Values: Any Default: None Depends On: None Depended On By: MOUNTLOGICAL, MOUNTPHYSICAL
110
IEEE Std 1244.1-2000
15.8.1.3 CartridgeID Name: CartridgeID Type: Characteristic Data Type: UUID Description: The unique identier for the cartridge on which this volume is located. Allowed Values: One of the values for PARTITION.CartridgeID Default: None Depends On: PARTITION.CartridgeID Depended On By: None 15.8.1.4 SideName Name: SideName Type: Characteristic Data Type: String Description: The name of the side on which this volume is located. Allowed Values: One of the values for PARTITION.SideName Default: None Depends On: PARTITION.SideName Depended On By: None 15.8.1.5 PartitionName Name: PartitionName Type: Characteristic Data Type: String Description: The name of the partition in which this volume is located. Allowed Values: One of the values for PARTITION.PartitionName Default: None Depends On: PARTITION.PartitionName Depended On By: None 15.8.1.6 VolumeNumberMounts Name: VolumeNumberMounts Type: Status Data Type: Integer Description: The total number of times that this volume has been mounted. Allowed Values: Any
111
IEEE Std 1244.1-2000
Default: 0 Depends On: None Depended On By: None 15.8.1.7 VolumeTimeCreated Name: VolumeTimeCreated Type: Status Data Type: Timestamp Description: The date/time when this volume was created. Allowed Values: Any Default: Nonethis attribute is set when the volume is created Depends On: None Depended On By: None 15.8.1.8 VolumeTimeMountedLast Name: VolumeTimeMountedLast Type: Status Data Type: Timestamp Description: The date/time when this volume was last mounted. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 15.8.1.9 VolumeTimeMountedTotal Name: VolumeTimeMountedTotal Type: Status Data Type: Duration Description: The total time that this volume has been mounted. Allowed Values: Any Default: 0 Depends On: None Depended On By: None 15.8.1.10 Client-dened attributes Name: .*
112
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. Examples include comments, notes, and site-specic controls. Allowed Values: Any Default: None Depends On: None Depended On By: None
16. The mount cluster

This cluster describes the currently mounted cartridges and volumes in the MMS, and includes the following objects listed in Table 20. Table 20Objects included in the mount cluster
MOUNTLOGICAL object MOUNTPHYSICAL object STALEHANDLE object DRIVECARTRIDGEACCESS object Species the volumes that are currently mounted. Describes which cartridges are currently mounted and their respective drives. Describes handles that are left over after a crash. Species the error and usage statistics for currently mounted cartridges and their drives.
All of the objects in this cluster are created by the system as the result of activities requested by clients of the system.
16.1 The MOUNTLOGICAL object

This object tracks which VOLUMEs are currently mounted. One instance of this record type is created for each logical handle created to a drive that is created. 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. For example, the application may want to access the volume in both compression and noncompression modes during one mount session. Note that on most systems, if the drive is a tape drive, only one such access mode is allowed to be active at any one time, implying a close and subsequent reopen between access modes. The MOUNTLOGICAL object is a system object that is created automatically whenever a volume is mounted. 16.1.1 The attributes of the MOUNTLOGICALobject 16.1.2 ApplicationName Name: ApplicationName Type: Status, Characteristic, Key
113
IEEE Std 1244.1-2000
Data Type: String Description: The Name of the application that owns the mounted volume. Allowed Values: One of the values for VOLUME.ApplicationName Default: None Depends On: VOLUME.ApplicationName Depended On By: None 16.1.2.1 VolumeName Name: VolumeName Type: Status, Characteristic, Key Data Type: String Description: The name of the volume that is mounted. Allowed Values: One of the values for VOLUME.VolumeName Default: None Depends On: VOLUME.VolumeName Depended On By: None 16.1.2.2 PartitionName Name: PartitionName Type: Status, Characteristic Data Type: String Description: The name of the partition that is mounted. Note that this may be empty if this is a mount of a side. Allowed Values: One of the values for VOLUME.PartitionName Default: None Depends On: VOLUME.PartitionName Depended On By: None 16.1.2.3 SideName Name: SideName Type: Status, Characteristic Data Type: String Description: The name of the side that is mounted. Allowed Values: One of the values for VOLUME.SideName Default: None Depends On: VOLUME.SideName Depended On By: None
114
IEEE Std 1244.1-2000
16.1.2.4 CartridgeID Name: CartridgeID Type: Characteristic, Status Data Type: UUID Description: The UUID of the cartridge that is mounted. Allowed Values: One of the values for VOLUME.CartridgeID Default: None Depends On: VOLUME.CartridgeID Depended On By: None 16.1.2.5 DriveName Name: DriveName Type: Characteristic, Status Data Type: String Description: The name of the drive in which the cartridge is mounted. Allowed Values: One of the values for DM.DriveName Default: None Depends On: DM.DriveName Depended On By: None 16.1.2.6 DMName Name: DMName Type: Characteristic, Status Data Type: String Description: The name of the DM controlling the drive in which the cartridge is mounted. Allowed Values: One of the values for DM.DMName Default: None Depends On: DM.DMName Depended On By: None 16.1.2.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 DMCAPABILITY.DMCapabilityName
115
IEEE Std 1244.1-2000
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: Nonethis 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
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
117
IEEE Std 1244.1-2000
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
IEEE Std 1244.1-2000
Default: Nonethis is set on creation Depends On: None Depended On By: None
16.3 The DRIVECARTRIDGEACCESS object

These objects keep track of which CARTRIDGEs were mounted in which DRIVEs, and the associated 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. 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. These records can also be used as the basis for a charge-back system. They store the time a cartridge was mounted and the amount of data transferred by the application. When each cartridge is unloaded, the DM forwards to the MMS several statistics about the utilization of the drive during that mount. A DRIVECARTRIDGEACCESS record is created to store the who/what/when of the mount, and the usage and error statistics. The system will not automatically delete DRIVECARTRIDGEACCESS records; it is dependent on an external administrative application to make use of the information if it desires. This status object is created by the system. 16.3.1 The Attributes of the DRIVECARTRIDGEACCESS Object 16.3.1.1 DriveName Name: DriveName Type: Characteristic, System, Key Data Type: String Description: The name of the drive in which the cartridge was mounted. Allowed Values: One of the values for DM.DriveName Default: None Depends On: DM.DriveName Depended On By: None 16.3.1.2 DMName Name: DMName Type: Characteristic, System, Key Data Type: String Description: The name of the DM that controlled the drive. Allowed Values: One of the values for DM.DMName Default: None
119
IEEE Std 1244.1-2000
Depends On: DM.DMName Depended On By: None 16.3.1.3 CartridgeID Name: CartridgeID Type: Characteristic, System, Key Data Type: UUID Description: The UUID of the cartridge that was mounted. Allowed Values: One of the values for PARTITION.CartridgeID Default: None Depends On: PARTITION CartridgeID Depended On By: None 16.3.1.4 SideName Name: SideName Type: Characteristic, System, Key Data Type: String Description: The name of the SIDE that was mounted. Allowed Values: One of the values for PARTITION.SideName Default: None Depends On: PARTITION.SideName Depended On By: None 16.3.1.5 PartitionName Name: PartitionName Type: Characteristic, System, Key Data Type: String Description: The name of the partition that was mounted. Allowed Values: One of the values for PARTITION.PartitionName Default: None Depends On: PARTITION.PartitionName Depended On By: None 16.3.1.6 ApplicationName Name: ApplicationName Type: Characteristic, System
120
IEEE Std 1244.1-2000
Data Type: String Description: The name of the application that caused the mount. Allowed Values: One of the values for APPLICATION.ApplicationName Default: None Depends On: APPLICATION.ApplicationName Depended On By: None 16.3.1.7 DriveCartridgeAccessTimeMount Name: DriveCartridgeAccessTimeMount Type: Status, Key Data Type: Timestamp Description: The date/time when the cartridge was mounted into the drive. Allowed Values: Any Default: Nonethis is set on creation Depends On: None Depended On By: None 16.3.1.8 DriveCartridgeAccessTimeUnmount Name: DriveCartridgeAccessTimeUnmount Type: Status Data Type: Timestamp Description: The date/time when the cartridge was unmounted from the drive. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 16.3.1.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. The value may equal 1 if this information is not available from the device and/or host operating system. Note that this and other counter values may exceed 231 or 232, so implementers must ensure that integer representation permits values larger than 32 bits. Allowed Values: Non-negative, or 1 indicating information not available Default: 1
121
IEEE Std 1244.1-2000
Depends On: None Depended On By: None 16.3.1.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. The value may equal 1 if this information is not available from the device and/or host operating system. Allowed Values: Non-negative, or 1 indicating information not available Default: 1 Depends On: None Depended On By: None 16.3.1.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. Individual devices are expected to provide more detailed information via device-dened attributes in the DriveCartridgeAccess object. The value may equal 1 if this information is not available from the device and/or host operating system. Allowed Values: Non-negative, or 1 indicating information not available Default: 1 Depends On: None Depended On By: None 16.3.1.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. Individual devices are expected to provide more detailed information via devicedened attributes in the DriveCartridgeAccess object. The value may equal 1 if this information is not available from the device and/or host operating system. Allowed Values: Non-negative, or 1 indicating information not available Default: 1 Depends On: None Depended On By: None
122
IEEE Std 1244.1-2000
16.3.1.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. Individual devices are expected to provide more detailed information via device-dened attributes in the DriveCartridgeAccess object. The value may equal 1 if this information is not available from the device and/or host operating system. Allowed Values: Non-negative, or 1 indicating information not available Default: 1 Depends On: None Depended On By: None 16.3.1.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. Individual devices are expected to provide more detailed information via devicedened attributes in the DriveCartridgeAccess object. The value may equal 1 if this information is not available from the device and/or host operating system. Allowed Values: Non-negative, or 1 indicating information not available Default: 1 Depends On: None Depended On By: None 16.3.1.15 System-dened attributes Name: System-dened attributes Type: Status Data Type: String Description: Additional attributes may be written by the system, but from the users point of view they are read-only. No user attributes may be added. Examples include total bytes read, total bytes written, and total corrected errors. Allowed Values: Any Default: None Depends On: None Depended On By: None
123
IEEE Std 1244.1-2000
17. The session cluster

This cluster describes the current sessions, and includes the objects listed in Table 21. Table 21Objects included in the session cluster
SESSION object CONNECTION object Species which applications have active session contexts, and which ones are connected. Describes the current active connections.
All of the objects in this cluster are created by the system as the result of activities requested by clients of the system.
17.1 The CONNECTION object

CONNECTION Objects represent the clients that are connected to the MM. This includes both administrative and non-administrative clients, and all instances of DMs and LMs. Every client program and control program that connects to the MMS will have an active CONNECTION record. Each of those connections implies an open socket. When the socket closes, the CONNECTION record will go away. This is a system object, created and deleted by the system. 17.1.1 The attributes of the CONNECTION object 17.1.1.1 Language Name: Language Type: Characteristic, Status, Key Data Type: String Description: The name of the language being used over this socket. Allowed Values: Any one of the dened language names Default: None Depends On: None Depended On By: None 17.1.1.2 Version Name: Version Type: Characteristic, System, Key Data Type: String Description: The version of the language being used over this socket. Allowed Values: Any dened version of the language Default: None Depends On: None Depended On By: None
124
IEEE Std 1244.1-2000
17.1.1.3 ConnectionClientName Name: ConnectionClientName Type: Characteristic, System, Key Data Type: String Description: The application or device name for the client on this socket. Allowed Values: Any name in the values for APPLICATION.ApplicationName, LIBRARY.LibraryName, or DRIVE.DriveName Default: None Depends On: APPLICATION.ApplicationName, LIBRARY.LibraryName, or DRIVE.DriveName Depended On By: None 17.1.1.4 ConnectionClientInstance Name: ConnectionClientInstance Type: Characteristic, Client, Key Data Type: String Description: The AI name or device control program name for the client. Allowed Values: One of the values for AI.AIName, LM.LMName, or DM.DMName Default: None Depends On: AI.AIName, LM.LMName, or DM.DMName Depended On By: None 17.1.1.5 ConnectionClientHost Name: ConnectionClientHost Type: Characteristic, Status, Key Data Type: String Description: The hostname for the client side of this socket. Allowed Values: Any Default: None Depends On: None Depended On By: None 17.1.1.6 ConnectionClientPort Name: ConnectionClientPort Type: Characteristic, System, Key Data Type: Integer Description: The TCP port number used for the client side of this socket.
125
IEEE Std 1244.1-2000
Allowed Values: Any Default: None Depends On: None Depended On By: None 17.1.1.7 ConnectionTimeCreated Name: ConnectionTimeCreated Type: Status Data Type: Timestamp Description: The date/time when this socket was rst opened. Allowed Values: Any Default: None Depends On: Nonethis is set on creation Depended On By: None 17.1.1.8 ConnectionTimeLastActive Name: ConnectionTimeLastActive Type: Status Data Type: Timestamp Description: The date/time when bytes were last passed through this socket. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None
17.2 The SESSION object

The SESSION object represents the clients that have active contexts, whether connected or not. When a CONNECTION is established for a client, a SESSION record is also created. All dynamic resources (e.g., drives) that an application accumulates during a session are associated with the SESSION record. They are tracked separately from resources associated with other SESSIONs. The SESSION record has a lifetime only slightly longer than the CONNECTION record. The SESSION record is deleted after the MM has released all of the dynamic resources that were not freed before the CONNECTION closed. Only AIs have SESSIONs; there is no SESSION object associated with a LIBRARY or a DRIVE. This status object is created and deleted by the system.
126
IEEE Std 1244.1-2000
17.2.1 The attributes of the SESSION object 17.2.1.1 SessionID Name: SessionID Type: Characteristic, Status, Key Data Type: UUID Description: The unique identier for this session. Allowed Values: Any Default: None Depends On: None Depended On By: REQUEST, CONNECTION 17.2.1.2 ApplicationName Name: ApplicationName Type: Characteristic, Status Data Type: String Description: The name of the application that created this session. Allowed Values: One of the values for APPLICATION.ApplicationName Default: None Depends On: APPLICATION.ApplicationName Depended On By: None 17.2.1.3 AIName Name: AIName Type: Characteristic, Status Data Type: String Description: The name of the instance of the application that created this session. Allowed Values: One of the values for AI.AIName Default: None Depends On: None Depended On By: None 17.2.1.4 Language Name: Language Type: Characteristic, Status Data Type: String
127
IEEE Std 1244.1-2000
Description: The name of the language being used. Allowed Values: Any language dened by the standard for an application Default: None Depends On: None Depended On By: None 17.2.1.5 SessionAttached Name: SessionAttached Type: Status Data Type: Boolean Description: Species whether or not the client is currently connected. Allowed Values: "true", "false" Default: "true" Depends On: None Depended On By: None 17.2.1.6 SessionClientHost Name: SessionClientHost Type: Characteristic, Status Data Type: String Description: The network name of the host on which the client was located when it created this session. Allowed Values: One of the values for CONNECTION.ConnectionClientHost Default: None Depends On: CONNECTION.ConnectionClientHost Depended On By: None 17.2.1.7 SessionClientPort Name: SessionClientPort Type: Characteristic, Status Data Type: Integer Description: The IP port number used by the client when it created this session. Allowed Values: One of the values for CONNECTION.ConnectionClientPort Default: None Depends On: CONNECTION.ConnectionClientPort Depended On By: None
128
IEEE Std 1244.1-2000
17.2.1.8 SessionTimeCreated Name: SessionTimeCreated Type: Status Data Type: Timestamp Description: The date/time when this session was created. Allowed Values: Any Default: Nonethis is set on creation Depends On: None Depended On By: None 17.2.1.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: First set to time of creation; then updated whenever there is activity Depends On: None Depended On By: None 17.2.1.10 User-dened attributes Name: .* 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. Examples include comments, notes, and site-specic controls. Allowed Values: Any Default: None Depends On: None Depended On By: None
18. The task cluster

This cluster describes the tasks generated by a command that is currently active, and includes the objects listed in Table 22. All of the objects in this cluster are created by the system as the result of activities requested by clients of the system.
129
IEEE Std 1244.1-2000
Table 22Object included in the task cluster

TASK object TASKCARTRIDGE object TASKDRIVE object TASKLIBRARY object Lists the current tasks. Lists the cartridges that are candidates for current tasks. Lists the drives that are candidates for a current task. Lists the libraries that are currently candidates for a current task.
18.1 The TASK object

A TASK object represents an MM command that is currently active, either running or waiting for resources. 18.1.1 The attributes of the TASK object 18.1.1.1 TaskID Name: TaskID Type: Characteristic, Status, Key Data Type: UUID Description: The unique identier for this task. Allowed Values: Any Default: None Depends On: None Depended On By: None 18.1.1.2 TaskType Name: TaskType Type: Characteristic, Status Data Type: String Description: The command name for the task, e.g., "mount". Allowed Values: Any one of the command names Default: None Depends On: None Depended On By: None 18.1.1.3 TaskArrivalTime Name: TaskArrivalTime Type: Status Data Type: Timestamp Description: The date/time when the task was rst submitted into the system.
130
IEEE Std 1244.1-2000
Allowed Values: Any Default: Nonethis is set on creation Depends On: None Depended On By: None 18.1.1.4 TaskPriority Name: TaskPriority Type: System, Control Data Type: Integer Description: The priority of this task relative to other tasks competing for the same resources. Lower numbers are processed rst. This task is initially always set to a system-wide default, but may be modied by an administrative application to effect a dynamic priority or scheduling environment. Tasks with lower values for this attribute will be serviced before tasks with higher values. Allowed Values: Any positive integer Default: 1000 Depends On: None Depended On By: None 18.1.1.5 ApplicationName Name: ApplicationName Type: Characteristic, System Data Type: String Description: The name of the application that submitted this task. Allowed Values: One in the values for APPLICATION.ApplicationName Default: None Depends On: APPLICATION.ApplicationName Depended On By: None 18.1.1.6 AIName Name: AIName Type: Characteristic, System Data Type: String Description: The name of the AI that submitted this task. AI names are predened by an administrative application, and persist after any particular execution of an AI. Allowed Values: One of the values for AI.AIName Default: None Depends On: AI.AIName Depended On By: None
131
IEEE Std 1244.1-2000
18.1.1.7 TaskStatement Name: TaskStatement Type: Status Data Type: String Description: The text of the command, as sent to the MM. Allowed Values: Any Default: None Depends On: None Depended On By: None 18.1.1.8 TaskState Name: TaskState Type: Status Data Type: Enumerated Description: Current status of the task. Allowed Values: "blocked", if the task is blocked, waiting for some resource; "dispatched", if the task has started execution Default: None Depends On: None Depended On By: None 18.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. Allowed Values: Any, but they should be unique for a given client Default: None Depends On: None Depended On By: None
18.2 The TASKCARTRIDGE object

This object represents a cartridge that is a candidate for a current TASK.
132
IEEE Std 1244.1-2000
18.2.1 The attributes of the TASKCARTRIDGE object 18.2.1.1 TaskID Name: TaskID Type: Characteristic, System, Key Data Type: UUID Description: The unique identier for this task. Allowed Values: One of the values for TASK.TaskID Default: None Depends On: TASK.TaskID Depended On By: None 18.2.1.2 CartridgeID Name: CartridgeID Type: System, Characteristic, Key Data Type: UUID Description: The unique identier of the cartridge that is a candidate for use in the given task. Allowed Values: One of the values for CARTRIDGE.CartridgeID Default: None Depends On: CARTRIDGE.CartridgeID Depended On By: None
18.3 The TASKDRIVE object

This object represents a drive that is a candidate for a current TASK. 18.3.1 The attributes of the TASKDRIVE 18.3.1.1 TaskID Name: TaskID Type: Characteristic, Status, Key Data Type: UUID Description: The unique identier for the task. Allowed Values: One of the values for TASK.TaskID Default: None Depends On: TASK.TaskID Depended On By: None
133
IEEE Std 1244.1-2000
18.3.1.2 DriveName Name: DriveName Type: Characteristic, Status, Key Data Type: Description: The name of the drive that is a candidate for use in the given task. Allowed Values: One of the values for DRIVE.DriveName Default: None Depends On: DRIVE.DriveName Depended On By: None
18.4 The TASKLIBRARY object

This object represents a library that is a candidate for a current TASK. 18.4.1 Attributes of the TASKLIBRARY object 18.4.1.1 TaskID Name: TaskID Type: Characteristic, Status, Key Data Type: UUID Description: The unique identier for the task. Allowed Values: One of the values for TASK.TaskID Default: None Depends On: TASK.TaskID Depended On By: None 18.4.1.2 LibaryName Name: LibaryName Type: Characteristic, Status, 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.LibraryName Default: None Depends On: LIBRARY.LibraryName Depended On By: None
134
IEEE Std 1244.1-2000
19. The system cluster

This cluster describes the general state of the system, and includes the objects listed in Table 23. Table 23Objects included in the system cluster
SYSTEM object MESSAGE object REQUEST object STALEHANDLE Denes the value of the basic system parameters. Contains the message log. Contains the current requests. Records all device handles that have been handed out to applications but have not been able to be cleaned up after a machine failure.
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.
19.1 The MESSAGE Object

The MESSAGE object controls a log of error or informational messages generated by some component of the system. The MMS supports both a log le on disk and a FIFO message queue in the catalog of the last set of messages. Each LM and DM, as well as the MM, can be set to generate different levels of severity of messages that they will generate. All messages that are generated will be appended to the log le on disk. Out of all the messages that are generated, only those messages that are at or above a specied level of severity will be added to the FIFO message queue in the catalog. The LM.LMMessageLevel and DM.DMMessageLevel attributes control the severity level of severity of messages generated by LMs and DMs, respectively. The SYSTEM.'SystemLogLevel' controls the severity of messages generated by pieces of the MMS. The SYSTEM.'SystemMessageAcceptLevel' controls the severity of messages that are accepted into the FIFO message queue in the catalog. The MessageSenderType will distinguish between messages from each of the following sources: an LM, a DM, or the MM. This object is a status object generated by the system. 19.1.1 The attributes of the MESSAGE object 19.1.1.1 MessageID Name: MessageID Type: Characteristic, Status, Key Data Type: UUID Description: The unique identier for this message, generated by the MM. Allowed Values: Any Default: None Depends On: None Depended On By: None
135
IEEE Std 1244.1-2000
19.1.1.2 MessageSenderType Name: MessageSenderType Type: Characteristic, Status Data Type: Enumerated Description: The type of object that generated the message. Allowed Values: "LM", "DM", or "MM", to represent the Library Manager, Drive Manager, or Media Manager respectively. Default: None Depends On: None Depended On By: None 19.1.1.3 MessageSenderName Name: MessageSenderName Type: Characteristic, Status Data Type: String Description: The name of the external client, in relation to which message is being or has been generated. This may be "MM" if the message is not in connection with any external client. Allowed Values: One of the values for LIBRARY.LibraryName or Drive.DriveName; or "MM" for the Media Manager Default: None Depends On: LM.LibraryName, or DM.DriveName Depended On By: None 19.1.1.4 MessageSenderInstance Name: MessageSenderInstance Type: Characteristic, System Data Type: String Description: Instance of the external client in relation to which message is being generated. This may be "MM" if the message is not in connection with any external client. Allowed Values: One of the values for LM.LMName or DM.DMName; or "MM" for the Media Manager Default: None Depends On: LM.LMName, or DM.DMName Depended On By: None 19.1.1.5 MessageLevel Name: MessageLevel Type: Status
136
IEEE Std 1244.1-2000
Data Type: Enumerated Description: The level of severity of this message. In the enumeration below, the number and level of detail of the messages increases from left to right. Allowed Values: "emergency", "alert", "critical", "error", "warning", "notice", "information", "debug", "developer" Default: None Depends On: None Depended On By: None 19.1.1.6 MessageText Name: MessageText Type: Status Data Type: String Description: The text of the message. Allowed Values: Any Default: None Depends On: None Depended On By: None 19.1.1.7 MessageTimeCreated Name: MessageTimeCreated Type: Status Data Type: Timestamp Description: The date/time when the message was generated. Allowed Values: Any Default: Nonethis is set on creation Depends On: None Depended On By: None
19.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. This object represents the current state of an interaction with the operator. An LM or DM can ask for an operator interaction via the "message" command in the LMP or DMP languages. When such a command arrives, a REQUEST record is created. One or more administrative applications will be polling the list of REQUEST records and displaying some subset of them for an operator.
137
IEEE Std 1244.1-2000
19.2.1 The attributes of the REQUEST object 19.2.1.1 RequestID Name: RequestID Type: Status, Characteristic, Key Data Type: UUID Description: The unique identier of a request sent by a DM or LM. The UUID is generated by the MM. Allowed Values: Any Default: None Depends On: None Depended On By: None 19.2.1.2 RequestingTaskID Name: RequestingTaskID Type: Characteristic, Status Data Type: UUID Description: The unique identier for the task identied for this request. Allowed Values: One of the values for TASK.TaskID Default: None Depends On: TASK.TaskID Depended On By: None 19.2.1.3 RequestingClient Name: RequestingClient Type: Characteristic, Status Data Type: String Description: The device name of the client making this request. Allowed Values: The two values for LM.LibraryName or DM.DriveName; or "MM", for the Media Manager Default: None Depends On: LM.LibraryName, DM.DriveName Depended On By: None 19.2.1.4 RequestingInstance Name: RequestingInstance Type: Characteristic, Status
138
IEEE Std 1244.1-2000
Data Type: String Description: The device instance name of the client making this request. Allowed Values: One of the values for LM.LMName, or DM.DMName Default: None Depends On: LM.LMName, and DM.DMName Depended On By: None 19.2.1.5 RequestingClientType Name: RequestingClientType Type: Characteristic, System Data Type: String Description: The type of client making 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.2.1.6 RequestPriority Name: RequestPriority Type: Characteristic Data Type: Number Description: Numeric value giving the priority of the request. Allowed Values: 01000, with lower numbers indicating higher priority Default: None Depends On: None Depended On By: None 19.2.1.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: "pending" "accepted" Default: "pending" Depends On: None Depended On By: None
139
IEEE Std 1244.1-2000
19.2.1.8 RequestText Name: RequestText Type: Status Data Type: String Description: This is actual text of the request for viewing by the operator/administrator. Allowed Values: Any Default: None Depends On: None Depended On By: None 19.2.1.9 AcceptingSessionID Name: AcceptingSessionID Type: Characteristic, System Data Type: UUID Description: This is the session ID of the operator application that has accepted and is processing the request. Obviously, if no operator (i.e., application) has yet accepted the request, or if the accepting session is closed, then this attribute is "undened". Allowed Values: One of the values for SESSION.SessionID Default: "undened" Depends On: SESSION.SessionID Depended On By: None 19.2.1.10 ResponseText Name: ResponseText Type: Characteristic Data Type: String Description: The text of the response to this request. This is generated by the application or operator that elds the request, and sent to the LM or DM by the MM. Allowed Values: Any Default: None Depends On: None Depended On By: None 19.2.1.11 RequestTimeCreated Name: RequestTimeCreated Type: Status Data Type: Timestamp
140
IEEE Std 1244.1-2000
Description: The date/time when the request entered the system. Allowed Values: Any Default: Nonethis is set on creation Depends On: None Depended On By: None 19.2.1.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. Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None 19.2.1.13 RequestTimeResponded Name: RequestTimeResponded Type: Status DataType: Timestamp Description: The date/time at which a response was made to the request. Privilege Levels: System Allowed Values: Any Default: Timestamp of all zeros Depends On: None Depended On By: None
19.3 The SYSTEM object

There is only one record of this type in an MMS. It contains global conguration options and status information. The MMS supports both a log le on disk and a FIFO message queue in the catalog of the last set of messages. Each LM and DM, as well as the MMS, can be set to generate different levels of message severity of messages that they will generate. All messages that are generated will be appended to the log le on disk. Out of all the messages that are generated, only those messages that are at or above a specied level of severity will be added to the FIFO message queue in the catalog. The LM.LMMessageLevel and DM.DMMessageLevel attributes control the severity level of messages generated by LMs and DMs, respectively. The SystemLogLevel controls the severity level of messages
141
IEEE Std 1244.1-2000
generated by pieces of the MMS. The SystemAcceptLevel controls the severity level of messages that are accepted into the FIFO message queue in the catalog. Since there is only one object of this type, there are no key attributes. 19.3.1 The attributes of the SYSTEM object 19.3.1.1 Administrator Name: Administrator Type: Control Data Type: String Description: The name or e-mail address of the person responsible for this MMS installation. This eld is for human use only and is intended to be viewed by an operator/administrator; there are no dependencies on other elds in the catalog, and no use is made of this eld other than to show it to humans. Allowed Values: Any Default: "unknown" Depends On: None Depended On By: None 19.3.1.2 SystemLogLevel Name: SystemLogLevel Type: Control Data Type: Enumerated Description: The severity level of messages to be generated by components of the MMS. All messages of this severity or higher will be appended to the log le. This is different from the SystemAcceptLevel so that detailed logs can be kept on one component without ushing the message FIFO of other content. In the enumeration below, the number and level of detail of the messages increases from left to right. Controls what log messages get added to the log le. Allowed Values: "emergency", "alert", "critical", "error", "warning", "notice", "information", "debug", "developer" Default: None Depends On: None Depended On By: None 19.3.1.3 SystemAcceptLevel Name: SystemAcceptLevel Type: Control Data Type: Enumerated Description: The severity of messages to be stored in the catalog message FIFO. All messages, from any source in the MMS, of this severity or higher will be appended to the message FIFO in the catalog. This is
142
IEEE Std 1244.1-2000
different from the SystemLogLevel so that detailed logs can be kept on one component without ushing the message FIFO of other content. In the enumeration below, the number and level of detail of the messages increases from left to right. Controls what log messages are visible via the MMP language. Allowed Values: "emergency", "alert", "critical", "error", "warning", "notice", "information", "debug", "developer" Default: None Depends On: None Depended On By: None 19.3.1.4 SystemLogFile Name: SystemLogFile Type: Control Data Type: String Description: The pathname of the log le to which all messages should be appended. If this le does not exist, it will be created. Log rotation can be accomplished by simply moving or renaming the existing log le out of the way. The MMS will automatically create the le again and start using the new one. The old log le will then be free for compaction archival or other disposal. Allowed Values: Any Default: None Depends On: None Depended On By: None 19.3.1.5 SystemMessageLimit Name: SystemMessageLimit Type: Control Data Type: Integer Description: The maximum number of messages to be stored in the catalog message FIFO. Note that this does not affect the number of messages stored in the log le. Allowed Values: Any Default: 100 Depends On: None Depended On By: None 19.3.1.6 SystemMessageCount Name: SystemMessageCount Type: Control Data Type: Integer
143
IEEE Std 1244.1-2000
Description: The current number of messages that are stored in the catalog message FIFO. Note that this does not show the number of messages in the log le. Allowed Values: Any Default: None Depends On: None Depended On By: None 19.3.1.7 SystemRequestLimit Name: SystemRequestLimit Type: Control Data Type: Integer Description: The maximum number of requests to be stored in the catalog request FIFO. Note that this does not include the number of requests for which there has not yet been a response; it only limits the number of historical request structures that are kept on hand. Allowed Values: Any Default: 100 Depends On: None Depended On By: None 19.3.1.8 SystemRequestCount Name: SystemRequestCount Type: Control Data Type: Integer Description: The current number of requests that are stored in the catalog request FIFO. Note that this does not include the number of requests for which there has not yet been a response. Allowed Values: Any Default: None Depends On: None Depended On By: None 19.3.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 le and truncating the log le. Allowed Values: Any Default: 1000
144
IEEE Std 1244.1-2000
Depends On: None Depended On By: None 19.3.1.10 SystemDCALimit Name: SystemDCALimit Type: Control Data Type: Integer Description: The maximum number of DRIVECARTRIDGEACCESS (DCA) records to be stored in the DCA FIFO. Note that this limits the number of historical DCA structures that are kept on hand. Allowed Values: Any Default: 100 Depends On: None Depended On By: None 19.3.1.11 SystemDCACount Name: SystemDCACount Type: Status Data Type: Integer Description: The current number of DRIVECARTRIDGEACCESS (DCA) records that are stored in the DCA FIFO. Allowed Values: Any Default: None Depends On: None Depended On By: None 19.3.1.12 System-dened attributes Name: .* Type: Client Data Type: String Description: Additional attributes added by an administrative application. Allowed Values: Any Default: None Depends On: None Depended On By: None
145
IEEE Std 1244.1-2000
19.4 The STALEHANDLE object

This STALEHANDLE object reects the state of MM-allocated mount handles that were in use when a DM crashed. The MM tracks this information so that it can effect recovery and prevent unauthorized access to data. 19.4.1 The attributes of the STALEHANDLE object 19.4.1.1 ApplicationName Name: ApplicationName Type: Status Data Type: String Description: The name of the application that had the volume mounted. Allowed Values: One of the entries in the list APPLICATION.ApplicationName Default: None Depends On: APPLICATION.ApplicationName Depended On By: None 19.4.1.2 VolumeName Name: VolumeName Type: Status Data Type: String Description: The name of the volume mounted. Allowed Values: One of the list VOLUME.VolumeName Default: None Depends On: VOLUME.VolumeName Depended On By: None 19.4.1.3 PartitionName Name: PartitionName Type: Status Data Type: String Description: The partition name. This is required for handling partition mounts. Allowed Values: One of the entries in the list PARTITION.PartitionName Default: None Depends On: PARTITION.PartitionName Depended On By: None
146
IEEE Std 1244.1-2000
19.4.1.4 SideName Name: SideName Type: Status Data Type: String Description: The side name. This is required for handling side mounts. Allowed Values: One of the entries in the list SIDE.SideName Default: None Depends On: SIDE.SideName Depended On By: None 19.4.1.5 CartridgeID Name: CartridgeID Type: Status Data Type: UUID Description: The cartridge that was mounted. Allowed Values: One of the entries in the list CARTRIDGE.CartridgeID Default: None Depends On: CARTRIDGE.CartridgeID Depended On By: None 19.4.1.6 DriveName Name: DriveName Type: Status Data Type: String Description: The name of the drive. Allowed Values: One of the entries in the list DRIVE.DriveName Default: None Depends On: DRIVE.DriveName Depended On By: None 19.4.1.7 DMName Name: DMName Type: Status Data Type: String Description: The name of the controlling DM. Allowed Values: One of the entries in the list DM.DMName
147
IEEE Std 1244.1-2000
Default: None Depends On: DM.DMName Depended On By: None 19.4.1.8 MountLogicalHandle Name: MountLogicalHandle Type: Status Data Type: String Description: The mount access handle, i.e., mount path. Allowed Values: Any Default: None Depends On: None Depended On By: None 19.4.1.9 MountLogicalTimeWhenMounted Name: MountLogicalTimeWhenMounted Type: Status Data Type: Timestamp Description: The time when the mount occurred. Allowed Values: Any Default: Nonethis is set on creation Depends On: None Depended On By: None
20. Tokens9
20.1 Instructions
By following these instructions, registered and unregistered tokens may be used without collision. 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 specic products in this clause are for information only and are not meant to show endorsement by the IEEE.
9Examples
148
IEEE Std 1244.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, that user may employ an unregistered token using a registered vendor or organization name as a mandatory pre-x. Unregistered tokens shall be composed of an underscore character, followed by the text of the vendor or organization name with all trailing blanks removed, followed by another underscore character, followed by the rest of the attribute name. An example of an unregistered token belonging to the ACME Technology Corporation might be "_ACME_OverTemp". A registry of vendor or organizational names is kept under the authority and responsibility of the National Committee for Information Technology Standards (NCITS). These are the vendor or organizational names used by the NCITS T10 technical committee, which develops standards and technical reports on I/O interfaces, particularly the series of Small Computer System Interface (SCSI) standards. The registration authority provided by the NCITS T10 committee shall be used for the purpose of dening vendor or organization names used as pre-xes of unregistered MMS tokens. These vendor or organization names are for the exclusive use of the vendor or organization registering them, and their use is entirely at the discretion of the vendor or organization. New vendor or organization names may be registered according to the NCITS T10 approved standard SPC, ANSI X3.301:1997. Directions for obtaining a copy of this standard may be found at the following URL: http:/ /www.t10.org/pubs.htm. A nal draft of the standard is available for reference only at ftp://ftp.t10.org/t10/drafts /spc/spc-r11a.pdf. To register a vendor or organization name that is not already registered, use the information provided at http://www.t10.org/lists/2vid.htm. The ofcial list of vendor or organization names is available at ftp://ftp.t10.org/t10/drafts/spc2/vid-alph.txt, and is frequently updated by the NCITS T10 committee. All of the information in this clause is described at the IEEE SSSWG Web site (http://www.ssswg.org). The IEEE SSSWG will not judge the merit of tokens submitted for registration, but will advise the submitter of collisions, if any, with existing tokens. Tokens shown in this clause are registered, and all may use them without concern for collision or incompatibility. These are the tokens in existence at the time this standard was published.
20.2 MMP mount modes

When an application requests that a cartridge be mounted, it has the ability to ask that the resulting access to the cartridge have certain characteristics. For example, rewind the media when the device is closed and enable drive-based data compression. The mechanism that the application uses to indicate those desired characteristics to the MMS is the MMP Mount Modes tokens. 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. 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. Only those modes of access to a given drive that provide matching MMP Mount Mode tokens are considered candidates. If a drive has no modes of access with matching MMP Mount Mode tokens, then that drive cannot be used for this MOUNT operation. Tokens identied at this writing for MMP mount modes are shown in Table 24.10
10Tokens
are consistently being updated. Please go to http://www.ssswg.org/ for a complete list of updated tokens. Information on how to register a token can also be found at that website.
149
IEEE Std 1244.1-2000
Table 24Tokens 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 mount point will allow only reading of the media. Rewind the media when the mount point is closed. Do not rewind the media when the mount point is closed. Attempt to compress the data stream. Do not attempt to compress the data stream. 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. Blocks on the media will be a xed size independent of the number of bytes of data transferred by the application. If the drive is connected via a parallel SCSI connection, sequential bytes are put on the bus with the rst byte on the lower 8 bits of the bus. If the drive is connected via a parallel SCSI connection, sequential bytes are put on the bus with the rst byte on the upper 8 bits of the bus.
block littleendian bigendian
Interchange Interchange Interchange
20.3 Slot type names

This is a list of possible values for the database eld "SLOTTYPE.SlotTypeName". They are the names given to types of slots in removable media libraries an MMS. Note that some types of slots in some removable media libraries may take more than one shape of cartridge. For example, some libraries can now manage DLT shaped cartridges or 3480 shaped cartridges in the same slots. 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 value shows the type of that slot, indirectly telling the MMS which types of cartridges can t into that slot. Each SLOTTYPE object contains both a SlotTypeName eld and a CartridgeShapeName eld. The CartridgeShapeName eld in those objects provides a linkage to CARTRIDGETYPE objects that share the same CartridgeShapeName value. When there are multiple instances of SLOTTYPE objects that share a common SlotTypeName, the CartridgeShapeName elds in those objects provide a many-to-many mapping to CARTRIDGETYPE objects. The MMS is free to make use of this mapping information when deciding if a given cartridge will t into a given slot. The DM will send SlotTypeName values to the MM in its DMP CONFIG command for each mode of access that the drive supports. The values show the shape of cartridges that the drive can accept in each mode of operation. Client or administrative applications may also use SlotTypeNames for informational or administrative purposes. Tokens identied at this writing for slot types are shown in Table 25.11
11Tokens
are consistently being updated. Please go to http://www.ssswg.org/ for a complete list of updated tokens.
150
IEEE Std 1244.1-2000
Table 25Tokens for slot types

Token 8mm 3480 DLT DLTor3480 DAT D2-S D2-M D2-L DTF VHS QIC CDROM LP33 e.g., CDROM, DVDROM, DVDRAM 12 inch vinyl audio recording Any generic 8 mm shell e.g., IBM 3480/3490/3495, STK 4480/4490. e.g., Compact III (i.e., DLT2000), Compact IV (i.e., DLT7000) May take 3480 or DLT cartridges e.g., DDS2 "small" DST cartridges (25 GB capacity) "medium" DST cartridges (75 GB capacity) "large" DST cartridges (165 GB capacity) e.g., 20 GB cartridges from Sony e.g., Metrum Description or usage
20.4 Cartridge shape names

This is a list of possible values for the database eld "CARTRIDGETYPE.CartridgeShapeName". They are the names given to the external shapes of cartridges in an MMS. Note that many different CARTRIDGETYPE objects might share the same value for their CartridgeShapeName elds. For example, 3480, 3490, and 3590 cartridges all share the same CartridgeShapeName of "3480". 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 value shows the type of that slot, indirectly telling the MMS which types of cartridges can t into that slot. Each SLOTTYPE object contains both a SlotTypeName eld and a CartridgeShapeName eld. The CartridgeShapeName eld in those objects provides a linkage to CARTRIDGETYPE objects that share the same CartridgeShapeName value. When there are multiple instances of SLOTTYPE objects that share a common SlotTypeName, the CartridgeShapeName elds in those objects provide a many-to-many mapping to CARTRIDGETYPE objects. The MMS is free to make use of this mapping information in deciding if a given cartridge will t into a given slot. Client or administrative applications may also use SlotTypeNames for informational or administrative purposes. Tokens identied at this writing for cartridge shapes are shown in Table 26.12
12Tokens
151
IEEE Std 1244.1-2000
Table 26Tokens for cartridge shapes

Token 8mm 3480 DLT DAT D2-S D2-M D2-L DTF VHS QIC CDROM LP33 e.g., CDROM, DVDROM, DVDRAM 12 inch vinyl audio recording Any generic 8 mm shell e.g., IBM 3480/3490/3495, STK 4480/4490, etc. e.g., Compact III (i.e., DLT2000), Compact IV (i.e., DLT7000) e.g., DDS2 "small" DST cartridges (25 GB capacity) "medium" DST cartridges (75 GB capacity) "large" DST cartridges (165 GB capacity) e.g., 20 GB cartridges from Sony e.g., Metrum Description or Usage
20.5 Bit formats

This is a list of possible values for the database eld "DMBITFORMAT.DMBitFormatName". They are the names given to the different recording formats of data on media managed by an MMS. 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. One of the better-known cases is that of a 3490 cartridge. It is possible to record bits onto a piece of 3490 media in the format that a 3490 drive uses natively, but it is also possible to record bits on that media in the format that a 3480 drive uses natively. Thus, the cartridge can be used in either a 3480 drive or a 3490 drive. 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, while a 3480 drive can only access data written in 3480 format. 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. A DLT7000 drive can read DLT2000 data in compressed or uncompressed format, but cannot write data in DLT2000 compressed format. On drives that attach using a parallel-SCSI interconnect and that negotiate for "wide" (16 bit) access to the bus, the ordering of bytes on the bus will impact the ability to interchange that cartridge with drives attached to other computer systems. 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, the net effect is a swapping of bytes. 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. In order to pick a drive that can successfully read the contents of a cartridge that already has data on it, the MMS needs to know both the exact format the data is recorded in, the "BitFormatName", and the data formats that each potentially useful drive can access. Each mode of access that a drive supports species a BitFormatName that that mode of access supports. The "BitFormatName" is the token that links the data format
152
IEEE Std 1244.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. Tokens identied at this writing for BIT formats are shown in Table 27.13 Table 27Tokens 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, little endian IBM Magstar native, big endian IBM Magstar compressed, little endian IBM Magstar compressed, big endian STK Timberline native STK Redwood native, little endian STK Redwood native, big endian STK Redwood compressed, little endian STK Redwood compressed, 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, so the little-endian versus big-endian issue becomes relevant. The Magstar drive will negotiate for 16-bit "wide" access to a SCSI bus, so the little-endian versus big-endian issue becomes relevant. Description
13Tokens
153
IEEE Std 1244.1-2000
Table 27Tokens for BIT formats (continued)

Token D2le D2be D2lec D2bec ISO9660 Description Ampex DST native, little endian Ampex DST native, big endian Ampex DST compressed, little endian Ampex DST compressed, big endian The Ampex drive will negotiate for 16-bit "wide" access to a SCSI bus, so the little-endian versus big-endian issue becomes relevant.
20.6 Cartridge type names

This is a list of possible values for the database eld "CARTRIDGETYPE.CartridgeTypeName". The CARTRIDGETYPE object records various pieces of information about each type of cartridge known to the MMS. The names of those types of cartridges shall be unique within an MMS installation, and to allow interchange of cartridge information between MMS installations, they should be common to all installations. Tokens identied at this writing for cartridge type names are shown in Table 28.14 Table 28Tokens 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, TK86) DLT4000, DLT7000 Product name or description
14Tokens
154
IEEE Std 1244.1-2000
Table 28Tokens 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.7 Partition names

This is a list of possible values for the database eld "PARTITION.PartitionName". The DM Protocol assumes a standard set of names is used for partitioned media. The ATTACH command that is sent by the MM to the DM includes an indication of which partition the DM should grant access to. Each type of partitioned media may have its own unique designations for each partition, but the MM needs to be able to refer to those partitions in a uniform way independent of the type of 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 dened nomenclature for partitions on its supported media types. Tokens identied at this writing for partition names are shown in Table 29.15 Table 29Tokens for partitions
Token Part1 Description The rst partition on the media. On a linear media such as a tape, Part1 is dened to be the one closest to the physical beginning of the media. On a nonlinear media such as a disk, Part1 is dened to be the lowest numbered or lettered partition, using whatever standard partitioning mechanism exists on that media. The second partition on the media. On a linear media such as a tape, Part2 is dened to be the one immediately following Part1 on the media. On a non-linear media such as a disk, Part2 is dened to be the second lowest numbered or lettered partition, using whatever standard partitioning mechanism exists on that media. Note that Part2 does not refer to the next partition that is in use, it refers to the next partition. For example, a disk drive might dene partitions 1 through 16 but only normally use partitions 1, 6, 8, and 10. Part2 would refer to partition 2, not partition 6. As one might expect, the pattern continues...
Part2
Part3
15Tokens
155
IEEE Std 1244.1-2000
20.8 Attribute names

Attributes can be attached to many of the object types in the MMS Data Model. 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, i.e., so that they can be used and understood by more than the person or group who dened them. For each registered attribute, the Attribute Name registry contains the name of the attribute, its meaning, its allowable values, and the object it can be attached to. Note that two attributes attached to different types of objects can have the same attribute name, they will have separate entries in the Attribute Name registry. Tokens identied at this writing for attribute names are shown in Table 30.16 Table 30Tokens for attributes
Attribute name ReadBandwidth Object name DMCAPABILITY Value 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. The total effective bandwidth that an application should be able to sustain when writing to that drive using the given capability set. The total storage capacity of the cartridge that an application should be able to expect when accessing that drive using the given capability set. The I/O size that would best utilize the drive/cartridge combination when using that drive with the given capability set. The number of seconds between the time a cartridge is rst inserted into a drive and the time that the drive is ready to read/ write data. The approximate time it will take for the library to move a cartridge from its home location to a drive, or back, not including drive load/unload time. This is analogous to the nominal seek time of a disk drive, and is dened 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.
WriteBandwidth
DMCAPABILITY
Numeric, in bytes per second
Capacity
DMCAPABILITY
Numeric, in megabytes
Blocksize
DMCAPABILITY
Numeric, in bytes
LoadTime
DMCAPABILITY
Numeric, in seconds
LoadTime
LIBRARY
Numeric, in seconds
16Tokens
156

MMS Standard

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

MMS Standard

Загружено:

Авторское право:

Доступные форматы

IEEE Std 1244.

IEEE Standard for Media Management System (MMS) Architecture

Storage Systems Standards Committee of the IEEE Computer Society

IEEE-SA Standards Board

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

Copyright 2000 IEEE. All rights reserved.

Copyright 2000 IEEE. All rights reserved.

Also included is the following nonvoting IEEE-SA Standards Board liaison:

Catherine K. N. Berger IEEE Standards Project Editor

Copyright 2000 IEEE. All rights reserved.

Tokens................................................................................................................................................ 39 Data modelintroduction ................................................................................................................. 39

Copyright 2000 IEEE. All rights reserved.

Copyright 2000 IEEE. All rights reserved.

Copyright 2000 IEEE. All rights reserved.

IEEE Standard for Media Management System (MMS) Architecture

Copyright 2000 IEEE. All rights reserved.

IEEE Std 1244.1-2000

IEEE STANDARD FOR MEDIA MANAGEMENT

on references can be found in Clause 3.

Copyright 2000 IEEE. All rights reserved.

SYSTEM (MMS) ARCHITECTURE

IEEE Std 1244.1-2000

Copyright 2000 IEEE. All rights reserved.

IEEE Std 1244.1-2000

IEEE STANDARD FOR MEDIA MANAGEMENT

Copyright 2000 IEEE. All rights reserved.

SYSTEM (MMS) ARCHITECTURE

IEEE Std 1244.1-2000

3. Denitions, abbreviations, and acronyms

Copyright 2000 IEEE. All rights reserved.

IEEE Std 1244.1-2000

IEEE STANDARD FOR MEDIA MANAGEMENT

Copyright 2000 IEEE. All rights reserved.

SYSTEM (MMS) ARCHITECTURE

IEEE Std 1244.1-2000

3.2 Acronyms and abbreviations

Copyright 2000 IEEE. All rights reserved.

IEEE Std 1244.1-2000

IEEE STANDARD FOR MEDIA MANAGEMENT

4.1 Interface protocols

Copyright 2000 IEEE. All rights reserved.

SYSTEM (MMS) ARCHITECTURE

IEEE Std 1244.1-2000

4.2 Programming and command line interfaces

Copyright 2000 IEEE. All rights reserved.

IEEE Std 1244.1-2000

IEEE STANDARD FOR MEDIA MANAGEMENT

An implementation of the MMS does not require any of these interfaces.

4.3 Data transfer protocol and interface

4.4 Operation of the MMS

Copyright 2000 IEEE. All rights reserved.

SYSTEM (MMS) ARCHITECTURE

IEEE Std 1244.1-2000

Copyright 2000 IEEE. All rights reserved.

IEEE Std 1244.1-2000

IEEE STANDARD FOR MEDIA MANAGEMENT

Copyright 2000 IEEE. All rights reserved.

SYSTEM (MMS) ARCHITECTURE

IEEE Std 1244.1-2000

Copyright 2000 IEEE. All rights reserved.

IEEE Std 1244.1-2000

IEEE STANDARD FOR MEDIA MANAGEMENT