[go: up one dir, main page]

WO1996006393A1 - Interface de programme d'application (api) pour dispositif de changement de support - Google Patents

Interface de programme d'application (api) pour dispositif de changement de support Download PDF

Info

Publication number
WO1996006393A1
WO1996006393A1 PCT/US1995/010763 US9510763W WO9606393A1 WO 1996006393 A1 WO1996006393 A1 WO 1996006393A1 US 9510763 W US9510763 W US 9510763W WO 9606393 A1 WO9606393 A1 WO 9606393A1
Authority
WO
WIPO (PCT)
Prior art keywords
changer
api
medium
applications program
media
Prior art date
Application number
PCT/US1995/010763
Other languages
English (en)
Inventor
Robert P. Rossi
Original Assignee
Arcada Software, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Arcada Software, Inc. filed Critical Arcada Software, Inc.
Priority to AU33720/95A priority Critical patent/AU3372095A/en
Publication of WO1996006393A1 publication Critical patent/WO1996006393A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G06F13/102—Program control for peripheral devices where the programme performs an interfacing function, e.g. device driver
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements

Definitions

  • This invention relates generally to an applications program interface for interfacing an applications program with a medium changer and, more particularly, to an applications program interface for interfacing any applications program that may control any type of tape medium changer.
  • An applications program or software is, generally, a program that is written to cause a device such as a computer or any of its computer peripherals to perform a specific task.
  • an applications program may cause the computer to perform data management or word processing functions.
  • the applications program also may be written to cause the computer to control and/or obtain status information about a peripheral device such as a medium changer which can move any one or more data storage media into and out of a drive for reading or writing data on the medium.
  • a medium changer is a device that mechanizes the movement of media to and from a media drive such as a disk or tape drive and between other locations within the range of the medium changer device.
  • Each of the medium changer devices that may be coupled to a computer or be a component of a computer network may have its own characteristics and capabilities; however, they all have one or more instances of at least three common physical elements. These are (1) a storage element which is a location within the medium changer device to hold a unit of media while it is not in some other type of element, (2) a drive or data transfer element which is a location of the drive that is capable of reading or writing the medium, and (3) a transport element which is a location that a given medium occupies while it is being moved from one element address to another within or about the medium changer device.
  • the medium changer device has one or more instances of (4) an import/export element which is a location for inserting and removing media from the medium changer device (which may be referred to as a portal) .
  • an import/export element which is a location for inserting and removing media from the medium changer device (which may be referred to as a portal) .
  • each of these four elements is viewed as a unique addressable element having its own element address.
  • SCSI small computer system interface
  • IOCTL I/O Control Code
  • An IOCTL is a mechanism for user-mode (application level code) to communicate with kernel-mode (device driver level code) .
  • An applications program using the low level IOCTL kernel API as its interface boundary between the application and kernel level is going to, by definition, be forced to handle most non-standard medium changer device issues in the application. This is because it is not easy to expand the low level IOCTL kernel API, or add more APIs without extensive work if such a non-standard device needs to be supported but cannot fit within the existing definitions of the IOCTLs. For example, adding a new IOCTL would typically require every device driver to be altered to handle and return gracefully from an IOCTL request, even though only one device may really have any true use for it.
  • handling device specific problems in the application has other disadvantages.
  • the application should only see the changer device as an "object", not as a specific physical product, e.g. one having a particular model number, and made by a specific company, e.g., company XYZ.
  • the application With the low level IOCTL kernel API, as the code in the application grows so as to handle new devices and their specific problems, the application becomes more prone to bugs and more difficult to maintain.
  • MEDIA_ID MountMedia
  • This API's definition would be that when called the media with media code MEDIA_ID must be located in the changer, and put or mounted into any available drive.
  • the media with MEDIA_ID is found in the portal, having been manually placed there by the user. There then may have to be multiple commands issued to the device to satisfy this API call. For example, one command would cause the portal to be closed, another command would cause all the drive elements to be scanned to find an available drive, and yet another command would cause the media to be moved into the drive. And, while responding to these commands, checks would have to be performed to be sure the device has not errored, or is busy servicing another initiator.
  • This example assumed that the particular changer had media code (“bar code”) scanning ability to get the media ID, but if it did not then multiple problems arise. Thus, there simply is too much occurring underneath the call MountMedia
  • an applications program interface for interfacing one or more applications programs with one or more medium changer devices
  • the API has a plurality of API calls for obtaining information about the status parameters of the elements of a given medium changer device and the features parameters of any such device, and for moving the medium supported by the device from one of the elements to another
  • one of the calls has a data structure including a plurality of data structure members in which one of the members can store information about the status parameters of the elements of the device
  • another one of the calls has a data structure including a plurality of data structure members in which one of the members can store information indicating one or more features that the device supports.
  • the present invention is a method for interfacing any of a plurality of applications programs with any of a plurality of medium changer devices supporting a set of SCSI commands, using an API, comprising the API receiving from the applications program a pointer to a data structure storing device parameters from which the applications program can configure itself to utilize a given medium changer device, getting information about the vendor of the device, the specific device itself and the features supported by the device, and building an inventory in the database of the information.
  • the present invention constitutes a multilayered software architecture for supporting one or more different medium changer devices, including (a) an applications program; (b) an applications program interface layered beneath the applications program; (c) an I/O manager of an operating system layered beneath the applications program interface; (d) a plurality of different vendor specific drivers layered beneath the I/O manager; (e) a SCSI changer driver layered beneath the plurality of vendor specific drivers for driving the one or more medium changer drivers; and (f) a database used by the applications program to specify supported changers and by the SCSI changer driver to load the correct VSDs.
  • the API of the present invention has the advantage of supporting many different medium changer device vendors and status parameters and products, as well as any particular features (up to 32 in the specific embodiment described below) that a particular changer device may have. This allows the applications program to tailor itself to any given medium changer device, thereby making use of the flexibility and expandability of the API.
  • FIGURE 1 is a perspective view of one example of a medium changer device having instances of the basic four types of elements defined by the SCSI-2 specifications.
  • FIGURE 2 illustrates the multilayered architecture of a software system in which the API of the present invention is layered.
  • FIGURES 3A and 3B illustrate data structures of the API of the present invention useable in a computer system.
  • FIGURE 4 is a flow diagram of the overall procedure of the API of the present invention.
  • FIGURE 5 is a flow diagram illustrating the procedure in which the API of the present invention initializes a medium changer device.
  • FIGURE 6 is a flow diagram showing the procedure in which the API of the present invention performs medium changer device functions.
  • FIGURE 7 is a flow diagram illustrating the procedure in which the API of the present invention performs de-initialization of the medium changer device.
  • Fig. 1 illustrates a representative example of a medium changer device 10 that has a set of four classes or types of discrete physical elements defined by SCSI- 2 specifications.
  • the medium changer device 10 is a tape medium changer 12, although the principles of the API of the present invention apply to other media and media changer devices such as disk and CD-ROM.
  • Instances of four elements are illustrated as (1) one or more storage elements 14 storing a plurality of tape cassette media 16, (2) one or more drive elements 18 for reading and writing one of the loadable tape media 16, (3) a transport element 20 which is the location of a given tape medium 16 while the medium is being moved to another element such as the drive element 18, and (4) an import/export element or portal 22 showing the location for inserting and removing media 16 from the tape medium changer 12.
  • Each of these elements is an addressable element having, for example, a unique 16- bit address.
  • Fig. 2 illustrates the multi-layered software architecture 24 of the present invention.
  • a given applications program 26 which has been written to, among many other things, cause the medium changer 12 to perform one or more functions.
  • a medium changer API 28 is layered directly beneath the applications program 26 and interfaces the applications program 26 with a medium changer 12.
  • This API 28 is neither a high level, highly abstract API such as MountMedia(MEDIA_ID) , nor is it defined at the IOCTL level, such that the API may require new application-level code be written for each new medium changer 12 (only one changer 12 shown in Fig. 2) added to a computer or a computer network system (not shown) .
  • the API 28 communicates with the next layer of the architecture 24 which is an I/O manager 30 of a given operating system via a line 32 transferring API IOCTLs.
  • the API 28 can interface with any type of operating system; however, for each O.S., there will typically be unique methods of obtaining a "handle" to a given medium changer device 10, as well as a way to associate which drives belong within the scope of that desired medium changer device 10.
  • a "handle” is a variable that identifies an object; an indirect reference to an operating system resource.
  • the I/O manager 30 interfaces with and selects any of a plurality of vendor specific drivers 34 (VSDs) over respective lines 36.
  • VSDs vendor specific drivers 34
  • the I/O manager 30 uses the changer handle to route the request to a proper VSD 34 and process it.
  • the next layer of the software architecture 24 is a conventional SCSI-2 compliant changer driver 38 which interfaces with the VSDs 34 over lines 40 shown respectively as 40a, 40b and 40c.
  • the changer driver 38 is the layer that communicates with a SCSI port/miniport driver(s) 41 which interacts with the SCSI bus host adapter to drive the medium changer 12.
  • VSD Database 42 is used as the communication hub between the applications program and the SCSI changer driver 38. It contains Vendor and Product ID and the associated VSD name for each device 12 the applications program 26 wishes to support, and for which there exists a VSD for the SCSI changer drive 38 to load. Under the above- mentioned Windows NT operating system, the registry would be used for the VSD Database 42.
  • the applications program uses the VSD Database 42 as a method to tell the SCSI changer driver 38 what changers it wants support for.
  • This Database 42 is created by the applications program at installation time on a computer system (not shown) , and devices may be added or deleted as desired at a later time. Depending on the O.S., changes to the VSD Database 42, might not be recognized until the drivers are re ⁇ loaded, or the operating system re-booted.
  • VSDs 34 are important in the architecture of this invention. A given VSD 34 should make any digressions from the SCSI-2 specification transparent at the API level, and the VSD 34 should take advantage of any vendor unique commands that make compliance to the rules of the API easier.
  • the API 28 of the present invention has ten calls 1-10 for any applications program 26 utilizing the medium changer 12. These are defined generally as follows and thereafter in full detail:
  • Changer_Portal_Operation Opens or closes a given portal 22 in a given medium changer 12, enabling/disabling the user from inserting/removing media via the given portal.
  • P pointer For example, if a given parameter has the symbol pdw, that is a pointer to a double word.
  • Each detailed definition of a call lists information about parameters that are input by the applications program 26 to the API 28, followed by a description of the data structure member associated with that call. For example, for the call Changer_Get Element_Status there is a listing:
  • dwSourceAddress which is the source address a medium 16 at dwElementAddress (another parameter) was moved from.
  • Fig. 3A and 3B illustrate, as examples, two respective data structures whose members are used in connection with two calls. These are the calls Changer
  • this data structure has several members or fields which include a source address (SA) , primary media code (PMC) , alternate media code (AMC) , and element status (ES) .
  • SA source address
  • PMC primary media code
  • AMC alternate media code
  • ES element status
  • the field ES is, for example, a 32-bit field in which a "1" in a particular bit position represents a defined condition as specified in the detailed listing below.
  • a "1" in the bit position identified in the detailed listing ELEMENT_ACCESS means that the transport elemen (s) 20 is currently allowed access to an element at the parameter dwElementAddress (which is the address of the element whose status is to be reported) .
  • the data structure member has several members or fields which include a vendor ID field (VID) , a product ID field (PID) ... and a features field FTRs.
  • the field VID contains information about the specific vendor of a given tape medium changer 12 as returned by a SCSI-2 command and the field PID contains information about the specific medium changer 12 as returned by a SCSI-2 command.
  • the field FTR is a 32-bit field in which a "1" in a given bit position indicates that the corresponding feature is supported. For example, a "1" in the bit position Move_Drive_To Drive means that the medium changer 12 requires only one changer move medium command to move media between drive elements 18.
  • these 32-bit features parameters and status parameters provide for an API 28 that is flexible and expandable by being able to store up to 32 features and status information, respectively.
  • pdwBufferSize Pointer to a dword that should have the size, in bytes, of the buffer specified by peiElementlnformation. If the buffer is too small, the dword receives the required size.
  • peiElementlnformation Pointer to a structure containing the statue information of the element at dwElementAddress.
  • structure members The following describes the structure members:
  • cPrimaryMediaCode[n] Null-terminated string containing the media code of the media at dwElementAddress, accessible via a ChangerMoveMedium command without the invert bit set. Valid only if the device has media code scanning capabilities, and media is present at dwElementAddress.
  • cAlternateMediaCode[n] Null-terminated string containing the media code of the media at dwElementAddress, accessible via a ChangerMoveMedium command with the invert bit set (the other side of the media) .
  • dwElementStatus Contains supported information about the element at dwElementAddress. A value of 1 in the proper bit-field represents a given condition. The following describes the element status:
  • EXPORT PORTAL ACCESS The changer currently allows exporting media out of the scope of the medium changer device via the portal at dwElementAddress. Valid only if dwElementAddress is a portal element address.
  • ELEMENT ACCESS The transport element (s) are currently allowed access to the element at dwElementAddress. Valid only if dwElementAddress is a portal element address, storage element address, or drive element address.
  • IMPORT PORTAL ACCESS The changer currently allows importing media into the scope of the medium changer device via the portal at dwElementAddress. Valid only if dwElementAddress is a portal element address.
  • LAST PORTAL ACCESS Indicates the media at dwElementAddress was placed there by an operator. Otherwise, the media was placed there by a transport element. Valid only if dwElementAddress is a portal element address, and the MEDIA_PRESENT status is set.
  • MEDIA INVERTED The media at dwElementAddress has been inverted by a ChangerMoveMedium command since the media was last at dwElementAddress. Valid only if the MEDIA INVERTED VALID status is set. MEDIA_INVERTED_VALID Indicates the MEDIA_INVERTED status is valid .
  • MEDIA PRESENT Media is currently present at dwElementAddress. Valid only if supported.
  • pdwBufferSize Pointer to a dword that should have the size, in bytes, of the buffer specified by pciChangerlnformation. If the buffer is too small, the dword receives the required size.
  • pciChangerlnformation Pointer to an information structure from which the application can configure itself to utilize the medium changer driver to its fullest capabilities.
  • dwNumTransportElements Number of transport elements in the medium changer device.
  • BJECT_MEDIA_BEFORE_INITIALIZB The device requires that in a drive element be ejected (unloaded) b e f o r e c a l l i n g ChangerlnitializeElementStatus to initialize that drive element.
  • EJECT MEDIA BEFORE MOVE The device requires that media in a given drive element be ejected (unloaded) before calling ChangerMoveMedium with that drive element or the source element address.
  • INITIALIZE BY ELEMENT Supports initializing a single g i v e n e l e m e n t v i a ChangerInitializeElementStatus.
  • INITIALIZE SCANS MEDIA CODE ChangerInitializeElementStatus also automatically scans the code of the media at the specified element(s).
  • MOVE DRIVE TO DRIVE The device supports moving media between drive elements: You can specify both the source and destination element address to be that of drive elements in a ChangerMoveMedium command.
  • MOVE STORAGE TO STORAGE The device supports moving media between storage elements: You can specify both the source and destination element address to be that of storage elements in a ChangerMoveMedium command.
  • PORTAL OPERATION REQUIRED The portal (s) must be opened/closed each time media is to be moved into/out of the scope of the medium changer device.
  • the medium changer device has import/export portal(s) .
  • PORTAL ELEMENTS AS STORAGE
  • the portal element(s) can be used to (temporarily) store media.
  • a portal must be closed to be used as a (temporary) storage location.
  • OSITION RANSPORT The medium changer device supports positioning the transport elements.
  • PREVENT MANUAL ACCESS Supports locking the device, preventing the user from manual operation of panel controls and media.
  • the medium changer device has the ability to report the prescence of media at all of its element addresses.
  • RESERVE RELEASE DEVICE Supports reserving/releasing all elements in the medium changer device at once.
  • RESERVE RELEASE ELEMENTS Supports reserving/releasing specified elements in the medium changer device.
  • SCAN_MEDI ⁇ _CODE_ALL_ELEMENTS Supports scanning the media code of all the elements at once via ChangerScanMediaCode.
  • SCAN MEDIA CODE BY ELEMENT Supports scanning the media code of a single given element via ChangerScanMediaCode.
  • TRANSPORT ELEMENT ILLEGAL It is illegal to specify a transport element address as a source or destination element address in a ChangerMoveMedium command. The command expects the source and destination element addresses to be element addresses of one of the other valid element types.
  • TRANSPORT_ELEMENT_REQUIRED It is required for every ChangerMoveMedium command, either the source or destination element address must be the element address of the transport element.
  • the return value is COMPLETE SUCCESS. Otherwise it is an error code.
  • INITIALIZE ALL_ELEMENTS bit is set in dwSpeciallnitialize.
  • INITIALIZE_ALL_ELEMENTS Initialize all elements in the medium changer device.
  • TRUE prevents the user from manual operation of panel control (s) (eject, move, etc..) and media. If FALSE, allows the user manual operation of panel control(s) and media.
  • INVERT MEDIA Invert flip the media prior to moving to the destination element address.
  • dwTransportAddress Element address of the transport to be associated with the portal operation If there is only one transport element in the device, then the element address of that transport should be used.
  • bOpenClose Indicates open or close operation: TRUE open the portal, FALSE close the portal.
  • the return value is COMPLETE SUCCESS. Otherwise it is an error code.
  • dwDestinationAddress Destination element address must be the address of a drive, storage, or portal element only.
  • sID The ID to be associated with the element(s) to be Reserved, or the ID of the element (s) to be Released.
  • the ID is an arbitrary value in the range 0-255. Ignored if the Reserve/Release operation is of RESERVE/RELEASE_DEVICE type.
  • dwStartingAddress The starting element of a specific element-type to be Reserved. Ignored unless RESERVE_ELEMENTS operation. Valid only if supported.
  • Non-zero values are valid only if reserving specified elements is supported.
  • the return value is COMPLETE SUCCESS. Otherwise it is an error code.
  • dwTransportAddress Element address of the transport to be associated with the scan operation If there is only one transport element in the device, then the element address of that transport should be used.
  • FIG. 4 is a flow diagram used to explain one manner in which the API 28 of the present invention may be used on a computer system (not shown) together with the execution of components of the software shown in Fig. 2.
  • the API 28 will perform medium changer initializations (block 52) . If the initializations are successful (block 54) , then the API 28 will cause performance of the requested changer functions (block 56) as will be further described.
  • the primary functions that may be performed are for the medium changer 12 to move a medium 16, position the transport, do a portal operation, scan the media and/or get the status of a given element 16.
  • the de- initialization of the changer 12 occurs (block 58) and the program is done (block 60) . If the changer initializations are not successful (block 54) then the program is done (block 60) .
  • Fig. 5 is a flow diagram showing in more detail the initializations that are performed by the API 28 of the present invention with reference to a number of the calls (1)-(10).
  • the first step is to obtain a handle for the changer (block 62) .
  • Next is the call of Changer_Get_Status which returns the status of medium changer 12 (block 64) . If there is no error (block 66) , the next call is Changer_Get_Parameters (block 68) , which returns the capabilities of medium changer 12.
  • call Changer_Manual Access (block 76) is executed, which locks up the changer 12 and prevents manual access to the media 16. Then, if there is no error (block 78) , all the elements of medium changer 12 are initialized by calling Changer_Initialize_Element Status (block 80) . If there is no error (Block 82) , the application may then enter a loop (Blocks 84, 86, 87, 88) obtaining information about each element by calling Changer_Get_Element_Status (Block 84) .
  • Change_Scan_Media_Code may then be called (Block 84) to get the media code.
  • the information returned from these calls may be used at this time to build (Block 87) or if persistent, verify the Internal Inventory. If the status of all the elements has been obtained (block 88) , then the initializations have been successfully performed and this program is done (block 90) .
  • a series 92 of error recovery procedures will occur in connection with each call. For example, if there is an error (block 66) during or on the completion of the call Changer_Get_Status (block 64) , then an error handler is invoked (block 94) . If the error is recoverable (block 96) , then the call (block 64) , is executed again. If the error is not recoverable (block 96) , then initialization has failed and this program is done (block 98) . As can be seen in Fig. 5, a similar error handler procedure for each call can be executed. If all the initializations have been performed as illustrated in Fig. 5, then the calls shown in Fig.
  • Fig. 7 illustrates the flow for performing changer de-initialization (block 58) .
  • the call Changer Manual_Access (block 110) is executed to allow manual access to the medium changer 12. If there is no error
  • block 114 is executed to release any lock on the changer so it may be then used by other initiators. If there is no error (block 116) then de-initialization is done (block 118) . Again, as shown to the right of Fig. 7, a simple error handle 92 procedure is invoked at each call.
  • the Internal Inventory is an internal database, stored in the computer system
  • This Internal Inventory is then updated when required after performing certain changer functions such as Changer_Move_Medium.
  • This Internal Inventory also has the option of being persistent, or being generated every time at initialization of the programs application. The persistent Internal Inventory is especially useful in very large changers 12, where numerous media and drive elements exist, and initialization of every element would take a long period of time. Should for some reasons the applications program shut down, it can be re-started, and the persistent Internal Inventory can be used to continue operations.
  • the applications program would also have the option of calling certain changer API's, and comparing the results to its Internal Inventory to detect problems, discrepancies, or possible user tampering inside the changer 12 while the applications program 26 was down.
  • the Internal Inventory contains information about the media, relative to the elements in a changer.
  • the applications program can continually access this database to verify user's requests are valid, or to report back information to the user. It can be used to determine error or inconsistencies with what the APIs are reporting back as well.
  • An advantage to a persistent inventory is the increased ability to recover from power-failures, one of storage management applications' biggest nightmares. In such a situation a changer device's firmware may be reset, such that it cannot provide reliable information regarding its elements relative to the state it was in prior to the power-outage.
  • the applications program could reference that, and most likely figure out the state it was in when it was last shut-down, and continue with operations, reporting any necessary errors/warnings to the user. Not only does this persistent Internal Inventory help with regards to the changer, but to the devices IN the changer. If there is media in the drives, and there is a power outage, then when the applications program starts back up, it may be in an error state relative to those drives because it was not expecting media to be in them at start-up. The Internal Inventory could then be used to tell the applications program what storage elements those tapes came from, and decide how to recover, whether to continue drive operations, or move them back to their original storage element.
  • the API 28 allows for not just one, but two different approaches in its use.
  • One is an interactive approach where the APIs are called every time information is needed about an element or prior to performing an operation. This approach relies on the device's ability to report the information based on the devices firmware, which is the origin of the information that is reported back through the APIs.
  • the second approach is to initially call the information APIs (i.e. ChangerGetElementStatus) to build the Internal Inventory, and then use that inventory whenever possible to obtain information.
  • the changer APIs then only to need to be called for functional requests.
  • Inventory can also be used to check against an informational API, or to recover from an error state.
  • the conceptual definition of the changer API of the present invention is different than that of the low level IOCTL kernel API and abstract high level API described above.
  • the changer API of the present invention is defined such that it creates a very device-centric view of a changer object so that the applications program can tailor itself to use the different physical changers 12 in a more organized fashion without actually knowing what the make and model of changer 12 it is using.
  • the API 28 is a layer over the IOCTL API to hide the exact driver/device protocols, making the API 28 more like what applications programmers are used to interfacing with.
  • the task of making the API 28 conform to its definition takes place under the API before making the IOCTL call, or in the drivers.
  • the application no longer needs to be altered every time a device 12 that needs special treatment to meet the definition of the changer API 28 is to be supported.
  • additional code is required in the applications program 26, it is clearly defined and organized, and once put in place, will work for every device 12 that requires the support of that new code. Aiding in accomplishing this is the design of the VSD/SCSI Changer Driver architecture of Fig. 2 lends itself to better organization, separation, and ease of adding new device support at the driver level than traditional class or filter driver architectures. Only VSDs 34 should have to be added/altered, not the SCSI changer driver 38.
  • the applications program 26 views a medium changer 10 as an object with a handle, which lends itself to be easily utilized using object-oriented program methodologies.
  • a C ++ class "wrapper” can be placed around the API to create a medium changer "class”, which when instantiated, would become a medium changer object.
  • MCERROR_HARD ARE MCERROR_INSUFFICIENT_MEMORY
  • MCERROR_DRIVER_TIMEOUT MCERROR_INVALID_REQUEST
  • MCERROR_NO_SCH_DEVICE MCERROR_VSD_DRIVER_CALL_FAI ED
  • MCERROR_SCSI_CHANGER_INTERNAL MCERROR_UNRECOGNIZED_STATUS

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Automatic Disk Changers (AREA)

