Browse Prior Art Database

Selection of Resources by Participation rather than Scoping

IP.com Disclosure Number: IPCOM000111963D
Original Publication Date: 1994-Apr-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 4 page(s) / 119K

Publishing Venue

IBM

Related People

Allen, MO: AUTHOR [+6]

Abstract

Disclosed is a method for selecting Open Systems Interconnection (OSI) managed objects representing a set of resources based upon the participation of those resources in a particular group rather than by scoping on the names of the managed objects.

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

Selection of Resources by Participation rather than Scoping

      Disclosed is a method for selecting Open Systems
Interconnection (OSI) managed objects representing a set of resources
based upon the participation of those resources in a particular group
rather than by scoping on the names of the managed objects.

      OSI management provides a powerful function, called scoping,
that allows a manager to select particular managed object instances
at an agent based upon partial matching of the distinguished names of
those object instances.  The distinguished name for a managed object
instance is constructed from a series of names according to a rule
called a name binding.  Name bindings for particular managed object
classes are designed to facilitate scoping by constructing a name
that is based upon a well-understood relationship at the agent.

      For example, in Systems Network Architecture (SNA), the name of
a computer system (called a node, control point, or CP in SNA) in a
network is a 1-8 character string prefixed by the name of the SNA
network of which the node is a member (generally encoded as
"netID.CPname").  The name binding selected for an SNA node uses
these same two tokens:

   netid=networkname,nodeid=nodename

      The SNA name for a logical unit (an application program or a
terminal) has a name constructed in the same manner:  "netid.LUname";
however there is an important relationship between an LU and the node
that provides network access for the LU.  In SNA, this relationship
is communicated by providing two names in pertinent control messages:
the name of the LU and the name of the node that provides services
for the LU.  To summarize this relationship, the name binding created
for instances of the managed objects representing LUs consists of
three tokens:

   netid=networkname,nodeid=CPname,luname=LUname

      This name construction allows a manager to use scoping, as in a
command to the agent at a node that says

   return the operational state for every managed object instance
   meeting this condition:
    name matches this pattern: netid=networkname,nodeid=CPname,
luname=<any>

      This use of scoping based upon a name binding is potentially
very useful, but there is a problem in this case.  There is another
important relationship that cannot easily be included in the design
of the LU name binding.  LUs that are resident at a terminal
controller-type system (a physical unit, or PU in SNA terminology)
have important operational dependencies on the PU.  The PU, in turn,
has a dependency upon the control point.  Ideally, the name binding
for these "dependent LUs" would be constructed in this manner:

   netid=networkname,nodeid=CPname,nodeid=PUname,luname=LUname
but the relationship...