Browse Prior Art Database

Uniform Handle Space for OS/2

IP.com Disclosure Number: IPCOM000110575D
Original Publication Date: 1992-Dec-01
Included in the Prior Art Database: 2005-Mar-25
Document File: 2 page(s) / 73K

Publishing Venue

IBM

Related People

Banda, VP: AUTHOR [+3]

Abstract

The OS/2* operating system is not a distributed operating system. However, various components of a distributed system (e.g, distributed file system (DFS), security, Remote Procedure Call, etc.) can be installed on the base operating system as subsystems. One would like application programs to be able to use the facilities of these subsystems using APIs exported by the OS/2 system. For example, an application program should be able to use the DFS component by invoking a DosOpen on a DFS file. Similarly, it must be able to open a socket by invoking a a DosOpen on a resource belonging to the socket subsystem. This approach has the advantage of unifying various subsystems and providing a common interface to the application program.

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

Uniform Handle Space for OS/2

       The OS/2* operating system is not a distributed operating
system.  However, various components of a distributed system (e.g,
distributed file system (DFS), security, Remote Procedure Call, etc.)
can be installed on the base operating system as subsystems.  One
would like application programs to be able to use the facilities of
these subsystems using APIs exported by the OS/2 system.  For
example, an application program should be able to use the DFS
component by invoking a DosOpen on a DFS file.  Similarly, it must be
able to open a socket by invoking a a DosOpen on a resource belonging
to the socket subsystem.  This approach has the advantage of unifying
various subsystems and providing a common interface to the
application program.

      Providing such a seamless integration of the various subsystems
requires that the base operating system provide the following
capabilities:
      1.  Establish a Naming Convention: The naming convention should
be able to identify the subsystem that a given name refers to. In our
prototype we prefixed all resource names with the appropriate
subsystem name, e.g., a DFS resource would be names as DFS .....
      2.  Provide a means of registering subsystems to the base
operating system.  This involves registering the name along with the
functions that the subsystem supports.
      3.  Provide the necessary support to map a given resource
handle to a specific resource within a specific subsystem.  In other
words, the base operating system should be able to provide a Uniform
Handle Space.  Each time the base operating system returns a handle,
it keeps track of the subsystem that handle belongs to.  It wo...