Abstract

Une interface de programme d'application (API) relie au moins un programme d'application à au moins un dispositif de changement de support comportant une multitude d'éléments physiques adressables. Cette interface comporte une pluralité d'appels API permettant d'obtenir des informations sur les paramètres de tous types de dispositifs et de déplacer un support médiatique d'un élément à l'autre. L'un de ces appels comprend une structure de données stockant, entre autres, les paramètres des fonctions d'un dispositif de changement de support particulier, et un autre de ces appels comprend une structure de données stockant, entre autre, l'état des éléments des dispositifs.
PCT/US1995/010763 1994-08-24 1995-08-24 Interface de programme d'application (api) pour dispositif de changement de support WO1996006393A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU33720/95A AU3372095A (en) 1994-08-24 1995-08-24 Application program interface (api) for a medium changer

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US29497494A 1994-08-24 1994-08-24
US08/294,974 1994-08-24

Publications (1)

Publication Number Publication Date
WO1996006393A1 true WO1996006393A1 (fr) 1996-02-29

Family

ID=23135713

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1995/010763 WO1996006393A1 (fr) 1994-08-24 1995-08-24 Interface de programme d'application (api) pour dispositif de changement de support

Country Status (2)

Country Link
AU (1) AU3372095A (fr)
WO (1) WO1996006393A1 (fr)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998016886A1 (fr) * 1996-10-15 1998-04-23 Philips Electronics N.V. Systeme de commande pour dispositifs electroniques grand public commande par tache
WO1998033113A1 (fr) * 1997-01-23 1998-07-30 Overland Data, Inc. Bibliotheque de supports virtuels
WO2000036606A1 (fr) * 1998-12-15 2000-06-22 Sony Electronics, Inc. Modele et jeu de commande pour une sous-unite de lecteurs av/c
US6131129A (en) * 1997-07-30 2000-10-10 Sony Corporation Of Japan Computer system within an AV/C based media changer subunit providing a standarized command set
EP1233343A3 (fr) * 2001-02-16 2002-10-30 Microsoft Corporation Procédé et une couche d'interface radio composes d'un ensemble des interfaces de programmation des applications (APIs)
EP1497723A4 (fr) * 2001-06-06 2007-07-04 Sap Ag Couche d'interface de programmation d'applications pour une reference croisee d'appareils a des applications correspondantes
US8972348B2 (en) 1999-10-04 2015-03-03 Microsoft Corporation Method and system for supporting off-line mode of operation and synchronization
US8990695B2 (en) 2003-10-23 2015-03-24 Microsoft Technology Licensing, Llc Flexible architecture for notifying applications of state changes
US9065902B2 (en) 2002-02-01 2015-06-23 Microsoft Technology Licensing, Llc Method and system for managing changes to a contact database

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0371941A2 (fr) * 1988-11-29 1990-06-06 International Business Machines Corporation Système et méthode d'interface générique pour des programmes d'application

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0371941A2 (fr) * 1988-11-29 1990-06-06 International Business Machines Corporation Système et méthode d'interface générique pour des programmes d'application

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Message Logging Services for Personal Computer Systems", IBM TECHNICAL DISCLOSURE BULLETIN, vol. 37, no. 8, NEW YORK US, pages 483 - 486 *
GALBREATH ET AL: "Applications-Driven Parallel I/O", PROCEEDINGS SUPERCOMPUTING 1993, 15 November 1993 (1993-11-15) - 19 November 1993 (1993-11-19), PORTLAND, US, pages 462 - 471 *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998016886A1 (fr) * 1996-10-15 1998-04-23 Philips Electronics N.V. Systeme de commande pour dispositifs electroniques grand public commande par tache
WO1998033113A1 (fr) * 1997-01-23 1998-07-30 Overland Data, Inc. Bibliotheque de supports virtuels
US6328766B1 (en) 1997-01-23 2001-12-11 Overland Data, Inc. Media element library with non-overlapping subset of media elements and non-overlapping subset of media element drives accessible to first host and unaccessible to second host
US6131129A (en) * 1997-07-30 2000-10-10 Sony Corporation Of Japan Computer system within an AV/C based media changer subunit providing a standarized command set
WO2000036606A1 (fr) * 1998-12-15 2000-06-22 Sony Electronics, Inc. Modele et jeu de commande pour une sous-unite de lecteurs av/c
US8972348B2 (en) 1999-10-04 2015-03-03 Microsoft Corporation Method and system for supporting off-line mode of operation and synchronization
EP1233343A3 (fr) * 2001-02-16 2002-10-30 Microsoft Corporation Procédé et une couche d'interface radio composes d'un ensemble des interfaces de programmation des applications (APIs)
US6826762B2 (en) 2001-02-16 2004-11-30 Microsoft Corporation Radio interface layer in a cell phone with a set of APIs having a hardware-independent proxy layer and a hardware-specific driver layer
EP1497723A4 (fr) * 2001-06-06 2007-07-04 Sap Ag Couche d'interface de programmation d'applications pour une reference croisee d'appareils a des applications correspondantes
US9065902B2 (en) 2002-02-01 2015-06-23 Microsoft Technology Licensing, Llc Method and system for managing changes to a contact database
US10409829B2 (en) 2002-02-01 2019-09-10 Microsoft Technology Licensing, Llc Method and system for managing changes to a contact database
US8990695B2 (en) 2003-10-23 2015-03-24 Microsoft Technology Licensing, Llc Flexible architecture for notifying applications of state changes

