Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Device Self-Description for Installation without Software Modifications

IP.com Disclosure Number: IPCOM000114070D
Original Publication Date: 1994-Nov-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 6 page(s) / 364K

Publishing Venue

IBM

Related People

Ripberger, RA: AUTHOR

Abstract

A method for identifying a device's characteristics to a program is disclosed which facilitates device installation without requiring additional programming support. Self-description techniques are utilized to allow the program to determine compatibility of a new device with existing programming support.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 14% of the total text.

Device Self-Description for Installation without Software Modifications

      A method for identifying a device's characteristics to a
program is disclosed which facilitates device installation without
requiring additional programming support.  Self-description
techniques are utilized to allow the program to determine
compatibility of a new device with existing programming support.

      When a new I/O device is developed, it is typical that new
software support is required for the device unless it exactly
emulates the operation of some existing product which is already
supported.  The requirement for new software is undesirable for all
of the following reasons:
  o  Cost of development
  o  Need to provide software on older levels of program for
      compatibility with the new device.
  o  Need to coordinate the availability of the software with the
      availability of the hardware.
  o  Need to install the software on all attaching systems before
      installing hardware.
  o  Inability to force customers to install new software may prevent
      the installation of hardware.
  o  Unexpected behavior/problems when wrong software support for the
      product is installed, but seems to more or less work.

      It would be desirable to find a way to avoid to have to write
new device software when the device behaves exactly like an existing
device from a programming perspective except that it differs in one
or more of the following ways:
  o  A new name (e.g., a new type number or model number).
  o  A different type of medium or recording format.
  o  Additional features which are optionally exploitable by the
      program.
  o  Only a subset of the features of the original device are
      supported.

      If a mechanism is provided to address these above cases, then
it must also provide a way to determine when the program does not
have the appropriate support for a new device.  Given that the above
problems can be solved, it is also conceivable to consider
dynamically configuring the device to the system at the point the
program detects that a new device has been attached provided the
necessary support is available.

      For example, in ESA/390* environments, device support has
typically been based around a device type number (e.g., 3480).
Normally, the following elements are provided:
  o  Programming support is written which understands the
      characteristics of a given device type.
  o  Configuration information is provided which associates a given
      device type with a given address.  In some implementations,
this
      information is provided when the system is generated (e.g.,
      SYSGEN, IOGEN).  In more sophisticated implementations, the
      configuration is dynamically updated while the system is
running.
  o  Validation of the configuration is normally performed during
      program initializatio...