Also Published As

Publication number Publication date
AU3372095A (en) 1996-03-14

Similar Documents

Publication Publication Date Title
US5920709A (en) Bus interface for IDE device
US5430845A (en) Peripheral device interface for dynamically selecting boot disk device driver
US5768568A (en) System and method for initializing an information processing system
US5854905A (en) Extensible bios for boot support of devices on multiple hierarchical buses
US6016402A (en) Method for integrating removable media disk drive into operating system recognized as fixed disk type and modifying operating system to recognize as floppy disk type
US6085318A (en) Computer system capable of booting from CD-ROM and tape
US5794032A (en) System for the identification and configuration of computer hardware peripherals
US5568641A (en) Powerfail durable flash EEPROM upgrade
US7882206B2 (en) Storage device system and storage device system activating method
US20040230963A1 (en) Method for updating firmware in an operating system agnostic manner
US7624233B2 (en) Portable storage device
EP0726518A2 (fr) Méthode et appareil pour démarrer un système d'ordinateur sans préinstallation d'un système d'exploitation
US20030005278A1 (en) Multifunction semiconductor storage device and a method for booting-up computer host
US7395420B2 (en) Using protected/hidden region of a magnetic media under firmware control
EP1378830B1 (fr) Selecteur de systeme d'exploitation et disque de stockage de dounees
WO1997029451A1 (fr) Procedes et appareil destines a l'initialisation d'un ordinateur a unite de disque amovible
WO2000019310A2 (fr) Enregistrement d'amorçage pilote a double mise en application
TWI813869B (zh) 資料儲存裝置及維持資料儲存裝置正常開機運作的方法
US20050041459A1 (en) Interface for removable storage devices
JP2003150322A (ja) 単一ライブラリ内で仮想ライブラリを使って複数のドライブタイプをサポートする仮想電子データ・ライブラリ
WO1996006393A1 (fr) Interface de programme d'application (api) pour dispositif de changement de support
CN112306581A (zh) 一种基板管理控制器管理bios配置的方法及介质
US6446139B1 (en) Multiple chip single image BIOS
US6760788B2 (en) Domain validation process that is transparent to a device driver
US20020138680A1 (en) Apparatus and methods for controlling removable media devices using a BIOS abstraction layer

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AM AT AU BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU IS JP KE KG KP KR KZ LK LR LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TT UA UG UZ VN

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE MW SD SZ UG AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase