OS/2 Shareware BBS: 8 Other/08-Other.zip/dcedirsv.zip/DCEDIRSV.INF

OS/2 Help File | 1998-05-08 | 487KB | 11,784 lines

ΓòÉΓòÉΓòÉ 1. Notices ΓòÉΓòÉΓòÉ

Second Edition (June 1996)

The following paragraph does not apply to the United Kingdom or any country
where such provisions are inconsistent with local law:  INTERNATIONAL BUSINESS
MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states
do not allow disclaimer of express or implied warranties in certain
transactions, therefore, this statement may not apply to you.

This publication could include technical inaccuracies or typographical errors.
Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time.

It is possible that this publication may contain reference to, or information
about, IBM products (machines and programs), programming, or services that are
not announced in your country.  Such references or information must not be
construed to mean that IBM intends to announce such IBM products, programming,
or services in your country.

Requests for technical information about IBM products should be made to your
IBM reseller or IBM marketing representative.


ΓòÉΓòÉΓòÉ 1.1. Copyright Notices ΓòÉΓòÉΓòÉ

COPYRIGHT LICENSE: This publication contains printed sample application
programs in source language, which illustrate OS/2 programming techniques. You
may copy, modify, and distribute these sample programs in any form without
payment to IBM, for the purposes of developing, using, marketing or
distributing application programs conforming to the OS/2 application
programming interface.

Each copy of any portion of these sample programs or any derivative work, which
is distributed to others, must include a copyright notice as follows: "(C)
(your company name) (year).  All rights reserved."

(C)Copyright International Business Machines Corporation 1992, 1996.  All
rights reserved.
Note to U.S. Government Users - Documentation related to restricted rights -
Use, duplication or disclosure is subject to restrictions set forth in GSA ADP
Schedule Contract with IBM Corp.


ΓòÉΓòÉΓòÉ 1.2. Disclaimers ΓòÉΓòÉΓòÉ

References in this publication to IBM products, programs, or services do not
imply that IBM intends to make these available in all countries in which IBM
operates. Any reference to an IBM product, program or service is not intended
to state or imply that only that IBM product, program, or service may be used.
Subject to IBM's valid intellectual property or other legally protectable
rights, any functionally equivalent product, program, or service may be used
instead of the IBM product, program, or service. The evaluation and
verification of operation in conjunction with other products, except those
expressly designated by IBM, are the responsibility of the user.

IBM may have patents or pending patent applications covering subject matter in
this document. The furnishing of this document does not give you any license to
these patents. You can send license inquiries, in writing, to:

      IBM Director of Licensing
      IBM Corporation
      500 Columbus Avenue
      Thornwood, NY  10594
      U.S.A.

 Licensees of this program who wish to have information about it for the
 purpose of enabling: (i) the exchange of information between independently
 created programs and other programs (including this one) and (ii) the mutual
 use of the information which has been exchanged, should contact IBM
 Corporation, Department LZKS, 11400 Burnet Road, Austin, TX 78758 U.S.A.  Such
 information may be available, subject to appropriate terms and conditions,
 including in some cases, payment of a fee.

 Asia-Pacific users can inquire, in writing, to the IBM Director of
 Intellectual Property and Licensing, IBM World Trade Asia Corporation, 2-31
 Roppongi 3-chome, Minato-ku, Tokyo 106, Japan.


ΓòÉΓòÉΓòÉ 1.3. Trademarks ΓòÉΓòÉΓòÉ

The following terms are trademarks of the IBM Corporation in the United States
or other countries or both:

      AIX

      IBM

      OS/2

 The following terms are trademarks of other companies:

 OSF       Open Software Foundation

 UNIX      Registered trademark in the United States and other countries,
           licensed exclusively through X/Open Company Limited.

 Other company, product, and service names, which may be denoted by a double
 asterisk (**), may be trademarks or service marks of others.


ΓòÉΓòÉΓòÉ 2. About This Book ΓòÉΓòÉΓòÉ

The IBM Distributed Computing Environment 2.1 for OS/2 Warp: Application
Development Guide - Directory Services provides information on how to access
the DCE Directory Service on an IBM OS/2 Warp operating system to share
information and resources between cells.

The Directory Service primarily includes three components:

   o  DCE Cell Directory Service (CDS)
   o  DCE Global Directory Service (GDS) (not supported for this release)
   o  X/Open Directory Service (XDS) and X/Open OSI-Abstract-Data Manipulation
      (XOM) Interfaces


ΓòÉΓòÉΓòÉ 2.1. Who Should Use This Book ΓòÉΓòÉΓòÉ

This guide is written for application programmers with OS/2 operating system
and C language experience who want to develop and write applications to run on
DCE. It does not assume that you have prior knowledge of, or experience with,
designing and writing distributed applications using the Open Software
Foundation's (OSF)** Distributed Computing Environment (DCE) services. Ideally,
you should be able to perform the following:

   o  Edit, browse, and copy OS/2 Warp files;

   o  Print files; and

   o  Write, compile, link, debug, and run C programs on OS/2 Warp.

 A good working knowledge and understanding of the following would also be
 helpful:

   o  Structured programming techniques;

   o  Computer communications over a network using Transmission Control
      Protocol (TCP) and User Datagram Protocol (UDP); and

   o  Concepts behind a distributed application.

 Some exposure to the UNIX** or AIX* operating systems is helpful but not
 essential to use this guide.


ΓòÉΓòÉΓòÉ 2.2. How This Book is Organized ΓòÉΓòÉΓòÉ

This book is divided into 14 sections which describe application programming,
program functions, and packages. Each section provides detailed instructions
for performing each specific set of tasks. Where necessary, directions to other
sections of the document are provided.


ΓòÉΓòÉΓòÉ 2.3. Related Publications ΓòÉΓòÉΓòÉ

In order to obtain a good foundation of the components and concepts behind DCE
prior to developing applications using this guide, you may find it helpful to
read or refer to the following:

   o  IBM Distributed Computing Environment 2.1 for OS/2 Warp: Getting Started

   o  IBM Distributed Computing Environment 2.1 for OS/2 Warp: Administration
      Guide

   o  IBM Distributed Computing Environment 2.1 for OS/2 Warp: Administration
      Command Reference

   o  IBM Distributed Computing Environment 2.1 for OS/2 Warp: Application
      Development Guide - Introduction and Style Guide

   o  IBM Distributed Computing Environment 2.1 for OS/2 Warp: Application
      Development Guide - Core Components

   o  IBM Distributed Computing Environment 2.1 for OS/2 Warp: Application
      Development Reference

   o  IBM Distributed Computing Environment 2.1 for OS/2 Warp: Network File
      System to Distributed File System Authenticating Gateway Guide and
      Reference

   o  IBM Distributed Computing Environment 2.1 for OS/2 Warp: Distributed File
      Service Client Guide and Reference

 Additionally, you may find the following documents helpful while developing
 your distributed application using IBM Distributed Computing Environment 2.1
 for OS/2 Warp:

   o  ANSI.C, American National Standard X3.159-1989

   o  CCITT Blue Book, Fascicle VIII.4, International Telecommunications Union,
      1988

   o  Information Processing - Programming Language C, ISO Draft International
      Standard DIS9899


ΓòÉΓòÉΓòÉ 2.4. Conventions Used in This Book ΓòÉΓòÉΓòÉ

This guide uses the following typographic conventions throughout:

 Bold                 Bold words or characters represent system elements that
                      you must enter into the system literally, such as
                      commands and file, path, and directory names.

 Italics              Italicized words or characters represent values for
                      variables that you supply. Italics is also used to
                      highlight a word or phrase that is being described.

 Example Font         Examples and information displayed by the system are
                      printed using an example font that is a constant width
                      typeface.

 [ ]                  Optional items found in format and syntax descriptions
                      are enclosed in brackets.

 { }                  In format and syntax descriptions, a list from which you
                      must choose an item is enclosed in braces.

 |                    A vertical bar separates items in a list of choices.

 < >                  Angle brackets enclose the name of a key on a keyboard.

 ...                  Horizontal ellipsis points indicate that you can repeat
                      the preceding item one or more times. Vertical ellipsis
                      points indicate that you can repeat the preceding item
                      one or more times.

 This document uses the following keying conventions throughout:

 <Ctrl-x>                   The notation <Ctrl-x> or ^x followed by the name of
                            a key, indicates a control character sequence. For
                            example, <Ctrl-c> means hold down the control key
                            while pressing c key.

 <Enter>                    The notation <Enter> refers to the key on your
                            terminal or workstation that is labeled with either
                            the word Enter or Return, or with a left arrow.

 Entering commands          When instructed to enter a command, type the
                            command name and then press the <Enter> key. For
                            example, the instruction "Enter the IDL command"
                            means that you type the IDL command and then press
                            the <Enter> key.


ΓòÉΓòÉΓòÉ 2.5. Terminology Used in This Book ΓòÉΓòÉΓòÉ

Although every attempt has been made to conform to Systems Application
Architecture (SAA)* terminology guidelines, you must keep in mind that the DCE
technology has been developed from the UNIX environment.

Notes:

   1. Throughout this document, the terms API, call, and routine all refer to
      the same IBM Distributed Computing Environment 2.1 for OS/2 Warp:
      application programming interface that is referenced. For example,
      rpc_binding_free API, rpc_binding_free call, and rpc_binding_free
      routine, all refer to the same rpc_binding_free API.

   2. Throughout this document, all references to individual DCE. components
      (such as RPC) refer to that component with the IBM Distributed Computing
      Environment 2.1 for OS/2 Warp: product. For example, references to RPC,
      DCE RPC, and IBM DCE for OS/2 RPC all refer to the same IBM DCE for OS/2
      component - RPC.


ΓòÉΓòÉΓòÉ 3. DCE Directory Service Overview ΓòÉΓòÉΓòÉ

This section of the DCE for OS/2 Warp Application Development Guide - Directory
Services provides an overview of the DCE Directory Service for application
programmers. This section begins with a basic description. It then introduces
DCE Directory Service concepts, the structure of DCE names, and the DCE
namespace. This section then provides an overview of the programming interfaces
used to access the DCE Directory Service.


ΓòÉΓòÉΓòÉ 3.1. Introduction to the DCE Cell Directory Service ΓòÉΓòÉΓòÉ

This section describes how application developers can access the DCE Directory
Service. From the application programmer's perspective, the Directory Service
has three main parts - the DCE Cell Directory Service (CDS), the DCE Global
Directory Service (GDS), and the X/Open Directory Service (XDS) and X/Open
OSI-Abstract-Data Manipulation (XOM) programming interfaces. GDS is not
supported for this release of DCE. See the DCE for AIX Version 1.3 publications
if you need information on GDS.

This product contains support for the XDS/XOM API over CDS. Although the
documentation contains numerous references to the functions provided by the
Global Directory Services (GDS), only the XDS/XOM API over CDS functionality is
shipped with this product.


ΓòÉΓòÉΓòÉ 3.1.1. Document Usage ΓòÉΓòÉΓòÉ

Before reading this guide, you should read the Introduction to Distributed
Computing Environment. It contains overviews, along with illustrations, of all
the DCE components and of DCE as a whole. Introductions that are necessary to a
full understanding of what is described here. Next, read this section in its
entirety.

If you do not find the information you need either in this guide or in the DCE
for OS/2 Warp: Application Development Reference, see the DCE for OS/2
Warp:Administration Guide and the DCE for OS/2 Warp: Administration Command
Reference. For example, information about the DCE Cell Directory Service as a
separate component is found in the administration documentation. Although the
DCE Security Service is documented in the application development guides, some
information of interest to programmers (such as adding new principals to the
registry database) is also found in the administration information units.


ΓòÉΓòÉΓòÉ 3.1.2. Directory Service Tools ΓòÉΓòÉΓòÉ

CDS has commands that allow system administrators to inspect and alter the
contents of the directory. This can be useful when developing applications that
access the DCE namespace.

For information on the CDS Control Program (cdscp), see the DCE for OS/2
Warp:Administration Guide.


ΓòÉΓòÉΓòÉ 3.2. Using the DCE Directory Service ΓòÉΓòÉΓòÉ

The DCE Directory Service can be used in many ways. It is used by the DCE
services to support the DCE environment. For example, cells can be registered
in the global part of the Directory Service, enabling users from different
cells to share information and resources (you will need an AIX Version 1.3
system as part of your cell to perform this function).

The DCE Directory Service is also useful to DCE applications. The client and
server sides of an application can use the Directory Service to find each
other's locations. The Directory Service can also be used to store information
that needs to be made available in a globally accessible, well-known place.

For example, one DCE application could be a print service consisting of a
client side application that makes requests for jobs to be printed, and a
server side that prints jobs on an available printer. The Directory Service
could be used as a central place where the print clients could look up the
location of a print server. Furthermore, the Directory Service could be used to
store information about printers; for example, what type of jobs a printer can
accept, whether the printer is currently up or down, and whether it is
currently lightly or heavily loaded.

In some ways, a Directory Service can be used in the same way as a file system
has traditionally been used; that is, for containing globally accessible
information in a well-known place. An example is, the use of configuration
information stored in files in a UNIX /etc directory. However, the Directory
Service differs in important ways. It can be replicated so that information is
available even if one server goes down. Replicas can be kept automatically
up-to-date, so that, unlike multiple copies of a file on different machines,
the information in the replicas of the Directory Service can be kept current
without manual intervention.

The Directory Service can also provide security for data that is kept in a
globally accessible place. It supports Access Control Lists (ACLs) that provide
fine-grained control over who is able to read, modify, create, and perform
other operations on its data.

As you learn about the DCE Directory Service and how to access it, think about
the ways in which your application can best take advantage of the services it
provides.


ΓòÉΓòÉΓòÉ 3.3. DCE Directory Service Concepts ΓòÉΓòÉΓòÉ

This section provides a description of DCE Directory Service concepts that are
important to application developers. The following concepts are intended to
convey general definitions that are applicable to the DCE Directory Service as
a whole rather than specific to a particular Directory Service component. For
more detailed definitions, see the Glossary in the Introduction to Distributed
Computing Environment.

   o  DCE Namespace - The DCE namespace is the collection of names in a DCE
      environment. It can be made up of several domains, in which different
      types of servers own the names in different parts of the namespace (see
      DCE Cell Namespace in the DCE for OS/2 Warp: Administration Guide.
      Typically, there are two high-level, or global, domains to a DCE
      namespace: the GDS namespace and the Domain Name Service (DNS) namespace.
      At the next level is the CDS namespace, with names contained in the
      cell's CDS Server. A DCE environment always contains a cell namespace,
      which is implemented by CDS. Parts of the DCE namespace can be contained
      in any of the Directory Services; for example, the DFS namespace, also
      called the filespace, contains the names of files and directories in DFS,
      and the Security namespace contains principals and groups contained in
      the Security Server.

      The term DCE namespace is used when referring to names, but not the
      information associated with them. For example, it would include the name
      of a printer in the Directory Service, but not its associated location
      attribute, and it would include the name of a DFS file, but not its
      contents.

   o  Cell Namespace - All of the names found in a single DCE cell comprise the
      cell's namespace. This includes names managed by the cell's CDS Server
      and Security Server, names in the cell's DFS if it has one, and any other
      names that reside within a particular cell.

   o  Hierarchy - The DCE namespace is organized into a hierarchy; that is,
      each name except the global root has a parent node and can itself have
      child nodes or leaves. The leaves are called objects or entries, and in
      the CDS and DFS namespace, the nodes are called directories.

   o  Directory - The word directory has two meanings, which can be
      differentiated by their context. The first is the node of a hierarchy as
      mentioned in the previous definition. The second is a collection of
      objects managed by a directory service.

   o  Directory Service - A directory service is software that manages names
      and their associated attributes. A directory service can store
      information, be queried about information, and be requested to change
      information. DCE for OS/2 Warp 2.1 contains Cell Directory Service (CDS)
      and interacts with DNS and GDS (which are not part of this release).

   o  Junction - A junction is a point in the DCE namespace where two domains
      meet. For example, the point where the DFS entries are mounted into a CDS
      namespace is a junction. DCE also has junctions between the global
      directory services and CDS, and between CDS and the Security Service.

   o  Object - The word object can have two meanings, depending on the context.
      Sometimes it means an entry in a directory service. Sometimes it means a
      real object that an entry in a directory service describes, such as a
      printer. In the context of XDS/XOM, the requested data is returned to the
      application in one or more interface objects, which are data structures
      that the application can manipulate.

   o  Entry - An entry is a unit of information in a directory service. It
      consists of a name and associated attributes. For example, an entry could
      consist of the name of a printer, its capabilities, and its network
      address.

           Class   In GDS, each entry has a class associated with it. The class
                   determines what type of entry it is and what attributes can
                   be associated with it. Class is optional in CDS.

           Link    A link is one type of object class. This type of object is a
                   pointer to another object; it is similar to a soft link in a
                   UNIX file system. A CDS link is similar to a GDS alias.

   o  Attribute - If an object is like a complex data structure, then its
      attributes are analogous to the separate member fields within that
      structure. Some of an object's attributes can be of significance only to
      the directory service that manages it. With attributes such as these, a
      directory service implements objects that contain various kinds of data
      about the directory itself, thus enabling the service to organize the
      entries into a meaningful structure. For example, directory objects can
      contain attributes whose values are other directory objects (called child
      directories or subdirectories) in the directory. Or link objects can
      contain attributes whose values are the names and internal identifiers of
      other directory entries, making a link object's entry name an alias of
      the other object to which its attributes indirectly refer.

           Type    Every attribute is characterized as being of a certain type.
                   The attribute is used to hold a certain kind of data, such
                   as a zip code or the name of a cat. Entries can also be
                   classified by type; for entries, the term used is class.

           Value   An attribute can have one or more values.

   o  Object Identifier - Directory attributes are uniquely identified by
      Object Identifiers (OIDs), which are administered by the International
      Organization for Standardization (ISO). In GDS, OIDs are also used to
      identify object classes. When it creates new attribute types, an
      application is responsible for tagging them with new, properly allocated
      OIDs (see your Directory Service administrator for OID assignments). In
      CDS, attribute types are sometimes identified by strings, which can be
      representations of OIDs. The cds_attr file contains the string to OID
      mappings.

   o  Name - A DCE name corresponds to an entry in some service participating
      in the DCE namespace, usually a directory service (see DCE Cell Namespace
      in the DCE for OS/2 Warp: Administration Guide).

           Global Name       A global name is a name that contains a path
                             through one of the global namespaces (GDS or DNS).

           Local Name        A local name is a name that uses the cell prefix
                             /.: to indicate the cell name and therefore does
                             not have a specific path through a global
                             namespace. The entry for a local name is always
                             contained in the local cell.

   o  Access Control List - Access to DCE namespace entries is determined by
      lists of entities that are attached through the DCE Security Service to
      both the entries and the objects when they are created. The lists, called
      Access Control Lists (ACLs), specify the privileges that an entity or
      group of entities has for the entry the ACL is associated with. The DCE
      Security Service provides servers with authenticated identification of
      every entity that contacts them; it is then the server's responsibility
      to check the ACL attached to the object that the potential client wants
      to access, and perform or refuse to perform the requested operation on
      the basis of what it finds there. The ACLs are checked using Security
      Service library routines.

      Objects in the GDS namespace have ACLs associated with them, but they are
      not DCE Security Service ACLs.

   o  Replication - The DCE Directory Service can keep replicas (copies) of its
      data on different servers. This means that if one server is unavailable,
      clients can still obtain information from another server.

   o  Caching - The CDS component of the DCE Directory Service supports caching
      of data on the client machine. When a client requests a piece of data
      from the Directory Service for the first time, the information must be
      obtained over the network from a server. However, the data can then be
      cached (stored) on the local machine, and subsequent requests for the
      same data can be satisfied more quickly by looking in the local cache
      instead of sending a request over the network. Programmers need to be
      aware of caching because in some cases you will want to bypass the cache
      to ensure that the data you obtain is as up-to-date as possible.


ΓòÉΓòÉΓòÉ 3.4. Structure of DCE Names ΓòÉΓòÉΓòÉ

The following sections describe the structure of the names found in a DCE
environment. DCE names can consist of several different parts, which reflect
the federated nature of the DCE namespace. A DCE name has some combination of
the following elements. They must occur in this order, but most elements are
optional.

   o  Prefix
   o  GDS cell name or DNS cell name
   o  GDS name or CDS name
   o  Junction
   o  Application name

 A DCE name can be represented by a string that is a readable description of a
 specific entry in the DCE namespace. The name is a string consisting of a
 series of elements separated by slashes (/). The elements are read from left
 to right. Each consecutive element adds further specificity to the entry being
 described, until finally one arrives at the rightmost element, which is the
 simple name of the entry itself. Thus, in appearance DCE names are similar to
 UNIX file names.

 In the discussion that follows, a DCE name element is the single piece of a
 name string enclosed between a consecutive pair of slashes. For example, in
 the following string:

  /.../C=US/O=OSF/OU=DCE/hosts/abc/self

 the substring O=OSF is an element and so is abc.

 The entire name contains (counting the ... element) a total of seven elements.

 In GDS, an element is called a Relative Distinguished Name (RDN) and the
 entire name is called a Distinguished Name (DN). In the preceding example, the
 attribute type O stands for the Organization type OID, which is 2.5.4.10.


ΓòÉΓòÉΓòÉ 3.4.1. DCE Name Prefixes ΓòÉΓòÉΓòÉ

The leftmost element of any valid DCE name is a root prefix. The appearance and
meaning of each is as follows:

 /...   This is the global root. It signifies that the immediately following
        elements form the name of a global namespace entry. Usually, the
        entry's contents consist of binding information for a DCE cell (more
        specifically, for some CDS server in the cell), and the name of the
        global entry is the name of the cell.

 /.:    This is the cell root. It is an alias for the global prefix plus the
        name of the local cell; that is, the cell in which the prefix is being
        used. It signifies that the immediately following elements taken
        together form the name of a cell namespace entry.

 /:     This is the filespace root. It is an alias for the global prefix, the
        name of the local cell, and the DFS junction.

 DCE also supports a junction into the Security Service namespace, but there is
 no alias for this junction.

 A prefix by itself is a valid DCE name. For example, you can list the contents
 of the /.: directory to see the top-level entries in the CDS namespace, and
 you can use a file system command to list the contents of the /: directory to
 see the top-level entries in the filespace.


ΓòÉΓòÉΓòÉ 3.4.2. Names of Cells ΓòÉΓòÉΓòÉ

After the global root prefix, the next section of a DCE name contains the name
of the cell in which the object's name resides. The name of a cell can be
expressed as either a GDS name or a DNS name, depending on which global
directory service (GDS or DNS) the cell is registered in. The following
sections provide examples.


ΓòÉΓòÉΓòÉ 3.4.2.1. GDS Cell Names ΓòÉΓòÉΓòÉ

GDS elements always consist of a substring in which an abbreviation or acronym
in capital letters is followed by an equal sign (=), which is followed by a
string value. These substrings represent pairs of attribute types and attribute
values. See Programming in the CDS Namespace for more information.

For example, in the global DCE name

/.../C=DE/O=SNI/OU=DCE/subsys/druecker/docs

the attribute = value form of the leftmost elements after the /... indicates
that the global part of the name is a GDS namespace entry, and that it ends
after the OU=DCE element; therefore, the rest of the name is in the
/.../C=DE/O=SNI/OU=DCE cell.


ΓòÉΓòÉΓòÉ 3.4.2.2. DNS Cell Names ΓòÉΓòÉΓòÉ

If DNS is used as the global directory, a global name has a form like the
following:

/.../cs.univ.edu/subsys/printers/docs

where the single element

cs.univ.edu

is the cell name; that is, the cell's name in the DNS namespace. The DNS name
consists of up to four domain names (depending on the name assigned to the
cell), separated by dots.


ΓòÉΓòÉΓòÉ 3.4.2.3. Discovering Your Local Cell's Name ΓòÉΓòÉΓòÉ

A DCE cell consists of the machines that are configured into it; each DCE
machine belongs to one DCE cell. Your local cell is therefore the cell to which
the machine you are using belongs. Depending on the DCE name you are using, you
can access your own cell or other (foreign) cells. If the name you are
accessing is global, then its cell is explicitly named. If the name begins with
the local cell prefix, then you are accessing a name within your local cell.
You can find out what cell you are in by calling the dce_cf_get_cell_name
function.

Using the global directory services, applications can access resources and
services in foreign cells; however, applications most frequently use resources
from their local cell. If this is not the case, the cell boundaries can not
have been well chosen.


ΓòÉΓòÉΓòÉ 3.4.3. CDS Names ΓòÉΓòÉΓòÉ

After the cell name or cell root prefix, the next part of a DCE name is often a
CDS name. For example, in the name /.../C=DE/O=SNI/OU=DCE/subsys/druecker/docs,
the CDS part is /subsys/druecker/docs. Or, in the name
/.../cs.univ.edu/subsys/printers/docs, the CDS part is /subsys/printers/docs.

The following strings show equivalent names using the cell root prefix,
assuming that the name is used from within the /.../C=DE/O=SNI/OU=DCE and
/.../cs.univ.edu cells, respectively:

/.:/subsys/druecker/docs
/.:/subsys/printers/docs


ΓòÉΓòÉΓòÉ 3.4.4. GDS Names ΓòÉΓòÉΓòÉ

Some names fall entirely in the GDS namespace. These names are pure X.500 (and
therefore GDS) names, because each element consists of a type and an attribute.
The entries for these names are contained in a GDS server. The following is an
example of a pure GDS name:

/.../C=US/L=Cambridge/CN=Kilroy


ΓòÉΓòÉΓòÉ 3.4.5. Junctions in DCE Names ΓòÉΓòÉΓòÉ

Some junctions are implied in a DCE name; others can be seen. There is an
implied junction between the global prefix and either GDS or DNS. It occurs
after the global prefix. The junction between either of the global namespaces
and the local cell namespace is also implied. It occurs after the cell name.
The junction between the local cell namespace and either the DFS namespace or
the security namespace is shown by the symbol /fs or /sec, respectively. The
following are examples of visible junctions in DCE names:

/.:/fs/usr/snowpaws
/.../dce.osf.org/sec/principal/ziggy


ΓòÉΓòÉΓòÉ 3.5. Application Names ΓòÉΓòÉΓòÉ

The part of a DCE name that occurs after a junction into a DCE application is
the application name. DFS and Security names are the currently supported
examples; in the future, application programmers might also be able to create
junctions in the namespace.

DFS names occur after the DFS junction. They are typeless and resemble UNIX
file system names. After the global and CDS parts of a DFS name have been
resolved by the appropriate directory services, the rest of the DFS name is
handled within the Distributed File Service. In the equivalent examples that
follow, /usr/snowpaws is the DFS part of the DCE name:

/.../dce.osf.org/fs/usr/snowpaws
/.:/fs/usr/snowpaws
/:/usr/snowpaws

Security names are similar to DFS names; first the parts of the name within the
DCE Directory Service are resolved, then the rest of the name is handled by the
Security Service. The entry is contained in the Security registry database. In
the following example:

/.:/sec/principal/ziggy

the Security part of the DCE name is /principal/ziggy.


ΓòÉΓòÉΓòÉ 3.6. The Federated DCE Namespace ΓòÉΓòÉΓòÉ

The DCE namespace is a single hierarchy of names, but the names can be
contained in many different services. Because several services cooperate to
make the DCE namespace, it is a federated namespace.

"A Federated DCE Namespace" shows a typical DCE namespace and the different
services in which names reside.


A Federated DCE Namespace


ΓòÉΓòÉΓòÉ 3.6.1. The GDS Namespace ΓòÉΓòÉΓòÉ

This section provides a brief overview of the main characteristics of the GDS
namespace regarded apart from the XDS interface used to access it.

In a GDS name such as /.../C=US/O=OSF/OU=DCE, the C=US and O=OSF elements do
not refer to directory entries that are fundamentally different from the one
represented by OU=DCE, unlike in CDS or the UNIX file system.

Thus, in the name string

/C=US/O=OSF/OU=DCE

the element C=US refers to a one-level-down Country entry whose value is US,
then to a two-levels-down Organization entry whose value is OSF, and then to a
three-levels-down Organization Unit entry whose value is DCE. Concatenating
these elements results in a valid path of entries from the directory root to
the DCE entry. The entry itself is the namespace sign to a GDS directory object
that contains binding information for the /.../C=US/O=OSF/OU=DCE cell.

"GDS Namespace Entries and Directory Objects" shows what a part of the DCE
global namespace could look like.


GDS Namespace Entries and Directory Objects

Levels in the tree of entries are numbered; the global root is at Level 0. The
GDS structure rules define what is allowed at each level. The structure rules
for the above figure show only country name entries at the next level under the
root; organization name and locality name entries can exist at the level below
a country name. An organizational unit name can be a child of an organizational
name entry, and a common name can be a child of a locality name.

The object entry /C=US/O=OSF/OU=DCE belongs to the Organizational Unit class.
One of the object's values is the CDS server binding information that is used
to reach the cell from other DCE cells. The entire name is an attribute of the
object that it refers to, as is the CDS server binding information that it
contains.


ΓòÉΓòÉΓòÉ 3.6.1.1. The GDS Schema ΓòÉΓòÉΓòÉ

The schema defines the shape and format of entries in the GDS directory. It
contains four types of rules, which describe the following:

   o  The legal hierarchy of entries. What entries can be subordinate of other
      entries. These rules are what prevents, for example, countries from being
      subordinate to states.

   o  The allowable object classes, the mandatory and optional attributes of
      entries, and which attributes are the naming attributes.

   o  The allowable attribute types, associating a unique OID and an attribute
      syntax with each attribute type.

   o  The syntaxes of attributes that describe what attribute values look like,
      such as strings, numbers, or OIDs.

 By installing the proper schema, an entry of any particular object class can
 have the two attributes needed to identify a cell.


ΓòÉΓòÉΓòÉ 3.6.2. The CDS Namespace ΓòÉΓòÉΓòÉ

The CDS namespace is the part of the DCE namespace that resides in the local
cell's CDS. DCE itself is made up of components that, like the applications
that use them, are distributed client/server applications. These components
rely on the Cell Directory Service to make themselves available as services to
DCE applications. This requires that the structure of the cell namespace be
stable, known, and have parts that are not alterable by casual users or
applications.


ΓòÉΓòÉΓòÉ 3.6.2.1. The CDS Schema ΓòÉΓòÉΓòÉ

The cell namespace hierarchy model is different from the GDS model, and the CDS
rules do not enforce any particular model; CDS allows entries containing any
kind of data to be created anywhere in the namespace. Thus, CDS offers a
free-form namespace in which entries and directories can be organized as
desired, and in which any entry or directory can contain any attributes. The
CDS administrator can create additional directories, and applications can add
name entries as needed; applications cannot create CDS directory entries.
Because of this, and because the cell namespace is so important to the
operation of the cell, application developers and system administrators have
more responsibility in planning and regulating their use of it.

The cell namespace has a structure similar to that of a UNIX file system. The
CDS namespace is a tree of entries that grows from the root downward. The name
entries are organized under directory entries, which can themselves be
subentries of other directories. The cell root (represented by the prefix /.: )
can be thought of as the location you get when you dereference the cell's
global name. New directories and new entries within the directories can be
added anywhere in the tree, subject to the restrictions mentioned previously.


ΓòÉΓòÉΓòÉ 3.6.2.2. CDS Entries and CDS Attributes ΓòÉΓòÉΓòÉ

There are three different kinds of CDS entries that are of significance to
application programmers:

   o  Object
   o  Soft link
   o  Directory

 The object entries are the most primitive form. These are where data is
 stored. Directory entries contain other entries (that is, can have children)
 just like UNIX file system directories. Soft link entries are essentially
 alias names for other directory or object entries. Only object entries and
 soft links can be created by applications; directories must be created and
 manipulated with the cdscp command.

 Thus, any CDS entry is defined as a directory, a soft link, or an object entry
 by the presence of a certain combination of attributes belonging to that kind
 of entry. You can use the cdscp command to get a display of all the attributes
 of any CDS entry.

 The term attribute as applied to namespace entry objects has roughly the same
 meaning in CDS and GDS. The main difference is that CDS does not restrict or
 control the combinations of attributes attached to entries written in its
 namespace.


ΓòÉΓòÉΓòÉ 3.7. Programming Interfaces to the DCE Directory Service ΓòÉΓòÉΓòÉ

Two sections that describe programming interfaces for accessing the DCE
Directory Service are:

   o  The X/Open Directory Service Interface
   o  The RPC Name Service Interface

 For information about programming interfaces to names that occur in namespace
 junctions, see the documentation for the component.


ΓòÉΓòÉΓòÉ 3.7.1. The X/Open Directory Service Interface ΓòÉΓòÉΓòÉ

The main programming interface to all services within the DCE Directory Service
is XDS/XOM, as defined by X/Open. The calls correspond to the X.500 service
requests, including Read, List (enumerate children), Search, Add Entry, Modify
Entry, Modify RDN, and Remove Entry. XDS uses XOM to define and manipulate data
structures (called objects) used as the parameters to these calls, and used to
describe the directory entries manipulated by the calls. XOM is extremely
flexible, but also somewhat complex. The interfaces are used in different ways,
depending on which underlying directory service is being addressed. For
example, CDS entries are typeless, but GDS entries are typed. This difference
is reflected in the use of the interface.


ΓòÉΓòÉΓòÉ 3.7.2. The RPC Name Service Interface ΓòÉΓòÉΓòÉ

The DCE Remote Procedure Call facility supports an interface to the Directory
Service that is specific to RPC and is layered on top of DCE Directory Service
interfaces; it is called the Name Service Independent (NSI) interface. NSI can
manipulate three object classes - entries, groups, and profiles (which were
created to store RPC binding information). NSI data is stored in CDS.


ΓòÉΓòÉΓòÉ 4. Programming in the CDS Namespace ΓòÉΓòÉΓòÉ

This section provides information about writing applications that use the
XDS/XOM interface to access the portion of the DCE namespace contained in the
Cell Directory Service.

The XDS/XOM interface provides generalized access to CDS.

If you only need to use CDS to store information related to RPC (for example,
storing the location of a server so that clients can find it), you should use
the Name Service Independent (NSI) interface of DCE RPC. NSI implements
RPC-specific use of the namespace. For information on using RPC NSI, see DCE
for OS/2 Warp: Application Development Guide - Core Components.

For information on the details of accessing the CDS namespace through the
XDS/XOM interface, see XDS and the DCE Cell Namespace.


ΓòÉΓòÉΓòÉ 4.1. Initial Cell Namespace Organization ΓòÉΓòÉΓòÉ

The following sections describe the organization of a cell's namespace after it
has initially been configured. For more information on configuring a cell, see
the DCE for OS/2 Warp: Administration Guide.

Every DCE cell is set up at configuration with the basic namespace structure
necessary for the other DCE components to be able to find each other and to be
accessible to applications. The vital parts of the namespace are protected from
being accessed by unauthorized entities by Access Control Lists (ACLs) that are
attached to the entries and directories.

"The Cell Namespace After Configuration" shows what the cell namespace looks
like after a cell has been configured and before any additional directories or
entries have been added to it by system administrators or applications. In the
figure, ovals represent directories, rectangles represent simple entries,
circles represent soft links, and triangles represent namespace junctions.


The Cell Namespace After Configuration

The following sections describe the organization of a cell's namespace after it
has initially been configured. For more information on configuring a cell, see
the DCE for OS/2 Warp: Administration Guide.

All of the simple entries shown in the figure are created for use with RPC NSI
routines; that is, they all contain server-binding information and exist to
enable clients to find servers. These are referred to as RPC entries.

Note:  Only the name entries (those in boxes) and junction entries (those in
       triangles) are RPC entries. The directories (entries indicated by ovals)
       are normal CDS directories.

 Some of the namespace entries in the figure are intended to be used (if
 desired) directly by applications (namely, /.:/cell-profile, /.:/lan-profile,
 and, through the /: soft link alias, /.:/fs). The self and profile name
 entries under hosts also fall into this category. Others, such as those under
 /.:/subsys/dce, are for the internal use of the DCE components themselves.

 Each of the entries is explained in detail in the sections:

   o  The Cell Profile
   o  LAN Profile
   o  The CDS Clearinghouse
   o  Hosts Directory
   o  Subsystems Directory
   o  The /: DFS Alias
   o  The DFS and Security Service Junctions

 See the DCE for OS/2 Warp: Administration Guide for detailed information on
 the contents of the initial DCE cell namespace.


ΓòÉΓòÉΓòÉ 4.1.1. The Cell Profile ΓòÉΓòÉΓòÉ

The /.:/cell-profile entry is an RPC profile entry that contains the default
list of namespace entries to be searched by clients trying to bind to certain
basic services. An RPC profile is a class of namespace entry used by the RPC
NSI routines. When a client imports bindings from such an entry, it imports,
through the profile, from an ordered list of RPC entries containing appropriate
bindings. The list of entries is keyed by their interface UUIDs so that only
bindings to servers offering the interface sought by the client are returned.
The entries listed in the profile exist independently in the namespace, and can
be separately accessed in the normal way. The profile is simply a way of
organizing clients' searches.

The main purpose of cell-profile is to have a path of last resort for
prospective clients. All other profile entries in the cell namespace are
required to have the cell-profile entry in their entry lists so that if a
client exhausts a particular profile's list of entries, it tries the entries in
cell-profile.


ΓòÉΓòÉΓòÉ 4.1.2. LAN Profile ΓòÉΓòÉΓòÉ

/.:/lan-profile is a LAN-oriented default list of services' namespace entries,
for use when servers' relative positions in the network topography are of
importance to their prospective clients.


ΓòÉΓòÉΓòÉ 4.1.3. The CDS Clearinghouse ΓòÉΓòÉΓòÉ

The /.:/cdshostname_ch entry is the namespace entry for cdshostname's
clearinghouse, where cdshostname is the name of the host machine on which a CDS
server is installed.

A clearinghouse is the database managed by a CDS server; it is where CDS
directory replicas are physically stored. For more information about
clearinghouses, see the DCE for OS/2 Warp: Administration Guide. All
clearinghouse namespace entries reside at the cell root, and there must be at
least one in a DCE cell. The first clearinghouse's name must be in the form
shown in the previous figure, but additional clearinghouses can be named as
desired.


ΓòÉΓòÉΓòÉ 4.1.4. Hosts Directory ΓòÉΓòÉΓòÉ

The /.:/hosts entry is a directory containing entries for all of the host
machines in the cell. Each host has a separate directory under hosts; its
directory has the same name as the host. Four entries are created in each
host's directory:

   o  self - This entry contains bindings to the host's RPC daemon (rpcd, also
      called the endpoint mapper), which is responsible for dynamically
      resolving the partial bindings that it receives in incoming RPCs from
      clients attempting to reach servers resident on this host.

   o  profile - This entry is the default profile entry for the host. This
      profile contains in its list of entries at least the /.:/cell-profile
      entry described in The Cell Profile.

   o  cds-clerk - This entry contains bindings to the host's resident CDS
      clerk.

   o  cds-server - This entry contains bindings to a CDS server.


ΓòÉΓòÉΓòÉ 4.1.5. Subsystems Directory ΓòÉΓòÉΓòÉ

The /.:/subsys entry is the directory for subsystems. Subdirectories below
subsys are used to hold entries that contain location-independent information
about services, particularly RPC binding information for servers.

The dce directory is created below /.:/subsys at configuration. This directory
contains directories for the DCE Security Service and Distributed File Service
components. The functional difference between these two directories and the fs
and sec junctions described in The DFS and Security Service Junctions is that
the latter two entries are the access points for the components' special
databases, whereas the directories under subsys/dce contain the services'
binding information.

Subsystems that are added to DCE should place their system names in directories
created beneath the /.:/subsys directory.

Companies adding subsystems should conform to the convention of creating a
unique directory below subsys by using their trademark as a directory name. Use
these directories for storage of location independent information about
services. You should store server entries, groups and profiles for the entire
cell in the directories below subsys. For example, International Air
Freight-supplied subsystems should be placed in /.:subsys/IAF.


ΓòÉΓòÉΓòÉ 4.1.6. The /: DFS Alias ΓòÉΓòÉΓòÉ

The entry /: is created and set up as a soft link to the /.:/fs entry, which is
the DFS database junction. The name /: is equivalent to /.:/fs. Note, however,
that the name /: is well-known, whereas the name /.:/fs is not, so using /:
makes an application more portable. A CDS soft link entry is an alias to some
other CDS entry. A soft link is created through the cdscp command. The
procedure is described in the DCE for OS/2 Warp: Administration Guide.


ΓòÉΓòÉΓòÉ 4.1.7. The DFS and Security Service Junctions ΓòÉΓòÉΓòÉ

The /.:/fs entry is the Distributed File Service junction entry. This is the
entry for a server that manages the DFS file location database.

The /.:/sec entry is the DCE Security Service junction entry. This is the entry
for a server that manages the Security Service database (also called the
registry database).

The /.:/fs and /.:/sec root entries in "The Cell Namespace After Configuration"
are junctions maintained by DCE components. The /.:/sec junction is the DCE
Security Service's namespace of principal identities and related information.
The Distributed File Service's fileset location servers are reached through the
/.:/fs entry, making /.:/fs effectively the entry point into the cell's
distributed file system.

Note:  The /.:/sec and /.:/fs are both actually RPC group entries (for
       definitions of the RPC entry types, see DCE for OS/2 Warp: Application
       Development Reference); the junctions are implemented by the servers
       whose entries are members of the group entries.

 See the DCE for OS/2 Warp: Administration Guide for further details on the
 Security Service and DFS junctions.


ΓòÉΓòÉΓòÉ 4.2. Recommended Use of the CDS Namespace ΓòÉΓòÉΓòÉ

CDS data is maintained in a loosely consistent manner. This means that when the
writeable copy of a replicated name is updated, the read/only copies cannot be
updated for some period of time, and applications reading from those
nonsynchronized copies can receive stale data. This is in contrast to
distributed databases, which use multiphase commit protocols that prevent
readers from accessing potentially stale or inconsistent data while the writes
are being propagated to all copies of the data. It is possible to specifically
request data from the master copy, which is guaranteed to be up-to-date, but
replication advantages are then lost. This should only be done when it is
important to obtain current data.


ΓòÉΓòÉΓòÉ 4.2.1. Storing Data in CDS Entries ΓòÉΓòÉΓòÉ

Some CDS entries can contain information that is immediately useful or
meaningful to applications. Other entries can contain RPC information that
enables application clients to reach application servers; that is, binding
handles for servers, which are stored and retrieved using the RPC NSI routines.
In either case, the entry's name should be a meaningful identification label
for the information that the entry contains. This is because the namespace
entry names are the main clue that users and applications have to the available
set of resources in the DCE cell. Using the CDS namespace to store and retrieve
binding information for distributed applications is the function of DCE RPC
NSI.

In general, applications can store data into CDS object entry attributes in any
XDS-expressible form they wish. The section Attribute and Data Type Translation
shows XDS-to-CDS data type translations.

If you add new attributes to the \opt\dcelocal\etc\cds_attr file, together with
a meaningful CDS syntax (that is, a data type identifier) and name, then the
attribute is displayed with the string representation of the OID by cdscp show
commands when executed on objects containing instances of that attribute. If
the attribute has not been added to cds_attr, then the OID is displayed. There
are three main questions to consider when using CDS to store data through
application calls to XDS:

   1. Where in the CDS namespace should the new entries be placed?

      You are free to create new directories as long as you do not disturb the
      namespace's configured structure. Keep in mind that CDS directories must
      be created with the cdscp command; they cannot be created by
      applications.

      Only two root-level directories are created at configuration: hosts and
      subsys. Applications should not add entries under the hosts tree; the
      host's default profile should instead be set up by a system
      administrator. The subsys directory is intended to be populated by
      directories (for example, /.:/subsys/dce) in which the servers and other
      components of independent vendors' distributed products are accessed.
      Thus, the typical cell should usually have a series of root-level CDS
      directories that represent a reasonable division of categories.

      One obvious division could be between entries intended for RPC use (that
      is, namespace entries that contain bindings for distributed
      applications), and entries that contain data of other kinds. On the other
      hand, it can be very useful to add supplementary data attributes to RPC
      entries in which various housekeeping or administrative data can be held.
      In this way, for example, performance data for printers can be associated
      with the print servers' name entries. You can either add new attributes
      to the server entries themselves, where, for example,

            /.:/applications/printers/pr1

      is the name of a server entry that receives the new attributes. Or you
      can change the subtree structure so that new entries are added to hold
      the data, the server bindings are still held in separate wholly RPC
      entries, and each group of entries is located under a directory named for
      the printer:

            /.:/applications/printers/pr1 -directory
            /.:/applications/printers/pr1/server -server bindings
            /.:/applications/printers/pr1/stats -extra data

      In general, the same principals of logic and order that apply to the
      organization of a file system apply to the organization of a namespace.
      For example, server entries should not be created directly at the
      namespace root because this is the place for default profiles,
      clearinghouse entries, and directories.

      "A Possible Namespace Structure" illustrates some of the preceding
      suggestions, added to the initial configuration namespace structure shown
      in the "The Cell Namespace After Configuration".


            A Possible Namespace Structure

      In "A Possible Namespace Structure", the vendor of the xyz subsystem has
      set up an xyz directory under /.:/subsys in which the system's servers
      are exported. This cell also has an /.:/applications directory in which
      the printers directory contains separate directories for each installed
      printer available on the system; the directory for pr1 is illustrated in
      the figure. In the pr1 directory, server is an RPC entry containing
      exported binding handles, and stats is an entry created and maintained
      through the XDS interface.

   2. How should the entries be constructed?

      Because CDS allows you to add as many attributes as you wish to an object
      entry, it is up to you to impose some restraint in doing this. In view of
      the XDS overhead involved in reading and writing single CDS attributes,
      it makes sense to combine multiple related attributes under single
      entries (that is, in the same directory object) where they can be read
      and written in single calls to ds_read or ds_modify_entry. This way, for
      example, you only have to create one interface input object (to pass to
      ds_read) to read all the attributes, which you can do with one call to
      ds_read. You can then separate out the returned subobjects that you are
      interested in and ignore the rest. XDS and the DCE Cell Namespace
      contains detailed discussions of XDS programming techniques.

      In any case, you should define object types for use in applications so
      that namespace access operations can be standardized and kept efficient.
      A CDS object type consists of a specific set of attributes that belong to
      an object of that type, with no other attributes allowed. Note again that
      CDS, unlike GDS, does not force you to do things this way. You could
      theoretically have hundreds of CDS object entries, each of which would
      contain a different combination of attributes.

   3. Should a directory or an entry be created?

      When you consider adding information to the namespace, you can choose
      between creating a new directory, possibly with entries in it, or
      creating simply one or more entries. When making your decision, take into
      consideration the following:

        a. Directories cannot be created using XDS; they must be created using
           administrative commands.

        b. Directories are more expensive; they take up more space and take
           more time to access. However, they can contain entries and can
           therefore be used to organize information in the namespace.

        c. Entries can be created using XDS and they are cheaper to create and
           use than directories. Entries are cheaper to create and use than
           directories. However, they must be created in existing directories,
           and cannot themselves contain other entries.


ΓòÉΓòÉΓòÉ 4.2.2. Access Control for CDS Entries ΓòÉΓòÉΓòÉ

Each object in the CDS namespace is automatically equipped with a mechanism by
which access to it can be regulated by the object's owner or by another
authority. For each object, the mechanism is implemented by a separate list of
the entities that can access the object in some way; for example, to read it,
write to it, delete it. Associated with each entity in this list is a string
that specifies which operations are allowed for that entity on the object. The
object's list is automatically checked by CDS whenever any kind of access is
attempted on that object by any entity. If the entity can be found in the
object's list, and if the kind of access the entity intends is found among its
permissions, then the operation is allowed to proceed by CDS; otherwise, it is
not allowed.

DCE permission lists are called Access Control Lists (ACLs). ACLs are one of
the features of the DCE Security Service used by the Cell Directory Service.
ACLs are used to test the entities' (that is, the principals') authorization to
do things to the objects they propose to do them to. The authorization
mechanism for all CDS objects is handled by CDS itself. All that users of the
CDS namespace have to do is make sure that ACLs on the CDS objects that they
create are set up with the appropriate permissions.


ΓòÉΓòÉΓòÉ 4.2.2.1. Creation of ACLs ΓòÉΓòÉΓòÉ

Whenever you create a new entry in the CDS namespace, an ACL is created for it
implicitly, and its initial list of entries and their permission sets are
determined by the ACL templates associated with the CDS directory in which you
create the entry.

Each CDS directory has the following two ACL templates associated with it:

   o  Initial Container - This template is used to generate the initial ACL for
      any directories created within the directory.

   o  Initial Object - This template is used to generate ACLs for entries
      created within the directory.

 Every CDS directory also has its own ACL, just like any other CDS object. This
 ACL is generated from the parent directory's Initial Container template when
 the child directory is created. The Initial Container template also serves as
 a template for the child directories' own Initial Container templates.


ΓòÉΓòÉΓòÉ 4.2.2.2. Manipulating ACLs ΓòÉΓòÉΓòÉ

There are two ways to manipulate ACLs: either through the acl_edit command,
which is documented in the DCE for OS/2 Warp: Administration Command Reference,
or through the DCE ACL application interface, which consists of routines
documented in the DCE for OS/2 Warp: Application Development Reference. (These
routines have names in the form of sec_acl_....)


ΓòÉΓòÉΓòÉ 4.2.2.3. Initializing ACLs ΓòÉΓòÉΓòÉ

After creating a CDS directory using the cdscp command, your first step is
usually to run the acl_edit command to set up the new directory's ACLs the way
you want them. (The new directory inherits its ACLs and its templates from the
directory in which it was created, as explained in Creation of ACLs.) You might
want to modify not only the directory's own ACLs, but also its two templates.
To edit the latter, you can specify the -ic option (for the Initial Container
template) or the -io option (for the Initial Object template); otherwise, edit
the object ACL.

You can modify a directory's ACL templates from an application, assuming that
you have control permission for the object, with the same combination of
sec_acl_lookup and sec_acl_replace calls as for the object ACL. An option to
these routines lets you specify which of the three possible ACLs on a directory
object you want the call applied to. The ACLs themselves are in identical
format.

The -e (entry) option to acl_edit can be used to make sure that you get the ACL
for the specified namespace entry object, and not the ACL (if any) for the
object that is referenced by the entry. This distinction has to be made clear
to acl_edit because it finds the object (and hence the ACL) in question by
looking it up in the namespace and binding to its ACL manager. Essentially, the
-e option tells acl_edit whether it should bind to the CDS ACL manager (if the
entry ACL is wanted), or to the manager responsible for the referenced object's
ACL. This latter manager would be a part of the server application whose
binding information the entry contained.

An example of such an ambiguous name would be a CDS clearinghouse entry, such
as the cdshostname_ch entry discussed previously. With the -e option

acl_edit -e /.:/cdshostname_ch

you would edit the ACL on the namespace entry; without the -e option you would
edit the ACL on the clearinghouse itself, which you presumably do not want to
do.

Similarly, there is a bind_to_entry parameter by which the caller of
sec_acl_bind can indicate whether the entry object's ACL or the ACL to which
the entry refers is desired. For further details on binding ambiguity, see DCE
for OS/2 Warp: Application Development Reference.

Note:  You can also use the dcecp command to create CDS directories and manage
       ACLs.


ΓòÉΓòÉΓòÉ 4.2.2.4. Namespace ACLs at Cell Configuration ΓòÉΓòÉΓòÉ

The ACLs attached to the CDS namespace at configuration are described in DCE
for OS/2 Warp: Administration Guide. The following ACL permissions are defined
for CDS objects. The single letter in parentheses for each item represents the
DCE notation for that permission. These single letters are identical to the
untokenized forms returned by sec_acl_get_printstring.

 read (r)             This permission allows a principal to look up an object
                      entry and view its attribute values.

 write (w)            This permission allows a principal to change an object's
                      modifiable attributes, except for its ACLs.

 insert (i)           This permission allows a principal to create new entries
                      in a CDS directory. It is used with directory entries
                      only.

 delete (d)           This permission allows a principal to delete a name entry
                      from the namespace.

 test (t)             This permission allows a principal to test whether an
                      attribute of an object has a particular value, but does
                      not permit it actually to see any of the attribute values
                      (in other words, read permission for the object is not
                      granted). The test permission allows an application to
                      verify a particular CDS attribute's value without reading
                      it.

 control (c)          This permission allows a principal to modify the entries
                      in the object's ACL. The control permission is
                      automatically granted to the creator of a CDS object.

 administer (a)       This permission allows a principal to issue cdscp
                      commands that control the replication of directories. It
                      is used with directory entries only.

 Detailed instructions on the mechanics of setting up ACLs on CDS objects can
 be found in the DCE for OS/2 Warp: Administration Guide.

 For CDS directories, read and test permissions are sufficient to allow
 ordinary principals to access the directory and to read and test entries
 therein. Principals who you want to be able to add entries in a CDS directory
 should have insert permission for that directory. Entries created by the RPC
 NSI routines (for example, when a server exports bindings for the first time)
 are automatically set up with the correct permissions. However, if you are
 creating new CDS directories for RPC use, you should be sure to grant
 prospective user principals insert permission to the directory so that servers
 can create entries when they export their bindings. A general list of the
 permissions required for the various RPC NSI operations as well as the RPC NSI
 routines (all of whose names are in the form rpc_ns_...) can be found in the
 DCE for OS/2 Warp: Application Development Reference.

 Note:  CDS names do not behave the same way as file system names. A principal
        does not have to have access to an entire entry name path in order to
        have access to an entry at the end of that path. For example, a
        principal can be granted read access to the following entry

                /.:/applications/utilities/pr2

 and yet not have read access to the utilities directory.


ΓòÉΓòÉΓòÉ 4.3. Valid Characters and Naming Rules for CDS ΓòÉΓòÉΓòÉ

See "Valid Characters and Naming Rules for CDS" in DCE for OS/2
Warp:Administration Guide. In that same document, also see the sections that
discuss the valid character sets for DCE Directory Service names as used by CDS
Interfaces as follows:

   o  Metacharacters
   o  Additional Rules
   o  Maximum Name Sizes


ΓòÉΓòÉΓòÉ 4.4. Use of Object Identifiers ΓòÉΓòÉΓòÉ

Object Identifiers (OIDs) are not seen by applications that restrict themselves
to using only the RPC NSI routines (rpc_ns_...). These identifiers are
important for applications that use the XDS interface to read entries directly
or to create new attributes for use with namespace entries.

RPC makes use of only four different entry attributes in various
application-specified or administrator-specified combinations. CDS, however,
contains definitions for many more than these. They can be added by
applications to RPC entries through the XDS interface. Attributes that already
exist are already properly identified so applications that use these attributes
do not have to concern themselves with the OIDs, except to the extent of making
sure that they handle them properly.

Unlike UUIDs, OIDs are not generated by command or function call. They
originate from the International Organization for Standardization (ISO), which
allocates them in hierarchically organized blocks to recipients. Each
recipient, typically some organization, is then responsible for ensuring that
the OIDs it receives are used uniquely.

For example, the OID block 1.3.22 was allocated to OSF by ISO. OSF can now
generate, for example, the OID 1.3.22.1.1.4 and allocate it to identify some
DCE directory object. (The OID 1.3.22.1.1.4 identifies the RPC profile entry
object attribute.) OSF is responsible for making sure that 1.3.22.1.1.4 is not
used to identify any other attribute. Thus, as long as all OIDs are generated
only from within each owner's properly obtained block, and as long as each
block owner makes sure that the OIDs generated within its block are properly
used, each OID is a universally valid identifier for its associated value.

OIDs are encoded and internally represented as strings of hexadecimal digits,
and comparisons of OIDs have to be performed as hexadecimal string comparisons
(not as comparisons on NULL-terminated strings because OIDs can have NULL bytes
as part of their value).

When applications have occasion to handle OIDs, they do so directly because the
numbers do not change and should not be reused. However, for users'
convenience, CDS also maintains a file (called cds_attr, found in
\opt\dcelocal\etc) that lists string equivalents for all the OIDs in use in a
cell in entries like the following one:

1.3.22.1.1.4        RPC_Profile        byte

This allows users to see RPC_Profile in output, rather than the meaningless
string 2.1.3.22.1.1.4. Further details about the cds_attr file and OIDs can be
found in the DCE for OS/2 Warp: Administration Guide.

In summary, the procedure you should follow to create new attributes on CDS
entries consists of the following steps:

   1. Request and receive from your local designated authority the OIDs for the
      attributes you intend to create.

   2. Update the cds_attr file with the new attributes. OIDs and labels if you
      want your application to be able to use string name representations for
      OIDs in output.

   3. Using XDS, write the routines to create, add, and access the attributes.

 Note:  The XDS interface does not look at the cds_attr file; therefore,
        entries cannot be referenced by the string name. You must use the
        actual OID or define the OID in a header file used by the application.

 Your cell administrator should be able to provide you with a name and an OID.
 The name is a guaranteed-unique series of values for a global directory entry
 name. If the directory is GDS, the name is a series of type/value pairs, such
 as C=US O=OSF.

 The cell administrator can also obtain an OID block. From this OID space, the
 administrator can assign you the OIDs you need for your application.

 There is no need for new OIDs in connection with cell names. The OIDs for
 Country Name and Organization Name are part of the X.500 standard implemented
 in GDS; only the values associated with the OIDs (the values of the objects)
 change from entry name to entry name. Instead, being able to generate new OIDs
 gives you the ability to invent and add new details to the directory itself.
 For example, you can create new kinds of CDS entry attributes by generating
 new OIDs to identify them. The same thing can be done to GDS, although the
 procedure is more complicated because it involves altering the directory
 schema.


ΓòÉΓòÉΓòÉ 5. XDS and the DCE Cell Namespace ΓòÉΓòÉΓòÉ

This section describes the use of the XDS programming interface when accessing
the CDS namespace. Introduction to Accessing CDS with XDS provides an
introduction to using XDS in the CDS namespace. XDS Objects describes XDS
objects and how they are used to access CDS data. Accessing CDS Using the XDS
Step-by-Step Procedure provides a step-by-step procedure for writing an XDS
program to access CDS. Object-Handling Techniques provides examples of using
the XOM interface to manipulate objects. XDS/CDS Object Recipes provides
details of the structure of XDS/CDS objects. Finally, Attribute and Data Type
Translation provides translation tables between XDS and CDS for attributes and
data types.


ΓòÉΓòÉΓòÉ 5.1. Introduction to Accessing CDS with XDS ΓòÉΓòÉΓòÉ

Outside of the DCE cells and their separate namespaces is the global namespace
in which the cell names themselves are entered, and where all intercell
references are resolved. Two directory services participate in the global
namespace. The first is the X.500-compliant Global Directory Service (GDS). The
second is the Domain Name Service (DNS), which DCE interacts with, but is not a
part of DCE.

The global and cell directory services are accessed implicitly by RPC
applications using the NSI interface. GDS and CDS can also be accessed
explicitly using the X/Open Directory Service (XDS) interface. With XDS,
application programmers can gain access to GDS, a powerful general-purpose
distributed database service, which can be used for many other things besides
intercell binding. XDS can also be used to access the cell namespace directly,
as this section describes.

An XDS application looks very different from the RPC-based DCE applications.
This is partly because there is no dependency in XDS on the DCE RPC interface,
although you can use both interfaces in the same application. Also, XDS is a
generalized directory interface, oriented more toward performing large database
operations than toward fine-tuning the contents of RPC entries. Nevertheless,
XDS can be used as a general access mechanism on the CDS namespace.


ΓòÉΓòÉΓòÉ 5.1.1. Using the Reference Material in this Section ΓòÉΓòÉΓòÉ

Complete descriptions of all the XDS and XOM functions used in CDS operations
can be found in the DCE for OS/2 Warp: Application Development Reference, which
you should have beside you as you read through the examples in this section. In
particular, refer to it for information about XDS error objects, which are not
discussed in this section.

Complete descriptions for all objects required as input parameters by XDS
functions when accessing a CDS namespace can be found in XDS/CDS Object
Recipes. XOM functions are general-purpose utility routines that operate on
objects of any class, and take the rest of their input in conventional form.

Slightly less detailed descriptions of the output objects you can expect to
receive when accessing CDS through XDS are also given in XDS/CDS Object
Recipes. You do not have to construct objects of these classes yourself. You
just have to know their general structure so that you can disassemble them
using XOM routines.

No information is given in this section about the DS_status error objects that
are returned by unsuccessful XDS functions. A description of all the subclasses
of DS_status requires a section in itself. Code for a rudimentary
general-purpose DS_status handling routine can be found in the cds_xmpl.c XDS
sample program.


ΓòÉΓòÉΓòÉ 5.1.2. What You Cannot Do with XDS ΓòÉΓòÉΓòÉ

XDS allows you to perform general operations on CDS entry attributes, something
which you cannot do through the DCE RPC NSI interface. However, there are
certain things you cannot do to cell directory entries even through XDS:

   o  You cannot create or modify directory entries.

      The ds_modify_rdn function does not work in a CDS namespace. These
      operations must be performed through the CDS cdscp command. For more
      information, see the DCE for OS/2 Warp: Administration Command Reference.

   o  You cannot perform XDS searches on the cell namespace

      The XDS function ds_search does not work. This is mainly because the CDS
      has no concept of a hierarchy of entry attributes, such as the X.500
      schema. The ds_compare function, however, does work.

   o  You cannot modify ACL entries in the cell namespace.


ΓòÉΓòÉΓòÉ 5.1.3. What Must Be Set Up ΓòÉΓòÉΓòÉ

If you are planning to use XDS to access the cell namespace in a one-cell
environment (that is, your cell does not need to communicate with other DCE
cells), you do not need to set up a cell entry in GDS or DNS for your cell
because the XDS functions simply call the appropriate statically linked CDS
routines to access the cell namespace. XDS, in conjunction with CDS, is able to
recognize the local cell portion of a name in the cell namespace without help
from GDS or DNS. You need to specify the complete name for the interface object
DS_C_DS_DN; omitting the cell name portion of the name is not allowed. See a
description of the DS_C_DS_DN object in Building a Name Object.

For XDS to be able to access any nonlocal cell namespace, that cell must be
registered (that is, have an entry) in the global namespace.

For information on setting up your cell name, see the DCE for OS/2
Warp:Administration Guide.


ΓòÉΓòÉΓòÉ 5.2. XDS Objects ΓòÉΓòÉΓòÉ

The XDS interface differs from the other DCE component interfaces in that it is
object oriented. The following sections explain two things:

   1. What object-oriented programming means in terms of using XDS.

   2. How to use XDS to access the Cell Directory Service.

 Imagine a generalized data structure that always has the same data type and
 yet can contain any kind of data, and any amount of it. Functions could pass
 these structures back and forth in the same way all the time, and yet they
 could use the same structures for any kind of data they wanted to store or
 transfer. Such a data structure, if it existed, would be a true object.
 Programming language constructs allow interfaces to pretend that they use
 objects, although the realities of implementation are not usually so simple.

 XDS is such an interface. For the most part, XDS functions neither accept nor
 return values in any form but as objects. The objects themselves are indeed
 always the same data type; namely, pointers to arrays of object descriptor (C
 struct) elements. Contained within these, OM_descriptor element structures are
 unions that can actually accommodate all the different kinds of values an
 object can be called on to hold. In order to allow the interface to make sense
 of the unions, each OM_descriptor also contains a syntax field, which
 indicates the data type of that descriptor's union. There is also a record of
 what the descriptor's value actually is (for example, whether it is a name, a
 number, an address, a list, and so on). This information is held in the
 descriptor's type field.

 These OM_descriptor elements, which are referred to as object descriptors or
 descriptors, are the basic building blocks of all XDS objects; every actual
 XDS object reduces to arrays of them. Each descriptor contains three items:

   o  A type field, which identifies the descriptor's value;
   o  A syntax field, which indicates the data type of the value field; and
   o  The value field, which is a union.

 "One Object Descriptor" illustrates one such object descriptor.


  One Object Descriptor

 From an abstract point of view, syntax is just an implementation detail. The
 scheme really consists only of a type/value pair. The type gives an identity
 to the object (something like CDS entry attribute, CDS entry name, or DUA
 access point), and the value is some data associated with that identity, just
 as a variable has a name that gives meaning to the value it holds, and the
 value itself.

 In order to make the representation of objects as logical and as flexible as
 possible, these two logical components of every object, type and value, are
 themselves each represented by separate object descriptors. Thus, the first
 element of every complete object descriptor array is a descriptor whose type
 field identifies its value field as containing the name of the kind (or class)
 of this object, and the syntax field indicates how that name value should be
 read. Next is usually one (or more, if the object has multiple values) object
 descriptor whose type field identifies its value field as containing some
 value appropriate for this class of object. Finally, every complete object
 descriptor array ends with a descriptor element that is identified by its
 fields as being a NULL-terminating element.

 Thus, a minimum-size descriptor array consists of just two elements:

   o  The first contains its class identity, and
   o  The second is a NULL (it is legitimate for objects not to have values).

 When an object does have a value, it is held in the value field of a
 descriptor whose type field communicates the value's meaning.

 "A Complete Object Represented" illustrates the arrangement of a complete
 object descriptor array.


  A Complete Object Represented


ΓòÉΓòÉΓòÉ 5.2.1. Object Attributes ΓòÉΓòÉΓòÉ

The generic term for any object value is attribute. In this sense, an object is
nothing but a collection of attributes, and every object descriptor describes
one attribute. The first attribute's value identifies the object's class, and
this determines all the other attributes the object is supposed to have. One or
more other attributes follow, which contain the object's working values. The
NULL object descriptor at the end is an implementation detail, and is not a
part of the object.

Note:  Depending on the attribute it represents, a descriptor's value field can
       contain a pointer to another array of object descriptors. In other
       words, an object's value can be another object.

 "A Three-Layer Compound Object" shows a three-layer compound object. The
 top-level superobject, dn_object, contains the subobject rdn1, which in turn
 contains the subobject ava1.


  A Three-Layer Compound Object


ΓòÉΓòÉΓòÉ 5.2.2. Interface Objects and Directory Objects ΓòÉΓòÉΓòÉ

GDS is comprised of objects. These are directory objects and reflect the X.500
design. The XDS interface also works with objects. However, there is a big
difference between directory and XDS objects. Programmers do not work directly
with the directory objects; they are composed of attributes that make up the
directory service's implementation of entries.

Programmers work with XDS objects. XDS objects have explicit data
representations that can be directly manipulated with programming language
operators. Some of these techniques are described in this section; others can
be found in the sample files in the \opt\dcelocal\examples\xdsxom directory.

XDS and GDS terminology sometimes suggests that XDS objects are somehow direct
representations of the directory objects to which they communicate information.
This is not the case, however. You never directly see or manipulate the
directory objects; the XDS interface objects are used only to pass parameters
to the XDS calls, which in turn request GDS (or CDS) to perform operations on
the directory objects. The XDS objects are therefore somewhat arbitrary
structures defined by the interface.

"Directory Objects and XDS Interface Objects" illustrates the relationship
between XDS (also called interface) objects and directory objects. The figure
shows an application passing several properly initialized XDS objects to some
XDS function; it then takes some action, which affects the attribute contents
of certain directory objects. The application never works with the directory
objects, it works with the XDS interface objects.

A side effect of the existence of a separate XDS interface and GDS or CDS
directory objects is the existence of attributes for both kinds of objects as
well. Because the purpose of XDS objects is to feed data into and extract data
from directory objects, programmers work with XDS objects whose attributes have
directory object attributes as their values. You should keep in mind the
distinction between directory objects and interface objects.


Directory Objects and XDS Interface Objects


ΓòÉΓòÉΓòÉ 5.2.3. Directory Objects and Namespace Entries ΓòÉΓòÉΓòÉ

The GDS namespace is a hierarchical collection of entries. The name of each of
these entries is an attribute of a directory object. The object is accessed
through XDS by stating its name attribute.

"Directory Objects and Namespace Entries" shows the relationship of entry names
in the GDS namespace to the GDS directory objects to which they refer.


Directory Objects and Namespace Entries


ΓòÉΓòÉΓòÉ 5.2.4. Values That an Object Can Contain ΓòÉΓòÉΓòÉ

There are many different classes of objects defined for the XDS interface;
still more are defined by the X.500 standard for general directory use. But
only a small number of classes are needed for XDS/CDS operations, and only
those classes are discussed in this section.

The class that an object belongs to determines what sort of information the
object can contain. Each object class consists of a list of attributes that
objects must have. For example, you would expect an object in the directory
entry name class to be required to have an attribute to hold the entry name
string. However, it is not sufficient to simply place a string like:

/.../C=US/O=OSF/OU=DCE/hosts/tamburlaine/self

into an object descriptor.

A full directory entry name such as the preceding one is called in XDS a
Distinguished Name (DN), meaning that the entry name is fully qualified
(distinct) from root to entry name. To properly represent the entry name in an
object, you must look up the definition of the XDS distinguished name object
class and build an object that has the set of attributes that the definition
prescribes.


ΓòÉΓòÉΓòÉ 5.2.5. Building a Name Object ΓòÉΓòÉΓòÉ

Complete definitions for all the object classes required as input for XDS
functions can be found in XDS/CDS Object Recipes. Among them is the class for
distinguished name objects, called DS_C_DS_DN. There you will learn that this
class of object has two attributes: its class attribute, which identifies it as
a DS_C_DS_DN object, and a second attribute, which occurs multiple times in the
object. Each instance of this attribute contains as its value one piece of the
full name; for example, the directory name hosts.

The DS_C_DS_DN attribute that holds the entry name piece, or Relative
Distinguished Name, is defined by the class rules to hold, not a string, but
another object of the Relative Distinguished Name class (DS_C_DS_RDN).

Thus, a static declaration of the descriptor array representing the DS_C_DS_DN
object would look like the following:

static OM_descriptor   Full_Entry_Name_Object[]={

   OM_OID_DESC(OM_CLASS, DS_C_DS_DN),
/*                                                             */
/*   Macro to put an "OID string" in a descrip-                */
/*     tor's value field and fill the type and                 */
/*     syntax fields with appropriate values.                  */


   {DS_RDNS, OM_S_OBJECT, {0, Country_RDN}},
/*                                                             */
/*     type      syntax            value                       */
/*                                                             */
/*     (the "value" union is in fact here a                    */
/*      structure; the 0 fills a pad field in                  */
/*      that structure.)                                       */


   {DS_RDNS, OM_S_OBJECT, {0, Organization_RDN}},
   {DS_RDNS, OM_S_OBJECT, {0, Org_Unit_RDN}},
   {DS_RDNS, OM_S_OBJECT, {0, Hosts_Dir_RDN}},
   {DS_RDNS, OM_S_OBJECT, {0, Tamburlaine_Dir_RDN}},
   {DS_RDNS, OM_S_OBJECT, {0, Self_Entry_RDN}},


   OM_NULL_DESCRIPTOR
/*                                                             */
/*    Macro to fill a descriptor with proper                   */
/*     NULL values.                                            */

};

The use of the OM_OID_DESC and OM_NULL_DESCRIPTOR macros slightly obscures the
layout of this declaration. However, each line contains code to initialize
exactly one OM_descriptor object; the array consists of eight objects.

The names (such as Country_RDN) in the descriptors' value fields refer to the
other descriptor arrays, which separately represent the relative name objects.
(The order of the C declaration in the source file is opposite to the order
described here.) Since DS_C_DS_RDN objects are now called for, the next step is
to look at what attributes that class requires.

The definition for DS_C_DS_RDN can be found in The DS_C_DS_RDN Object. This
class object is defined, like DS_C_DS_DN, to have only one attribute (with the
exception of the OM_Object attribute, which is mandatory for all objects). The
one attribute, DS_AVAS, holds the value of one relative name. The syntax of
this value is OM_S_OBJECT, meaning that DS_AVAS's value is a pointer to yet
another object descriptor array:

static OM_descriptor    Country_RDN[] = {

     OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),

     {DS_AVAS, OM_S_OBJECT, {0, Country_Value}},

     OM_NULL_DESCRIPTOR
};

Note:  There should also be five other similar declarations, one for each of
       the other DS_C_DS_RDN objects held in the DS_C_DS_DN.

 The declarations have the same meanings as they did in the previous example.
 Country_Value is the name of the descriptor array that represents the object
 of class DS_C_AVA.

 The rules for the DS_C_AVA class can be found in this section just after
 DS_C_DS_RDN. They tell us that DS_C_AVA objects have two attributes aside from
 the omnipresent OM_Object; namely:

 DS_ATTRIBUTE_VALUES                 This attribute holds the object's value.

 DS_ATTRIBUTE_TYPE                   This attribute gives the meaning of the
                                     object's value.

 In this instance, the meaning of the string US is that it is a country name.
 There is a particular directory service attribute value for this. It is
 identified by an OID that is associated with the label DS_A_COUNTRY_NAME (the
 OIDs held in objects are represented in string form). Accordingly, we make
 that OID the value of DS_ATTRIBUTE_TYPE, and we make the name string itself
 the value of DS_ATTRIBUTE_VALUES:

  static OM_descriptor    Country_Value[] = {

       OM_OID_DESC(OM_CLASS, DS_C_AVA),

       OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_COUNTRY_NAME),

       {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("US")},
  /*                                                               */
  /*                                             Macro to properly */
  /*       fill the "value" union with the NULL-terminated string. */
       OM_NULL_DESCRIPTOR
  };

 There are also five other DS_C_AVA declarations, one for each of the five
 other separate name piece objects referred to in the DS_C_DS_RDN superobjects.


ΓòÉΓòÉΓòÉ 5.2.6. A Complete Object ΓòÉΓòÉΓòÉ

The previous sections described how an object is created:

   o  Look up the rules for the object class that is required, and

   o  Add the attributes called for in the definition.

 Whenever some attribute is defined to have an object as its value, look up the
 class rules for the new object and declare a further descriptor array for it.
 In this way you continue working down through layers of subobjects until an
 object class is reached that contains no subobjects as values; at that point,
 you are finished.

 Normally, you do not statically declare objects in real applications. The
 steps outlined in the preceding text are given as a method for determining
 what an object looks like. Once that is done, then write routines to create
 the objects dynamically. An example of how to create OM descriptor entries
 dynamically can be found in the thradd.c program in the
 \opt\dcelocal\examples\xdsxom directory.

 The process of object building is somewhat easier than it sounds. There are
 only five different object classes needed for input to XDS functions when
 accessing CDS, and only one of those, the DS_C_DS_DN class, has more than one
 level of subobjects. The rules for all five of these classes can be found in
 XOM Programming. In order to use the GDS references, you should know a few
 things about class hierarchy.


ΓòÉΓòÉΓòÉ 5.2.7. Class Hierarchy ΓòÉΓòÉΓòÉ

Object classes are hierarchically organized so that some classes can be located
above some classes in the hierarchy and below others in the hierarchy. In any
such system of subordinate classes, each next lower class inherits all the
attributes prescribed for the class immediately above it, plus whatever
attributes are defined peculiarly for it alone. If the hierarchy continues
further down, cumulative collection of attributes continues to accumulate. If
there were a class for every letter of the alphabet, starting at the highest
level with A and continuing down to the lowest level with Z, and if each
succeeding letter was a subclass of its predecessor, the Z class would possess
all the attributes of all the other letters, as well as its own, while the A
class would possess only the A class attributes.

XDS/XOM classes are seldom nested more than two or at most three layers. All
inherited attributes are explicitly listed in the object descriptions that
follow, so you do not have to worry about class hierarchies here. However, the
complete descriptions of XDS/XOM objects of this guide rely on statements of
class inheritance to fill out their attribute lists for the different classes.


ΓòÉΓòÉΓòÉ 5.2.8. Class Hierarchy and Object Structure ΓòÉΓòÉΓòÉ

Note:  Class hierarchy is different from object structure. Object structure is
       the layering of object arrays that was previously described in the
       DS_C_DS_DN declaration in Building a Name Object. It occurs when one
       object contains another object as the value of one or more of its
       attributes.

 What is meant by recursive objects is one object can point to another object
 as one of its attribute values. The layering of subobjects below superobjects
 in this way is described repeatedly in XDS/CDS Object Recipes.

 The only practical significance of class hierarchy is in determining all the
 attributes a certain object class must have. Once you have done this, you
 might find that a certain attribute requires as its value some other object.
 The result is a compound object, but this is completely determined by the
 attributes for the particular class you are viewing.


ΓòÉΓòÉΓòÉ 5.2.9. Public and Private Objects and XOM ΓòÉΓòÉΓòÉ

In Building a Name Object, you saw how a multilevel XDS object can be
statically declared in C code. Now imagine that you have written an application
that contains such a static DS_C_DS_DN object declaration. From the point of
view of the application, that object is nothing but a series of arrays, and you
can manipulate them with all the normal programming operators, just as any
other data type. Nevertheless, the object is syntactically perfectly acceptable
to any XDS (or XOM) function that is prepared to receive a DS_C_DS_DN object.

Objects are also created by the XDS functions themselves. This is the way they
usually return information to callers. However, there is a difference between
objects generated by the XDS interface and objects that are explicitly declared
by the application: You cannot access the former, private, objects in the
direct way that you can the latter, public, objects.

These two kinds of objects are the same as far as their classes and attributes
are concerned. The only difference between them is in the way they are
accessed. The public objects that an application explicitly creates or declares
in its own memory area are just as accessible as any of the other data storage
it uses. However, private objects are created and held in the XDS interface's
own system memory. Applications get handles to private objects, and in order to
access the private objects' contents, they have to pass the handles to Object
Management functions. The Object Management (XOM) functions make up a sort of
all-purpose companion interface to XDS. Whereas XDS functions typically require
some specific class object as input, the XOM functions accept objects of any
class and perform useful operations on them.

If a private object needs to be manipulated, one of the XOM functions, om_get,
can be called to make a public copy of the private object. Then, calling the
XOM om_create function allows applications to generate private objects
manipulable by om_get. The main significance of private as opposed to public
objects is that they do not have to be explicitly operated on, instead, you can
access them cleanly through the XOM interface and let it do most of the work.
You still have to know something about the objects' logical representation,
however, to use XOM.

Except for a few more details, which will be mentioned as needed, this is
practically all there is to XDS object representation.


ΓòÉΓòÉΓòÉ 5.2.10. XOM Objects and XDS Library Functions ΓòÉΓòÉΓòÉ

To call an XDS library function:

   1. Decide what input parameters you must supply to the function.

   2. Bundle up these parameters in objects (that is, arrays of object
      descriptors) in an XDS format.

 Almost all data returned by an XDS function is enclosed in objects, which you
 must parse to recover the information that you want. This task is made almost
 automatic by a library function supplied with the companion X/Open
 OSI-Abstract-Data Manipulation (XOM) interface.

 With XDS, the programmer has to perform a lot of call parameter management,
 but in other respects the interface is easy to use. The XDS functions'
 dependence on objects makes them easy to call, after you have the objects
 themselves correctly set up.


ΓòÉΓòÉΓòÉ 5.3. Accessing CDS Using the XDS Step-by-Step Procedure ΓòÉΓòÉΓòÉ

You now know all that you need to know to work with a cell namespace through
XDS. The following sections provide a walk-through of the steps of some typical
XDS/CDS operations. They describe what is involved in using XDS to access
existing CDS attributes. They then describe how you can create and access new
CDS entry attributes.


ΓòÉΓòÉΓòÉ 5.3.1. Reading and Writing Existing CDS Entry Attributes Using XDS ΓòÉΓòÉΓòÉ

Suppose you want to use XDS to read some information from the following CDS
entry:

/.../C=US/O=OSF/OU=DCE/hosts/tamburlaine/self

As explained in the DCE for OS/2 Warp: Administration Guide, the
/.:/hosts/hostname/self entry, which is created at the time of cell
configuration, contains binding information for the machine hostname. Since
this is a simple RPC NSI entry, there is not very much in the entry that is
interesting to read, but this entry is used as an example anyway as a simple
demonstration.

Following are the header inclusions and general data declarations.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <xom.h>
#include <xds.h>
#include <xdsbdcp.h>
#include <xdscds.h>

The xom.h and xds.h header files must be included in the order shown in the
preceding example. Also note that the xdscds.h header file is brought in for
the sake of DSX_TYPELESS_RDN. This file is where the CDS-significant OIDs are
defined. The xdsbdcp.h file contains information necessary to the Basic
Directory Contents Package, which is the basic version of the XDS interface you
can use in this program.

The XDS/XOM interface defines numerous object identifier string constants,
which are used to identify the many object classes, parts, and pieces (among
other things) that it needs to know about. In order to make sure that these OID
constants do not collide with any other constants, the interface refers to them
with the string OMP_O_ prefixed to the user-visible form; for example,
DS_C_DS_DN becomes OMP_O_DS_C_DS_DN internally. In order to make application
instances consistent with the internal form, use OM_EXPORT to import all
XDS-defined or XOM-defined OID constants used in your application.

OM_EXPORT( DS_A_COUNTRY_NAME )
OM_EXPORT( DS_A_OBJECT_CLASS )
OM_EXPORT( DS_A_ORG_UNIT_NAME )
OM_EXPORT( DS_A_ORG_NAME )


OM_EXPORT( DS_C_ATTRIBUTE )
OM_EXPORT( DS_C_ATTRIBUTE_LIST )
OM_EXPORT( DS_C_AVA )
OM_EXPORT( DS_C_DS_DN )
OM_EXPORT( DS_C_DS_RDN )
OM_EXPORT( DS_C_ENTRY_INFO_SELECTION )
OM_EXPORT( DSX_TYPELESS_RDN )

/* ...Special OID for an untyped (i.e., non-X.500) "Relative */
/*  Distinguished Name". Defined in xdscds.h header.         */

A further important effect of OM_EXPORT is that it builds an OM_string
structure to hold the exported Object Identifier hexadecimal string. As
explained in the previous section, OIDs are not numeric values, but strings.
Comparisons and similar operations on OIDs must access them as strings. Once an
OID has been exported, you can access it using its declared name. For example,
the hexadecimal string representation of DS_C_ATTRIBUTE is contained in
DS_C_ATTRIBUTE.elements, and the length of this string is contained in
DS_C_ATTRIBUTE.length.


ΓòÉΓòÉΓòÉ 5.3.1.1. Significance of Typed and Untyped Entry Names ΓòÉΓòÉΓòÉ

Next are the static declarations for the lowest layer of objects that make up
the global name (Distinguished Name) of the CDS directory entry you want to
read. These lowest-level objects contain the string values for each part of the
name. Remember that the first three parts of the name (excluding the global
prefix /.../, which is not represented):

/C=US/O=OSF/OU=DCE/

constitute the cell name. In this example, assume that GDS is being used as the
cell's global directory service, so the cell name is represented in X.500
format, and each part of it is typed in the object representation; for example,
DS_A_COUNTRY_NAME is the DS_ATTRIBUTE_TYPE in the Country_String_Object. If you
were using DNS, and the cell name, for example was:

osf.org.dce

then the entire string osf.org.dce would be held in a single object whose
DS_ATTRIBUTE_TYPE would be DSX_TYPELESS_RDN.

DSX_TYPELESS_RDN is a special type that marks a name piece as not residing in
an X.500 namespace. If the object resides under a typed X.500 name, as is the
case in the declared object structures, then it serves as a delimiter for the
end of the cell name GDS looks up, and the beginning of the name that is passed
to a CDS server in that cell, assuming that the cell has access to GDS; if not,
such a name cannot be resolved. If the untyped portion of the name is at the
beginning, as would be the case with the name:

/.../osf.org.dce/hosts/zenocrate/self

then the name is passed immediately by XDS by way of the local CDS (and the
GDA) to DNS for resolution of the cell name. Thus, the typing of entry names
determines which directory service a global directory entry name is sent to for
resolution.


ΓòÉΓòÉΓòÉ 5.3.1.2. Static Declarations ΓòÉΓòÉΓòÉ

Following are the static declarations you need:

/*****************************************************************/
/* Here are the objects that contain the string values for each  */
/*  part of the CDS entry's global name...                   */

static OM_descriptor    Country_String_Object[] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_COUNTRY_NAME),
 {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("US")},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Organization_String_Object[]= {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_ORG_NAME),
 {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("OSF")},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Org_Unit_String_Object[] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_ORG_UNIT_NAME),
 {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("DCE")},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Hosts_Dir_String_Object[] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_TYPELESS_RDN),
 {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("hosts")},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Tamburlaine_Dir_String_Object[] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_TYPELESS_RDN),
 {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("tamburlaine")},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Self_Entry_String_Object[] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_TYPELESS_RDN),
 {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("self")},
 OM_NULL_DESCRIPTOR
};

The string objects are contained by a next-higher level of objects that
identify the strings as being pieces (RDNs) of a fully qualified directory
entry name (DN). Thus, the Country_RDN object contains Country_String_Object as
the value of its DS_AVAS attribute; Organization_RDN contains
Organization_String_Object.

/*****************************************************************/
/* Here are the "Relative Distinguished Name" objects.*/
static OM_descriptor    Country_RDN[] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
 {DS_AVAS, OM_S_OBJECT, {0, Country_String_Object}},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Organization_RDN[] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
 {DS_AVAS, OM_S_OBJECT, {0, Organization_String_Object}},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Org_Unit_RDN[] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
 {DS_AVAS, OM_S_OBJECT, {0, Org_Unit_String_Object}},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Hosts_Dir_RDN[] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
 {DS_AVAS, OM_S_OBJECT, {0, Hosts_Dir_String_Object}},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Tamburlaine_Dir_RDN[] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
 {DS_AVAS, OM_S_OBJECT, {0, Tamburlaine_Dir_String_Object}},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Self_Entry_RDN[] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
 {DS_AVAS, OM_S_OBJECT, {0, Self_Entry_String_Object}},
 OM_NULL_DESCRIPTOR
};

At the highest level, all the subobjects are gathered together in the DN object
named Full_Entry_Name_Object.

/*****************************************************************
/
static OM_descriptor    Full_Entry_Name_Object[]  = {
     OM_OID_DESC(OM_CLASS, DS_C_DS_DN),
     {DS_RDNS, OM_S_OBJECT, {0, Country_RDN}},
     {DS_RDNS, OM_S_OBJECT, {0, Organization_RDN}},
     {DS_RDNS, OM_S_OBJECT, {0, Org_Unit_RDN}},
     {DS_RDNS, OM_S_OBJECT, {0, Hosts_Dir_RDN}},
     {DS_RDNS, OM_S_OBJECT, {0, Tamburlaine_Dir_RDN}},
     {DS_RDNS, OM_S_OBJECT, {0, Self_Entry_RDN}},
     OM_NULL_DESCRIPTOR
};


ΓòÉΓòÉΓòÉ 5.3.1.3. Other Necessary Objects for ds_read ΓòÉΓòÉΓòÉ

The ds_read procedure takes requests in the form of a DS_C_ENTRY_INFO_SELECTION
class object. However, if you refer to the recipe for this object class in
XDS/CDS Object Recipes, you might find that it is much simpler than the name
object; it contains no subobjects, and its declaration is straightforward.

The value of the DS_ALL_ATTRIBUTES attribute specifies that all attributes be
read from the CDS entry, which is specified in the Full_Entry_Name_Object
variable. The term attribute is used slightly differently in CDS and XDS
contexts. In XDS, attributes describe the values that can be held by various
object classes; they can be thought of as object fields. In CDS, attributes
describe the values that can be associated with a directory entry. The
following code fragment shows the definition of a DS_C_ENTRY_INFO_SELECTION
object.

static OM_descriptor         Entry_Info_Select_Object[[= }
     OM_OID_DESC(OM_CLASS, DS_C_ENTRY_INFO_SELECTION),
     {DS_ALL_ATTRIBUTES, OM_S_BOOLEAN, OM_TRUE},
     {DS_INFO_TYPE, OM_S_ENUMERATION, DS_TYPES_AND_VALUES},
     OM_NULL_DESCRIPTOR
};


ΓòÉΓòÉΓòÉ 5.3.1.4. Miscellaneous Declarations ΓòÉΓòÉΓòÉ

The following are declarations for miscellaneous variables:

OM_workspace          xdsWorkspace;
     /* ...will contain handle to our "workspace"  */

DS_feature featureList[] = {

     { OM_STRING(OMP_O_DS_BASIC_DIR_CONTENTS_PKG), OM_TRUE },
     { 0 }
};
     /* ...list of service "packages" we will want from XDS     */

OM_private_object     session;
     /* ...will contain handle to a bound-to directory session  */

DS_status             dsStatus;
     /* ...status return from XDS calls  */

OM_return_code        omStatus;
     /* ...status return from XOM calls  */

OM_sint               dummy;
     /* ...for unsupported ds_read() argument  */

OM_private_object     readResultObject;
  /* ...to receive entry information read from CDS by "ds_read()" */

OM_type I_want_entry_object[] = {DS_ENTRY, OM_NO_MORE_TYPES};
OM_type I_want_attribute_list[] = {DS_ATTRIBUTES, OM_NO_MORE_TYPES};
OM_type I_want_attribute_value[] = }DS_ATTRIBUTE_VALUES,
                          OM_NO_MORE_TYPES};
   /* ...arrays to pass to "om_get()" to extract subobjects */
   /*  from the result object returned by "ds_read()"           */

OM_value_position number_of_descriptors;
   /* ...to hold number of attribute descriptors returned      */
   /*  by "om_get()                                             */

OM_public_object entry;
     /* ...to hold public object returned by "om_get()"     */


ΓòÉΓòÉΓòÉ 5.3.1.5. The Main Program ΓòÉΓòÉΓòÉ

This section describes the main program. Three calls usually precede any use of
XDS.

First, ds_initialize is called to set up a workspace. A workspace is a memory
area in which XDS can generate objects that will be used to pass information to
the application. If the call is successful, it returns a handle that must be
saved for the ds_shutdown call. If the call is unsuccessful, it returns NULL,
but this example does not check for errors.

xdsWorkspace = ds_initialize();

If GDS is being used as the global directory service, the service packages are
specified next. Packages consist of groups of objects, together with the
associated supporting interface functionality, designed to be used for some
specific end. This example uses the basic XDS service so
DS_BASIC_DIR_CONTENTS_PKG is specified. The featureList parameter to ds_version
is an array, not an object, because packages are not being handled yet.

dsStatus = ds_version(featureList, xdsWorkspace);

Note:  If you are not using GDS as your global directory service (in other
       words, if you are using XDS by itself), then you do not need to call
       ds_version. If you use XDS to access the CDS namespace in any cell with
       an X.500 cell name, DS_BASIC_DIR_CONTENTS_PKG is required.

 From this point on, status is returned by XDS functions by way of a DS_status
 variable.DS_status is a handle to a private object, whose value is DS_SUCCESS
 (that is, NULL) if the call was successful. If something went wrong, the
 information in the (possibly complex) private error object has to be analyzed
 through calls to om_get, which is one of the general-purpose object management
 functions that belongs to XDS's companion interface XOM. Usage of om_get is
 demonstrated later on in this program, but return status is not checked in
 this example.

 The third necessary call is to ds_bind. This call brings up the directory
 service, which binds to the CDS namespace. The DS_DEFAULT_SESSION parameter
 calls for a default session. The alternative is to build and fill out your own
 DS_C_SESSION object and pass that object. However, when accessing the CDS
 namespace, the DS_DEFAULT_SESSION parameter is all that is required. The
 default is used in this example:

  dsStatus = ds_bind(DS_DEFAULT_SESSION, xdsWorkspace, &session);


ΓòÉΓòÉΓòÉ 5.3.1.6. Reading a CDS Attribute ΓòÉΓòÉΓòÉ

At this point, you can read a set of object attributes from the cell namespace
entry. Call ds_read with the two objects that specify the entry to be read and
the specific entry attribute you want:

dsStatus = ds_read(session, DS_DEFAULT_CONTEXT,
           Full_Entry_Name_Object,
           Entry_Info_Select_Object, &readResultObject, &dummy);

The DS_DEFAULT_CONTEXT parameter could be substituted with a DS_C_CONTEXT
object, which would typically be reused during a series of related XDS calls.
This object specifies and records how the operations should be performed. Most
of the fields in the DS_C_CONTEXT object have no meaning when accessing the CDS
namespace.

If the call succeeds, the private object readResultObject contains a series of
DS_C_ATTRIBUTE subobjects, one for each attribute read from the cell name
entry. A complete recipe for the DS_C_READ_RESULT object can be found in XDS
Class Definitions, but the following is a skeletal outline of the object's
structure:

DS_C_READ_RESULT
        DS_ENTRY:  object(DS_C_ENTRY_INFO)
        DS_ALIAS_DEREFERENCED:  OM_S_BOOLEAN
        DS_PERFORMER:  object(DS_C_NAME)

    DS_C_ENTRY_INFO
            DS_FROM_ENTRY:  OM_S_BOOLEAN
            DS_OBJECT_NAME:  object(DS_C_NAME)
            DS_ATTRIBUTES:  one or more object(DS_C_ATTRIBUTE)

       DS_C_NAME == DS_C_DS_DN
               DS_RDNS:  object(DS_C_DS_RDN)

           DS_C_DS_RDN
                   DS_AVAS:  object(DS_C_AVA)

               DS_C_AVA
                       DS_ATTRIBUTE_TYPE: OID string
                       DS_ATTRIBUTE_VALUES: anything

       DS_C_ATTRIBUTE  -one for each attribute read
      DS_ATTRIBUTE_TYPE:  OID string
              DS_ATTRIBUTE_VALUES:  anything
      DS_C_ATTRIBUTE
              DS_ATTRIBUTE_TYPE:  OID string
              DS_ATTRIBUTE_VALUES:  anything


"The DS_C_READ_RESULT Object Structure" illustrates the general object
structure of a DS_C_READ_RESULT, showing only the object-valued attributes, and
only one DS_C_ATTRIBUTE subobject.


The DS_C_READ_RESULT Object Structure


ΓòÉΓòÉΓòÉ 5.3.1.7. Handling the Result Object ΓòÉΓòÉΓòÉ

The next goal is to extract the instances of the DS_C_ATTRIBUTE subclass, one
for each attribute read, from the returned object. The first step is to make a
public copy of readResultObject, which is a private object and does not,
therefore, allow access to the object descriptors themselves. Using the XOM
om_get function, you can make a public copy of readResultObject, and at the
same time specify that only the relevant parts of it be preserved in the copy.
Then with a couple of calls to om_get, you can reduce the object to manageable
size, leaving a superobject whose immediate subobjects are fairly easily
accessed.

The om_get function takes as its third input parameter an OM_type_list, which
is an array of OM_type. Possible parameters are DS_ENTRY, DS_ATTRIBUTES,
DS_ATTRIBUTE_VALUES, and anything that can legitimately appear in an object
descriptor's type field. The types specified in this parameter are interpreted
according to the options specified in the preceding parameter. For example, the
relevant attribute from the read result is DS_ENTRY. It contains the
DS_C_ENTRY_INFO object, which in turn contains the DS_C_ATTRIBUTE objects. The
DS_C_ATTRIBUTE objects contain the data read from the cell directory name
entry. Therefore, you should specify the OM_EXCLUDE_ALL_BUT_THESE_TYPES option,
which has the effect of excluding everything but the contents of the object's
DS_ENTRY type attribute.

The OM_EXCLUDE_SUBOBJECTS option is also ORed into the parameter. Why would you
not preserve the subobjects of DS_C_ENTRY_INFO? Because om_get works only on
private, not on public objects. If you were to use om_get on the entire object
substructure, you would not be able to continue getting the subobjects, and
instead you would have to follow the object pointers down to the
DS_C_ATTRIBUTEs. However, when om_get excludes subobjects from a copy, it does
not really leave them out; it merely leaves the subobjects private, with a
handle to the private objects where pointers would have been. This allows you
to continue to call om_get as long as there are more subobjects.

The following is the first call:

/* The DS_C_READ_RESULT object that ds_read()               */
/*  return has one subobject, DS_C_ENTRY_INFO;              */
/*  it in turn has two subobjects, i.e. a DS_C_NAME         */
/*  which holds the object's distinguished name (which we   */
/*  don't care about here), and a DS_C_ATTRIBUTE            */
/*  which contains the attribute info we read; that one we  */
/*  want.  So we climb down to it...                        */
/* This om_get() will "return" the entry-info object...     */

omStatus = om_get(readResultObject,
                  OM_EXCLUDE_ALL_BUT_THESE_TYPES +
                  OM_EXCLUDE_SUBOBJECTS,
                  I_want_entry_object,
                  OM_FALSE,
                  OM_ALL_VALUES,
                  OM_ALL_VALUES,
                  &entry,
                  &number_of_descriptors);

The number_of_descriptors parameter contains the number of attribute
descriptors returned in the public copy, not in any excluded subobjects.

If an XOM function is successful, it returns an OM_SUCCESS code. Unsuccessful
calls to XOM functions do not return error objects, but rather return simple
error codes. The interface assumes that if the XOM function does not accept
your object, then you will not be able to get much information from any further
objects. The return status is not checked in this example.

The return parameter entry should now contain a pointer to the DS_C_ENTRY_INFO
object with the following immediate structure. (The number of instances of
DS_ATTRIBUTES depends on the number of attributes read from the entry.)

DS_C_ENTRY_INFO
    DS_FROM_ENTRY:  OM_S_BOOLEAN
    DS_OBJECT_NAME:  object(DS_C_NAME)
    DS_ATTRIBUTES:  object(DS_C_ATTRIBUTE)
                            DS_C_ATTRIBUTE
                                DS_ATTRIBUTE_TYPE:  OID string
                                DS_ATTRIBUTE_VALUES:  anything

DS_ATTRIBUTES:  object(DS_C_ATTRIBUTE)
                         object(DS_C_ATTRIBUTE)
                             DS_C_ATTRIBUTE
                                 DS_ATTRIBUTE_TYPE:  OID string
                                 DS_ATTRIBUTE_VALUES:  anything

The items in bold are private subobjects.

"The DS_C_ENTRY_INFO Object Structure" shows the DS_C_ENTRY_INFO object. Only
one instance of a DS_C_ATTRIBUTE subobject is shown in the figure; usually
there are several such subobjects, all at the same level, each containing
information about one of the attributes read from the entry. These subobjects
are represented in DS_C_ENTRY_INFO as a series of descriptors of type
DS_ATTRIBUTES, each of which has as its value a separate DS_C_ATTRIBUTE
subobject.


The DS_C_ENTRY_INFO Object Structure

Now extract the separate attribute values of the entry that was read. These
were returned as separate object values of DS_ATTRIBUTES; each one has an
object class of DS_C_ATTRIBUTE To return any one of these subobjects, a second
call to om_get is necessary, as follows.

/*  The second om_get() returns one selected sub-object     */
/*  from the DS_C_ENTRY_INFO subobject we just got.   */
/*  The contents of "entry" as we enter this call is the       */
/*  private subobject which is the value of DS_ATTRIBUTES.  */
/*  If we were to make the following call with the             */
/*  OM_EXCLUDE_SUBOBJECTS and without the                */
/*  OM_EXCLUDE_ALL_BUT_THESE_VALUES flags,      */
/*  we would get back an object consisting of six private      */
/*  subobjects, one for each of the attributes returned.       */
/*  Note the values for initial and limiting                   */
/*  position: "2" specifies                                    */
/*  that we want only the third DS_C_ATTRIBUTE subobject */
/*  to be gotten (the subobjects are numbered from 0, not      */
/*  from one), and the "3" specifies that we want no more      */
/*  than that-- in other words, the limiting value must al-    */
/*  ways be one more than the initial value if the latter      */
/*  is to have any effect.                                     */
/*  OM_EXCLUDE_ALL_BUT_THESE_VALUES             */
/*  is likewise required for the initial and limiting val-     */
/*  ues to have any effect...                              */

omStatus = om_get(entry->value.object.object,
                  OM_EXCLUDE_ALL_BUT_THESE_TYPES
                  + OM_EXCLUDE_SUBOBJECTS
                  + OM_EXCLUDE_ALL_BUT_THESE_VALUES,
                  I_want_attribute_list,
                  OM_FALSE,
                  ((OM_value_position) 2),
                  ((OM_value_position) 3),
                  &entry,
                  &number_of_descriptors);

See the value that is passed as the first parameter. Because om_get does not
work on public objects, the application must pass it the handle of the private
subobject explicitly. To do this you have to know the arrangement of the
descriptor's value union, which is defined in xom.h.


ΓòÉΓòÉΓòÉ 5.3.1.8. Representation of Object Values ΓòÉΓòÉΓòÉ

The following is the layout of the object field in a descriptor's value union:

typedef struct {
        OM_uint32         padding;
        OM_object         object;
} OM_padded_object;

The following is the layout of the value union:

typedef union OM_value_union {
        OM_string        string;
        OM_boolean       boolean;
        OM_enumeration   enumeration;
        OM_integer       integer;
        OM_padded_object        object;
} OM_value;

The following is the layout of the descriptor:

typedef struct OM_descriptor_struct {
        OM_type                   type;
        OM_syntax                 syntax;
        union OM_value_union   value;
} OM_descriptor;

Thus, if entry is a pointer to the DS_C_ENTRY_INFO object, then
entry->value.object.object is the private handle to the DS_C_ATTRIBUTE object
that you want next.


ΓòÉΓòÉΓòÉ 5.3.1.9. Extracting an Attribute Value ΓòÉΓòÉΓòÉ

The last call yielded one separate DS_C_ATTRIBUTE subobject from the original
returned result object:

DS_C_ATTRIBUTE
        DS_ATTRIBUTE_TYPE:  OID string
        DS_ATTRIBUTE_VALUES:  anything

"The DS_C_ATTRIBUTE Object Structure" illustrates what is left.


The DS_C_ATTRIBUTE Object Structure

A final call to om_get returns the single object descriptor that contains the
actual value of the single attribute you selected from the returned object:

omStatus = om_get(entry->value.object.object,
                  OM_EXCLUDE_ALL_BUT_THESE_TYPES,
                  I_want_attribute_value,
                  OM_FALSE,
                  OM_ALL_VALUES,
                  OM_ALL_VALUES,
                  &entry,
                  &number_of_descriptors);

At this point, the value of entry is the base address of an object descriptor
whose entry->type is DS_ATTRIBUTE_VALUES. Depending on the value found in
entry->syntax, the value of the attribute can be read from
entry->value.string,entry->value.integer, entry->value.boolean, or
entry->value.enumeration. For example, suppose the value of entry->syntax is
OM_S_OCTET_STRING. The attribute value, represented as an octet string (not
terminated by a NULL), is found in entry->value.string.elements; its length is
found in entry->value.string.length.

You can check any attribute value against the value you get from the cdscp
command by entering:

cdscp show object /.: /hosts/tamburlaine/self

For further information on cdscp, see the DCE for OS/2 Warp: Administration
Command Reference.

You can always call om_get to get the entire returned object from an XDS call.
This yields a full structure of object descriptors that you can manipulate like
any other data structure. To do this with the ds_read return object would have
required the following call:

/* make a public copy of ENTIRE object...   */

omStatus = om_get(readResultObject,
                  OM_NO_EXCLUSIONS,
                  ((OM_type_list) 0),
                  OM_FALSE,
                  ((OM_value_position) 0),
                  ((OM_value_position) 0),
                  &entry,
                  &number_of_descriptors);

At the end of every XDS session you have to unbind from the CDS namespace, and
then deallocate the XDS and XOM structures and other storage. You must also
explicitly deallocate any service-generated objects, whether public or private,
with calls to om_delete, as follows:

/* delete service-generated public or private objects...  */

omStatus = om_delete(readResultObject);
omStatus = om_delete(entry);

/* unbind from the CDS namespace  */
dsStatus = ds_unbind(session);

/* close down the workspace... */
dsStatus = ds_shutdown(xdsWorkspace);

exit;


ΓòÉΓòÉΓòÉ 5.3.2. Creating New CDS Entry Attributes ΓòÉΓòÉΓòÉ

The following sections provide the procedure and some code examples for
creating new CDS entry attributes:

   o  Procedure for Creating New Attributes
   o  Rules for Transforming an OID into XDS Internal Form
   o  Coding Examples


ΓòÉΓòÉΓòÉ 5.3.2.1. Procedure for Creating New Attributes ΓòÉΓòÉΓòÉ

To create new attributes of your own on cell namespace entries, you must do the
following:

   1. Allocate a new ISO Object Identifier (OID) for the new attribute. For
      information on how to do this, see the DCE for OS/2 Warp: Administration
      Guide.

   2. Enter the new attribute's name and OID in the \opt\dcelocal\etc\cds_attr
      file. This text file contains OID-to-readable string mappings that are
      used, for example, by the CDS administration command cdscp when it
      displays CDS entry attributes. Each entry also gives a syntax for reading
      the information in the entry itself. This should be congruent with the
      format of the data you intend to write in the attribute. For more
      information about the cds_attr file, see DCE for OS/2
      Warp:Administration Guide.

   3. In the xdscds.h header file, define an appropriate OID string constant to
      represent the new attribute.

      For example, the following shows the xdscds.h definition for the CDS
      CDS_Class attribute:

            #define OMP_O_DSX_A_CDS_Class            "\x2B\x16\x01\x03\x0F"

      Note the XDS internal form of the name. This is what DSX_A_CDS_Class
      looks like when it has been exported using OM_EXPORT in an application,
      as all OIDs must be. Thus, if you wanted to create a CDS attribute called
      CDS_Brave_New_Attrib, you would obtain an OID from your administrator and
      add the following line to xdscds.h:

            #define OMP_O_DSX_A_CDS_Brave_New_Attrib "your_OID"

   4. In an application, call the XDS ds_modify_entry routine to add the
      attribute to the cell namespace entry of your choice.


ΓòÉΓòÉΓòÉ 5.3.2.2. Rules for Transforming an OID into XDS Internal Form ΓòÉΓòÉΓòÉ

In Item 3 in the previous procedure, the CDS_Class attribute is shown in the
XDS internal form as \x2B\x16\x01\x03\x0F. In the cds_attr file, the OID is
defined as 1.3.22.1.3.15. The following provides the rules for transforming an
OID into the XDS internal form. They must be applied in the sequence listed
below.

   1. The first two OID values are collapsed into a single byte using the
      following formula:

     OID Value 1 x 40 + OID Value 2

 For example, OID 1.3 transforms to \x2B (1 x 40 + 3 = 43 or \x2B).

   2. If an OID value is 127 or less, it is represented by its hex value. For
      example, the OID value 22 above is represented by \x16.

   3. If an OID value is larger than 127, the value is represented by multiple
      bytes in the XDS internal form. In the XDS internal form, the high order
      bit (\x80) means that the following byte is part of the same OID value.
      The low order 7 bits are concatenated with the lower 7 bits of the next
      byte. This concatenation continues until a byte is reached that is \x7F
      or less. Once this transformation is complete, the values of the bits
      concatenated together will be the value of the OID.

      For example, the OID for the Service Package is 1.3.12.2.1011.28.0 and
      has an XDS internal representation of \x2B\x0C\x02\x87\x73\x1C\00. The
      following illustrates the mapping used:

              1.3 -> \x2B       (Rule 1)
               12 -> \x0C       (Rule 2)
                2 -> \x02       (Rule 2)
             1011 -> \87\x73    (Rule 3 - see below)
               28 -> \x1C       (Rule 2)
                0 -> \x00       (rule 2)

      If you concatenate the last 7 bits of \x87 and \x73, the value \x03\xF3
      is obtained (which is 1011 in decimal).


ΓòÉΓòÉΓòÉ 5.3.2.3. Coding Examples ΓòÉΓòÉΓòÉ

In the following code fragments a set of declarations similar to those in the
previous examples is assumed.

The ds_modify_entry function, which is called to add new attributes to an entry
or to write new values into existing attributes, requires a DS_C_ENTRY_MOD_LIST
input object whose contents specify the attributes and values to be written to
the entry. The name, as always, is specified in a DS_C_DS_DN object. The
following is a static declaration of such a list, which consists of two
attributes:

static OM_descriptor    Entry_Modification_Object_1[] = {
     OM_OID_DESC(OM_CLASS, DS_C_ENTRY_MOD),
     OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_A_CDS_Brave_New_Attrib),
     {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING,
             OM_STRING("O brave new attribute")},
     {DS_MOD_TYPE, OM_S_ENUMERATION, DS_ADD_ATTRIBUTE}
     OM_NULL_DESCRIPTOR
};

static OM_descriptor    Entry_Modification_Object_2[] = {
     OM_OID_DESC(OM_CLASS, DS_C_ENTRY_MOD),
     OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_A_CDS_Class),
     {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING,  OM_STRING("Miscellaneous")},
     }DS_MOD_TYPE, OM_S_ENUMERATION, DS_ADD_ATTRIBUTE},
     OM_NULL_DESCRIPTOR
};


static OM_descriptor     Entry_Modification_List_Object[] =  {
     OM_OID_DESC(OM_CLASS, DS_C_ENTRY_MOD_LIST),
     {DS_CHANGES, OM_S_OBJECT, {0, Entry_Modification_Object_1}},
     {DS_CHANGES, OM_S_OBJECT, {0, Entry_Modification_Object_2}},
     OM_NULL_DESCRIPTOR
};

A full description of this object can be found in XDS/CDS Object Recipes. There
could be any number of additional attribute changes in the list; this would
mean additional DS_C_ENTRY_MOD objects declared, and an additional DS_CHANGES
descriptor declared and initialized in the DS_C_ENTRY_MOD_LIST object.

With the DS_C_ENTRY_MOD_LIST class object having been declared as shown
previously, the following code fragment illustrates how to call XDS to write a
new attribute value (actually two new values because two attributes are
contained in the list object).

Note:  Any of the attributes can be new, although the entry itself must already
       exist.

  dsStatus = ds_modify_entry(session,            /* Directory session from "ds_bind" */
                    DS_DEFAULT_CONTEXT, /* Usual directory context   */
                    Full_Entry_Name_Object, /* Entry name object         */
                    Entry_Modification_List_Object, /* Entry Modifi- */
                                            /*  cation object      */
                    &dummy);                /* Unsupported argument  */

 If the entire entry is new, you must call ds_add_entry. This function requires
 an input object of class DS_C_ATTRIBUTE_LIST, whose contents specify the
 attributes (and values) to be attached to the new entry. Following is the
 static declaration for an attribute list that contains three attributes:

  static OM_descriptor    Class_Attribute_Object[] = {
       OM_OID_DESC(OM_CLASS, DS_C_ATTRIBUTE),
       OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_A_CDS_Class),
       {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING,
        OM_STRING("Printer")},
       OM_NULL_DESCRIPTOR
  };

  static OM_descriptor    ClassVersion_Attribute_Object[] = {
       OM_OID_DESC(OM_CLASS, DS_ATTTRIBUTE),
       OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_A_CDS_ClassVersion),
       {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("1.0")},
       OM_NULL_DESCRIPTOR
  };

  static OM_descriptor    My_Own_Attribute_Object[] = {
       OM_OID_DESC(OM_CLASS, DS_C_ATTRIBUTE),
       OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_A_CDS_My_OwnAttribute),
       {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING,
         OM_STRING("zorro")},
       OM_NULL_DESCRIPTOR
  };

  static OM_descriptor    Attribute_List_Object[]= {
       OM_OID_DESC(OM_CLASS, DS_C_ATTRIBUTE_LIST),
       {DS_ATTRIBUTES, OM_S_OBJECT, {0, Class_Attribute_Object}},
       {DS_ATTRIBUTES, OM_S_OBJECT, {0, ClassVersion_Attribute_Object}},
       {DS_ATTRIBUTES, OM_S_OBJECT, {0, My_Own_Attribute_Object}},
       OM_NULL_DESCRIPTOR
  };

 The ds_add_entry function also requires a DS_C_DS_DN class object containing
 the new entry's full name, for example:

  /.../osf.org.dce/subsys/doc/my_book

 where every member of the name exists except for the last one, my_book.
 Assuming that Full_Entry_Name_Object is a DS_C_DS_DN object, the following
 code shows what the call would look like:

  dsStatus = ds_add_entry(session, /*Directory session from "ds_bind()" */
             DS_DEFAULT_CONTEXT, /* Usual directory context     */
             Full_Entry_Name_Object, /* Name of new entry           */
             Attribute_List_Object, /* Attributes to be attached   */
                                /*  to new entry, with values           */
                &dummy);               /* Unsupported argument      */


ΓòÉΓòÉΓòÉ 5.4. Object-Handling Techniques ΓòÉΓòÉΓòÉ

These sections describe the use of XOM and discuss dynamic object creation:

   o  Using XOM to Access CDS
   o  Dynamic Creation of Objects


ΓòÉΓòÉΓòÉ 5.4.1. Using XOM to Access CDS ΓòÉΓòÉΓòÉ

The following code fragments demonstrate an alternative way to set up the entry
modification object for a ds_modify_entry call, mainly for the sake of showing
how the om_put and om_write functions are used.

The following technique is used to initialize the modification object:

   1. The om_create function is called to generate a private object of a
      specified class.

   2. The om_put function is called to copy statically declared attributes into
      a declared private object.

   3. The om_write function is called to write the value string, which is to be
      assigned to the attribute, into the private object.

   4. The om_get function is called to make the private object public.

   5. The object is now public, and its address is inserted into the
      DS_C_ENTRY_MOD_LIST object's DS_CHANGES attribute.

 The following new declarations are necessary:

  OM_private_object newAttributeMod_priv;
    /* ...handle to a private object to "om_put" to               */

  OM_public_object newAttributeMod_pub;
    /* ...to hold public object from "om_get"                     */

  OM_type types_to_include[] = {DS_ATTRIBUTE_TYPE,
                  DS_ATTRIBUTE_VALUES,
                  DS_MOD_TYPE, OM_NO_MORE_TYPE};
    /* ...i.e., all attribute values of the Entry Modification    */
    /*  object. For "om_put()" and "om_get"                       */

  char *my_string = "O brave new attribute";
    /* ...value I want to write into attribute                    */

  OM_value_position number_of_descriptors;
    /* ...to hold value returned by "om_get"                      */

 First, use XOM to generate a private object of the desired class:

  omStatus = om_create(DS_C_ENTRY_MOD,  /*  Class of object   */
                  OM_TRUE,   /* Initialize attributes per defaults   */
                  xdsWorkspace,  /* Our workspace handle                */
                  &newAttributeMod_priv);  /* Created object handle     */

 Next, copy the public object's attributes into the private object:

  omStatus = om_put(newAttributeMod_priv, /*Private object to copy */
                                           /*  attributes into      */
               OM_REPLACE_ALL,        /* Which attributes to replace in */
                                           /*  destination object  */
               Entry_Modification_Object, /* Source object to copy      */
                                           /*  attributes from     */
               types_to_include, /* List of attribute types we want     */
                                           /*  copied              */
               0, 0); /* Start-stop index for multivalued attributes    */
                      /* ignored with OM_REPLACE_ALL        */

 Because om_put ignores the class of the source object (the object from which
 attributes are being copied), it is not necessary to declare class descriptors
 for the source objects. In other words, the static declarations could have
 omitted the OM_CLASS initializations if this technique were being used, for
 example:

  static OM_descriptor    Entry_Modification_Object_2[]= {
  /*     OM_OID_DESC(OM_CLASS, DS_C_ENTRY_MOD), */
  /*     Not needed for "om_put"...                        */

       OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_A_CDS_Class),
       {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING,
        OM_STRING("Miscellaneous")},
       {DS_MOD_TYPE, OM_S_ENUMERATION, DS_ADD_ATTRIBUTE},
       OM_NULL_DESCRIPTOR
  };

 The OM_CLASS was already properly initialized by om_create.

 Next, write the attribute value string into the private object:

  omStatus = om_write(newAttributeMod_priv, /* Private object to write to */
           DS_ATTRIBUTE_VALUES,             /* Attribute type whose value */
                                            /*  we're writing */
           0,                               /* Descriptor index if attribute  is multivalued */
           OM_S_PRINTABLE_STRING,          /* Syntax of value */
           0,                               /* Offset in source string to write from */
           my_string);                      /* Source string to write from */

 Now make the whole thing public again:

  omStatus = om_get(newAttributeMod_priv, /* Private object to get*/
           0,                    /* Get everything               */
           types_to_include,     /* All attribute types          */
           0,                    /* Unsupported argument         */
           0, 0, /* Start-stop descriptor index for multival-    */
                 /*  ued attributes; ignored in this case        */
           &newAttributeMod_pub, /* Pointer to returned copy   */
           &number_of_descriptors); /* Number of attribute      */
                                   /*  descriptors returned */

 Finally, insert the address of the subobject into its superobject:

  Entry_Modification_List_Object[1].value.object.object = newAttributeMod_pub;


ΓòÉΓòÉΓòÉ 5.4.2. Dynamic Creation of Objects ΓòÉΓòÉΓòÉ

Objects can be completely dynamically allocated and initialized; however, you
have to implement the routines to do this yourself. The examples in this
section are code fragments; for complete examples, see the
\opt\dcelocal\examples\xdsxom directory.

Initialization of object structures can be automated by declaring macros or
functions to do this. For example, the following macro initializes one object
descriptor with a full set of appropriate values:

   /* Put a C-style (NULL-terminated) string into an object, and     */
   /* set all the other descriptor fields to requested values... */
#define FILL_OMD_STRING( desc, index, typ, syntx, val ) \
        desc[index].type = typ; \
        desc[index].syntax = syntx; \
        desc[index].value.string.length =
(OM_element_position)strlen(val); \
        desc[index].value.string.elements = val;

When generating objects, use malloc to allocate space for the number of objects
desired, and then use macros (or functions) such as the preceding one to
initialize the descriptors. The following code fragment shows how this can be
done for the top level object of a DS_C_DS_DN, such as the one described near
the beginning of this section. Recall that the DS_C_DS_DN has a separate
DS_RDNS descriptor for each name piece in the full name.

/* Calculate number of "DS_RDNS" attributes there should be... */
numberOfPieces = number_of_name_pieces;

/* Allocate space for that many descriptors, plus one for the      */
/*  object class at the front, and a NULL descriptor at the        */
/*  back...                                                    */
Name_Object = (OM_object)malloc((numberOfPieces + 2) *
                  sizeof(OM_descriptor));
if(Name_Object == NULL)                  /* "malloc" failed */
return OM_MEMORY_INSUFFICIENT;

/* Initialize it as a DS_C_DS_ DN object by placing that class  */
/*  identifier in the first position...                        */

FILL_OMD_XOM_STRING(Name_Object, 0, OM_CLASS,
    OM_S_OBJECT_IDENTIFIER_STRING, DS_C_DS_DN)

All of these steps would have to be repeated for each of the DS_C_DS_RDN
objects required as attribute values of the DS_C_DS_DN. Then a tier of DS_C_AVA
objects would have to be created in the same way, because each of the
DS_C_DS_RDNs requires one of them as its attribute value.

You could now use om_create and om_put to generate a private copy of this
object, if so desired.

The application is responsible for managing the memory it allocates for such
dynamic object creation.


ΓòÉΓòÉΓòÉ 5.5. XDS/CDS Object Recipes ΓòÉΓòÉΓòÉ

The following sections contain shorthand for object classes. For example, if
you look at the reference pages for the ds_... functions, you will see that an
object of class DS_C_NAME is required to hold entry names you want to pass to
the call, not DS_C_DS_DN as is stated in this section. However, DS_C_NAME is in
fact an abstract class with only one subclass, DS_C_DS_DN, so in this section,
DS_C_DS_DN is used.


ΓòÉΓòÉΓòÉ 5.5.1. Input XDS/CDS Object Recipes ΓòÉΓòÉΓòÉ

In general, the objects you work with in an XDS/CDS application fall into two
categories:

   o  Objects you have to supply as input parameters to XDS functions

   o  Objects returned to you as output by XDS functions

 This section describes only the first category, because you have to construct
 these input objects yourself.

 The following list shows XDS functions and the objects required by them as
 input parameters. Only items significant to CDS are listed. DS_C_SESSION and
 DS_C_CONTEXT are ignored. DS_C_SESSION is returned by ds_bind, which usually
 receives the DS_DEFAULT_SESSION constant as input. DS_C_CONTEXT is usually
 substituted by the DS_DEFAULT_CONTEXT constant.

 Note:  DS_C_NAME is an abstract class that has the single subclass DS_C_DS_DN.
        Therefore, DS_C_NAME is practically the same thing as DS_C_DS_DN.

   o  Directory Service Functions with their Required Input Objects

           Function                 Input Object

           ds_add_entry             DS_C_NAME
                                    DS_C_ATTRIBUTE_LIST

           ds_bind                  None

           ds_compare               DS_C_NAME
                                    DS_C_AVA

           ds_initialize            None

           ds_list                  DS_C_NAME

           ds_modify_entry          DS_C_NAME
                                    DS_C_ENTRY_MOD_LIST

           ds_read                  DS_C_NAME
                                    DS_C_ENTRY_INFO_SELECTION

           ds_remove_entry          DS_C_NAME

           ds_shutdown              None

           ds_unbind                None

           ds_version               None


ΓòÉΓòÉΓòÉ 5.5.2. Input Object Classes for XDS/CDS Operations ΓòÉΓòÉΓòÉ

The following sections contain information about all the object types required
as input to any of the XDS functions that can be used to access the CDS. In
order to use these functions successfully, you must be able to construct and
modify the objects that the functions expect as their input parameters. XDS
functions require most of their input parameters to be wrapped in a nested
series of data structures that represent objects, and these functions deliver
their output returns to callers in the same object form.

Objects that are returned to you by the interface are not difficult to
manipulate because the om_get function allows you to go through them and
retrieve only the value parts you are interested in, and discard the parts of
data structures you are not interested in. However, any objects you are
required to supply as in put to an XDS or XOM function are another matter. You
must build and initialize these object structures yourself.

The basics of object building have already been explained earlier in this
section. Each object described in the following sections is accompanied by a
static declaration in C of a very simple instance of that object class. The
objects in an application are usually built dynamically (this technique was
demonstrated earlier in this section). The static declarations that follow give
a simple example of what the objects look like.

An object's properties, such as what sort of values it can hold, how many of
them it can hold,and so on, are determined by the class the object belongs to.
Each class consists of one or more attributes that an object can have. The
attributes hold whatever values the object contains. Thus, the objects are data
structures that all look the same (and can be handled in the same way) from the
outside, but whose specific data fields are determined by the class each object
belongs to. At the abstract level, objects consist of attributes, just as
structures consist fields.


ΓòÉΓòÉΓòÉ 5.5.2.1. XDS/CDS Object Types ΓòÉΓòÉΓòÉ

Following is a list of all the object types that are described in the following
sections. Most of these objects are object structures, that is, compounds
consisting of superobjects that contain subobjects as some of their values.
These latter can in turn contain other objects, and so on. Subobjects are
indicated by indentation. A DS_C_DS_DN object contains at least one DS_C_DS_RDN
object, and each of the latter contains one DS_C_AVA object. Note that
subobjects can, and often do, exist by themselves, depending on what object
class is called for by a given function. This list contains all the possible
kinds of objects that can be required as input for any XDS/CDS operation.

   o  DS_C_ATTRIBUTE_LIST
        -  DS_C_ATTRIBUTE
   o  DS_C_DS_DN
        -  DS_C_DS_RDN
             o  DS_C_AVA
   o  DS_C_ENTRY_MOD_LIST
        -  DS_C_ENTRY_MOD
   o  DS_C_ENTRY_INFO_SELECTION

 In each section, information is provided for the described object's
 attributes. All of its attributes are listed.

 The illustrations in the following sections can be compared to the same object
 classes' tabular definitions in XDS Class Definitions.


ΓòÉΓòÉΓòÉ 5.5.2.2. The DS_C_ATTRIBUTE_LIST Object ΓòÉΓòÉΓòÉ

A DS_C_ATTRIBUTE_LIST class object is required as input to ds_add_entry. The
object contains a list of the directory attributes you want associated with the
entry that is to be added.

Its general structure is as follows:

   o  Attribute List class type attribute

   o  Zero or more Attribute objects:

        -  Attribute class type attribute

        -  Attribute Type attribute

        -  Zero or more Attribute Value(s)

 Thus, a DS_C_ATTRIBUTE_LIST object containing one attribute consists of two
 object descriptor arrays because each additional attribute in the list
 requires an additional descriptor array to represent it. The subobject arrays'
 names (that is, addresses) are the contents of the value fields in the
 DS_ATTRIBUTES object descriptors.

 "The DS_C_ATTRIBUTE_LIST Object" shows the attributes of the
 DS_C_ATTRIBUTE_LIST object.


  The DS_C_ATTRIBUTE_LIST Object

   o  OM_CLASS - The value of this attribute is an OID string that identifies
      the object's class; its value is always DS_C_ATTRIBUTE_LIST.

   o  DS_ATTRIBUTES - This is an attribute whose value is another object of
      class DS_C_ATTRIBUTE. The attribute is defined by a separate array of
      object descriptors whose base address is the value of the DS_ATTRIBUTES
      attribute. There can be any number of instances of this attribute, and
      therefore any number of subobjects.


ΓòÉΓòÉΓòÉ 5.5.2.3. The DS_C_ATTRIBUTE Object ΓòÉΓòÉΓòÉ

An object of this class can be an attribute of a DS_C_ATTRIBUTE_LIST object
(see XDS/CDS Object Types).

   o  OM_CLASS - The value of this attribute is an OID string that identifies
      the object's class; its value is always DS_C_ATTRIBUTE.

   o  DS_ATTRIBUTE_TYPE - The value of this attribute, which is an OID string,
      identifies the directory attribute whose value is contained in this
      object.

   o  DS_ATTRIBUTE_VALUES - These are the actual values for the directory
      attribute represented by this DS_C_ATTRIBUTE object. Both the value
      syntax and the number of values depend on what directory attribute this
      is; that is, they depend on the value of DS_ATTRIBUTE_VALUE.


ΓòÉΓòÉΓòÉ 5.5.2.4. Example Definition of a DS_C_ATTRIBUTE_LIST Object ΓòÉΓòÉΓòÉ

The following code fragment is a definition of a DS_C_ATTRIBUTE_LIST object.

static OM_descriptor    Single_Attribute_Object [] = {
 OM_OID_DESC(OM_CLASS, DS_C_ATTRIBUTE),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_A_CDS_Class),
 {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("Printer"){,
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Attribute_List_Object []  = {
 OM_OID_DESC(OM_CLASS, DS_C_ATTRIBUTE_LIST),
 {DS_ATTRIBUTES, OM_S_OBJECT,{0, Single_Attribute_Object}},
 OM_NULL_DESCRIPTOR
};


ΓòÉΓòÉΓòÉ 5.5.2.5. The DS_C_DS_DN Object ΓòÉΓòÉΓòÉ

DS_C_DS_DN class objects are used to hold the full names of directory entries
(Distinguished Names). You need an object of this class to pass directory entry
names to the following XDS functions:

   o  ds_add_entry
   o  ds_compare
   o  ds_list
   o  ds_modify_entry
   o  ds_read
   o  ds_remove_entry

 "The DS_C_DS_DN Object Attributes" shows the attributes of a DS_C_DS_DN
 object.


  The DS_C_DS_DN Object Attributes

   o  OM_CLASS - The value of this attribute is an OID string that identifies
      the object's class; its value is DS_C_DS_DN.

   o  DS_RDNS - This is an attribute whose value is another object of class
      DS_C_DS_RDN (see The DS_C_DS_RDN Object). The DS_C_DS_RDN object is
      defined by a separate array of object descriptors whose base address is
      the value of the DS_RDNS attribute.

      There are as many DS_RDNS attributes in a DS_C_DS_DN object as there are
      separate name components in the full directory entry name. For example,
      to represent the CDS entry name /.../C=US/O=OSF/OU=DCE/hosts/brazil/self,
      a total of six instances of the DS_RDNS attribute are required in the
      DS_C_DS_DN object. The /.../ (global root prefix) is not represented.
      This means that another six object descriptor arrays are required to hold
      the Relative Distinguished Name objects, as well as six object
      descriptors in the present object, one to hold (as the value of a DS_RDNS
      attribute) a pointer to each array. The order of these DS_RDNS attributes
      is significant, that is, the first DS_RDNS should contain as its value a
      pointer to the array representing the C=US part of the name; the next
      DS_RDNS should contain as its value a pointer to the array representing
      the O=OSF part. The root part of the name is not represented at all.


ΓòÉΓòÉΓòÉ 5.5.2.6. The DS_C_DS_RDN Object ΓòÉΓòÉΓòÉ

DS_C_DS_RDN class objects are required as values for the DS_RDNS attributes of
DS_C_DS_DN objects. (For an illustration of its structure, see the previous
figure.) RDN refers to the X.500 term Relative Distinguished Name that is used
to signify a part of a full entry name. Separate objects of this class are not
usually required as input to XDS functions.

The standard permits multiple AVAs in an RDN, but the DCE Directory and XDS API
restrict an RDN to one AVA.

   o  OM_CLASS - The value of this attribute is an OID string that identifies
      the object's class; its value is always DS_C_DS_RDN.

   o  DS_AVAS - This is an attribute whose value is yet another object of class
      DS_C_AVA (see The DS_C_AVA Object). The DS_C_AVA object is defined by a
      separate array of object descriptors whose base address is the value of
      the DS_AVAS attribute.

      There can only be one instance of this attribute in the DS_C_RDN object.
      The object descriptor array describing this object always consists of
      three object descriptor structures: the first describes the object's
      class, the second describes the DS_AVAS attribute, and the third
      descriptor is the terminating NULL.


ΓòÉΓòÉΓòÉ 5.5.2.7. The DS_C_AVA Object ΓòÉΓòÉΓòÉ

The DS_C_AVA class object is used to hold an actual value. The value is usually
in the form of one of the many different XOM string types. (For an illustration
of its structure, see "The DS_C_DS_DN Object Attributes".)

In calls to ds_compare, an object of this type is required to hold the type and
value of the attribute that you want compared with those in the entry you
specify. It holds the type and value in a separate DS_C_DS_DN object.

DS_C_AVA is also included here because it is a required subobject of
DS_C_DS_DN. DS_C_AVA is the subobject in which the name part's actual literal
value is held.

   o  OM_CLASS - The value of this attribute is an OID string that identifies
      the object's class; its value is always DS_C_AVA.

   o  DS_ATTRIBUTE_TYPE - The value of this attribute, which is an OID string,
      identifies the directory attribute whose value is contained in this
      object.

   o  DS_ATTRIBUTE_VALUES - This is the literal value of what is represented by
      this DS_C_AVA object.

      If the DS_C_AVA object is a subobject of DS_C_DS_RDN (and therefore also
      of DS_C_DS_DN), then the value is a string representing the part of the
      directory entry name represented by this object. For example, if the
      DS_C_DS_RDN object contains the O=OSF part of an entry name, then the
      string OSF is the value of the DS_ATTRIBUTE_VALUES attribute, and
      DS_A_COUNTRY_NAME is the value of the DS_ATTRIBUTE_TYPE attribute.

      On the other hand, if DS_C_AVA contains an entry attribute type and value
      to be passed to ds_compare, then DS_ATTRIBUTE_TYPE identifies the type of
      the attribute, and DS_ATTRIBUTE_VALUES contains a value, which is
      appropriate for the attribute type, to be compared with the entry value.

      For example, suppose you wanted to compare a certain value with a CDS
      entry's CDS_Class attribute's value. The identifiers for all the valid
      CDS entry attributes are found in the \opt\dcelocal\etc\cds_attr file.
      The value of DS_ATTRIBUTE_TYPE would be DSX_A_CDS_Class, which is the
      label of an object identifier string, and DS_ATTRIBUTE_VALUES would
      contain some desired value, in the correct syntax for CDS_Class. The
      syntax also is found in the cds_attr file; for CDS_Class it is byte, that
      is, a character string. The user could code OM_S_OCTET_STRING for
      DS_ATTRIBUTE_VALUES. See Attribute and Data Type Translation.


ΓòÉΓòÉΓòÉ 5.5.2.8. Example Definition of a DS_C_DS_DN Object ΓòÉΓòÉΓòÉ

The following code fragment shows an example definition for a DS_C_DS_DN
object.

static OM_descriptor    Entry_String_Object [] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_TYPELESS_RDN),
 {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("brazil")},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Entry_Part_Object [] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
 {DS_AVAS, OM_S_OBJECT, {0, Entry_String_Object}},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Entry_Name_Object[] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_DN),
 {DS_RDNS, OM_S_OBJECT, {0, Entry_Part_Object}},
 OM_NULL_DESCRIPTOR
};


ΓòÉΓòÉΓòÉ 5.5.2.9. The DS_C_ENTRY_MOD_LIST Object ΓòÉΓòÉΓòÉ

DS_C_ENTRY_MOD_LIST class objects, which contain a list of changes to be made
to some directory entry, must be passed to ds_modify_entry. DS_C_ENTRY_MOD_LIST
objects have the attributes shown in "The DS_C_ENTRY_MOD_LIST Object".


The DS_C_ENTRY_MOD_LIST Object

   o  OM_CLASS - The value of this attribute is an OID string that identifies
      the object's class; its value is always DS_C_ENTRY_MOD_LIST.

   o  DS_CHANGES - This is an attribute whose value is another object of class
      DS_C_ENTRY_MOD (see The DS_C_ENTRY_MOD_LIST Object). The DS_C_ENTRY_MOD
      object is defined by a separate array of object descriptors whose base
      address is the value of the DS_CHANGES attribute.

      There can be one or more instances of this attribute in the object, which
      is why it is called _LIST. Each attribute contains one separate entry
      modification. To learn how the modification itself is specified, see The
      DS_C_ENTRY_MOD_LIST Object. The order of multiple instances of this
      attribute is significant because if more than one modification is
      specified, the modifications are performed by ds_modify_entry in the
      order in which the DS_CHANGES attributes appear in the
      DS_C_ENTRY_MOD_LIST object.


ΓòÉΓòÉΓòÉ 5.5.2.10. The DS_C_ENTRY_MOD_LIST Object ΓòÉΓòÉΓòÉ

The DS_C_ENTRY_MOD class object holds the information associated with a
directory entry modification. (For an illustration of its structure, see "The
DS_C_ENTRY_MOD_LIST Object".) Each DS_C_ENTRY_MOD object describes one
modification. To create a list of modifications suitable to be passed to a
ds_modify_entry call, describe each modification in a separate DS_C_ENTRY_MOD
object, and then insert these objects as multiple instances of the DS_CHANGES
attribute in a DS_C_ENTRY_MOD_LIST object (see The DS_C_ENTRY_MOD_LIST Object).

   o  OM_CLASS - The value of this attribute is an OID string that identifies
      the object's class; its value is always DS_C_ENTRY_MOD.

   o  DS_ATTRIBUTE_TYPE - The value of this attribute, which is an OID string,
      identifies the directory attribute whose modification is described in
      this object.

   o  DS_ATTRIBUTE_VALUES - These are the values required for the entry
      modification; their type and number depend on both the entry type and the
      modification requested.

   o  DS_MOD_TYPE - The value of this attribute identifies the kind of
      modification requested. It can be one of the following:

           DS_ADD_ATTRIBUTE             The attribute specified by
                                        DS_ATTRIBUTE_TYPE is not currently in
                                        the entry. It should be added, along
                                        with the value(s) specified by
                                        DS_ATTRIBUTE_VALUES, to the entry. The
                                        entry itself is specified in a separate
                                        DS_C_DS_DN object, which is also passed
                                        to ds_modify_entry.

           DS_ADD_VALUES                The specified attribute is currently in
                                        the entry. The value(s) specified by
                                        DS_ATTRIBUTE_VALUES should be added to
                                        it.

           DS_REMOVE_ATTRIBUTE          The specified attribute is currently in
                                        the entry and should be deleted from
                                        the entry. Any values specified by
                                        DS_ATTRIBUTE_VALUES are ignored.

           DS_REMOVE_VALUES             The specified attribute is currently in
                                        the entry. One or more values,
                                        specified by DS_ATTRIBUTE_VALUES,
                                        should be removed from it.


ΓòÉΓòÉΓòÉ 5.5.2.11. Example Definition of a DS_C_ENTRY_MOD_LIST Object ΓòÉΓòÉΓòÉ

The following code fragment is an example definition of a DS_C_ENTRY_MOD_LIST
object.

OM_string my_uuid;

static OM_descriptor    Entry_Mod_Object[] =  {
 OM_OID_DESC(OM_CLASS, DS_C_ENTRY_MOD),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_UUID),
 {DS_ATTRIBUTE_VALUES, OM_S_OCTET_STRING, my_uuid},
 {DS_MOD_TYPE, OM_S_ENUMERATION, DS_ADD_ATTRIBUTE},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    Entry_Mod_Object[] =  {
 OM_OID_DESC(OM_CLASS, DS_C_ENTRY_MOD_LIST),
 {DS_CHANGES, OM_S_OBJECT, {0, Entry_Mod_Object}},
 OM_NULL_DESCRIPTOR
};


ΓòÉΓòÉΓòÉ 5.5.2.12. The DS_C_ENTRY_INFO_SELECTION Object ΓòÉΓòÉΓòÉ

When you call ds_read to read one or more attributes from a CDS entry, you
specify in the DS_C_ENTRY_INFO_SELECTION object the entry attributes you want
to read.

The DS_C_ENTRY_INFO_SELECTION object contains the attributes shown in "The
DS_C_ENTRY_INFO_SELECTION Object".


The DS_C_ENTRY_INFO_SELECTION Object

Note:  This object class has no subobjects.

   o  OM_CLASS - The value of this attribute is an OID string that identifies
      the object's class; its value is always DS_C_ENTRY_INFO_SELECTION.

   o  DS_ALL_ATTRIBUTES - This attribute is a simple Boolean option whose value
      indicates whether all the entry's attributes are to be read, or only some
      of them. Its possible values are as follows:

        -  OM_TRUE, meaning that all attributes in the directory entry should
           be read. Any values specified by the DS_ATTRIBUTES_SELECTED
           attribute are ignored.

        -  OM_FALSE, meaning that only some of the entry attributes should be
           read; namely, those specified by the DS_ATTRIBUTES_SELECTED
           attribute.

   o  DS_ATTRIBUTES_SELECTED - The value of this attribute, which is an OID
      string, identifies the entry attribute to be read. Note that this
      attribute's value has meaning only if the value of DS_ALL_ATTRIBUTES is
      OM_FALSE. If it is OM_TRUE, the value of DS_ATTRIBUTES_SELECTED is
      ignored.

      There are multiple instances of this attribute if more than one
      attribute, but not all of them, is to be selected for reading. Each
      separate instance of DS_ATTRIBUTES_SELECTED has as its value an OID
      string that identifies one directory entry attribute to be read. If
      DS_ATTRIBUTES_SELECTED is present but does not have a value, ds_read
      reads the entry but does not return any attribute data; this technique
      can be used to verify the existence of a directory entry.

   o  DS_INFO_TYPE - The value of this attribute specifies what information is
      to be read from each attribute specified by DS_ATTRIBUTES_SELECTED. The
      two possible values are as follows:

        -  DS_TYPES_ONLY, meaning that only the attribute types of the selected
           attributes should be read.

        -  DS_TYPES_AND_VALUES, meaning that both the attribute types and the
           attribute values of the selected attributes should be read.


ΓòÉΓòÉΓòÉ 5.5.2.13. Example Definition of a DS_C_ENTRY_INFO_SELECTION Object ΓòÉΓòÉΓòÉ

The following code fragment provides an example definition of a
DS_C_ENTRY_INFO_SELECTION object.

static OM_descriptor   Entry_Info_Select_Object[] = {
 OM_OID_DESC(OM_CLASS, DS_C_ENTRY_INFO_SELECTION),
 OM_OID_DESC(DS_ATTRIBUTES_SELECTED, DSX_A_CDS_Class),
 {DS_ALL_ATTRIBUTES, OM_S_BOOLEAN, OM_FALSE},
 {DS_INFO_TYPE, OM_S_ENUMERATION, DS_TYPES_AND_VALUES},
 OM_NULL_DESCRIPTOR
};


ΓòÉΓòÉΓòÉ 5.6. Attribute and Data Type Translation ΓòÉΓòÉΓòÉ

The following lists provide translations between CDS and XDS for attributes and
data types. The first list provides the OM syntax for CDS attributes. The
second list provides the OM syntax for CDS data types, and the third defines
the mapping of the CDS Data Types to OM Syntaxes.

   1. CDS Attributes to OM Syntax Translation

           CDS Attribute                    OM Syntax
           CDS_CTS                          OM_S_OCTET_STRING
           CDS_UTS                          OM_S_OCTET_STRING
           CDS_Class                        OM_S_OCTET_STRING
           CDS_Class Version                OM_S_INTEGER
           CDS_ObjectUID                    OM_S_OCTET_STRING
           CDS_AllUpTo                      OM_S_OCTET_STRING
           CDS_Convergence                  OM_S_INTEGER
           CDS_InCHName                     OM_S_INTEGER
           CDS_Directory Version            OM_S_INTEGER
           CDS_Upgrade_To                   OM_S_INTEGER
           CDS_LinkTimeout                  OM_S_INTEGER
           CDS_Towers                       OM_S_OCTET_STRING

   2. OM Syntax to CDS Data Types Translation

           OM Syntax                                    CDS Data Type
           OM_S_TELETEX_STRING                          cds_char
           OM_S_OBJECT_IDENTIFIER_STRING                cds_byte
           OM_S_OCTET_STRING                            cds_byte
           OM_S_PRINTABLE_STRING                        cds_char
           OM_S_NUMERIC_STRING                          cds_char
           OM_S_BOOLEAN                                 cds_long
           OM_S_INTEGER                                 cds_long
           OM_S_UTC_TIME_STRING                         cds_char
           OM_S_ENCODING                                cds_byte

   3. CDS Data Types to OM Syntax Translation

           CDS Data Type              OM Syntax
           cds_none                   OM_S_NULL
           cds_long                   OM_S_INTEGER
           cds_short                  OM_S_INTEGER
           cds_small                  OM_S_INTEGER
           cds_uuid                   OM_S_OCTET_STRING
           cds_Timestamp              OM_S_OCTET_STRING
           cds_Version                OM_S_PRINTABLE_STRING
           cds_char                   OM_S_TELETEX_STRING
           cds_byte                   OM_S_OCTET_STRING


ΓòÉΓòÉΓòÉ 6. XDS API Logging ΓòÉΓòÉΓòÉ

The XDS API logging facility displays informational and error messages for XDS
functions. In addition, the input and output arguments to XDS function calls
can also be displayed. For each XDS object, its OM types, syntaxes, and values
are displayed recursively. A number of different display formats can be
selected for the XDS objects. These are selected by setting the value of the
environment variable XDS_LOG as shown in "XDS_LOG Values".

Logging can be activated dynamically at run-time by setting the environment
variable XDS_LOG.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 1. XDS_LOG Values                                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé XDS_LOG VALUE  Γöé RESULT                        Γöé   EXAMPLE   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Bit 1 = on    Γöé Display arguments, messages, results, and errors   Γöé    N/A    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Bit 1 = off   Γöé Display messages only (all other bits ignored)    Γöé    N/A    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Bit 2 = on    Γöé Display result and error objects as private objects Γöé    N/A    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Bit 2 = off   Γöé Display result and error objects as public objects  Γöé    N/A    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Bit 3 = on    Γöé Object identifiers displayed as specified in fourth Γöé    N/A    Γöé
Γöé         Γöé bit                         Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Bit 3 = off   Γöé Object identifiers displayed as symbolic constants  Γöé  DS_C_SESSION  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Bit 4 = on    Γöé Object identifiers displayed as dotted-decimal    Γöé   2.5.4.35   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Bit 4 = off   Γöé Object identifiers displayed as hexadecimal bytes  Γöé  \x55\x04\x23  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Bit 5 = on    Γöé Syntaxes displayed as integers            Γöé    127    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Bit 5 = off   Γöé Syntaxes displayed as symbolic constants       Γöé  OM_S_OBJECT  Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

The bits shown in the previous table can be combined. For example, the
following command sequence sets XDS_LOG to 5 (0101 in binary):

set XDS_LOG=5

In the previous example, the logging facility is directed to display arguments,
messages, results, and errors, to convert results and errors into public
objects (for display purposes only) and to display object identifiers as
hexadecimal bytes; and to display OM syntaxes as symbolic constants. OM Types
are always displayed as integers. Normally, XDS_LOG should be set to 0. If full
tracing is required, set XDS_LOG to 1.

The location of the log file can be set by means of the D2_LOG_DIR environment
variable. For example, the following places the log files in c:\tmp\log.

SET D2_LOG_DIR=c:\tmp\log

A separate log file is created for each process that uses the XDS API. The log
file names have the following format:

pid.xds

where pid is the process ID of the application. If the environment variable
D2_LOG_DIR is not set, the files are placed in the directory set by the HOME
environment variable.


ΓòÉΓòÉΓòÉ 6.1. Logging Format ΓòÉΓòÉΓòÉ

The following general display format is used by the logging facility:

identifier-name = {
  { type, syntax, value },
  { type, syntax, value },
  :
  :
  etc. }; /* identifier-name */

where:

   o  TYPE - The integer defined for the specified type

   o  SYNTAX - A symbolic constant for the specified syntax. A +L is appended
      to the syntax label if the OM_S_LOCAL_STRING bit is set in the OM_syntax
      field.

   o  VALUE

        -  An integer (if syntax is OM_S_INTEGER or OM_S_ENUMERATION)

        -  OM_FALSE or OM_TRUE (if syntax is OM_S_BOOLEAN)

        -  Symbolic constant, dotted-decimal notation, or hexadecimal bytes (if
           syntax is OM_S_OBJECT_ID_STRING)

        -  Quoted-string (if syntax is any other type of string)

        -  Another object (if syntax is OM_S_OBJECT)

 Note:  The terminating NULL descriptor is expected but not displayed.


ΓòÉΓòÉΓòÉ 6.2. Examples ΓòÉΓòÉΓòÉ

These examples show how a selection of XDS objects are displayed by the logging
facility.

The following filter selects entries that do not have the value secret for the
DS_A_USER_PASSWORD attribute. The DS_FILTER_TYPE has the value DS_NOT. It
contains a single DS_C_FILTER_ITEM attribute. DS_C_FILTER_ITEM tests for
equality against the DS_A_USER_PASSWORD attribute.

my_filter = {
   { OM_CLASS, OM_S_OBJECT_ID_STRING,    DS_C_FILTER },
   { DS_FILTER_ITEMS, OM_S_OBJECT,
     {
       { OM_CLASS, OM_S_OBJECT_ID_STRING, DS_C_FILTER_ITEM },
       { DS_FILTER_ITEM_TYPE, OM_S_ENUMERATION, 0 },
       { DS_ATTRIBUTE_TYPE, OM_S_OBJECT_ID_STRING, DS_A_USER_PASSWORD },
       { DS_ATTRIBUTE_VALUES, OM_S_OCTET_STRING, "secret" },
     }
   }
   { DS_FILTER_TYPE, OM_S_ENUMERATION, 3 },
}; /* my_filter */

The following example shows logging output if the interface logger encounters a
NULL pointer. The NULL pointer is flagged as follows:

my_session = {
   { OM_CLASS, OM_S_OBJECT_ID_STRING, DS_C_SESSION },
   { DS_DSA_NAME, OM_S_OBJECT, ---WARNING: NULL pointer encountered--- },
}; /* my_session */

The following example shows logging output if the interface logger encounters a
private object. The private object is displayed as follows:

bound_session = {
   { OM_PRIVATE_OBJECT,    OM_S_OBJECT_ID_STRING, DS_C_SESSION } ...
}; /* bound_session */

The following example shows how a five-part DSA distinguished name is displayed
(/C=de/O=sni/OU=ap/CN=dsa/CN=dsa-ml):

dsa_name = {
   { DS_DSA_NAME, OM_S_OBJECT,
     {
       { OM_CLASS, OM_S_OBJECT_ID_STRING, DS_C_DS_DN },
       { DS_RDNS, OM_S_OBJECT,
         {
           { OM_CLASS, OM_S_OBJECT_ID_STRING, DS_C_DS_RDN },
             { DS_AVAS, OM_S_OBJECT,
               {
                 {OM_CLASS, OM_S_OBJECT_ID_STRING, DS_C_AVA },
                 { DS_ATTRIBUTE_TYPE, OM_S_OBJECT_ID_STRING, DS_A_COUNTRY_NAME },
                 { DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, "de" },
               }
             }
           }
         }
         { DS_RDNS, OM_S_OBJECT,
           {
             {OM_CLASS, OM_S_OBJECT_ID_STRING, DS_C_DS_RDN },
             { DS_AVAS, OM_S_OBJECT,
               {
                 {OM_CLASS, OM_S_OBJECT_ID_STRING, DS_C_AVA },
                 { DS_ATTRIBUTE_TYPE, OM_S_OBJECT_ID_STRING, DS_A_ORG_NAME },
                 { DS_ATTRIBUTE_VALUES, OM_S_TELETEX_STRING, "sni" },
               }
             }
           }
         }
         { DS_RDNS, OM_S_OBJECT,
           {
             {OM_CLASS, OM_S_OBJECT_ID_STRING, DS_C_DS_RDN },
             { DS_AVAS, OM_S_OBJECT,
               {
                 { OM_CLASS, OM_S_OBJECT_ID_STRING, DS_C_AVA },
                 { DS_ATTRIBUTE_TYPE, OM_S_OBJECT_ID_STRING, DS_A_ORG_UNIT_NAME },
                 { DS_ATTRIBUTE_VALUES, OM_S_TELETEX_STRING, "ap" },
               }
             }
           }
         }
         { DS_RDNS, OM_S_OBJECT,
           {
             { OM_CLASS, OM_S_OBJECT_ID_STRING, DS_C_DS_RDN },
             { DS_AVAS, OM_S_OBJECT,
               {
                 { OM_CLASS, OM_S_OBJECT_ID_STRING, DS_C_AVA },
                 { DS_ATTRIBUTE, OM_S_OBJECT_ID_STRING, DS_A_COMMON_NAME },
                 { DS_ATTRIBUTE_VALUES, OM_S_TELETEX_STRING, "dsa" },
               }
             }
           }
         }
         { DS_RDNS, OM_S_OBJECT,
           {
             { OM_CLASS, OM_S_OBJECT_ID_STRING, DS_C_DS_RDN },
             { DS_AVAS, OM_S_OBJECT,
               {
                 { OM_CLASS, OM_S_OBJECT_ID_STRING, DS_C_AVA },
                 { DS_ATTRIBUTE_TYPE, OM_S_OBJECT_ID_STRING, DS_A_COMMON_NAME },
                 { DS_ATTRIBUTE_VALUES, OM_S_TELETEX_STRING, "dsa-m1" },
               }
             }
           }
         }
       }
     }
 }; /* dsa_name */


ΓòÉΓòÉΓòÉ 7. XOM Programming ΓòÉΓòÉΓòÉ

XOM API defines a general-purpose interface for use in conjunction with other
application-specific APIs for OSI services, such as XDS API to CDS. It presents
the application programmer with a uniform information architecture based on the
concept of groups, classes, and similar information objects.

This section describes some of the basic concepts required to understand and
use the XOM API effectively.

The following names refer to the complete XDS example programs, which are
shipped with DCE and can be found in \opt\dcelocal\examples\xdsxom.

   o  add_list.c (add_list.h)
   o  cds_xmpl.c (cds_xmpl.h)
   o  example.c (example.h)
   o  thradd.c (thradd.h)
   o  teldir2.c

 Note:  For multithreaded XDS/XOM applications, see Using Threads with the
        XDS/XOM API. For use of the XDS/XOM convenence functions, refer to DCE
        for OS/2 Warp: Application Development Guide - Core Components.


ΓòÉΓòÉΓòÉ 7.1. OM Objects ΓòÉΓòÉΓòÉ

The purpose of XOM API is to provide an interface to manage complex information
objects. These information objects belong to classes and have attributes
associated with them. There are two distinct kinds of classes and attributes
that are used throughout this guide - directory and OM.

The directory classes and attributes defined for XDS API correspond to entries
that make up the objects in the directory. These classes and attributes are
defined in the X.500 directory standard and by additional GDS extensions
created for DCE. Other APIs, such as the X.400 Application Interface, which is
the application interface for the industry standard X.400 electronic mail
service, define their own set of objects in terms of classes and attributes. OM
classes and OM attributes are used to model the objects in the directory.

XOM API provides a common information architecture so that the information
objects defined for any API that conforms to this architectural model can be
shared. Different application service interfaces can communicate using this
common way of defining objects by means of workspaces. A workspace is simply a
common work area where objects defined by a service can be accessed and
manipulated. In turn, XOM API provides a set of standard functions that perform
common operations on these objects in a workspace. Two different APIs can share
information by copying data from one workspace to another.


ΓòÉΓòÉΓòÉ 7.1.1. OM Object Attributes ΓòÉΓòÉΓòÉ

OM objects are composed of OM attributes. OM objects can contain zero or more
OM attributes. Every OM attribute has zero or more values. An attribute
comprises an integer that indicates the attribute's type. Each value is
accompanied by an integer that indicates that value's syntax.

An OM attribute type is a category into which all the values of an OM attribute
are placed on the basis of its purpose. Some OM attributes can either have
zero, one, or multiple values. The OM attribute type is used as the name of the
OM attribute.

A syntax is a category into which a value is placed on the basis of its form.
OM_S_PRINTABLE_STRING is an example of a syntax.

An OM attribute value is an information item that can be viewed as a
characteristic or property of the OM object of which it is a part.

OM attribute types and syntaxes have integer values and symbolic equivalents
assigned to them for ease of use by naming authorities in the various API
specifications. The integers that are assigned to the OM attribute type and
syntax are fixed, but the attribute values can change. These OM attribute types
and syntaxes are defined in the DCE implementation of XDS and XOM APIs in
header files that are included with the software along with additional OM
attributes specific to the DCE implementation.

The following figure shows the internal structure of an OM object.


The Internal Structure of an OM Object

For example, the tables in "Mapping the Class Definition of
DS_C_ENTRY_INFO_SELECTION" show the OM attributes, syntax, and values for the
OM class DS_C_ENTRY_INFO_SELECTION, and how the integer values are mapped to
corresponding names in the xom.h and xds.h header files. See XDS Class
Definitions for a complete description of DS_C_ENTRY_INFO_SELECTION and the
accompanying table.

DS_C_ENTRY_INFO_SELECTION is a subclass of OM_C_OBJECT. This information is
supplied in the description of this OM class in XDS Class Definitions. As such,
DS_C_ENTRY_INFO_SELECTION inherits the OM attributes of OM_C_OBJECT. The only
OM attribute of OM_C_OBJECT is OM_CLASS. OM_CLASS identifies the object's OM
class, which in this case is DS_C_ENTRY_INFO_SELECTION.
DS_C_ENTRY_INFO_SELECTION identifies information to be extracted from a
directory entry and has the following OM attributes, in addition to those
inherited from OM_C_OBJECT:

   o  DS_ALL_ATTRIBUTES
   o  DS_ATTRIBUTES_SELECTED
   o  DS_INFO_TYPE

 As part of an XDS function call, DS_ALL_ATTRIBUTES specifies to the Directory
 Service whether all the attributes of a directory entry are relevant to the
 application program. It can take the values OM_TRUE or OM_FALSE. These values
 are defined to be of syntax OM_S_BOOLEAN. The value OM_TRUE indicates that
 information is requested on all attributes in the directory entry. The value
 OM_FALSE indicates that information is only requested on those attributes that
 are listed in the OM attribute DS_ATTRIBUTES_SELECTED.

 DS_ATTRIBUTES_SELECTED lists the types of attributes in the entry from which
 information is to be extracted. The syntax of the value is specified as
 OM_S_OBJECT_IDENTIFIER_STRING.

 OM_S_OBJECT_IDENTIFIER_STRING contains an octet string of integers that are
 BER encoded object identifiers of the types of OM attributes in the OM
 attribute list. The value of DS_ATTRIBUTES_SELECTED is only significant if the
 value of DS_ALL_ATTRIBUTES is OM_FALSE, as described previously.

 DS_INFO_TYPE identifies what information is to be extracted from each OM
 attribute identified. The syntax of the value is specified as
 Enum(DS_INFORMATION_TYPE). DS_INFO_TYPE is an enumerated type that has two
 possible values:  DS_TYPES_ONLY and DS_TYPES_AND_VALUES. DS_TYPES_ONLY
 indicates that only the attribute types in the entry are returned by the
 Directory Service operation. DS_TYPES_AND_VALUES indicates that both the types
 and the values of the attributes in the directory entry are returned.

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  Γöé Table 2. OM Attributes of a OM_C_OBJECT                         Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé          Γöé                    Γöé  VALUE  Γöé  VALUE  Γöé  VALUE Γöé
  Γöé ATTRIBUTE     Γöé VALUE SYNTAX              Γöé  LENGTH Γöé  NO.  Γöé  INI-  Γöé
  Γöé          Γöé                    Γöé     Γöé     Γöé TIALLY Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé OM_CLASS      Γöé String(OM_S_OBJECT_IDENTIFIER_STRING) Γöé   -   Γöé   1   Γöé   -  Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  Γöé Table 3. OM Attributes of a DS_ENTRY_INFO_SELECTION                   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé ATTRIBUTE     Γöé VALUE SYNTAX         Γöé  VALUE  Γöé  VALUE  Γöé VALUE INITIALLY  Γöé
  Γöé          Γöé               Γöé  LENGTH Γöé  NO.  Γöé          Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_ALL_ATTRIBUTES Γöé OM_S_BOOLEAN         Γöé   -   Γöé   1   Γöé OM_TRUE      Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_ATTRIBUTES   Γöé String(OM_S_OBJECT      Γöé   -   Γöé  0 or  Γöé -         Γöé
  Γöé _SELECTED     Γöé _IDENTIFIER_STRING)     Γöé     Γöé  more  Γöé          Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_INFO_TYPE    Γöé Enum(DS_Information_Type)  Γöé   -   Γöé   1   Γöé DS_TYPES_AND_   Γöé
  Γöé          Γöé               Γöé     Γöé     Γöé VALUES      Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ


  Mapping the Class Definition of DS_C_ENTRY_INFO_SELECTION

 A typical Directory Service operation, such as a read operation (ds_read),
 requires the entry_information_selection parameter to specify to the Directory
 Service the information to be extracted from the directory entry. This
 entry_information_selection parameter is built by the application program as a
 public object (Public Objects describes how to create a public object), and is
 included as a parameter to the ds_read function call, as shown in the
 following code fragment from example.c:

  /*
  * Public Object ("Descriptor List") for
  * Entry-Information-Selection
  * parameter to ds_read.
  */
  OM_descriptor selection[] = {
  OM_OID_DESC(OM_CLASS,DS_C_ENTRY_INFO_SELECTION),
  { DS_ALL_ATTRIBUTES, OM_S_BOOLEAN,{ OM_FALSE, NULL } },
  OM_OID_DESC(DS_ATTRIBUTES_SELECTED, DS_A_TELEPHONE_NUMBER),
  { DS_INFO_TYPE,OM_S_ENUMERATION,{ DS_TYPES_AND_VALUES,NULL } },
  OM_NULL_DESCRIPTOR
  };

  CHECK_DS_CALL(ds_read(session, DS_DEFAULT_CONTEXT,
                 name, selection, &result, &invoke_id));.


ΓòÉΓòÉΓòÉ 7.1.2. Object Identifiers ΓòÉΓòÉΓòÉ

OM classes are uniquely identifiable by means of ASN.1 object identifiers. OM
classes have mandatory and optional OM attributes. Each OM attribute has a
type, value, and syntax. OM objects are instances of OM classes that are
uniquely identifiable by means of ASN.1 object identifiers. The syntax of
values defined for these OM object classes and OM attributes are
representations at a higher level of abstraction so that implementers can
provide the necessary high-level language binding for their own implementations
of the various application interfaces, such as XDS API.

The DCE implementation uses the C language to define the internal
representation of OM classes and OM attributes. These definitions are supplied
in the header files that are included as part of the XDS and XOM API.

OM classes are defined as symbolic constants that correspond to ASN.1 object
identifiers. An ASN.1 object identifier is a sequence of integers that uniquely
identifies a specific class. OM attribute type and syntax are defined as
integer constants. These standardized definitions provide application programs
with a uniform and stable naming environment in which to perform directory
operations. Registration authorities are responsible for allocating the unique
object identifiers.

The following code fragment from the xdsbdcp.h (the Basic Directory Contents
Package) header file contains the symbolic constant OMP_O_DS_A_COUNTRY_NAME:

#ifndef dsP_attributeType /* joint-iso-ccitt(2) ds(5)
attributeType(4) */
#define dsP_attributeType(X) ("\x55\xo4" #X)
#endif

#define OMP_O_DS_A_COUNTRY_NAME      dsp_attributeType(\x06)

It resolves to 2.5.4.6, which is the object identifier value for the Country
Name attribute type as defined in the directory standard. The symbolic constant
for the directory object class Country resolves to 2.5.6.2, the corresponding
object identifier in the directory standard. OM classes are defined in the
header files in the same manner.

Note:  2.5.4.6 and 2.5.6.2 are object identifiers defined by the standards, not
       the BER encoding found in the header file which are \x55\x04\x06 and
       \x55\x06\x02.


ΓòÉΓòÉΓòÉ 7.1.3. C Naming Conventions ΓòÉΓòÉΓòÉ

In the DCE implementation of XDS and XOM APIs, all object identifiers start
with the letters ds, DS, MH, or OMP. Note that the interface reserves all
identifiers starting with the letters dsP and omP for internal use by
implementations of the interface. It also reserves all identifiers starting
with the letters dsX, DSX, omX, and OMX for vendor specific extensions of the
interface. Applications programmers should not use any identifier starting with
these letters.

The C identifiers for interface elements are formed using the following
conventions:

   o  XDS API function names are specified entirely in lowercase letters, and
      are prefixed by ds_(for example, ds_read).

   o  XOM API function names are specified entirely in lowercase letters, and
      are prefixed by om_(for example, om_get).

   o  C function parameters are derived from the parameter and result names and
      are specified entirely in lowercase letters. In addition, the names of
      results have _return added as a suffix (for example,
      operation_status_return).

   o  OM class names are specified entirely in uppercase letters, and are
      prefixed by DS_C_ and MH_C_ (for example, DS_C_AVA).

   o  OM attribute names are specified entirely in uppercase letters, and are
      prefixed by DS_ and MH_ (for example, DS_RDNS).

   o  OM syntax names are specified entirely in uppercase letters, and are
      prefixed by OM_S_(for example, OM_S_PRINTABLE_STRING).

   o  Directory class names are specified entirely in uppercase letters, and
      are prefixed by DS_O(for example, DS_O_ORG_PERSON).

   o  Directory attribute names are specified entirely in uppercase letters,
      and are prefixed by DS_A (for example, DS_A_COUNTRY_NAME).

   o  Errors are treated as a special case. Constants that are the possible
      values of the OM attribute DS_PROBLEM of a subclass of the OM class
      DS_C_ERROR are specified entirely in uppercase letters, and are prefixed
      by DS_E_(for example, DS_E_BAD_CLASS).

   o  The constants in the Value Length and Value Number columns of the OM
      class definition tables are also assigned identifiers. Where the upper
      limit in one of these columns is not 1, it is given a name that consists
      of the OM attribute name, prefixed by DS_VL_ for value length, or DS_VN_
      for value number.

   o  The sequence of octets for each object identifier is also assigned an
      identifier for internal use by certain OM macros. These identifiers are
      all uppercase letters and are prefixed by OMP_O_.

 The following summarizes the XDS and XOM naming conventions.


ΓòÉΓòÉΓòÉ 7.1.3.1. C Naming Conventions for XDS ΓòÉΓòÉΓòÉ

 Item                                                     Prefix

 Reserved for implementers                                dsP

 Reserved for interface extensions                        dsX

 Reserved for interface extensions                        DSX

 XDS functions                                            ds

 Error problem values                                     DS_E_

 OM class names                                           DS_C_,MH_C_

 OM attribute names                                       DS_,MH_

 OM value length limits                                   DS_VL_

 OM value number limits                                   DS_VN_

 Other constants                                          DS_,MH_

 Attribute type                                           DS_A_

 Object class                                             DS_O_


ΓòÉΓòÉΓòÉ 7.1.3.2. Naming Conventions for XOM ΓòÉΓòÉΓòÉ

 Element Type                                             Prefix

 Data type                                                OM_

 Data value                                               OM_

 Data value (class)                                       OM_C_

 Data value (syntax)                                      OM_S_

 Data value component (structure member)                  None

 Function                                                 om_

 Function parameter                                       None

 Function result                                          None

 Macro                                                    OM_

 Reserved for use by implementers                         OMP

 Reserved for use by implementers                         omP

 Reserved for proprietary extension                       omX

 Reserved for proprietary extension                       OMX


ΓòÉΓòÉΓòÉ 7.1.4. Public Objects ΓòÉΓòÉΓòÉ

The ultimate aim of an application program is access to the directory to
perform some operation on the contents of the directory. A user can request the
telephone number or electronic mail address of a fellow employee. In order to
access this information, the application performs a read operation on the
directory so that information is extracted about a target object in the
directory and manipulated locally within the application.

XDS functions that perform directory operations, such as ds_read, require
public and private objects as input parameters. Typically, a public object is
generated by an application program and contains the information required to
access a target directory object. This information includes the AVAs and RDNs
that make up a distinguished name of an entry in the directory. However, an
application program can also generate a private object. Private objects are
described in Private Objects.

A public object is created using OM classes and OM attributes. These OM classes
and OM attributes model the target object entry in the directory and provide
other information required by the Directory Service to access the directory.


ΓòÉΓòÉΓòÉ 7.1.4.1. Descriptor Lists ΓòÉΓòÉΓòÉ

A public object is represented by a sequence of OM_descriptor data structures
that is built by the application program. A descriptor contains the type,
syntax, and value for an OM attribute in a public object.

The data structure OM_descriptor is defined in the xom.h header file as
follows:

typedef struct OM_descriptor_struct {
        OM_type                    type;
        OM_syntax                  syntax;
        union OM_value_union       value;
}OM_descriptor;

The following figure shows the representation of a public object in a
descriptor list. The first descriptor in the list indicates the object's OM
class; the last descriptor is a NULL descriptor that signals the end of the
list of OM attributes. In between the first and the last descriptor are the
descriptors for the OM attributes of the object.


A Representation of a Public Object Using a Descriptor List

For example, the following represents the public object country in example.c.

static OM_descriptor        country[] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_COUNTRY_NAME),
 { DS_ATTRIBUTE_VALUES,OM_S_PRINTABLE_STRING, OM_STRING("US") },
 OM_NULL_DESCRIPTOR
 };

The descriptor list is an array of data type OM_descriptor that defines the OM
class, OM attribute types, syntax, and values that make up a public object.

The first descriptor gives the OM class of the object. The OM class of the
object is defined by the OM attribute type, OM_CLASS. The OM_OID_DESC macro
initializes the syntax and value of an object identifier, in this case to OM
class DS_C_AVA, with syntax of OM_S_OBJECT_IDENTIFIER_STRING.
OM_S_OBJECT_IDENTIFIER_STRING is an OM syntax type that is assigned by
definition in the macro to any OM attribute type and value parameters input to
it.

The second descriptor defines the first OM attribute type, DS_ATTRIBUTE_TYPE,
which has as its value DS_A_COUNTRY_NAME and syntax
OM_S_OBJECT_IDENTIFIER_STRING.

The third descriptor specifies the AVA of an object entry in the directory. The
OM_OID_DESC macro is not used here because OM_OID_DESC is only used to
initialize values having OM_S_OBJECT_IDENTIFIER_STRING syntax. The OM attribute
type is DS_ATTRIBUTE_VALUES, the syntax is OM_S_PRINTABLE_STRING, and the value
is US. The OM_STRING macro creates a data value for a string data type (data
type OM_string), in this case OM_S_PRINTABLE_STRING. A string is specified in
terms of its length or whether or not it terminates with a NULL. The OM_STRING
macro is described in The OM_STRING Macro.

The last descriptor is a NULL descriptor that marks the end of the public
object definition. It is defined in the xom.h header file as follows:

#define OM_NULL_DESCRIPTOR      \
{ OM_NO_MORE__TYPES, OM_S_NO_MORE_SYNTAXES,{ { 0, OM_ELEMENTS_UNSPECIFIED } } }

OM_NULL_DESCRIPTOR is OM attribute type OM_NO_MORE_TYPES, syntax
OM_S_NO_MORE_SYNTAXES, and value OM_ELEMENTS_UNSPECIFIED.

"A Descriptor List for the Public Object: country" shows the composition of a
descriptor list representing a public object.


A Descriptor List for the Public Object: country


ΓòÉΓòÉΓòÉ 7.1.5. Building the Distinguished Name as a Public Object ΓòÉΓòÉΓòÉ

Recall that RDNs are built from AVAs and a distinguished name is built from a
series of RDNs. In a typical application program, several AVAs are defined in
descriptor lists as public objects. These public objects are incorporated into
descriptor lists that represent corresponding RDNs. Finally, the RDNs are
incorporated into one descriptor list that represents the distinguished name of
an object in the directory, as shown in the following figure. This descriptor
list is included as one of the input parameters to a Directory Service
function.

The following code fragment from example.c shows how a distinguished name is
built as a public object. The public object is the name parameter for a
subsequent read operation call to the directory. The representation of a
distinguished name in the DIT is shown in "The Distinguished Name of Peter in
the DIT".


The Distinguished Name of Peter in the DIT

The first section of code defines the four AVAs. These AVAs make the assertion
to the Directory Service that the attribute values in the distinguished name of
Peter are valid and can therefore be read from the directory. The country name
is US, the organization name is ibm, the organizational unit name is austin,
and the CDS name is Peter.

/*
 * Public Object ("Descriptor List") for Name parameter to
 * ds_read.
 * Build the Distinguished-Name of Peter Piper  */

static OM_descriptor        country[] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_COUNTRY_NAME),
 { DS_ATTRIBUTE_VALUES,OM_S_PRINTABLE_STRING, OM_STRING("US") },
 OM_NULL_DESCRIPTOR
 };
static OM_descriptor        organization[] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_ORG_NAME),
 { DS_ATTRIBUTE_VALUES,OM_S_TELETEX_STRING, OM_STRING("ibm") },
 OM_NULL_DESCRIPTOR
 };
static OM_descriptor        organizational_unit[] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_ORG_UNIT_NAME),
 { DS_ATTRIBUTE_VALUES,OM_S_TELETEX_STRING, OM_STRING("austin") },
 OM_NULL_DESCRIPTOR
 };
static OM_descriptor        cds_name[] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_TYPELESS_RDN),
 { DS_ATTRIBUTE_VALUES,OM_S_TELETEX_STRING, OM_STRING("Peter")},
 OM_NULL_DESCRIPTOR
 };

The next section of code is nested one level above the previously defined AVAs.
Each RDN has a descriptor with OM attribute type DS_AVAS (indicating that it is
OM attribute type AVA), a syntax of OM_S_OBJECT, and a value of the name of the
descriptor array defined in the previous section of code for an AVA. The rdn1
descriptor contains the descriptor list for the AVA country, the rdn2
descriptor contains the descriptor list for the AVA organization, and so on.

OM_S_OBJECT is a syntax that indicates that its value is a subobject. For
example, the value for DS_AVAS is the previously defined object country. In
this manner a hierarchy of linked objects and subobjects can be constructed.

static OM_descriptor        rdn1[] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
 { DS_AVAS, OM_S_OBJECT, { 0, country } },
 OM_NULL_DESCRIPTOR
 };
static OM_descriptor        rdn2[] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
 { DS_AVAS, OM_S_OBJECT, { 0, organization } },
 OM_NULL_DESCRIPTOR
 };
static OM_descriptor        rdn3[] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
 { DS_AVAS, OM_S_OBJECT, { 0, organization_unit  } },
 OM_NULL_DESCRIPTOR
 };
static OM_descriptor        rdn4[] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
 { DS_AVAS, OM_S_OBJECT, { 0, cds_name } },
 OM_NULL_DESCRIPTOR
 };

The next section of code contains the RDNs that make up the distinguished name,
which is stored in the array of descriptors called name. It is made up of the
OM class DS_C_DS_DN (representing a distinguished name) and four RDNs of OM
attribute type DS_RDNS and syntax OM_S_OBJECT.

OM_descriptor       name[] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_DN),
 { DS_RDNS, OM_S_OBJECT, { 0, rdn1 } },
 { DS_RDNS, OM_S_OBJECT, { 0, rdn2 } },
 { DS_RDNS, OM_S_OBJECT, { 0, rdn3 } },
 { DS_RDNS, OM_S_OBJECT, { 0, rdn4 } },
 OM_NULL_DESCRIPTOR
 };

In summary, the distinguished name for Peter is stored in the array of
descriptors called name, which is composed of three nested levels of arrays of
descriptors (see "Building a Distinguished Name"). The definitions for the AVAs
are at the innermost level, the definitions for RDNs are at the next level up,
and the distinguished name is at the top level.


Building a Distinguished Name

"A Simplified View of the Structure of a Distinguished Name" shows a more
general view of the structure distinguished name.


A Simplified View of the Structure of a Distinguished Name

The name descriptor defines a public object that is provided as the name
parameter required by the XDS API read function call, ds_read, as follows (XDS
API function calls are described in detail in XDS Programming):

CHECK_DS_CALL(ds_read(session, DS_DEFAULT_CONTEXT,
                    name, selection, &result, &invoke_id));

The result of the ds_read function call is in a private implementation-specific
format; it is stored in a workspace and pointed to by result. The application
program must use XOM function calls (described in OM Function Calls) to
interpret the data and extract the information. This extraction process
involves uncovering the nested data structures in a series of XOM function
calls.


ΓòÉΓòÉΓòÉ 7.1.6. Client-Generated and Service-Generated Public Objects ΓòÉΓòÉΓòÉ

There are two types of public objects - service-generated objects and
client-generated objects. The distinguished name object described in the
previous section is a client-generated public object because an application
program (the client) created the data structure. As the creator of the public
object, it is the responsibility of the application program to manage the
memory resources allocated for it.

Service-generated public objects are created by the XOM service.
Service-generated public objects can be generated as a result of an XOM
request. An XOM API function, such as om_get, converts a private object into a
service-generated public object. This is necessary because XDS can return a
pointer to data in private format that can only be interpreted by XOM functions
such as om_get.

For example, "Client-Generated and Service-Generated Objects" shows how the
read request described in the previous example returns a pointer to an encoded
data structure stored in result. This encoded data structure, referred to as a
private object (described in the next section) is one of the input parameters
to om_get. The om_get function provides a pointer to a public object (in this
case, entry) as an output parameter. The public object is a data structure that
has been interpreted by om_get and is accessible by the application program
(the client). The information requested by the application in the read request
is contained in the output parameter entry.


Client-Generated and Service-Generated Objects

The application program is responsible for managing the storage (memory) for
the service-generated public object. This is an important point because it
requires that the application issue a series of om_delete calls to delete the
service-generated public object from memory. Because the data structures
involved with Directory Service requests can be very large, it is imperative
that the application programmer build into any application program the
efficient management of memory resources.

The following code fragment from example.h demonstrates how storage for public
and private objects is released using a series of om_delete function calls
after they are no longer needed by the application program. The data (a list of
phone numbers associated with the name Peter required by the application
program) has already been extracted using a series of om_get function calls:

/*  We can now safely release all the private objects
*  and the public objects we no longer need
*/
CHECK_OM_CALL(om_delete(session));
CHECK_OM_CALL(om_delete(result));
CHECK_OM_CALL(om_delete(entry));
CHECK_OM_CALL(om_delete(attributes));


ΓòÉΓòÉΓòÉ 7.2. Private Objects ΓòÉΓòÉΓòÉ

Private objects are created dynamically by the service interface. In
Client-Generated and Service-Generated Public Objects the ds_read function
returns a pointer to the data structure result in the workspace. This
service-generated data structure is a private object in a private
implementation-specific format, which requires a call to om_get to interpret
the data. A private object is one of the required input parameters to XOM API
functions (such as om_get), as shown in "Client-Generated and Service-Generated
Objects". Private objects are always service generated.

The following table compares private and public objects.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 4. Comparison of Private and Public Objects                    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé PRIVATE                   Γöé PUBLIC                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Representation is implementation specific  Γöé Representation is defined in the API    Γöé
Γöé                       Γöé specification               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Not directly accessible by the client    Γöé Directly accessible by the client     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Manipulated by the client using OM func-  Γöé Manipulated by the client using program-  Γöé
Γöé tions                    Γöé ming constructs              Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Created in storage provided by the service Γöé Is a service-generated object if created  Γöé
Γöé                       Γöé by the service               Γöé
Γöé                       Γöé                      Γöé
Γöé                       Γöé Is a client-generated object if created  Γöé
Γöé                       Γöé by the client in storage provided by the  Γöé
Γöé                       Γöé client                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Cannot be modified by the client directly, Γöé If a client-generated object, can be mod- Γöé
Γöé except through the service interface    Γöé ified directly by the client        Γöé
Γöé                       Γöé                      Γöé
Γöé                       Γöé If a service-generated object, cannot be  Γöé
Γöé                       Γöé modified directly by the client, except  Γöé
Γöé                       Γöé through the service interface       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Storage is allocated and released by the  Γöé If a service-generated object, storage is Γöé
Γöé service                   Γöé allocated and released by the service   Γöé
Γöé                       Γöé                      Γöé
Γöé                       Γöé If a client-generated object, storage is  Γöé
Γöé                       Γöé allocated and released by the client    Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

Private objects can also be used as input to XOM and XDS API functions to
improve program efficiency. For example, the output of a ds_compare request can
be used as input to a ds_read. The compare request may return the distinguished
name of the target object (present if the passed name was dereferenced). If
present, the target name private object may be used as input to the ds_read
operation.


ΓòÉΓòÉΓòÉ 7.3. Object Classes ΓòÉΓòÉΓòÉ

Objects are categorized into OM classes based on their purpose and internal
structure. An object is an instance of its OM class. An OM class is
characterized by OM attribute types that can appear in its instances. An OM
class is uniquely identified by an ASN.1 object identifier.

Later in this section, it will be shown how OM classes are organized into
groups of OM classes, called packages, that support some aspect of the
Directory Service.


ΓòÉΓòÉΓòÉ 7.3.1. OM Class Hierarchy and Inheritance Properties ΓòÉΓòÉΓòÉ

OM classes are related to each other in a tree hierarchy whose root is a
special OM class called OM_C_OBJECT. Each of the other OM classes is the
immediate subclass of precisely one other OM class. This tree structure is
known as the OM class hierarchy. It is important because of the property of
inheritance. The OM class hierarchy is defined by the XDS/XOM. DCE implements
this hierarchy for XDS/XOM.

The OM attribute types that can exist in an instance of an OM class but not in
an instance of an OM class above it in the tree hierarchy are said to be
specific to that OM class. OM Attributes that can appear in an object are those
specific to its OM class as well as those inherited from OM classes above it in
the tree. OM classes above an instance of an OM class in the tree are
superclasses of that OM class. OM classes below an instance of an OM class are
subclasses of that OM class.

For example, as shown in "The OM Class DS_C_ENTRY_INFO_SELECTION",
DS_C_ENTRY_INFO_SELECTION inherits its OM attributes from its superclass
OM_C_OBJECT. The OM attributes DS_ALL_ATTRIBUTES, DS_ATTRIBUTES_SELECTED, and
DS_INFO_TYPE are attributes specific to the OM class DS_C_ENTRY_INFO_SELECTION.
The DS_C_ENTRY_INFO_SELECTION class has no subclasses.


The OM Class DS_C_ENTRY_INFO_SELECTION

Another important point about OM class inheritance is that an instance of an OM
class is also considered to be an instance of each of its superclasses and can
appear wherever the interface requires an instance of any of those
superclasses. For example, DS_C_DS_DN is a subclass of DS_C_NAME. Everywhere in
an application program where DS_C_NAME is expected at the interface (as a
parameter to ds_read, for example), it is permitted to supply DS_C_DS_DN.


ΓòÉΓòÉΓòÉ 7.3.2. Abstract and Concrete Classes ΓòÉΓòÉΓòÉ

OM classes are defined as abstract or concrete.

An abstract OM class is an OM class in which instances are not permitted. An
abstract OM class can be defined so that subclasses can share a common set of
OM attributes between them.

In contrast to abstract OM classes, instances of OM concrete classes are
permitted. However, the definition of each OM concrete class can include the
restriction that a client not be allowed to create instances of that OM class.
For example, consider two alternative means of defining the OM classes used in
XDS: DS_C_LIST_INFO and DS_C_READ_RESULT. DS_C_LIST_INFO and DS_C_READ_RESULT
are subclasses of the abstract OM class DS_C_COMMON_RESULT.

"A Comparison of Two Classes With and Without an Abstract OM Class" shows the
relationship of DS_C_LIST_INFO and DS_C_READ_RESULTS when the abstract OM class
DS_C_COMMON_RESULT is defined and when it is not defined. It demonstrates that
the presence of an abstract OM class enables the programmer to develop
applications that process information more efficiently.


A Comparison of Two Classes With and Without an Abstract OM Class

The following list contains the hierarchy of concrete and abstract OM classes
in the Directory Service Package. Abstract OM classes are shown in italics. The
indentation shows the class hierarchy; for example, the abstract class
OM_C_OBJECT is a superclass of the abstract class DS_C_COMMON_RESULTS, which in
turn is a superclass of the concrete class DS_C_COMPARE_RESULT.

OM_C_OBJECT

   o  DS_C_ACCESS_POINT
   o  DS_C_ADDRESS
        -  DS_C_PRESENTATION_ADDRESS
   o  DS_C_ATTRIBUTE
        -  DS_C_AVA
        -  DS_C_ENTRY_MOD
        -  DS_C_FILTER_ITEM
   o  DS_C_ATTRIBUTE_ERROR
   o  DS_C_ATTRIBUTE._LIST
        -  DS_C_ENTRY_INFO
   o  DS_C_COMMON_RESULTS
        -  DS_C_COMPARE_RESULT
        -  DS_C_LIST_INFO
        -  DS_C_READ_RESULT
        -  DS_C_SEARCH_INFO
   o  DS_C_CONTEXT
   o  DS_C_CONTINUATION_REF
        -  DS_C_REFERRAL
   o  DS_C_ENTRY_INFO_SELECTION
   o  DS_C_ENTRY_MOD_LIST
   o  DS_C_ERROR
        -  DS_C_ABANDON_FAILED
        -  DS_C_ATTRIBUTE_PROBLEM
        -  DS_C_COMMUNICATIONS_ERROR
        -  DS_C_LIBRARY_ERROR
        -  DS_C_NAME_ERROR
        -  DS_C_SECURITY_ERROR
        -  DS_C_SYSTEM_ERROR
        -  DS_C_SECURITY_ERROR
        -  DS_C_UPDATE_ERROR
   o  DS_C_EXT
   o  DS_C_FILTER
   o  DS_C_LIST_INFO_ITEM
   o  DS_C_LIST_RESULT
   o  DS_C_NAME
        -  DS_C_DS_DN
   o  DS_C_OPERATION_PROGRESS
   o  DS_C_PARTIAL_OUTCOME_QUAL
   o  DS_C_RELATIVE_NAME
        -  DS_C_DS_RDN
   o  DS_SEARCH_RESULT
   o  DS_C_SESSION

 In summary, an OM class is defined with the following elements:

   o  OM class name (indicated by an object identifier)
   o  Identity of its immediate superclass
   o  Definitions of the OM attribute types specific to the OM class
   o  Indication whether the OM class is abstract or concrete
   o  Constraints on the OM attributes

 A complete description of OM classes, OM attributes, syntaxes, and values that
 are defined for XDS and XOM APIs are described in this guide. Tables and
 textual descriptions, such as the one shown in "A Complete Description of the
 Concrete OM Class DS_C_ATTRIBUTE" for the concrete OM class DS_C_ATTRIBUTE,
 are also provided in this guide for each OM class.


  A Complete Description of the Concrete OM Class DS_C_ATTRIBUTE

 "A Complete Description of the Concrete OM Class DS_C_ATTRIBUTE" provides
 information under the following headings:

 OM Attribute        The name of each of the OM attributes

 Value Syntax        The syntaxes of each of the OM attribute's values

 Value Length        Any constraints on the number of bits, octets, or
                     characters in each value that is a string

 Value Number        Any constraints on the number of values

 Value Initially     Any value with which the OM attribute can be initialized

 An OM class can be constrained to contain only one member of a set of OM
 attributes. In turn, OM attributes can be restricted to having no more than a
 fixed number of values, either 0 (zero) or 1 as an optional value, or exactly
 one mandatory value.

 An OM attribute's value can be also constrained to a single syntax. That
 syntax can be further restricted to a subset of defined values.

 An object passed as a parameter to an XOM and XDS function call needs to meet
 a minimum set of conditions:

   o  The type of each OM attribute must be specific to the object's OM class
      or one of its superclasses.

   o  The number of values of each OM attribute must be within OM class limits.

   o  The syntax of each value must be among those the OM class permits.

   o  The number of bits, octets, or characters in each string value must be
      within OM class limits.


ΓòÉΓòÉΓòÉ 7.4. Packages ΓòÉΓòÉΓòÉ

A package is a collection of OM classes that are grouped together, usually by
function. The packages themselves are features that are negotiated with the
Directory Service using the XDS function ds_version. Consider what OM classes
will be required for your application programs and determine the packages that
contain these OM classes.

A package is uniquely identified by an ASN.1 object identifier. DCE XDS API
supports four packages of which one is mandatory and three are optional:

   o  The Directory Service Package (mandatory)
   o  The Basic Directory Contents Package (optional)
   o  The Global Directory Service Package (optional; not used for CDS)
   o  The MHS Directory User Package (optional; not used for CDS)


ΓòÉΓòÉΓòÉ 7.4.1. The Directory Service Package ΓòÉΓòÉΓòÉ

The Directory Service Package is the default package and as such does not
require negotiation. The optional packages have to be negotiated with the
Directory Service using the ds_version function.

The object identifiers for specific packages are defined in header files that
are part of the XDS API and XOM API. An object identifier consists of a string
of integers. The header files include #define preprocessor statements that
assign names to these constants in order to make them more readable. These
assignments alleviate the application programmer from the burden of maintaining
these strings of integers. For example, the object identifiers for the
Directory Service Package are defined in xds.h. The xds.h header file contains
OM class and OM attribute names, OM object constants, and defines prototypes
for XDS API functions, as shown in the following code fragment from the xds.h
file.

/* DS package object identifier */
/* {iso(1) identifier-organization(3) icd-ecma(12)
 *  member-company(2)
 *  dec(1011) xopen(28) dsp(0) } */

#define OMP_O_DS_SERVICE_PKG   "\x2B\x0C\x02\x87\x73\xlC\x00"

A ds_version function call must be included within an application program to
negotiate the optional features (packages) with the Directory Service. The
first step is to build an array of object identifiers for the optional packages
to be negotiated (the Basic Directory Contents Package and the Global Directory
Service Package), as shown in the following code fragment from the acl.h header
file:

DS_feature features [ ] = {
 { OM_STRING(OMP_O_DS_BASIC_DIR_CONTENTS_PKG), OM_TRUE },
 { 0 }
{;

The OM_STRING macro is provided for creating a data value of data type
OM_string for octet strings and characters. XOM API macros are described in XOM
API Macros.

The array of object identifiers is stored in features, and passed as an input
parameter to ds_version, as shown in the following code fragment:

/* Negotiate the use of the BDCP package. */

if (ds_version(features) != DS_SUCCESS)
  printf("ds_version() error\n");


ΓòÉΓòÉΓòÉ 7.4.2. The Basic Directory Contents Package ΓòÉΓòÉΓòÉ

The Basic Directory Contents Package contains the object identifier definition
of directory classes and attribute types as defined by the X.500 standard.
These definitions allow the creation of and maintenance of directory entries
for a number of common objects so that the representation of all such objects
is the same throughout the directory. Also included are the definitions of the
OM classes and OM attributes required to support the directory attribute types.

Basic Directory Contents Package describes the Basic Directory Contents package
in detail.

The object identifier associated with the Basic Directory Contents Package is
shown in the following code fragment from the xdsbdcp.h header file:

/* BDCP package object identifier */
/* { iso(1) identifier-organization(3) icd-ecma(12)
 *   member-company (2)
 *   dec(1011) xopen(28) bdcp(1) } */

 #define OMP_DS_BASIC_DIR_CONTENTS_PKG
 "\x2B\x0C\x02\x87\x73\x1C\x01"

Note:  The xdsbdcp.h header file must be included.


ΓòÉΓòÉΓòÉ 7.5. Package Closure ΓòÉΓòÉΓòÉ

An OM class can be defined to have an attribute whose OM class is defined in
some other package. This avoids duplication of OM classes. This gives rise to
the concept of a package closure. A package closure is the set of all OM
classes that need to be supported so that all possible instances of all OM
classes can be defined in the package.


ΓòÉΓòÉΓòÉ 7.6. Workspaces ΓòÉΓòÉΓòÉ

Two application-specific APIs or two different implementations of the same
service require work areas, called workspaces, to maintain private and public
(service-generated) objects. The workspace is required because two
implementations of the same service (or different services) can represent
private objects differently. Each one has its own workspace. Using the
functions provided by XOM API, such as om_get and om_copy, objects can be
copied and moved from one workspace to another.

Recall that private objects are returned by a service to a workspace in private
implementation-specific format. Using the OM function calls described in OM
Function Calls the data can be extracted from the private object for further
program processing.

Before a request to the directory can be made by an application program, a
workspace must be created using the appropriate XDS function. An application
creates a workspace by performing the XDS API call ds_initialize. Once the
workspace is obtained, subsequent XDS API calls, such as ds_read, return a
pointer to a private object in the workspace. When program processing is
completed, the workspace is destroyed using the ds_shutdown XDS API function.
Implicit in ds_shutdown is a call to the XOM API function om_delete to delete
each private object the workspace contains.

The programs in the \opt\dcelocal\examples\xdsxom directory demonstrate how to
initialize and shut down a workspace. The XDS functions ds_initialize and
ds_shutdown are described in detail in The ds_initialize Function Call and The
ds_shutdown Function Call, respectively.

The closures of one or more packages are associated with a workspace. A package
can be associated with any number of workspaces. An application program must
obtain a workspace that supports an OM class before it is able to create any
instances of that OM class.


ΓòÉΓòÉΓòÉ 7.7. Storage Management ΓòÉΓòÉΓòÉ

An object occupies storage. The storage occupied by a client-generated public
object is allocated by the client, and is, therefore, directly accessible by
the client and can be released by the client. The storage occupied by a private
object is not accessible by the client and must be managed indirectly using XOM
function calls. Release of service-generated public objects must also be
managed indirectly by the client using the om_delete function.

Objects are accessed by an application program by way of object handles. Object
handles are used as input parameters to interface functions by the client and
returned as output parameters by the service. The object handle for a public
object is simply a pointer to the data structure (an array of descriptors)
containing the object OM attributes. The object handle for a private object is
a pointer to a data structure that is in private implementation-specific format
and therefore inaccessible directly by client.

The client creates a client-generated public object using normal programming
language constructs; for example, static initialization. The client is
responsible for managing any storage involved. The service creates
service-generated public objects and allocates the necessary storage. As
previously mentioned, the client must destroy service-generated public objects
and release the storage by applying the XOM function om_delete to it, as shown
in the following code fragment:

 /*  We can now safely release all the private objects
 *  and the public objects we no longer need
 */
CHECK_OM_CALL(om_delete(session));
CHECK_OM_CALL(om_delete(result));
CHECK_OM_CALL(om_delete(entry));
CHECK_OM_CALL(om_delete(attributes));

The service also creates private objects for which it allocates storage that
must be managed by the application.

One of the input parameters to the ds_read function call is name. The name
parameter is a client-generated public object created by the application from a
series of nested data structures (RDNs and AVAs) to represent the distinguished
name containing Peter. When the application no longer needs the
client-generated public object, it must manage the storage for the
client-generated public object outside the XDS/XOM API. The ds_read call
returns the pointer to a private object, result, deposited in the workspace by
the service.

The program goes on to use the XOM function om_get with the input parameter
result as a pointer to extract attribute values from the returned private
object. The om_get call returns the pointer entry as a service-generated public
object to the program so that the attribute values specified in the call can be
accessed by it. Once the value is extracted, the application program can
continue processing; for example, printing a message to a user with some
extracted value like a phone number or postal address. The service-generated
public object becomes the responsibility of the application program. The
program goes on to release the resources allocated by the service by issuing a
series of calls to om_delete, as shown in the following code fragment from
example.h:

/*
 * extract the telephone number(s) of "name" from the result
 *
 * There are 4 stages:
 * (1) get the Entry-Information from the Read-Result.
 * (2) get the Attributes from the Entry-Information.
 * (3) get the list of phone numbers.
 * (4) scan the list and print each number.
 */
CHECK_OM_CALL(   om_get(result,
            OM_EXCLUDE_ALL_BUT_THESE_TYPES
          + OM_EXCLUDE_SUBOBJECTS,
            entry_list, OM_FALSE, 0, 0, &entry,
            &total_num));
CHECK_OM_CALL(   om_get(entry->value.object.object,
            OM_EXCLUDE_ALL_BUT_THESE_TYPES
          + OM_EXCLUDE_SUBOBJECTS,
            attributes_list, OM_FALSE, 0, 0, &attributes,
            &total_num));
CHECK_OM_CALL(   om_get(attributes->value.object.object,
            OM_EXCLUDE_ALL_BUT_THESE_TYPES
          + OM_EXCLUDE_SUBOBJECTS,
            telephone_list, OM_FALSE, 0, 0, &telephones,
            &total_num));
/*  We can now safely release all the private objects
 *  and the public objects we no longer need
 */
CHECK_OM_CALL(om_delete(session));
CHECK_OM_CALL(om_delete(result));
CHECK_OM_CALL(om_delete(entry));
CHECK_OM_CALL(om_delete(attributes));

If the client possesses a valid handle (or pointer) for an object, it has
access to a private object. If the client does not possess an object handle or
the handle is not a valid one, a private object is inaccessible to the client
and an error is returned to the calling function. In the preceding code
fragment, the handles for the objects stored in entry, attributes, and
telephones are the pointers &entry, &attributes, and &telephones, respectively.


ΓòÉΓòÉΓòÉ 7.8. OM Syntaxes for Attribute Values ΓòÉΓòÉΓòÉ

An OM attribute is made up of an integer uniquely defined within a package that
indicates the OM attribute's type, an integer giving that value's syntax, and
an information item called a value. The syntaxes defined by the XOM API
standard are closely aligned with ASN.1 types and type constructors.

Some syntaxes are described in the standard in terms of syntax templates.

A syntax template defines a group of related syntaxes. The syntax templates
that are defined are as follows:

   o  Enum(*)
   o  Object(*)
   o  String(*)


ΓòÉΓòÉΓòÉ 7.8.1. Enumerated Types ΓòÉΓòÉΓòÉ

An OM attribute with syntax template Enum(*) is an enumerated type
(OM_S_ENUMERATION) and has a set of values associated with that OM attribute.
For example, one of the OM attributes of the OM class DS_C_ENTRY_INFO_SELECTION
is DS_INFO_TYPE. DS_INFO_TYPE is listed in the OM attribute table for
DS_C_ENTRY_INFO_SELECTION in XDS Class Definitions as having a value syntax of
Enum(DS_INFORMATION_TYPE), as shown in the following table. DS_INFO_TYPE takes
one of the following values:

   o  DS_TYPES_ONLY
   o  DS_TYPES_VALUES

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  Γöé Table 5. OM Attributes of a DS_C_ENTRY_INFO_SELECTION                  Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé OM ATTRIBUTE     Γöé VALUE SYNTAX             Γöé VALUEΓöé VALUE Γöé VALUE INI-  Γöé
  Γöé           Γöé                   Γöé LENGTΓöé NUMBERΓöé TIALLY    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_ALL_       Γöé OM_S_BOOLEAN             Γöé  -  Γöé  1  Γöé OM_TRUE   Γöé
  Γöé ATTRIBUTES      Γöé                   Γöé    Γöé    Γöé       Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_ATTRIBUTES_    Γöé String(OM_S_IDENTIFIER_STRING    Γöé  -  Γöé  0 or Γöé -      Γöé
  Γöé OBJECT_SELECTED   Γöé                   Γöé    Γöé  more Γöé       Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_INFO_TYPE     Γöé Enum(DS_INFORMATION_TYPE       Γöé  -  Γöé  1  Γöé DS_TYPES_  Γöé
  Γöé           Γöé                   Γöé    Γöé    Γöé AND_VALUES  Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 The C language representation of the syntax of the OM attribute type
 DS_INFO_TYPE is OM_S_ENUMERATION as defined in the xom.h header file. The
 value of the OM attribute is either DS_TYPES_ONLY or DS_TYPES_AND_VALUES, as
 shown in the following code fragment from example.h:

  /*
   * Public Object ("Descriptor List") for
   * Entry-Information-Selection
   * parameter to ds_read.
   */
   OM_descriptor selection[ ] = {
   OM_OID_DESC(OM_CLASS, DS_C_ENTRY_INFO_SELECTION),
   { DS_ALL_ATTRIBUTES,  OM_S_BOOLEAN, { OM_FALSE, NULL } },
   OM_OID_DESC(DS_ATTRIBUTES_SELECTED, DS_A_TELEPHONE_NUMBER),
   { DS_INFO_TYPE,OM_S_ENUMERATION, { DS_TYPES_AND_VALUES,NULL } },
   OM_NULL_DESCRIPTOR
   };


ΓòÉΓòÉΓòÉ 7.8.2. Object Types ΓòÉΓòÉΓòÉ

An OM attribute with syntax template Object(*) has OM_S_OBJECT as syntax and a
subobject as a value. For example, one of the OM attributes of the OM class
DS_C_DS_DN is DS_RDNS. DS_RDNS is listed in the OM attribute table for DS_DS_DN
as having a value syntax of Object(DS_C_DS_RDN), as shown in the following
table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 6. OM Attributes of a DS_C_DS_DN                         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé          Γöé                    Γöé  VALUE  Γöé  VALUE  Γöé VALUE  Γöé
Γöé OM ATTRIBUTE    Γöé VALUE SYNTAX              Γöé  LENGTH Γöé  NUMBER Γöé INI-  Γöé
Γöé          Γöé                    Γöé     Γöé     Γöé TIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_RDNS      Γöé Object(DS_C_DS_RDN)          Γöé   -   Γöé  0 or  Γöé  -   Γöé
Γöé          Γöé                    Γöé     Γöé  more  Γöé     Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

The C language representation of the syntax of the OM attribute type DS_RDNS is
OM_S_OBJECT, as shown in following code fragment from example.h:

OM_descriptor       name[ ] = {
 OM_OID_DESC(OM_CLASS, DS_C_DS_DN),
 { DS_RDNS, OM_S_OBJECT, { 0, rdn1 } },
 { DS_RDNS, OM_S_OBJECT, { 0, rdn2 } },
 { DS_RDNS, OM_S_OBJECT, { 0, rdn3 } },
 { DS_RDNS, OM_S_OBJECT, { 0, rdn4 } },
 OM_NULL_DESCRIPTOR
 };


ΓòÉΓòÉΓòÉ 7.8.3. Strings ΓòÉΓòÉΓòÉ

An OM attribute with syntax template String(*) specifies the string syntax of
its value. A string is categorized as either a bit string, an octet string, or
a character string. The bits of a bit string, the octets of an octet string, or
the octets of a character string constitute the elements of the string. See
Information Syntaxes for a list of the syntaxes that form the string group.

The value length of a string is the number of elements in the string. Any
constraints on the value length of a string are specified in the appropriate OM
class definitions.

The elements of the string are numbered. The position of the first element is 0
(zero). The positions of successive elements are successive positive integers.

For example, one of the OM attributes of the OM class DS_C_ENTRY_INFO_SELECTION
is DS_ATTRIBUTES_SELECTED. DS_ATTRIBUTES_SELECTED is listed in the OM attribute
table for DS_C_ENTRY_INFO_SELECTION as having a value syntax of
String(OM_S_OBJECT_IDENTIFIER_STRING).


ΓòÉΓòÉΓòÉ 7.8.4. Other Syntaxes ΓòÉΓòÉΓòÉ

The other syntaxes are defined as follows:

   o  OM_S_BOOLEAN - A value of this syntax is Boolean; that is, the value can
      be OM_TRUE or OM_FALSE.

   o  OM_S_INTEGER - A value of this syntax is a positive or negative integer.

   o  OM_S_NULL - The one value of this syntax is a valueless place holder.


ΓòÉΓòÉΓòÉ 7.9. Service Interface Data Types ΓòÉΓòÉΓòÉ

The local variables within an application program that contain the parameters
and results of XDS and XOM API function calls are declared using a standard set
of data types. These data types are defined by typedef statements in the xom.h
header files. Some of the more commonly used data types are described in the
following sections. A complete description of service interface data types is
XOM Service Interface and in DCE for OS/2 Warp: Application Development
Reference.


ΓòÉΓòÉΓòÉ 7.9.1. The OM_descriptor Data Type ΓòÉΓòÉΓòÉ

The OM_descriptor data type is used to describe an OM attribute type, syntax,
and value. A data value of this type is a descriptor, which embodies an OM
attribute value. An array of descriptors can represent all the values of an
object.

OM_descriptor is defined in the xom.h header file as follows:

/* Descriptor */

typedef struct OM_descriptor_struct {
        OM_type                    type;
        OM_syntax                  syntax;
        union OM_value_union       value;
} OM_descriptor;

OM_descriptor is made up of a series of nested data structures, as shown in
"Data Type OM_descriptor_struct".


Data Type OM_descriptor_struct

"Data Type OM_descriptor_struct" shows that type and syntax are integer
constants for an OM attribute type and syntax, as shown in the following code
fragment from example.c:

static OM_descriptor        country [ ] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_COUNTRY_NAME),
 { DS_ATTRIBUTE_VALUES,OM_S_PRINTABLE_STRING,OM_STRING("US"},
 OM_NULL_DESCRIPTOR
 };

The code fragment initializes four descriptors, as shown in the following
figure. The type and syntax evaluate to integers for all four descriptors.


Initializing Descriptors

The value component is a little more complex. "Data Type OM_descriptor_struct"
shows that value is a union of OM_value_union. OM_value_union has five members:
string, boolean, enumeration, integer, and object. The members boolean,
enumeration, and integer have integer values. The string member contains a
string of type OM_string, which is a structure composed of a length and a
pointer to a string of characters. The object member is a structure of type
OM_padded_object that points to another object nested below it. Many OM
attributes have other objects as values. These subobjects, in turn, can have
other subobjects and so on.

For example, as shown in "An Object and a Subordinate Object", the OM class
DS_READ_RESULT has one OM attribute: DS_ENTRY. The syntax of DS_ENTRY is
OM_S_OBJECT with a value of DS_C_ENTRY_INFO, indicating that it points to the
subobject DS_C_ENTRY_INFO. DS_C_ENTRY_INFO has the OM attribute DS_OBJECT_NAME
with the syntax OM_S_OBJECT, indicating that it points to the subobject
DS_C_NAME.


An Object and a Subordinate Object


ΓòÉΓòÉΓòÉ 7.9.2. Data Types for XDS API Function Calls ΓòÉΓòÉΓòÉ

The following code fragment from example.h shows how the data types are used to
declare the variables that contain the output parameters from the XDS API
function calls.

int main(void)
{
  DS_status         error;       /* return value from DS functions          */
  OM_return_code    return_code; /* return value from OM functions  */
  OM_workspace      workspace;  /* workspace for objects        */
  OM_private_object session;    /* session for directory operations      */
  OM_private_object result;     /* result of read operation              */
  OM_sint           invoke_id;  /* Invoke-ID of the read operation       */
  CHECK_DS_CALL((OM_object) !(workspace=ds_initialize()));
  CHECK_DS_CALL(ds_version(bdcp_package, workspace));
  CHECK_DS_CALL(ds_bind(DS_DEFAULT_SESSION, workspace, &session));

The code fragment shows:

   o  The ds_initialize call returns a variable of type OM_workspace
      (workspace) that contains a handle or pointer to a workspace.

   o  The ds_bind call returns a pointer to a variable of type
      OM_private_object (&session). The private object contains the session
      information required by all subsequent XDS API calls, except ds_shutdown.

   o  The ds_read call returns a pointer to the result of a directory read
      request in a variable of type OM_private_object (&results).

   o  The error handing macros CHECK_DS_CALL and CHECK_OM_CALL, defined in the
      example.h header file, use the data types DS_status and OM_return_code,
      respectively, as return values from XDS and XOM API function calls.


ΓòÉΓòÉΓòÉ 7.9.3. Data Types for XOM API Calls ΓòÉΓòÉΓòÉ

The following code fragment from example.h shows how the data types are used to
declare the variables that contain the input and output parameters for the XOM
API function calls.

/*
 * variables to extract the telephone number(s)
 */
 OM_type                  entry_list[]         = { DS_ENTRY, 0 };
 OM_type                  attributes_list[]    = { DS_ATTRIBUTES, 0 };
 OM_type                  telephone_list[]     = { DS_ATTRIBUTE_VALUES, 0 };
 OM_public_object         entry;
 OM_public_object         attributes;
 OM_public_object         telephones;
 OM_descriptor            *telephone;      /* current phone number  */
 OM_value_position        total_num;       /* number of Attribute Descriptors
*/

This code fragment shows:

   o  The series of om_get calls requires a list of OM attribute types that
      identifies the types of OM attributes to be included in the operation.
      The variables entry_list, attribute_list, and telephone_list are declared
      as type OM_type.

   o  The series of om_get calls return pointers to variables of type
      OM_public_object. The om_get call generates public objects that are
      accessible to the application program.

   o  Where the variable total_num is type OM_value_position and is used to
      hold the number of OM descriptors returned by om_get.

 XOM Service Interface contains detailed descriptions of all the data types
 defined by XOM API.


ΓòÉΓòÉΓòÉ 7.10. OM Function Calls ΓòÉΓòÉΓòÉ

XOM API supports general-purpose OM functions defined by the X/Open standards
body that allow an application program to manipulate objects in a workspace.
Summary of OM Function Calls lists the OM function calls and gives a brief
description of each. Using the OM Function Calls illustrates the use of OM
function calls using the om_get call as an example.


ΓòÉΓòÉΓòÉ 7.10.1. Summary of OM Function Calls ΓòÉΓòÉΓòÉ

The following list of XOM API function calls contains a brief description of
each function. See the DCE for OS/2 Warp: Application Development Reference for
a detailed description of the input and output parameters, return codes, and
usage of each function.

 om_copy              Creates an independent copy of an existing private object
                      and all of its subobjects in a specified workspace.

 om_copy_value        Replaces an existing OM attribute value or inserts a new
                      value into a target private object with a copy of an
                      existing OM attribute value found in a source private
                      object.

 om_create            Creates a private object that is an instance of the
                      specified OM class.

 om_delete            Deletes a private or service-generated public object.

 om_get               Creates a new public object that is an exact but
                      independent copy of an existing private object; certain
                      exclusions and/or syntax conversion can be requested for
                      the copy.

 om_instance          Tests to determine if an object is an instance of a
                      specified OM class (includes the case when the object is
                      a subclass of that OM class).

 om_put               Places or replaces copies of the attribute values of the
                      source private or public object into the target private
                      object.

 om_read              Reads a segment of a string attribute from a private
                      object.

 om_remove            Removes and discards values of an attribute of a private
                      object.

 om_write             Writes a segment of a string attribute to a private
                      object.

 om_encode            Not supported by DCE XOM API.

 om_decode            Not supported by DCE XOM API.


ΓòÉΓòÉΓòÉ 7.10.2. Using the OM Function Calls ΓòÉΓòÉΓòÉ

Most application programs require the use of a series of om_get function calls
to create service-generated public objects from which the program can extract
requested information. For this reason, this section uses the operation of
om_get as an example to describe how XOM API functions operate in general.

The following code fragment from example.h shows how a series of om_get
function calls extract a list of telephone numbers from a workspace. The
ds_read function call deposits the private object stored in result in the
workspace and provides access to it by the pointer &result.

/*
 * extract the telephone number(s) of "name" from the result
 *
 * There are 4 stages:
 * (1) get the Entry-Information from the Read-Result.
 * (2) get the Attributes from the Entry-Information.
 * (3) get the list of phone numbers.
 * (4) scan the list and print each number.
 */

CHECK_OM_CALL(   om_get(result,
                   OM_EXCLUDE_ALL_BUT_THESE_TYPES
                 + OM_EXCLUDE_SUBOBJECTS,
                   entry_list, OM_FALSE, 0, 0, &entry,
                   &total_num));

CHECK_OM_CALL(   om_get(entry->value.object.object,
                   OM_EXCLUDE_ALL_BUT_THESE_TYPES
                 + OM_EXCLUDE_SUBOBJECTS,
                   attributes_list, OM_FALSE, 0, 0, &attributes,
                   &total_num));

CHECK_OM_CALL(   om_get(attributes->value.object.object,
                   OM_EXCLUDE_ALL_BUT_THESE_TYPES
                 + OM_EXCLUDE_SUBOBJECTS,
                   telephone_list, OM_FALSE, 0, 0, &telephones,
                   &total_num));

/*  We can now safely release all the private objects
 *  and the public objects we no longer need
 */
CHECK_OM_CALL(om_delete(session));
CHECK_OM_CALL(om_delete(result));
CHECK_OM_CALL(om_delete(entry));
CHECK_OM_CALL(om_delete(attributes));
for (telephone = telephones;
          telephone->type != DS_ATTRIBUTE_VALUES;
          telephone++)
         {
 if (telephone->type   != DS_ATTRIBUTE_VALUES
||  (telephone->syntax & OM_S_SYNTAX) !=
    OM_S_TELETEX_STRING)
     {
(void) fprintf(stderr, "malformed telephone number\en");
        exit(EXIT_FAILURE);
     }

(void) printf("Telephone number: %s\en",
     telephone->value.string.elements);
     }
CHECK_OM_CALL(om_delete(telephones));
CHECK_DS_CALL(ds_shutdown(workspace));

The om_get call makes a copy of all or a selected set of parts of a private
object. The copy is a service-generated public object that is accessible to the
application program. The application program extracts the list of telephone
numbers from this copy.


ΓòÉΓòÉΓòÉ 7.10.3. Required Input Parameters ΓòÉΓòÉΓòÉ

The om_get function requires the following input parameters:

   o  A private object,
   o  A set of exclusions,
   o  A set of OM attributes to be included in the copy,
   o  A flag to indicate whether local string processing is required,
   o  The position of the first value to be copied (the base value), and
   o  The position within each OM attribute that is one beyond the last
      attribute to be included in the copy (indicating the scope of the copy).

 The om_get call returns the following output parameters:

   o  The public object that is a copy of the private object, and
   o  The number of OM attribute descriptors returned in the public object.

 In the code fragment from example.h, the private object result is input to
 om_get.

 The next parameter, the exclusions parameter, reduces the copy to a prescribed
 portion of the original. The exclusions apply to the OM attributes of the
 object, but not to those of subobjects. The possibilities for determining the
 combinations of types, values, subobjects, and descriptors to be excluded
 depend on the creativity of the programmer. For a detailed description of all
 the exclusion possibilities, see the DCE for OS/2 Warp: Application
 Development Reference. The values chosen for the om_get calls in the preceding
 code fragments from example.h are simplified for clarity. These exclusion
 values are as follows:

   o  OM_EXCLUDE_ALL_BUT_THESE_TYPES
   o  OM_EXCLUDE_SUBOBJECTS

 Each value indicates an exclusion, as defined by om_get, and is chosen from
 the set of exclusions; alternatively, the single value OM_NO_EXCLUSIONS can be
 chosen, which selects the entire object. Each value, except OM_NO_EXCLUSIONS,
 is represented by a distinct bit, the presence of the value being represented
 as 1, and its absence as 0 (zero). Multiple exclusions are requested by adding
 or ORing the values that indicate the individual exclusions.

 OM_EXCLUDE_ALL_BUT_THESE_TYPES indicates that the OM attributes included are
 only the ones defined in the list of included types supplied in the next
 parameter, entry_list. OM_EXCLUDE_SUBOBJECTS indicates that for each value
 whose syntax is OM_S_OBJECT, a descriptor containing an object handle for the
 original private subobject is returned, rather than a public copy of it. This
 handle makes that subobject accessible for use in subsequent function calls.
 This exclusion provides a means to examine an object one level at a time. The
 object the handle points to is used in the next om_get call to get the next
 level.

 The entry_list parameter is declared as data type OM_type and initialized as
 an array with two entries (DS_ENTRY and a NULL terminator). DS_ENTRY specifies
 the single OM attribute type included for that om_get call. This call limits
 processing to the one directory entry. The NULL terminator marks the end of
 the OM attribute list.

 The next parameter, OM_FALSE, is just a place holder for a parameter that is
 not supported by XOM local strings. The next two parameters set the initial
 and limiting value to 0 (zero), meaning that no specific values are to be
 excluded.

 The final two parameters are output parameters: entry, a pointer to a
 service-generated public object deposited by om_get in the workspace, and
 total_num, an integer. Both entry and total_num are available for examination
 by the application program.


ΓòÉΓòÉΓòÉ 7.10.4. Extracting the Data from the Read Result ΓòÉΓòÉΓòÉ

The entry parameter contains the result of processing by om_get of the read
parameter generated by the ds_read operation. A successful call to ds_read
returns an instance of OM class DS_C_READ_RESULT in the private object result.
DS_C_READ_RESULT contains the information extracted from the directory entry of
the target object. The following figure shows the relationship of some of the
superclasses, subclasses, and the OM attribute of DS_C_READ_RESULT. Consider
"The Read Result" as a partial map of the contents of result.


The Read Result

The om_get function call creates a public object to make the information
contained in result available to the application program. The entry parameter
is defined as data type OM_public_object. As such, it is composed of several
nested layers of subobjects that contain entry information, OM attributes, and
OM attribute values, as shown in "Extracting Information Using om_get". The
series of om_get calls removes these layers of objects to extract a list of
telephone numbers.


Extracting Information Using om_get

"Extracting Information Using om_get" also shows that the process of exposing
the subobjects continues while the syntax of the subobjects is OM_S_OBJECT. In
effect, example.h is reversing the process of building up a series of public
objects as input to ds_read, namely, the distinguished name of Peter and the
descriptor list for entry_information_selection. The following code fragment
from example.c shows how the syntax of the variable telephones is tested for
valid syntax, in this case, OM_S_TELETEX_STRING:

Note:  In example.c the phone number values were created with a syntax of
       OM_S_PRINTABLE_STRING and returned with a syntax of OM_S_TELETEX_STRING.
       See Attribute and Data Type Translation for a description of the syntax
       translation that takes place when using CDS as the directory.

  for (telephone = telephones;
       telephone->type != DS_ATTRIBUTE_VALUES;
       telephone++)
      {
   if (telephone->type != DS_ATTRIBUTE_VALUES ||
       (telephone->syntax & OM_S_SYNTAX) !=
       OM_S_TELETEX_STRING)
        {
  (void) fprintf(stderr, "malformed telephone number\en");
          exit(EXIT_FAILURE);
        }
  (void) printf("Telephone number: %s\en",
          telephone->value.string.elements);
         }

 The preceding example determines whether telephones is in a format that can be
 used by the application program as a string data that can be printed out, and
 that the syntax is correct for a list of telephone numbers. Note that the
 program uses the constant OM_S_SYNTAX to mask off the top 6 bits. These bits
 are special bits that are used by XOM API. See XOM Service Interface for more
 information on these special bits.


ΓòÉΓòÉΓòÉ 7.10.5. Return Codes ΓòÉΓòÉΓòÉ

XOM API function calls return a value of type OM_return_code, which indicates
whether the function succeeded. If the function is successful, the value of
OM_return is set to OM_SUCCESS. If the function fails, it returns one of the
values listed in XOM Service Interface. The constants for OM_return_code are
defined in the xom.h header file.


ΓòÉΓòÉΓòÉ 7.11. XOM API Header Files ΓòÉΓòÉΓòÉ

The XOM API includes the header file xom.h. This header file is composed of
declarations defining the C workspace interface. It supplies type definitions,
symbolic constant definitions, and macro definitions.


ΓòÉΓòÉΓòÉ 7.11.1. XOM Type Definitions and Symbolic Constant Definitions ΓòÉΓòÉΓòÉ

The xom.h header file includes typedef statements that define the data types of
all OM objects used in the interface. It also provides definitions of symbolic
constants used by the interface.

See the DCE for OS/2 Warp: Application Development Reference for a listing of
the xom.h header file.


ΓòÉΓòÉΓòÉ 7.11.2. XOM API Macros ΓòÉΓòÉΓòÉ

XOM API provides several macros that are useful in defining public objects in
your application programs. These macros are defined in the xom.h header file:

 OM_IMPORT                       Makes object identifier symbolic constants
                                 available within a C source module.

 OM_EXPORT                       Allocates memory and initializes object
                                 identifier symbolic constants within a C
                                 source module.

 OM_OID_DESC                     Initializes the type, syntax, and value of an
                                 OM attribute that holds an object identifier.

 OM_NULL_DESCRIPTOR              Marks the end of a client-generated public
                                 object.

 OMP_LENGTH                      Calculates the length of an object identifier.

 OM_STRING                       Creates a data value of a string data type.


ΓòÉΓòÉΓòÉ 7.11.2.1. The OM_EXPORT and OM_IMPORT Macros ΓòÉΓòÉΓòÉ

Most application programs find it convenient to export all the names they use
from the same C source module. OM_EXPORT allocates memory for the constants
that represent an object OM class or an object identifier, as shown in the
following code fragment from example.c.

/*  Define necessary Object Identifier constants
 */
OM_EXPORT(DS_A_COUNTRY_NAME)
OM_EXPORT(DS_A_ORG_NAME)
OM_EXPORT(DS_A_ORG_UNIT_NAME)
OM_EXPORT(DSX_TYPELESS_RDN)
OM_EXPORT(DS_C_AVA)
OM_EXPORT(DS_C_DS_DN)
OM_EXPORT(DS_C_DS_RDN)
OM_EXPORT(DS_C_ENTRY_INFO_SELECTION)
OM_EXPORT(DS_C_ATTRIBUTE)
OM_EXPORT(DS_C_ATTRIBUTE_LIST)
OM_EXPORT(DS_A_TELEPHONE_NUMBER)

In this code fragment, object identifier constants that represent OM classes
that are defined in the xds.h and xdsbdcp.h header files are exported to the
main program module. The object identifier constants are defined in xds.h and
xdscds.h with the OMP_O prefix followed by the variable name for the object
identifier. The constant itself provides the hexadecimal value of the object
identifier string.

The OM_EXPORT macro takes the OM class name as input and creates two new data
structures:  a character string and a structure of type OM_string. The
structure of type OM_string contains a length and a pointer to a string that
can be used later in an application program by the OM_OID_DESC macro to
initialize the value of an object identifier.

OM_IMPORT marks the identifiers as external for the compiler. It is used if
OM_EXPORT is called in a different file from where its values are referenced.
OM_IMPORT is not used in example.c because OM_EXPORT is called in the file
where the object identifiers are referenced.


ΓòÉΓòÉΓòÉ 7.11.3. The OM_OID_DESC Macro ΓòÉΓòÉΓòÉ

The OM_OID_DESC macro initializes the type, syntax, and value of an OM
attribute that holds an object identifier; in other words, it initializes
OM_descriptor. It takes as input an OM attribute type and the name of an object
identifier. The object identifier should have already been exported to the
program module, as shown in the previous section.

The output of the macro is an OM_descriptor composed of a type, syntax, and
value. The type is the name of the OM class. The syntax is
OM_S_OBJECT_IDENTIFIER. The value is a two-member structure with the length of
the object identifier and a pointer to the actual object identifier string. It
is defined as a pointer to void so that it can be used as a generic pointer; it
can point to any data type.

OM_OID_DESC calls OMP_LENGTH to calculate the length of the object identifier
string.

The following code fragment from xom.h shows the OM_OID_DESC and OMP_LENGTH
macros:

/* Private macro to calculate length
 * of an object identifier
 */
#define OMP_LENGTH(oid_string) (sizeof(OMP_O_##oid_string)-1)

/* Macro to initialize the syntax and value
 * of an object identifier
 */
#define OM_OID_DESC(type, oid_name)               \
        { (type), OM_S_OBJECT_IDENTIFIER_STRING,  \
         { OMP_LENGTH(oid_name) , OMP_D_##oid_name } }


ΓòÉΓòÉΓòÉ 7.11.3.1. The OM_NULL_DESCRIPTOR Macro ΓòÉΓòÉΓòÉ

The OM_NULL_DESCRIPTOR macro marks the end of a client-generated public object
by setting the type, syntax, and value to OM_NO_MORE_TYPES,
OM_S_NO_MORE_SYNTAXES, and a value of zero length and a NULL string,
respectively.


ΓòÉΓòÉΓòÉ 7.11.3.2. The OM_STRING Macro ΓòÉΓòÉΓòÉ

The OM_STRING macro creates a string data value. Data strings are of type
OM_string, as shown from this code fragment from the xom.h header file:

/* String */

typedef struct {
        OM_string_length            length;
        void                       *elements;
} OM_string;

#define OM_STRING(string)            \
         { (OM_string_length)(sizeof(string)-1), string }

A string is specified in terms of its length or whether or not it terminates
with a NULL. OM_string_length is the number of octets by which the string is
represented, or it is the OM_LENGTH_UNSPECIFIED value if the string terminates
with a NULL.

The bits of a bit string are represented as a sequence of octets. The first
octet stores the number of unused bits in the last octet. The bits in the bit
string, beginning with the first bit and proceeding to the trailing bit, are
placed in bits 7 to 0 of the second octet. These are followed by bits 7 to 0 of
the third octet, then by bits 7 to 0 of each octet in turn, followed by as many
bits as are required of the final octet commencing with bit 7.


ΓòÉΓòÉΓòÉ 8. XDS Programming ΓòÉΓòÉΓòÉ

XDS API defines an application programming interface to directory services in
the X/Open Common Applications Environment as defined in the X/Open Portability
Guide. This interface is based on the 1988 CCITT X.500 Series of
Recommendations and the ISO 9594 Standard. This joint standard is referred to
from this point on simply as X.500.

This section describes the purpose and function of XDS API functions in a
general way. Refer to the DCE for OS/2 Warp: Application Development Reference
for complete and detailed reference information on specific function calls.

The following sections describe these XDS functions:

   o  XDS Interface Management - Interact with the XDS interface
   o  Directory Management - Initiate, manage, and end connections with the
      directory
   o  Directory Operation - Perform operations on a directory

 Note:  The DCE XDS API does not support asynchronous operations from within
        the same thread. If an application requires asynchronous XDS
        operations, then it should use multiple threads to achieve this
        functionality.

 The ds_abandon function is not supported in this release. A ds_abandon returns
 a DS_C_ABANDON_FAILED ( DS_E_TOO_LATE) error. See XDS Interface Description
 for information on abandoning directory operations.

 The example.c (example.h) refers to the complete XDS example program, which
 can be found in the \opt\dcelocal\examples\xdsxom directory.


ΓòÉΓòÉΓòÉ 8.1. XDS Interface Management Functions ΓòÉΓòÉΓòÉ

XDS API defines a set of functions that only interact with the XDS interface
and have no counterpart in the directory standard definition:

   o  ds_initialize
   o  ds_version
   o  ds_shutdown

 These interface functions perform operations that involve the initialization,
 management, and termination of sessions with the XDS interface service.


ΓòÉΓòÉΓòÉ 8.1.1. The ds_initialize Function Call ΓòÉΓòÉΓòÉ

Every application program must first call ds_initialize to establish a
workspace where objects returned by the Directory Service are deposited. The
ds_initialize function must be called before any other directory interface
functions are called.

The ds_initialize call returns a handle (or pointer) to a workspace. The
application program performs operations on OM objects in this workspace. OM
objects created in this workspace can be used as input parameters to the other
directory interface functions. In addition, objects returned by the Directory
Service are deposited in the workspace.

Within the following code fragment from example.c, a workspace is initialized
(the declaration of the variable workspace and the call to ds_initialize are
found in different sections of the program):

int main(void)
{
  DS_status             error;               /* return value from DS functions*/
  OM_return_code        return_code;         /* return value from OM functions */
  OM_workspace          workspace;           /* workspace for objects */
  OM_private_object     session;             /* session for directory operations */
  OM_private_object     result;              /* result of read  operation */
  OM_sint               invoke_id;           /* Invoke-ID of the read operation */
  OM_value_position     total_num;           /* Number of Attribute Descriptors */

/*
 * Perform the Directory operations:
 * (1) Initialize the Directory Service and get an OM workspace.
 * (2) bind a default directory session.
 * (3) read the telephone number of "name".
 * (4) end the directory session.
 */

CHECK_DS_ALL((OM_object)  !(workspace=ds_initialize()));

OM_workspace is a type definition in the xom.h header file defined as a pointer
to void. A void pointer is a generic pointer that can point to any data type.
The variable workspace is declared as data type OM_workspace. The return value
is assigned to the variable workspace and the CHECK_DS_CALL macro determines if
the call is successful. CHECK_DS_CALL is an error handling macro that is
defined in example.h.

The ds_initialize call returns a handle to a workspace in which OM objects can
be created and manipulated. Only objects created in this workspace can be used
as parameters to other directory interface functions. The ds_initialize call
returns NULL if it fails.


ΓòÉΓòÉΓòÉ 8.1.2. The ds_version Function Call ΓòÉΓòÉΓòÉ

The ds_version call negotiates features of the directory interface. These
features are collected into packages that define the scope of the service.
Packages define such things as object identifiers for directory and OM classes
and OM attributes, enumerated types, structures, and OM object constants.

XDS API defines the following packages in separate header files as part of the
XDS API software product:

   o  Directory Service Package - Contains the OM classes and OM attributes
      used to interact with the Directory Service. This package is contained in
      the xds.h header file.

   o  Basic Directory Contents Package - Contains the OM classes and OM
      attributes that represent values of selected attributes and selected
      objects defined in the X.500 standard. This package is contained in the
      xdsbdcp.h header file.

 The ds_version call is not required when using XDS/XOM to access the CDS
 namespace.


ΓòÉΓòÉΓòÉ 8.1.3. The ds_shutdown Function Call ΓòÉΓòÉΓòÉ

The ds_shutdown call deletes the workspace established by ds_initialize and
enables the Directory Service to release resources. No other directory
functions that reference that workspace can be called after this function.

The following code fragment from example.h demonstrates how the application
closes the directory workspace by performing a ds_shutdown.

CHECK_DS_CALL(ds_shutdown(workspace));


ΓòÉΓòÉΓòÉ 8.2. Directory Connection Management Functions ΓòÉΓòÉΓòÉ

The following sections describe the XDS functions that initiate, manage, and
end connections with the Directory Service:

   o  A Directory Session
   o  The ds_bind Function Call
   o  The ds_unbind Function Call
   o  Automatic Connection Management


ΓòÉΓòÉΓòÉ 8.2.1. A Directory Session ΓòÉΓòÉΓòÉ

A directory session is intended to identify the DSA to which a directory
operation is sent. When using XDS/XOM over CDS, it is used to bind to the CDS
namespace.

An application program can request a session with specific OM attributes
tailored for the program's requirements. The application passes an instance of
OM class DC_C_SESSION with the appropriate OM attributes, or it uses the
default parameters by passing the constant DS_DEFAULT_SESSION as a parameter to
the ds_bind function call. DS_DEFAULT_SESSION is sufficient when using XDS/XOM
over CDS.


ΓòÉΓòÉΓòÉ 8.2.2. The ds_bind Function Call ΓòÉΓòÉΓòÉ

The ds_bind call establishes a session with the CDS namespace.

When a ds_bind call completes successfully, the directory returns a pointer to
an OM private object of OM class DC_C_SESSION. This parameter is then passed as
the first parameter to most interface function calls until a ds_unbind is
called to end the directory session.

XDS API supports multiple concurrent sessions so that an application can
interact with the Directory Service using several identities, and interact
directly and concurrently with different parts of the CDS namespace.

The following code fragment from example.c shows how an application binds to
the CDS namespace using the default session:

CHECK_DS_CALL(ds_bind(DS_DEFAULT_SESSION, workspace, &session));


ΓòÉΓòÉΓòÉ 8.2.3. The ds_unbind Function Call ΓòÉΓòÉΓòÉ

The ds_unbind call ends a directory session and makes the session parameter
unavailable for use with other interface functions. However, the unbound
session can be modified by OM functions and used again as a parameter to
ds_bind. When the session parameter is no longer needed, it should be deleted
using OM functions such as om_delete.

The following code fragment from example.c shows how the application closes the
connection to the CDS namespace using ds_unbind:

/* Close the connection to the CDS namespace server.  */

CHECK_DS_CALL(ds_unbind(session));


ΓòÉΓòÉΓòÉ 8.2.4. Automatic Connection Management ΓòÉΓòÉΓòÉ

The XDS implementation does not support automatic connection management. A CDS
connection is established when ds_bind is called and released when ds_unbind is
called.


ΓòÉΓòÉΓòÉ 8.3. XDS Interface Class Definitions ΓòÉΓòÉΓòÉ

The XDS Interface Class Definitions are described in detail in XDS Class
Definitions. The OM attribute types, syntax, and values and inheritance
properties are described for each OM class.

A good way to begin to understand how the OM class hierarchy is structured and
the relationship between OM classes and OM attributes to the service provided
by the Directory Service Package is to look up one of the OM classes listed in
XDS Class Definitions.


ΓòÉΓòÉΓòÉ 8.3.1. Example:  The DS_C_ATTRIBUTE_LIST Class ΓòÉΓòÉΓòÉ

For example, DS_C_ATTRIBUTE_LIST inherits the OM attributes from its superclass
OM_C_OBJECT, as do all OM classes. OM_C_OBJECT, as defined in XOM Programming,
has one OM attribute, OM_CLASS, which has the value of an object identifier
string that identifies the numeric representation of the object's OM class.
DS_C_ATTRIBUTE_LIST also has one OM attribute.

The purpose of DS_C_ATTRIBUTE_LIST is to define a list of attributes for an
object. It has the DS_ATTRIBUTES OM attribute. The DS_ATTRIBUTE OM attribute
has a value of a pointer to the DS_C_ATTRIBUTE OM object.


ΓòÉΓòÉΓòÉ 8.3.2. The DS_C_CONTEXT Parameter ΓòÉΓòÉΓòÉ

The OM class DS_C_CONTEXT is the second parameter to every Directory Service
request. DS_C_CONTEXT defines the characteristics of the Directory Service
interaction that are specific to a particular Directory Service operation.
These characteristics are divided into three categories of OM attributes:

   o  Common Parameters - Affect the processing of each Directory Service
      operation.

   o  Service Controls - Indicate how the Directory Service should handle
      requests. Included in this category are decisions about whether or not
      chaining is permitted, the priority of requests, the scope of referral
      (to DSAs within a country or within a DMD), and the maximum number of
      objects about which a function should return information.

   o  Local Controls -  Include asynchronous support and automatic continuation
      (XDS does not currently support asynchronous operations from within the
      same thread). Applications requiring asynchronous use of the XDS/XOM API
      should use threads as defined in XDS Programming.

 Note:  Service Controls and Local Controls are not supported for XDS/XOM over
        CDS.


ΓòÉΓòÉΓòÉ 8.4. Directory Class Definitions ΓòÉΓòÉΓòÉ

The X.500 standards define a number of attribute types and classes. These
definitions allow the creation and maintenance of directory entries for a
number of common objects so that the representation of all such objects is the
same throughout the directory. The Basic Directory Contents Package contains OM
classes and OM attributes that model the X.500 attribute types and classes.

The X.500 object classes and attributes are defined in the following documents
published by CCITT. These are the objects and the associated attributes that
will be the targets of Directory Service operations in your application
programs:

   o  The Directory: Selected Attributes Types (Recommendation X.520)
   o  The Directory: Selected Object Classes (Recommendation X.521)

 "Representation of Values for Selected Attribute Types" describes the OM
 classes, OM attributes, and their object identifiers that model the X.500
 objects and attributes. See The Basic Directory Contents Package for more
 tables with the same type of information.

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  Γöé Table 7. Representation of Values for Selected Attribute Types             Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé ATTRIBUTE TYPE   Γöé OM VALUE SYNTAX       Γöé  VALUE  Γöé  MULTI  Γöé   MATCHING   Γöé
  Γöé          Γöé               Γöé  LENGTH Γöé  VALUED Γöé    RULES    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_ALIASED    Γöé Object(DS_C_NAME)      Γöé  None  Γöé   No  Γöé     E     Γöé
  Γöé _OBJECT_NAME    Γöé               Γöé     Γöé     Γöé          Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_BUSINESS   Γöé String(OM_S_TELETEX     Γöé  1-128  Γöé  Yes  Γöé     E,S    Γöé
  Γöé _CATEGORY     Γöé _STRING)           Γöé     Γöé     Γöé          Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_COMMON_NAME  Γöé String(OM_S_TELETEX     Γöé  1-64  Γöé  Yes  Γöé     E,S    Γöé
  Γöé          Γöé _STRING)           Γöé     Γöé     Γöé          Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_COUNTRY_NAME Γöé String(OM_S         Γöé   2   Γöé   No  Γöé     E     Γöé
  Γöé          Γöé _PRINTABLE_STRING)(**)    Γöé     Γöé     Γöé          Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_DESCRIPTION  Γöé String(OM_S_TELETEX     Γöé  1-1024 Γöé  Yes  Γöé     E,S    Γöé
  Γöé          Γöé _STRING)           Γöé     Γöé     Γöé          Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 The tables in The Basic Directory Contents Package contain similar categories
 of information as do similar tables for the attributes defined in the
 Directory Service Package. These information categories include:

   o  OM Value Syntax
   o  Value Length
   o  Multivalued
   o  Matching Rules

 The OM Value Syntax column describes the structure of the values of an OM
 attribute. The Value Length column gives the range of lengths permitted for
 the string types. The Multivalued column indicates whether the attribute can
 have multiple values.

 The CCITT standards define matching rules that are used for determining
 whether two values are equal, for ordering two values, or for identifying one
 value as a substring of another in Directory Service operations. These are
 indicated in the Matching Rules column.

 Note:  The above elements are used when the cell name is an X.500 style name.
        When using XDS/XOM over CDS, none of the checking for value length and
        related information is performed. Only attribute types like
        DS_A_COUNTRY_NAME used in the cell name should be required from the
        Basic Directory Contents Package.


ΓòÉΓòÉΓòÉ 8.5. Directory Operation Functions ΓòÉΓòÉΓòÉ

The X.500 standard defines the operations provided by the directory in a
document called the Abstract Service Definition. DCE implements this standard
with XDS API functions calls. The XDS API functions allow an application
program to interact with the Directory Service. The standard divides these
interactions into three general categories - read, search, and modify.

The XDS API functions correspond to the Abstract Service functions defined in
the X.500 standard, as shown in the following table.

   o  Mapping of XDS API Functions to the Abstract Services

           XDS Function Call        Abstract Service Equivalent
           ds_read                  Read
           ds_compare               Compare
           ds_list                  List
           ds_search                Search
           ds_add_entry             AddEntry
           ds_remove_entry          RemoveEntry
           ds_modify_entry          ModifyEntry
           ds_modify_rdn            ModifyRDN

 Note:  ds_search and ds_modify_rdn are not supported for XDS/XOM over CDS.


ΓòÉΓòÉΓòÉ 8.6. Directory Read Operations ΓòÉΓòÉΓòÉ

Read functions retrieve information from specific named entries in the
directory where names are mapped to attributes. This is analogous to looking up
some information about a name in the White Pages phone directory.

XDS API implements the following read functions:

 ds_read          The requester supplies a distinguished name and one or more
                  attribute types. The value(s) of requested attributes or just
                  the attribute type(s) is returned by the DSA.

 ds_compare       The requester gives a distinguished name and an Attribute
                  Value Assertion (AVA). If the AVA is TRUE for the named
                  entry, a value of TRUE is returned by the DSA.

 For example, a typical read operation could request the telephone number of a
 particular employee. A read request would submit the distinguished name of the
 employee with an indication to return its telephone number:
 /C=us/O=ibm/OU=austin/Peter.


ΓòÉΓòÉΓòÉ 8.6.1. Reading an Entry from the Directory ΓòÉΓòÉΓòÉ

The following sections describe a typical read operation using the ds_read
function call. They include a description of tasks directly related to the read
operation. They do not include service-related tasks such as initializing the
interface, allocating an OM workspace, and binding to the CDS namespace. These
tasks are described in XDS Interface Management Functions. The following
sections also do not describe the process of extracting information from the
workspace using XOM functions. See XOM Programming for a description of how to
use XOM functions to access the workspace.

A typical read operation involves the following steps:

   1. Define the necessary object identifier constants for the OM classes and
      OM attributes that will define public objects for input to ds_read using
      the OM_EXPORT macro.

   2. Declare the variables that will contain the output from the XDS functions
      to be used in the application.

   3. Build public objects (descriptor lists) for the name parameter to
      ds_read.

   4. Create a descriptor list for the selection parameter to ds_read that
      selects the type and scope of information in your request.

   5. Perform the read operation.

 These steps are demonstrated in the following code fragments from example.c
 (see the \opt\dcelocal\examples\xdsxom directory for a complete program
 listing). The program reads the telephone numbers of a given target entry.


ΓòÉΓòÉΓòÉ 8.6.2. Step 1:  Export Object Identifiers for Required Directory Classes and Attributes ΓòÉΓòÉΓòÉ

Most application programs find it convenient to export all the names they use
from the same C source module. In the following code fragment from example.c
the OM_EXPORT macro allocates memory for the constants that represent the OM
object classes and directory attributes required for the read operation:

/*  Define necessary Object Identifier constants   */
OM_EXPORT(DS_A_COUNTRY_NAME)
OM_EXPORT(DS_A_ORG_NAME)
OM_EXPORT(DS_A_ORG_UNIT_NAME)
OM_EXPORT(DSX_TYPELESS_RDN)
OM_EXPORT(DS_C_AVA)
OM_EXPORT(DS_C_DS_DN)
OM_EXPORT(DS_C_DS_RDN)
OM_EXPORT(DS_C_ENTRY_INFO_SELECTION)
OM_EXPORT(DS_C_ATTRIBUTE)
OM_EXPORT(DS_C_ATTRIBUTE_LIST)
OM_EXPORT(DS_A_TELEPHONE_NUMBER)

The OM_EXPORT macro performs the following steps:

   1. It defines a character array called OMP_D_ concatenated with the
      class_name input parameter.

   2. It initializes this array to the value of a character string called
      OMP_O_ concatenated with the class_name input parameter. This value has
      already been defined in a header file.

   3. It defines an OM_string data structure as the class_name input parameter.

   4. It initializes the OM_string data structure's first component to the
      length of the array initialized in Step 2 above and initializes the
      second component to a pointer to the value of the array initialized in
      Step 2.


ΓòÉΓòÉΓòÉ 8.6.3. Step 2:  Declare Local Variables ΓòÉΓòÉΓòÉ

The local variables session, result, and invoke_id are defined in the following
code fragment from example.c

int main(void)
{
  DS_status             error;             /* return value from DS functions */
  OM_return_code        return_code;       /* return value from OM functions */
  OM_workspace          workspace;         /* workspace for objects          */
  OM_private_object     session;           /* session for directory          */
  OM_private_object     result;            /* result of read operation       */
  OM_sint               invoke_id;         /* Invoke-ID of the read operation */
  OM_value_position     total_num;         /* Number of Attribute Descriptors */

These data types are defined in a typedef statement in the xom.h header file.
The session and result variables are defined as data type OM_private_object
because they are returned by ds_bind and ds_read, respectively, to the
workspace as private objects. Since asynchronous operations (within the same
thread) are not supported, the invoke_id functionality is redundant. The
invoke_id parameter must be supplied to the XDS functions as described in the
DCE for OS/2 Warp: Application Development Reference, but its return value
should be ignored.

Values in error and return_code are returned by XOM and XDS functions to
indicate whether a call was successful. The workspace variable is defined as
OM_workspace and is used when establishing an OM workspace. The total_num
variable is defined as OM_value_position to indicate the number of attribute
descriptors returned in the public object by om_get based on the inclusion and
exclusion parameters specified.


ΓòÉΓòÉΓòÉ 8.6.4. Step 3:  Build Public Objects ΓòÉΓòÉΓòÉ

A ds_read function call can take a public object as an input parameter. A
public object is generated by an application program and contains the
information required to access a target directory object. This information
includes the AVAs and RDNs that make up a distinguished name of an entry in the
directory.

A public object is created using OM classes and OM attributes. These OM classes
and OM attributes model the target object entry in the directory and provide
other information required by the Directory Service to access the directory. In
this case, the target object entry in the directory is the entry for Peter.

Public Objects describes how to create the required public objects for the
ds_read function call using macros and data structures defined in the XDS and
XOM API header files.

The purpose of building the public objects for AVAs and RDNs is to provide the
public objects that represent a distinguished name. The distinguished name
public object is stored in the array of descriptors called name and provided as
an input parameter to the ds_read function call.


ΓòÉΓòÉΓòÉ 8.6.5. Step 4:  Create an Entry-Information-Selection Parameter ΓòÉΓòÉΓòÉ

The distinguished name for Peter is an entry in the directory that the
application is designed to access. The selection parameter of the ds_read
function call tailors its results to obtain just part of the required entry.
Information on all attributes, no attributes, or a specific group of attributes
can be chosen. Attribute types are always returned, but the attribute values
need not be.

The value of the parameter is a public object (descriptor list) that is an
instance of OM class DS_C_ENTRY_INFO_SELECTION, as shown in the following code
fragment from example.c.

/*
 * Public Object ("Descriptor List") for
 * Entry-Information-Selection
 * parameter to ds_read.
 */
OM_descriptor selection[] = {
OM_OID_DESC(OM_CLASS, DS_C_ENTRY_INFO_SELECTION), { DS_ALL_ATTRIBUTES, OM_S_BOOLEAN, { OM_FALSE, NULL } },
OM_OID_DESC(DS_ATTRIBUTES_SELECTED, DS_A_TELEPHONE_NUMBER),
{ DS_INFO_TYPE,OM_S_ENUMERATION, { DS_TYPES_AND_VALUES,NULL } },
OM_NULL_DESCRIPTOR
};

DS_C_ENTRY_INFO_SELECTION is a subclass of OM_C_OBJECT (this information is
supplied in the description of this class in XDS Class Definitions). As such,
DS_C_ENTRY_INFO_SELECTION inherits the OM attributes of OM_C_OBJECT. The only
OM attribute of OM_C_OBJECT is OM_CLASS. OM_CLASS identifies an object's class,
which in this case is DS_C_ENTRY_INFO_SELECTION. DS_C_ENTRY_INFO_SELECTION
identifies information to be extracted from a directory entry and has the
following OM attributes:

   o  OM_C_CLASS (inherited from OM_C_OBJECT)
   o  DS_ALL_ATTRIBUTES
   o  DS_ATTRIBUTES_SELECTED
   o  DS_INFO_TYPE

 As part of a ds_read function call, DS_ALL_ATTRIBUTES specifies to the
 Directory Service which attributes of a directory entry are relevant to the
 application program. It can take the values OM_TRUE or OM_FALSE. These values
 are defined to be of syntax OM_S_BOOLEAN. The value OM_TRUE indicates that
 information is requested on all attributes in the directory entry. The value
 OM_FALSE, used in the preceding sample fragment, indicates that information is
 only requested on those attributes that are listed in the OM attribute
 DS_ATTRIBUTES_SELECTED.

 DS_ATTRIBUTES_SELECTED lists the types of attributes in the entry from which
 information is to be extracted. The syntax of the value is specified as
 OM_S_OBJECT_IDENTIFIER_STRING.

 OM_S_OBJECT_IDENTIFIER_STRING contains an octet string of BER-encoded
 integers, which are decimal representations of object identifiers of the types
 of attributes in the attribute list. In the preceding code fragment, the
 string value is the attribute name DS_A_TELEPHONE_NUMBER because the purpose
 of the read call is to read a list of telephone numbers from the directory.

 DS_INFO_TYPE identifies what information is to be extracted from each
 attribute identified. The syntax of the value is specified as
 Enum(DS_Information_Type). DS_INFO_TYPE is an enumerated type that has two
 possible values: DS_TYPES_ONLY and DS_TYPES_AND_VALUES. DS_TYPES_ONLY
 indicates that only the attribute types of the selected attributes in the
 entry are returned by the Directory Service operation. DS_TYPES_AND_VALUES
 indicates that both the attribute types and the attribute values of the
 selected attributes in the entry are returned. The code fragment from
 example.c shown previously defines the value of DS_INFO_TYPE as
 DS_TYPES_AND_VALUES because the program wants to get the actual telephone
 numbers.


ΓòÉΓòÉΓòÉ 8.6.6. Step 5:  Perform the Read Operation ΓòÉΓòÉΓòÉ

The following code fragment from example.c shows the ds_read function call and
the XDS calls that precede it:

/*
 * Perform the Directory operations:
 * (1) Initialize the Directory Service
 *     and get an OM workspace.
 * (2) bind a default directory session.
 * (3) read the telephone number of "name".
 * (4) end the directory session.
 */

CHECK_DS_CALL((OM_object) !(workspace = ds_initialize()));

CHECK_DS_CALL(ds_version(bdcp_package, workspace));

CHECK_DS_CALL(ds_bind(DS_DEFAULT_SESSION, workspace,
                      &session));

CHECK_DS_CALL(ds_read (session, DS_DEFAULT_CONTEXT,
                            name, selection, &result,  &invoke_id));

CHECK_DS_CALL is an error-checking macro defined in the example.h header file
that is included by example.c. The ds_read call returns a return code of type
DS_status to indicate whether or not the read operation completed successfully.
If the call was successful, ds_read returns the value DS_SUCCESS. If the call
fails, it returns an error code. CHECK_DS_CALL interprets this return value and
returns successfully to the program or branches to an error-handling routine.

The session input parameter is a private object generated by ds_bind prior to
the ds_read call, as shown in the preceding code fragment. DS_DEFAULT_CONTEXT
describes the characteristics of a Directory Service interaction. Most XDS API
function calls require these two input parameters because they define the
operating parameters of a session with the CDS namespace. Sessions are
described in A Directory Session; contexts are described in The DS_C_CONTEXT
Parameter.

The result of a Directory Service request is returned in a private object (in
this case, result) that is appropriate to the type of operation. The result of
the operation is returned in a single OM object. The components of the result
are represented by OM attributes in the operations result object:

 DS_C_COMPARE_RESULT         Returned by ds_compare

 DS_C_LIST_RESULT            Returned by ds_list

 DS_C_READ_RESULT            Returned by ds_read

 The OM class returned by ds_read is DS_C_READ_RESULT. The OM class returned by
 the ds_compare call is DS_C_COMPARE_RESULT, and so on. See the DCE for OS/2
 Warp:Application Development Reference for a description of the OM classes
 associated with a particular function call. See XDS Class Definitions for full
 descriptions of the OM attributes, syntaxes, and values associated with these
 OM classes.

 The superclasses, subclasses, and OM attributes for DS_C_READ_RESULT are shown
 in "Output from ds_read: DS_C_READ_RESULT".


  Output from ds_read: DS_C_READ_RESULT

 The result value is returned to the workspace in private
 implementation-specific format. As such, it cannot be read directly by an
 application program, but requires a series of om_get function calls to extract
 the requested information from it. The following code fragment from example.c
 shows how a series of om_get calls extracts the list of telephone numbers
 associated with the distinguished name for Peter. Using the OM Function Calls
 describes this extraction process in detail.

  /*
   * extract the telephone number(s) of "name" from the result
   *
   * There are 4 stages:
   * (1) get the Entry-Information from the Read-Result.
   * (2) get the Attributes from the Entry-Information.
   * (3) get the list of phone numbers.
   * (4) scan the list and print each number.
   */

  CHECK_OM_CALL(   om_get()(result,
                     OM_EXCLUDE_ALL_BUT_THESE_TYPES
                   + OM_EXCLUDE_SUBOBJECTS,
                     entry_list, OM_FALSE, 0, 0, &entry,
                     &total_num));

  CHECK_OM_CALL(   om_get()(entry->value.object.object,
                     OM_EXCLUDE_ALL_BUT_THESE_TYPES
                   + OM_EXCLUDE_SUBOBJECTS,
                     attributes_list, OM_FALSE, 0, 0, &attributes,
                     &total_num));

  CHECK_OM_CALL(   om_get()(attributes->value.object.object,
                     OM_EXCLUDE_ALL_BUT_THESE_TYPES
                   + OM_EXCLUDE_SUBOBJECTS,
                     telephone_list, OM_FALSE, 0, 0, &telephones,
                     &total_num));


ΓòÉΓòÉΓòÉ 8.7. Directory Search Operations ΓòÉΓòÉΓòÉ

Search functions can be used to browse through the CDS namespace. For example,
a search request could supply the distinguished name of an entry and request a
list of the distinguished names of the children of that entry.

XDS over CDS API implements the ds_list search operation. With ds_list, the
requestor supplies a distinguished name. The Directory Service returns a list
of the immediate subordinates of the named entry.


ΓòÉΓòÉΓòÉ 8.8. Directory Modify Operations ΓòÉΓòÉΓòÉ

Modify functions alter information in the directory. For example, if an
employee changed telephone numbers, a typical modify request would modify the
telephone number attribute in the person's directory entry to reflect the
change.

XDS API implements the following modify functions:

 ds_modify_entry         The requestor gives a distinguished name and a list of
                         modifications to the named entry. The XDS/XOM API
                         carries out the specified changes if the user
                         requesting the change has proper access rights.

 ds_add_entry            The requestor gives a distinguished name and values
                         for a new entry. The entry is added as a leaf node in
                         the DIT if the user requesting the change has proper
                         access rights. If the leaf entry already exists, it
                         fails and the ds_modify_entry must be used.

 ds_remove_entry         The requestor gives a distinguished name. The entry
                         with that name is removed if the user requesting the
                         change has proper access rights.

 Note:  ds_add_entry and ds_remove entry only apply to leaf entries. They are
        not intended to provide a general facility for building and
        manipulating the DIT. Access rights are defined for the session by CDS.
        The user needs the same access rights as if accessing CDS through
        dcecp.


ΓòÉΓòÉΓòÉ 8.8.1. Modifying Directory Entries ΓòÉΓòÉΓòÉ

This section describes a modification and subsequent listing of the DIT using
the ds_add_entry, ds_list, and ds_remove_entry function calls. It includes a
description of tasks directly related to these operations and does not include
service-related tasks. It does not include a ds_modify_entry function call.

A typical operation to add, remove, or list an entry uses the following steps:

   1. Define the necessary object identifier constants for the OM classes and
      OM attributes that define public objects for input to the function calls
      by using the OM_EXPORT macro.

   2. Declare the variables that contain the output from the XDS functions you
      will use in your application.

   3. Build public objects (descriptor lists) for the name parameters to the
      function calls.

   4. Create descriptor lists for the attributes to be added, removed, or
      listed.

   5. Perform the operations.

 These steps are demonstrated in the following code fragments. The program adds
 two entries to the directory, then a list operation is performed on their
 superior entry, and finally the two entries are removed from the directory.
 The directory tree shown in "A Sample Directory Tree" is used in the program.


  A Sample Directory Tree


ΓòÉΓòÉΓòÉ 8.8.2. Step 1:  Export Object Identifiers for Required Directory Classes and Attributes ΓòÉΓòÉΓòÉ

In the following code fragment, the OM_EXPORT macro allocates memory for the
constants that represent the object classes and attributes required for the
add, list, and remove operations:

/* The application has to export the object identifiers    */
/* it requires.     */

OM_EXPORT (DS_C_AVA)
OM_EXPORT (DS_C_DS_RDN)
OM_EXPORT (DS_C_DS_DN)
OM_EXPORT (DS_C_ENTRY_INFO_SELECTION)
OM_EXPORT (DS_C_ATTRIBUTE)
OM_EXPORT (DS_C_ATTRIBUTE_LIST)
OM_EXPORT (DSX_TYPELESS_RDN)

OM_EXPORT (DS_A_COUNTRY_NAME)
OM_EXPORT (DS_A_ORG_NAME)
OM_EXPORT (DS_A_ORG_UNIT_NAME)
OM_EXPORT (DS_A_COMMON_NAME)
OM_EXPORT (DS_A_OBJECT_CLASS)
OM_EXPORT (DS_A_TELEPHONE_NUMBER)
OM_EXPORT (DS_A_USER_PASSWORD)
OM_EXPORT (DS_A_SURNAME)

OM_EXPORT (DS_O_TOP)
OM_EXPORT (DS_O_PERSON)
OM_EXPORT (DS_O_ORG_PERSON)


ΓòÉΓòÉΓòÉ 8.8.3. Step 2:  Declare Local Variables ΓòÉΓòÉΓòÉ

The local variables bound_session, result, and invoke_id are defined in the
following sample code fragment:

OM_private_object bound_session;    /* Holds the Session object                */
                                    /* which is returned by                       */
                                    /* ds_bind.                                */
OM_private_object result;           /* Holds the list result                   */
                                    /* object.                                 */
OM_sint              invoke_id;     /* Integer for the invoke  id              */
                                    /* returned by ds_list.                  */
                                    /* This parameter must be                  */
                                    /* present even though it is               */
                                    /* ignored.                                */

These data types are defined in typedef statements in the xom.h header file.
The bound_session and result variables are defined as data type
OM_private_object because they are returned by ds_bind and ds_list operations
to the workspace as private objects. Since asynchronous operations (within the
same thread) are not supported,  the invoke_id parameter functionality is
redundant. The invoke_id parameter must be supplied to the XDS functions as
described in the DCE for OS/2 Warp: Application Development Reference, but its
return value should be ignored.


ΓòÉΓòÉΓòÉ 8.8.4. Step 3:  Build Public Objects ΓòÉΓòÉΓòÉ

The public objects required by the ds_add_entry, ds_list, and ds_remove_entry
operations are defined in the following code fragment:

/* Build up a descriptor list for the distinguished names:              */
/*     C=us/O=ibm/OU=austin/temp                                        */
/*     C=us/O=ibm/OU=austin/temp/Brendan                                */
/*     C=us/O=ibm/OU=austin/temp/Sinead                                 */

static OM_descriptor    countryName[] = {
    OM_OID_DESC(OM_CLASS, DS_C_AVA),
    OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_COUNTRY_NAME),
    {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("us")},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor    orgName[] = {
    OM_OID_DESC(OM_CLASS, DS_C_AVA),
    OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_ORG_NAME),
    {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("ibm")},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor    orgUnitName[] = {
    OM_OID_DESC(OM_CLASS, DS_C_AVA),
    OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_ORG_UNIT_NAME),
    {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("austin")},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor    dirName[] = {
    OM_OID_DESC(OM_CLASS, DS_C_AVA),
    OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_TYPELESS_RDN),
    {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING, OM_STRING("temp")},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor    commonName[] = {
    OM_OID_DESC(OM_CLASS, DS_C_AVA),
    OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_TYPELESS_RDN),
    {DS_ATTRIBUTE_VALUES, OM_S_TELETEX_STRING, OM_STRING("Brendan")},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor    commonName2[] = {
    OM_OID_DESC(OM_CLASS, DS_C_AVA),
    OM_OID_DESC(DS_ATTRIBUTE_TYPE, DSX_TYPELESS_RDN),
    {DS_ATTRIBUTE_VALUES, OM_S_TELETEX_STRING, OM_STRING("Sinead")},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor    rdn1[] = {
    OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
    {DS_AVAS, OM_S_OBJECT, {0, countryName}},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor    rdn2[] = {
    OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
    {DS_AVAS, OM_S_OBJECT, {0, orgName}},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor    rdn3[] = {
    OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
    {DS_AVAS, OM_S_OBJECT, {0, orgUnitName}},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor    rdn4[] = {
    OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
    {DS_AVAS, OM_S_OBJECT, {0, dirName}},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor    rdn5[] = {
    OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
    {DS_AVAS, OM_S_OBJECT, {0, commonName}},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor    rdn6[] = {
    OM_OID_DESC(OM_CLASS, DS_C_DS_RDN),
    {DS_AVAS, OM_S_OBJECT, {0, commonName2}},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor name1[] = {
    OM_OID_DESC(OM_CLASS,DS_C_DS_DN),
    {DS_RDNS,OM_S_OBJECT,{0,rdn1}},
    {DS_RDNS,OM_S_OBJECT,{0,rdn2}},
    {DS_RDNS,OM_S_OBJECT,{0,rdn3}},
    {DS_RDNS,OM_S_OBJECT,{0,rdn4}},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor name2[] = {
    OM_OID_DESC(OM_CLASS,DS_C_DS_DN),
    {DS_RDNS,OM_S_OBJECT,{0,rdn1}},
    {DS_RDNS,OM_S_OBJECT,{0,rdn2}},
    {DS_RDNS,OM_S_OBJECT,{0,rdn3}},
    {DS_RDNS,OM_S_OBJECT,{0,rdn4}},
    {DS_RDNS,OM_S_OBJECT,{0,rdn5}},
    OM_NULL_DESCRIPTOR
};
static OM_descriptor name3[] = {
    OM_OID_DESC(OM_CLASS,DS_C_DS_DN),
    {DS_RDNS,OM_S_OBJECT,{0,rdn1}},
    {DS_RDNS,OM_S_OBJECT,{0,rdn2}},
    {DS_RDNS,OM_S_OBJECT,{0,rdn3}},
    {DS_RDNS,OM_S_OBJECT,{0,rdn4}},
    {DS_RDNS,OM_S_OBJECT,{0,rdn6}},
    OM_NULL_DESCRIPTOR
};


ΓòÉΓòÉΓòÉ 8.8.5. Step 4:  Create Descriptor Lists for Attributes ΓòÉΓòÉΓòÉ

The following code fragments show how the attribute lists are created for the
attributes to be added to the directory.

First, initialize the public object object_class to contain the representation
of the classes in the CDS object that are common to both Organizational Person
entries, Top, Person, and Organizational Person:

/* Build up an array of object identifiers for the     */
/* attributes to be added to the directory.            */

static OM_descriptor    object_class[] = {
 OM_OID_DESC(OM_CLASS, DS_C_ATTRIBUTE),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_OBJECT_CLASS),
 OM_OID_DESC(DS_ATTRIBUTE_VALUES, DS_O_TOP),
 OM_OID_DESC(DS_ATTRIBUTE_VALUES, DS_O_PERSON),
 OM_OID_DESC(DS_ATTRIBUTE_VALUES, DS_O_ORG_PERSON),
 OM_NULL_DESCRIPTOR
};

Next, initialize the public objects that represent the attributes to be added:
surname and telephone for the distinguished name of Brendan, and surname2 and
password for the distinguished name of Sinead:

static OM_descriptor    telephone[] = {
 OM_OID_DESC(OM_CLASS, DS_C_ATTRIBUTE),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_TELEPHONE_NUMBER),
 {DS_ATTRIBUTE_VALUES, OM_S_PRINTABLE_STRING,  OM_STRING("555-5555")},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    surname[] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_SURNAME),
 {DS_ATTRIBUTE_VALUES, OM_S_TELETEX_STRING, OM_STRING("Moloney")},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    surname2[] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_SURNAME),
 {DS_ATTRIBUTE_VALUES, OM_S_TELETEX_STRING,  OM_STRING("Murphy")},
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    password[] = {
 OM_OID_DESC(OM_CLASS, DS_C_AVA),
 OM_OID_DESC(DS_ATTRIBUTE_TYPE, DS_A_USER_PASSWORD),
 {DS_ATTRIBUTE_VALUES, OM_S_OCTET_STRING, OM_STRING("secret")},
 OM_NULL_SCRIPTOR
};

Finally, initialize the public objects that represent the list of attributes to
be added to the directory:  attr_list1 for the distinguished name Brendan, and
attr_list2 for the distinguished name Sinead:

static OM_descriptor    attr_list1[] = {
 OM_OID_DESC(OM_CLASS, DS_C_ATTRIBUTE_LIST),
 {DS_ATTRIBUTES, OM_S_OBJECT, {0, object_class} },
 {DS_ATTRIBUTES, OM_S_OBJECT, {0, surname} },
 {DS_ATTRIBUTES, OM_S_OBJECT, {0, telephone} },
 OM_NULL_DESCRIPTOR
};

static OM_descriptor    attr_list2[] = {
 OM_OID_DESC(OM_CLASS, DS_C_ATTRIBUTE_LIST),
 {DS_ATTRIBUTES, OM_S_OBJECT, {0,  object_class} },
 {DS_ATTRIBUTES, OM_S_OBJECT, {0,  surname2} },
 {DS_ATTRIBUTES, OM_S_OBJECT, {0,  password} },
 OM_NULL_DESCRIPTOR
};

The attr_list1 variable contains the public objects surname and telephone, the
C representations of the attributes of the distinguished name
/C=us/O=ibm/OU=austin/temp/Brendan that are added to the directory. The
attr_list2 variable contains the public objects surname2 and password, the C
representations of the attributes of the distinguished name
/C=us/O=ibm/OU=austin/temp/Sinead.


ΓòÉΓòÉΓòÉ 8.8.6. Step 5:  Perform the Operations ΓòÉΓòÉΓòÉ

The following code fragments show the ds_add_entry, ds_list, and the
ds_remove_entry calls.

First, the two ds_add_entry function calls add the attribute lists contained in
attr_list1 and attr_list2 to the distinguished names represented by brendan and
sinead, respectively.

/* Add two entries to the CDS server.         */

if (ds_add_entry(bound_session, DS_DEFAULT_CONTEXT,
   name2, attr_list1,
   &invoke_id) != DS_SUCCESS)
   printf("ds_add_entry() error\n");

if (ds_add_entry(bound_session, DS_DEFAULT_CONTEXT,
   name3, attr_list2,
   &invoke_id) != DS_SUCCESS)
   printf("ds_add_entry() error\n");

Next, list all the subordinates of the object referenced by the distinguished
name /C=us/O=ibm/OU=austin/temp.

if (ds_list(bound_session, DS_DEFAULT_CONTEXT, name1,
   &result, &invoke_id) != DS_SUCCESS)
   printf("ds_list() error\n");

The ds_list call returns the result in the private object result to the
workspace. The components of result are represented by OM attributes in the OM
class DS_C_LIST_RESULT and can only be read by a series of om_get calls.

Finally, remove the two entries from the directory.

if (ds_remove_entry(bound_session, DS_DEFAULT_CONTEXT,
     name2, &invoke_id) != DS_SUCCESS)
     printf("ds_remove_entry() error\n");

if (ds_remove_entry(bound_session, DS_DEFAULT_CONTEXT,
     name3, &invoke_id) != DS_SUCCESS)
     printf("ds_remove_entry() error\n");


ΓòÉΓòÉΓòÉ 8.9. Return Codes ΓòÉΓòÉΓòÉ

XDS API function calls return a value of type DS_status, the exception being
ds_initialize, which returns a value of type OM_workspace. If the function is
successful, then DS_status returns a value of DS_SUCCESS. If the function does
not complete successfully, then DS_status takes either the error constant
DS_NO_WORKSPACE or one of the private error objects described in XDS Class
Definitions.


ΓòÉΓòÉΓòÉ 9. Using Threads with the XDS/XOM API ΓòÉΓòÉΓòÉ

Some programs work well when they are structured as multiple flows of control.
Other programs might show better performance when they are multithreaded
allowing the multiple threads to be mapped to multiple processors when they are
available.

XDS/XOM application programs can contain multiple threads of control. For
example, an XDS/XOM application might need to query several CDS servers. This
can be achieved more efficiently by using separate threads simultaneously to
query the different servers.

XDS/XOM supports multithreaded applications. Writing multithreaded applications
over XDS/XOM imposes new requirements on programmers; they must manage the
threads, synchronize thread access to global resources, and make choices about
thread scheduling and priorities.

This section describes a simple GDS application that uses threads.

The XDS/XOM API calls do not change when they are making use of DCE threads in
an application program. The service underneath XDS/XOM API is designed to be

   o  Thread-safe, to allow multiple threads to safely access shared data, and
   o  Cancel-safe, to handle unexpected cancellation of a thread in an
      application program.

 "Issuing XDS/XOM Calls From Within Different Threads" shows an example of how
 an application can issue XDS/XOM calls from within different threads.


  Issuing XDS/XOM Calls From Within Different Threads

 The order of thread completion is not defined; however, XDS/XOM has an
 inherent ordering. Multithreaded XDS applications must adhere to the following
 order of execution:

   1. ds_initialize
   2. ds_version (optional)
   3. ds_bind
   4. Other XDS calls in sequence or parallel from multiple threads
   5. ds_unbind
   6. ds_shutdown

 Multithreaded XOM applications must adhere to the following order of
 execution:

   1. ds_initialize
   2. XOM calls in sequence or parallel from multiple threads
   3. ds_shutdown

 The XDS/XOM API will return an appropriate error code if these sequences are
 not adhered to. For example the following errors are returned:

 DS_E_BUSY                             If ds_unbind is called while there are
                                       still outstanding operations, or if
                                       ds_shutdown is called before all
                                       directory connections have been released
                                       by ds_unbind.

 OM_NO_SUCH_WORKSPACE                  If any XOM API calls are made before
                                       completing ds_initialize, or if a call
                                       to ds_shutdown completes while there are
                                       outstanding XOM operations on the same
                                       workspace. In the latter case, these XOM
                                       operations will not be performed.


ΓòÉΓòÉΓòÉ 9.1. Overview of Sample Threads Program ΓòÉΓòÉΓòÉ

The sample program is called thradd. The thradd program is a multithreaded XDS
application that adds entries to a CDS directory. Each thread performs a
ds_add_entry call. The information for each entry to be added is read from an
input file.

The thradd program can also be used to reset the directory to its original
state. This is achieved by invoking thradd with a -d command-line argument. In
this case, thradd uses the same input file and calls ds_remove_entry for each
entry. The ds_remove_entry calls are also done in separate threads.

To keep the program short and clear, it works with a fixed tree for the upper
nodes (/C=us/O=ibm/OU=austin/temp), to which the entries described in the input
file are added. C=us/O=ibm/OU=austin is the cell name and temp is a directory
in that cell. The directory (temp) must already exist before executing thradd.
The input file contains the object name, the surname, and the phone number of
each Organizational-Person entry to be added.

For simplicity, only pthread_join is used for synchronization purposes; mutexes
are not used.

The thradd program could be enhanced to satisfy the following scenarios :

   o  As a server program for interactive directory actions from different
      users. The thradd program simulates a server program which gets requests
      from different users to add entries to a directory. In the case of
      thradd, the users' interactive input is simulated through the entries in
      the input file. Each line of input represents a different directory
      entry, and thradd uses a separate thread for each line.

   o  Initialization of the directory with data from file. The thradd program
      could be enhanced to read generic attribute information for a variety of
      directory object classes from a file, and to add the corresponding
      entries to the directory.


ΓòÉΓòÉΓòÉ 9.1.1. User Interface ΓòÉΓòÉΓòÉ

The thradd program is called from the command line as follows :

thradd [-d] [-f filename]

 -d             If the option -d is set, the entries in the file are deleted
                from the tree /C=us/O=ibm/OU=austin/temp; otherwise, they are
                added.

 -f file name   The option -f specifies the name of the input file. If no input
                file is specified, then a default filename of thradd.dat is
                used.


ΓòÉΓòÉΓòÉ 9.1.2. Input File Format ΓòÉΓòÉΓòÉ

The input file can contain any number of lines. Each line represents a
directory entry of a CDS object. Each line must contain the following three
attributes for each entry:

object surname number

The attributes must be strings without space characters. Lines containing less
than three strings are rejected by the program; any input on a line after the
first three strings is ignored and can be used for comments. The attributes are
separated by one or more space characters.

The input strings are not verified for their relevant attribute syntax. A wrong
attribute syntax will result in either a ds_add_entry error or a
ds_remove_entry error.

The following would be a valid input file for thradd :

Anna          Meister        010101
Erwin         Reiter         020202
Gerhard       Schulz         030303
Gottfried     Schmid         040404
Heidrun       Blum           050505
Hermann       Meier          060606
Josefa        Fischer        070707
Jutta         Arndt          080808
Leopold       Huber          090909
Magdalena     Schuster       101010
Margot        Junge          111111


ΓòÉΓòÉΓòÉ 9.1.3. Program Output ΓòÉΓòÉΓòÉ

The thradd program writes messages to stdout for every action done by a thread.
The order of the output can differ from the order in the input file; it depends
on the execution of the different threads.

Errors are reported to stderr.


ΓòÉΓòÉΓòÉ 9.1.4. Prerequisites ΓòÉΓòÉΓòÉ

The C=us/O=ibm/OU=austin/temp directory must exist and the user must have the
proper authority to create and delete objects in the directory. The thradd
program should always be invoked twice with the same input file - first without
and then with option -d. This guarantees that the directory is reset to its
original state. The DCE administration program, dcecp, can be used to verify
the directory contents after adding entries.


ΓòÉΓòÉΓòÉ 9.2. Description of Sample Program ΓòÉΓòÉΓòÉ

The static descriptors for the fixed tree (that is, /C=us/O=ibm/OU=austin/temp)
are declared in the thradd.h header file. The thradd.c application and the
thradd.h header file are shipped with the product and can be found in the
\opt\dcelocal\examples\xdsxom directory.

The main routine scans the command-line options, initializes the XDS workspace
and binds to the CDS namespace.

Each line of the input file is then processed in turn by a while loop (until
the end of file is reached). The while loop contains two for loops. The first
for loop creates a separate thread for each line of the input file, up to a
maximum of MAX_THREAD_NO of threads.

The add_or_remove procedure, which adds or removes an entry to or from the
directory, is the starting point of each thread's processing.

The second for loop waits for termination of the threads and then releases the
resources used by the threads.

When the entire input file has been processed, thradd closes the connection to
the CDS namespace.

Finally, the XDS workspace is closed.

"Program Flow for the thradd Sample Program" shows the program flow.


Program Flow for the thradd Sample Program


ΓòÉΓòÉΓòÉ 9.3. Detailed Description of Thread Specifics ΓòÉΓòÉΓòÉ

The program consists of the following general steps:

   1. Include the header file pthread.h.
   2. Define a parameter block structure type for the thread start routine.
   3. Declare arrays for thread handles and parameter blocks.
   4. Read the input file line by line.
   5. Update the parameter block.
   6. Create the thread.
   7. Wait for the termination of the thread.
   8. Release the resources used by the thread.
   9. Define the thread start routine.
  10. Declare local variables needed for descriptors for the objects read from
      the input file.

 The following paragraphs describe the corresponding step numbers from the
 program listing in the next section:

 Step 1 includes the header file pthread.h which is required for thread
 programming.

 Step 2 defines a parameter block structure type for the thread start routine.
 A thread start routine must have exactly one parameter. However, add_or_remove
 requires three parameters: session object, input line and operating mode. The
 structure pb_add_or_remove is defined as the parameter block for these
 components. Therefore, the single parameter block contains the three
 parameters required by add_or_remove.

 Step 3 declares arrays for thread handles and parameter blocks. The routine
 which creates the thread (main in this case) must maintain the following
 information for each thread:

   o  A thread handle of type pthread_t to identify the thread for join and
      detach calls.

   o  A thread specific parameter block that cannot be accessed by any other
      thread. This makes sure that a parameter for one thread is not
      overwritten by another thread.

 Step 4 reads the input file line by line. A thread is created for each line. A
 maximum MAX_THREAD_NO of threads are created in parallel. The program then
 waits for the termination of the created threads so that it can release the
 resources used by these threads, allowing it to create new threads for
 remaining input lines (if any).

 The absolute maximum number of threads working in parallel depends on system
 limits; for thradd a value of 10 was chosen (see thradd.h), which is well
 below the maximum on most systems.

 Step 5 updates the parameter block. For each thread a different element of the
 array of parameter blocks is used.

 Step 6 creates the thread. The thread is created by using the function
 pthread_create. The function has four parameters:

   o  The thread handle (output) is stored in an element of the array of type
      pthread_t.

   o  For the thread characteristics, the default pthread_attr_default is used.

   o  The start routine for this thread is add_or_remove.

   o  The parameter passed to add_or_remove is a pointer to an element of the
      array of parameter blocks.

 Step 7 waits for the termination of the thread. The pthread_join routine is
 called with the thread handle as the input parameter. The program waits for
 the termination of the thread. If the thread has already terminated, then
 pthread_join returns immediately. The second parameter of pthread_join
 contains the return value of the start function; here it's a dummy value
 because add_or_remove returns a void. add_or_remove is designed as a void
 function because the calling routine does not have to deal with error cases.
 The add_or_remove routine prints status messages itself to show the processing
 order of the threads. Normally a status should be returned to the application.

 Step 8 releases the resources used by the thread. The thread handle is used as
 input for the function pthread_detach, which releases the resources (for
 example, memory) used by the thread.

 Step 9 defines the thread start routine. As previously mentioned, the thread
 start routine must have exactly one parameter. In this case, it is a pointer
 to the parameter block structure defined in Step 2.

 Step 10 declares local variables needed for descriptors for the objects read
 from the input file. These descriptors are variables and are declared as
 automatic because of the reentrant requirement. In the previous sample
 programs, descriptors were generally declared static. For this example, only
 the constant descriptors declared in thradd.h can be declared static.

 This program shows only a small part of the possibilities of multithreaded XDS
 programming.


ΓòÉΓòÉΓòÉ 10. XDS Interface Description ΓòÉΓòÉΓòÉ

The XDS interface contains a number of functions, together with many OM classes
of OM objects, which are used as the parameters and results of the functions.
Both the functions and the OM objects are based closely on the Abstract Service
that is specified in the standards (see The Directory: Abstract Service
Definition, ISO 9594-3, CCITT X.511).

The interface models the directory interactions as service requests made
through a number of interface functions, which take a number of input
parameters. Each valid request causes an operation within the Directory
Service, which eventually returns a status and any result of the operation.

All interactions between the user and the Directory Service belong to a
session, which is represented by an OM object passed as the first parameter to
most interface functions.

The other parameters to the functions include a context and various
service-specific parameters. The context includes a number of parameters that
are common to many functions, and that seldom change from operation to
operation.

Each of the components of this model are described in the following sections
along with other features of the interface, such as security.


ΓòÉΓòÉΓòÉ 10.1. XDS Conformance to Standards ΓòÉΓòÉΓòÉ

The XDS interface defines an API that application programs can use to access
the functions of the underlying Directory Service. The DCE XDS API conforms to
the X/Open CAE Specification, API to Directory Services (XDS) (November 1991).

The DCE XDS implementation supports the following features:

   o  A synchronous interface. Asynchronous functionality can be achieved by
      using threads as described in XDS Programming.

   o  All synchronous interface functions except ds_search and ds_modify_rdn
      are supported. The two asynchronous specific functions are handled as
      follows: (for all practical purposes, these functions are not supported)

            ds_abandon

      This call does not issue a Directory Service abandon operation. It
      returns with a DS_C_ABANDON_FAILED (DS_E_TOO_LATE) error.

            ds_receive_result

      If there are any outstanding operations (when multiple threads issue XDS
      calls in parallel), this function returns DS_SUCCESS with the
      completion_flag_return parameter set to DS_OUTSTANDING_OPERATIONS. If no
      XDS calls are outstanding, this function returns DS_SUCCESS with the
      completion_flag_return parameter set to DS_NO_OUTSTANDING_OPERATION.

   o  Automatic connection management is not provided. The ds_bind and
      ds_unbind functions always try, respectively, to set up and release
      Directory Service connections immediately.

   o  The DS_FILE_DESCRIPTOR attribute of the DS_C_SESSION object is not used.

   o  The default values for OM attributes in the DS_C_CONTEXT and DS_C_SESSION
      objects are described in XDS Class Definitions.

   o  There is no support for local strings.  When using XDS/XOM over CDS, no
      mapping of input or output data is done.  It is a parameter on the
      following API's:

        -  dsX_extract_attr_values()
        -  omX_extract()
        -  omX_object_to_string()
        -  omX_string_to_object()
        -  om_get()
        -  om_read()

 DCE XDS supports four packages, of which one is mandatory and three are
 optional. Use of the optional packages is negotiated using ds_version. Only
 the required package is necessary for XDS/XOM over CDS. The packages are as
 follows:

   o  The Directory Service Package (as defined in XDS Class Definitions),
      which also includes the errors. This package is required.

   o  The Basic Directory Contents Package (as defined in Basic Directory
      Contents Package). This package is optional and is not required for
      XDS/XOM over CDS. However, it's xdsbdcp.h header file is required if any
      X.500 cell names are used.

   o  The Global Directory Service Package is optional and is not required for
      XDS/XOM over CDS.

   o  The MHS Directory User Package is optional and is not required for
      XDS/XOM over CDS.

 None of the OM classes defined in these four packages are able to be encoded.
 Thus, DCE XDS application programmers do not require the use of the XOM
 functions om_encode and om_decode, which are not supported by the DCE XOM API.


ΓòÉΓòÉΓòÉ 10.2. The XDS Functions ΓòÉΓòÉΓòÉ

As mentioned already, the standards define Abstract Services that requestors
use to interact with the directory. Each of these Abstract Services maps to a
single function call, and the detailed specifications are given in the XDS
reference pages in the DCE for OS/2 Warp: Application Development Reference.
The services and the function calls to which they map are as follows:

 DirectoryBind         (maps to ds_bind)
 DirectoryUnbind       (maps to ds_unbind)
 Read                  (maps to ds_read)
 Compare               (maps to ds_compare)
 Abandon               (maps to ds_abandon; not supported)
 List                  (maps to ds_list)
 Search                (maps to ds_search; not supported for XDS over CDS)
 AddEntry              (maps to ds_add_entry)
 RemoveEntry           (maps to ds_remove_entry)
 ModifyEntry           (maps to ds_modify_entry)
 ModifyRDN             (maps to ds_modify_rdn; not supported for XDS over CDS)

 There is a function called ds_receive_result, which has no counterpart in the
 Abstract Service. It is used with asynchronous operations. See the DCE for
 OS/2 Warp: Application Development Reference for information on how the
 asynchronous functions ds_abandon and ds_receive_result are handled by the DCE
 XDS API.

 The ds_initialize, ds_shutdown, and ds_version functions are used to control
 the XDS API and do not initiate any directory operations.

 The interface functions are summarized in the following list:

   o  The XDS Interface Functions

           Name                       Description

           ds_abandon                 Abandons the result of a pending
                                      asynchronous operation. This function is
                                      not supported (see XDS Conformance to
                                      Standards for more information).

           ds_add_entry               Adds a leaf entry to the CDS namespace.

           ds_bind                    Opens a session with the CDS namespace.

           ds_compare                 Compares a purported attribute value with
                                      the attribute value stored in a CDS
                                      object.

           ds_initialize              Initializes the XDS interface.

           ds_list                    Enumerates the names of the immediate
                                      subordinates of a particular directory
                                      entry.

           ds_modify_entry            Performs modification to a directory
                                      entry.

           ds_modify_rdn              Changes the RDN of a leaf entry. This
                                      function is not supported.

           ds_read                    Queries information on a particular entry
                                      by name.

           ds_receive_result          Retrieves the result of a asynchronously
                                      executed function (This function is not
                                      supported.) See XDS Conformance to
                                      Standards for more information.

           ds_remove_entry            Removes a leaf entry from the DIT.

           ds_search                  Finds entries of interest in a portion of
                                      the directory information tree. This
                                      function is not supported.

           ds_shutdown                Discards a workspace.

           ds_unbind                  Unbinds from a directory session.

           ds_version                 Negotiates features of the interface and
                                      service.


ΓòÉΓòÉΓòÉ 10.3. The XDS Negotiation Sequence ΓòÉΓòÉΓòÉ

The interface has an initialization and shutdown sequence that permits the
negotiation of optional features. This involves the ds_initialize, ds_version,
and ds_shutdown functions.

Every application program must first call ds_initialize, which returns a
workspace. This workspace supports the standard Directory Service Package (see
XDS Class Definitions).

The workspace can be extended to support the optional Basic Directory Contents
Package (see The Basic Directory Contents Package).

Note:  ds_version is not required for XDS/XOM over CDS.

 These packages are identified by means of OSI Object Identifiers, and these
 Object Identifiers are supplied to ds_version to incorporate the extensions
 into the workspace.

 After a workspace with the required features is negotiated, the application
 can use the workspace as required. It can create and manipulate OM objects
 using the OM functions, and can start one or more directory sessions using
 ds_bind.

 After completing its tasks, terminating all its directory sessions using
 ds_unbind, and releasing all its OM objects using om_delete, the application
 needs to ensure that resources associated with the interface are freed by
 calling ds_shutdown.

 It is possible to start another cycle by calling ds_initialize if so required
 by the application design.


ΓòÉΓòÉΓòÉ 10.4. The session Parameter ΓòÉΓòÉΓòÉ

A session binds the XDS/XOM to the CDS namespace. The session parameter is
passed as the first parameter to most interface functions.

A session is described by an OM object of OM class DS_C_SESSION. It is created
and appropriate parameter values can be set using the OM functions. A directory
session then starts with ds_bind and later ends with ds_unbind. A session with
default parameters can be started by passing the constant DS_DEFAULT_SESSION as
the DS_C_SESSION parameter to ds_bind.

The ds_bind function must be called before DS_C_SESSION can be used as a
parameter to any other function in this interface. After ds_unbind is called,
ds_bind must be called again if another session is to be started.

The interface supports multiple concurrent sessions so that an application
implemented as a single process, such as a server in a client/server model, can
interact with the directory using several identities, and a process can
interact directly and concurrently with different parts of the directory.

Details of the OM Class DS_C_SESSION are given in XDS Class Definitions.


ΓòÉΓòÉΓòÉ 10.5. The context Parameter ΓòÉΓòÉΓòÉ

The context defines the characteristics of the directory interaction that are
specific to a particular directory operation. Nevertheless, the same
characteristics are often used for many operations. Since these parameters are
presumed to be relatively static for a given directory user during a particular
directory interaction, these parameters are collected into an OM object of OM
class DS_C_CONTEXT, which is supplied as the second parameter of most Directory
Service requests. This reduces the number of parameters passed to each
function.

The context includes many administrative details, such as the CommonArguments
defined in the Abstract Service, which affect the processing of each directory
operation. These include a number of ServiceControls, which allow control over
some aspects of the service. The ServiceControls include options such as
dontDereferenceAliases.

Each of these is mapped onto an OM attribute in the context (see XDS Class
Definitions).

The effect of passing the context parameter is as if its contents were passed
as a group of additional parameters for every function call. The value of each
component of the context is determined when the interface function is called,
and remains fixed throughout the operation.

All OM attributes in the class DS_C_CONTEXT have default values, some of which
are administered locally. The constant DS_DEFAULT_CONTEXT can be passed as the
value of the DS_C_CONTEXT parameter to the interface functions, and has the
same effect as a context OM object created with default values. The context
must be a private object, unless it is DS_DEFAULT_CONTEXT.

See XDS Class Definitions for detailed specifications of the OM class
DS_C_CONTEXT.


ΓòÉΓòÉΓòÉ 10.6. The XDS Function Arguments ΓòÉΓòÉΓòÉ

The Abstract Service defines specific parameters for each operation. These are
mapped onto corresponding parameters to each interface function, which are also
called input parameters. Although each service has different parameters, some
specific parameters recur in several operations and these are briefly
introduced here. For complete details of these parameters, see XDS Class
Definitions

All parameters that are OM objects can generally be supplied to the interface
functions as public objects (that is, descriptor lists) or as private objects.
Private objects must be created in the workspace that is returned by
ds_initialize. In some cases, constants can be supplied instead of OM objects.

Note:  Wherever a function can accept an instance of a particular OM class as
       the value of a parameter, it also accepts an instance of any subclass of
       the OM class. For example, most functions have a name parameter, which
       accepts values of OM class DS_C_NAME. It is always acceptable to supply
       an instance of the subclass DS_C_DS_DN as the value of the parameter.


ΓòÉΓòÉΓòÉ 10.6.1. Attribute and Attribute Value Assertion ΓòÉΓòÉΓòÉ

Each directory attribute is represented in the interface by an OM object of OM
class DS_C_ATTRIBUTE. The type of the directory attribute is represented by an
OM attribute, DS_ATTRIBUTE_TYPE, within the OM object. The values of the
directory attribute are expressed as the values of the OM attribute
DS_ATTRIBUTE_VALUES.

The representation of the attribute value depends on the attribute type and is
determined as indicated in the following list. This list describes the way in
which an application program must supply values to the interface; for example,
in the changes parameter to ds_modify_entry. The interface follows the same
rules when returning attribute values to the application; for example, in the
ds_read result.

   o  The first possibility is that the attribute type and the representation
      of the corresponding values can be defined in a package; for example, the
      selected attribute types from the standards that are defined in Basic
      Directory Contents Package. In this case, attribute values are
      represented as specified.

   o  If the attribute type is not known and the value is an ASN.1 simple type
      such as IntegerType, the representation is the corresponding type
      specified in Information Syntaxes.

   o  If the attribute type is not known and the value is an ASN.1 structured
      type, the value is represented in the Basic Encoding Rules (BER) with OM
      syntax String(OM_S_ENCODING_STRING).

 Where attribute values have OM syntax String(*), they can be long segmented
 strings, and the functions om_read and om_write need to be used to access
 them.

 An Attribute Value Assertion (AVA) is an assertion about the value of an
 attribute of an entry, and can be TRUE, FALSE, or undefined. It consists of an
 attribute type and a single value. In general, the AVA is TRUE if one of the
 values of the given attribute in the entry matches the given value. An AVA is
 represented in the interface by an instance of OM class DS_C_AVA, which is a
 subclass of DS_C_ATTRIBUTE and can only have one value.

 Information used by ds_add_entry to construct a new directory entry is
 represented by an OM object of OM class DS_C_ATTRIBUTE_LIST, which contains a
 single multivalued OM attribute whose values are OM objects of OM class
 DS_C_ATTRIBUTE.


ΓòÉΓòÉΓòÉ 10.6.2. The EntryInformationSelection Parameter ΓòÉΓòÉΓòÉ

The selection parameter of the ds_read operation tailors its results to obtain
just part of the required entry. Information on all attributes, no attributes,
or a specific group of attributes can be chosen. Attribute types are always
returned, but the attribute values are not necessarily returned.

The value of the parameter is an instance of OM class
DS_C_ENTRY_INFO_SELECTION, but one of the constants in the following list can
be used in simple cases:

   o  To verify the existence of an entry for the purported name, use the
      constant DS_SELECT_NO_ATTRIBUTES.

   o  To return just the types of all attributes, use the constant
      DS_SELECT_ALL_TYPES.

   o  To return the types and values of all attributes, use the constant
      DS_SELECT_ALL_TYPES_AND_VALUES.

 To choose a particular set of attributes, create a new instance of the OM
 class DS_C_ENTRY_INFO_SELECTION and set the appropriate OM attribute values
 using the OM functions.


ΓòÉΓòÉΓòÉ 10.6.3. The name Parameter ΓòÉΓòÉΓòÉ

Most operations take a name parameter to specify the target of the operation.
The name is represented by an instance of one of the subclasses of the OM class
DS_C_NAME. The DCE XDS API defines the subclass DS_C_DS_DN to represent
distinguished names and other names.

For directory interrogations, any aliases in the name are dereferenced, unless
prohibited by the DS_DONT_DEREFERENCE_ALIASES service control. However, for
modify operations, this service control is ignored if set, and aliases are
never dereferenced.

RDNs are represented by an instance of one of the subclasses of the OM class
DS_C_RELATIVE_NAME. The DCE XDS API defines the subclass DS_C_DS_RDN to
represent RDNs.


ΓòÉΓòÉΓòÉ 10.7. XDS Function Call Results ΓòÉΓòÉΓòÉ

All XDS functions return a DS_status, which is the C function result. Most
return data in an invoke_id parameter, which identifies the particular
invocation and the interrogation operations each return data in the result
parameter. The result value is returned using a pointer that is supplied as a
parameter of the C function. These three types of function results are
introduced in the following sections.

All OM objects returned by interface functions (results and errors) are private
objects in the workspace returned by ds_initialize.


ΓòÉΓòÉΓòÉ 10.7.1. The invoke_id Parameter ΓòÉΓòÉΓòÉ

All interface functions that call a Directory Service operation return an
invoke_id parameter, which is an integer that identifies the particular
invocation of an operation. Since asynchronous operations (within the same
thread) are not supported, the invoke_id return value is no longer relevant for
operations. DCE application programmers must still supply this parameter as
described in the XDS reference pages (see DCE for OS/2 Warp: Application
Development Reference) but should ignore the value returned.


ΓòÉΓòÉΓòÉ 10.7.2. The result Parameter ΓòÉΓòÉΓòÉ

Directory Service interrogation operations return a result value only if they
succeed. All errors from these operations are reported in DS_status as are
errors from all other operations (see The DS_status Return Value).

The result of an interrogation is returned in a private object whose OM class
is appropriate to the particular operation. The format of directory operation
results is driven by the Abstract Service. To simplify processing, the result
of a single operation is returned in a single OM object, which corresponds to
the abstract result defined in the standards. The components of the result of
an operation are represented by OM attributes in the operation's result object.
All information contained in the Abstract Service result is made available to
the application program. The result is inspected using the functions provided
in the Object Management API, om_get.

Only the interrogation operations produce results, and each type of
interrogation has a specific OM class of OM object for its result. These OM
classes are as follows (see XDS Class Definitions):

   o  DS_C_COMPARE_RESULT
   o  DS_C_LIST_RESULT
   o  DS_C_READ_RESULT

 The results of the different operations share several common components,
 including the CommonResults defined in the standards (see The Directory:
 Abstract Service Definition, ISO 9594-3, CCITT X.511) by inheriting OM
 attributes from the superclass DS_C_COMMON_RESULTS. An additional common
 component is the full DN of the target object, after all aliases are
 dereferenced.

 The actual OM class of the result can always be a subclass of that named in
 order to allow flexibility for extensions. Thus, om_instance always needs to
 be used when testing the OM class.

 Any attribute values in the result are represented as discussed in Attribute
 and Attribute Value Assertion.


ΓòÉΓòÉΓòÉ 10.7.3. The DS_status Return Value ΓòÉΓòÉΓòÉ

Every interface function returns a DS_status value, which is either the
constant DS_SUCCESS or an error. Errors are represented by private objects
whose OM class is a subclass of DS_C_ERROR.

Other results of functions are not valid unless the status result has the value
DS_SUCCESS.


ΓòÉΓòÉΓòÉ 10.8. Synchronous Operations ΓòÉΓòÉΓòÉ

Since asynchronous use of the interface (within the same thread) is not
supported, the value of the DS_ASYNCHRONOUS OM attribute in DS_C_CONTEXT is
always OM_FALSE, causing all operations within the same thread to be
synchronous.

In synchronous mode, all functions wait until the operation is complete before
returning. The thread of control is blocked within the interface after calling
a function, and it can use the result immediately after the function returns.

Implementations define a limit on the number of asynchronous operations that
can be outstanding at any one time on any one session. The limit is given by
the implementation-defined constant DS_MAX_OUTSTANDING_OPERATIONS. It always
has the value 0 (zero) because asynchronous operations within the same thread
are not supported.

All errors occurring during a synchronous request are reported when the
function returns.

The DS_FILE_DESCRIPTOR OM attribute of DS_C_SESSION is not used by the DCE XDS
API and is always set to DS_NO_VALID_FILE_DESCRIPTOR.


ΓòÉΓòÉΓòÉ 11. XDS Class Definitions ΓòÉΓòÉΓòÉ

When referring to classes and attributes in the Directory Service, this guide
makes a clear distinction between OM classes and directory classes, and between
OM attributes and directory attributes. In both cases, the former is a
construct of the closely associated Object Management interface, while the
latter is a construct of the Directory Service to which XDS provides access.
The terms object class and attribute indicate the directory constructs, while
the phrases OM class and OM attribute indicate the Object Management
constructs.

Note:  Not all of the OM objects defined in this section are applicable to
       XDS/XOM over CDS. One example is DS_C_SEARCH_RESULT, which is valid for
       ds_search, but not supported for XDS/XOM over CDS. These OM objects are
       provided in this documentation for completeness. They should not,
       however, be needed by any application using XDS/XOM over CDS.


ΓòÉΓòÉΓòÉ 11.1. Introduction to OM Classes ΓòÉΓòÉΓòÉ

This section defines, in alphabetical order, the OM classes that make up the
Directory Service Package. This package incorporates the OM classes for the
errors which may be returned at the XDS interface. The object identifier
associated with this package is {iso(1) identified-organization(3)
icd-ecma(0012) member-company(2) dec(1011) xopen(28) dsp(0)} with the following
encoding:

\x2B\xC\x2\x87\x73\x1C\x0

This object identifier is represented by the constant DS_SERVICE_PKG.

The Object Management notation is briefly described in the following text. See
Information Syntaxes, XOM Service Interface, and Object Management Package for
more information on Object Management.

Each OM class is described in a separate section that identifies the OM
attributes specific to that OM class. The OM classes and OM attributes for each
OM class are listed in alphabetical order. The OM attributes that can be found
in an instance of an OM class are those OM attributes specific to that OM
class, as well as those inherited from each of its superclasses. The OM
class-specific OM attributes are defined in a table. The table indicates the
name of each OM attribute, the syntax of each of its values, any restrictions
upon the length (in bits, octets (bytes), or characters) of each value, any
restrictions upon the number of values, and the value, if any, om_create
supplies.

The constants that represent the OM classes and OM attributes in the C binding
are defined in the xds.h(4xds) header file (see the DCE for OS/2
Warp:Application Development Reference).


ΓòÉΓòÉΓòÉ 11.2. XDS Errors ΓòÉΓòÉΓòÉ

Errors are reported to the application program by means of DS_status, which is
a result of every function (it is the function result in the C language binding
for most functions). A function that completes successfully returns the value
DS_SUCCESS, whereas one that is not successful returns an error. The error is a
private object containing details of the problem that occurred. The error
constant DS_NO_WORKSPACE can be returned by all Directory Service functions,
except ds_initialize. DS_NO_WORKSPACE is returned if ds_initialize is not
invoked before calling any other Directory Service function.

Errors are classified into ten OM classes. The standards (see The Directory:
Abstract Service Definition, ISO 9594-3, CCITT X.511) classify errors into
eight different groups, as follows:

   o  Abandoned
   o  Abandon Failed
   o  Attribute Error
   o  Name Error
   o  Referral
   o  Security Error
   o  Service Error
   o  Update Error

 The Directory Service interface never returns an Abandoned error. The
 interface also defines three more kinds of errors - DS_C_LIBRARY_ERROR,
 DS_C_COMMUNICATIONS_ERROR, and DS_C_SYSTEM_ERROR. Each of these error types is
 represented by an OM class. These OM classes are detailed in later sections.
 All of them inherit the OM attribute DS_PROBLEM from their superclass
 DS_C_ERROR, which is described in this section. The values DS_PROBLEM can take
 are listed in the relevant portions of this section. The error OM classes
 defined in this section are part of the Directory Service Package.

 A DS_C_ATTRIBUTE_ERROR is not a subclass of DS_C_ERROR and is special because
 it can report several problems at once. Each one is reported in
 DS_C_ATTRIBUTE_PROBLEM, which is a subclass of DS_C_ERROR.


ΓòÉΓòÉΓòÉ 11.3. OM Class Hierarchy ΓòÉΓòÉΓòÉ

The following shows the hierarchical organization of the OM classes defined in
this section and, as a result, shows which OM classes inherit additional OM
attributes from their superclasses. In the following list, subclassification is
indicated by indentation, and the names of abstract classes are in italics.
Thus, for example, the concrete class DS_C_PRESENTATION_ADDRESS is an immediate
subclass of the abstract class DS_C_ADDRESS, which in turn is an immediate
subclass of the abstract class OM_C_OBJECT. OM_C_OBJECT is defined in XOM
Programming.

OM_C_OBJECT

   o  DS_C_ACCESS_POINT
   o  DS_C_ADDRESS
        -  DS_C_PRESENTATION_ADDRESS
   o  DS_C_ATTRIBUTE
        -  DS_C_AVA
        -  DS_C_ENTRY_MODE
        -  DS_C_FILTER_ITEM
   o  DS_C_ATTRIBUTE_LIST
        -  DS_C_ENTRY_INFO
   o  DS_C_COMMON_RESULTS
        -  DS_C_COMPARE_RESULT
        -  DS_C_LIST_INFO
        -  DS_C_READ_RESULT
        -  DS_C_SEARCH_INFO
   o  DS_C_CONTEXT
   o  DS_C_CONTINUATION_REF
   o  DS_C_ENTRY_INFO_SELECTION
   o  DS_C_ENTRY_MOD_LIST
   o  DS_C_ERROR
   o  DS_C_EXT
   o  DS_C_FILTER
   o  DS_C_LIST_INFO_ITEM
   o  DS_C_LIST_RESULT
   o  DS_C_NAME
        -  DS_C_DS_DN
   o  DS_C_OPERATION_PROGRESS
   o  DS_C_PARTIAL_OUTCOME_QUAL
   o  DS_C_RELATIVE_NAME
        -  DS_C_DS_RDN
   o  DS_C_SEARCH_RESULT
   o  DS_C_SESSION

 None of the classes in the preceding list are encodable using om_encode and
 om_decode. The application is not permitted to create or modify instances of
 some OM classes because these OM classes are only returned by the interface
 and never supplied by it. These OM classes are as follows:

   o  DS_C_ACCESS_POINT
   o  DS_C_COMPARE_RESULT
   o  DS_C_CONTINUATION_REF
   o  All subclasses of DS_C_ERROR
   o  DS_C_LIST_INFO
   o  DS_C_LIST_INFO_ITEM
   o  DS_C_LIST_RESULT
   o  DS_C_OPERATION_PROGRESS
   o  DS_C_PARTIAL_OUTCOME_QUAL
   o  DS_C_READ_RESULT
   o  DS_C_SEARCH_INFO
   o  DS_C_SEARCH_RESULT


ΓòÉΓòÉΓòÉ 11.4. DS_C_ABANDON_FAILED ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_ABANDON_FAILED reports a problem encountered
during an attempt to abandon an operation.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ERROR, and no additional OM attributes.

The OM attribute DS_PROBLEM, which is inherited from the superclass DS_C_ERROR,
identifies the problem. Its value is one of the following:

   o  DS_E_CANNOT_ABANDON
   o  DS_E_NO_SUCH_OPERATION
   o  DS_E_TOO_LATE

 A ds_abandon XDS call always returns a DS_E_TOO_LATE error for the
 DS_C_ABANDON_FAILED OM class. See XDS Interface Description information on
 abandoning directory operations.


ΓòÉΓòÉΓòÉ 11.5. DS_C_ACCESS_POINT ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_ACCESS_POINT identifies a particular point that a
DSA can be accessed.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 8. OM Attributes of DS_C_ACCESS_POINT                       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTES       Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ADDRESS         Γöé Object(DS_C_ADDRESS)    Γöé   -   Γöé   1   Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_AE_TITLE        Γöé Object(DS_C_NAME)      Γöé   -   Γöé   1   Γöé   -   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_ADDRESS     This attribute indicates the address of the DSA to be used when
                communicating with it.

 DS_AE_TITLE    This attribute indicates the name of the DSA.


ΓòÉΓòÉΓòÉ 11.6. DS_C_ADDRESS ΓòÉΓòÉΓòÉ

The OM class DS_C_ADDRESS represents the address of a particular entity or
service, such as a DSA.

It is an abstract class that has the OM attributes of its superclass,
OM_C_OBJECT, and no other OM attributes.

An address is an unambiguous name, label, or number that identifies the
location of the entity or service. All addresses are represented as instances
of some subclass of this OM class.

The only subclass defined by the DCE XDS API is DS_C_PRESENTATION_ADDRESS,
which is the presentation address of an OSI application entity used for OSI
communications with this subclass.


ΓòÉΓòÉΓòÉ 11.7. DS_C_ATTRIBUTE ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_ATTRIBUTE is an attribute of an object and is,
therefore, a component of its directory entry.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 9. OM Attributes of DS_C_ATTRIBUTE                        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTES       Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ATTRIBUTE_TYPE     Γöé String(OM_S_OBJECT     Γöé   -   Γöé   1   Γöé   -   Γöé
Γöé              Γöé _IDENTIFIER_STRING)     Γöé     Γöé     Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ATTRIBUTE_VALUES    Γöé Any             Γöé   -   Γöé  0 or  Γöé   -   Γöé
Γöé              Γöé               Γöé     Γöé  more  Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_ATTRIBUTE_TYPE                  The attribute type that indicates the class
                                    of information given by this attribute.

 DS_ATTRIBUTE_VALUES                The attribute values. The OM value syntax
                                    and the number of values allowed for this
                                    OM attribute are determined by the value of
                                    the DS_ATTRIBUTE_TYPE OM attribute in
                                    accordance with the rules given in
                                    Attribute and Attribute Value Assertion.

                                    If the values of this OM attribute have the
                                    syntax String(*), the strings can be long
                                    and segmented. For this reason, om_read and
                                    om_write need to be used to access all
                                    String(*) values.

 Note:  A directory attribute must always have at least one value, although it
        is acceptable for instances of this OM class not to have any values.


ΓòÉΓòÉΓòÉ 11.8. DS_C_ATTRIBUTE_ERROR ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_ATTRIBUTE_ERROR reports an attribute-related
Directory Service error.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 10. OM Attributes of DS_C_ATTRIBUTE_ERROR                     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTES       Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_OBJECT_NAME       Γöé Object(DS_C_NAME)      Γöé   -   Γöé   1   Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_PROBLEMS        Γöé Object(DS_C_ATTRIBUTE    Γöé   -   Γöé  1 or  Γöé   -   Γöé
Γöé              Γöé _PROBLEM)          Γöé     Γöé  more  Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_OBJECT_NAME             This attribute contains the name of the directory
                            entry to which the operation is applied when the
                            failure occurs.

 DS_PROBLEMS                This attribute documents the attribute-related
                            problems encountered. Uniquely, a
                            DS_C_ATTRIBUTE_ERROR can report several problems at
                            once. All problems are related to the preceding
                            object.


ΓòÉΓòÉΓòÉ 11.9. DS_C_ATTRIBUTE_LIST ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_ATTRIBUTE_LIST is a list of directory attributes.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attribute listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 11. OM Attribute of DS_C_ATTRIBUTE_LIST                      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ATTRIBUTES       Γöé Object (DS_C_ATTRIBUTE)   Γöé   -   Γöé  0 or  Γöé   -   Γöé
Γöé              Γöé               Γöé     Γöé  more  Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_ATTRIBUTES              The attributes that constitute a new object's
                            directory entry or those selected from an existing
                            entry.


ΓòÉΓòÉΓòÉ 11.10. DS_C_ATTRIBUTE_PROBLEM ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_ATTRIBUTE_PROBLEM documents one attribute-related
problem encountered while performing an operation as requested on a particular
occasion.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ERROR, in addition to the OM attributes listed in the
following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 12. OM Attribute of DS_C_ATTRIBUTE_PROBLEM                    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ATTRIBUTE_TYPE     Γöé String(OM_S_OBJECT     Γöé   -   Γöé   1   Γöé   -   Γöé
Γöé              Γöé _IDENTIFIER_STRING)     Γöé     Γöé     Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ATTRIBUTE_VALUE     Γöé Any             Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_ATTRIBUTE_TYPE                   This attribute identifies the type of
                                     attribute with which the problem is
                                     associated.

 DS_ATTRIBUTE_VALUE                  This attribute specifies the attribute
                                     value with which the problem is
                                     associated. Its syntax is determined by
                                     the value of DS_ATTRIBUTE_TYPE. This OM
                                     attribute is present if it is necessary to
                                     avoid ambiguity.

 The OM attribute DS_PROBLEM, which is inherited from the superclass
 DS_C_ERROR, identifies the problem. Its value is one of the following:

   o  DS_E_ATTRIBUTE_OR_VALUE_EXISTS
   o  DS_E_CONSTRAINT_VIOLATION
   o  DS_E_INAPPROP_MATCHING
   o  DS_E_INVALID_ATTRIBUTE_SYNTAX
   o  DS_E_NO_SUCH_ATTRIBUTE_OR_VALUE
   o  DS_E_UNDEFINED_ATTRIBUTE_TYPE


ΓòÉΓòÉΓòÉ 11.11. DS_C_AVA ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_AVA(Attribute Value Assertion) is a proposition
concerning the values of a directory entry.

An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ATTRIBUTE, and no other OM attributes. An additional
restriction on this OM class is that there must be exactly one value of the OM
attribute DS_ATTRIBUTE_VALUES. The DS_ATTRIBUTE_TYPE remains single valued. The
OM value syntax of DS_ATTRIBUTE_VALUES must conform to the rules outlined in
DS_C_ATTRIBUTE_LIST.


ΓòÉΓòÉΓòÉ 11.12. DS_C_COMMON_RESULTS ΓòÉΓòÉΓòÉ

The OM class DS_C_COMMON_RESULTS contains the results that are returned by, and
are common to, the directory interrogation operations.

It is an abstract OM class that has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 13. OM Attributes of DS_C_COMMON_RESULTS                     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ALIAS_DEREFERENCED   Γöé OM_S_BOOLEAN        Γöé   -   Γöé   1   Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_PERFORMER        Γöé Object (DS_C_NAME)     Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_ALIAS_DEREFERENCED                 This attribute indicates whether the
                                       name of the target object that is passed
                                       as a function argument includes an alias
                                       that is dereferenced to determine the
                                       DN.

 DS_PERFORMER                          When present, this attribute gives the
                                       DN of the performer of a particular
                                       operation. It can be present when the
                                       result is signed, and it holds the name
                                       of the DSA that signed the result. The
                                       DCE Directory Service does not support
                                       the optional feature of signed results;
                                       therefore, this OM attribute is never
                                       present.


ΓòÉΓòÉΓòÉ 11.13. DS_C_COMMUNICATIONS_ERROR ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_COMMUNICATIONS_ERROR reports an error occurring in
the other OSI services supporting the Directory Service.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ERROR, and no additional OM attributes.

Communications errors include those arising in remote operations, association
control, presentation, session, and transport.

The OM attribute DS_PROBLEM, which is inherited from the superclass DS_C_ERROR,
identifies the problem. Its value is DS_E_COMMUNICATIONS_PROBLEM.


ΓòÉΓòÉΓòÉ 11.14. DS_C_COMPARE_RESULT ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_COMPARE_RESULT contains the results of a
successful call to ds_compare.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_COMMON_RESULTS, in addition to the OM attributes listed in
the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 14. OM Attribute of DS_C_COMPARE_RESULT                      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_FROM_ENTRY       Γöé OM_S_BOOLEAN        Γöé   -   Γöé   1   Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_MATCHED         Γöé OM_S_BOOLEAN        Γöé   -   Γöé   1   Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_OBJECT_NAME       Γöé Object (DS_C_NAME)     Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_FROM_ENTRY               This attribute indicates whether the assertion is
                             tested against the specified object's entry,
                             rather than a copy of the entry.

 DS_MATCHED                  This attribute indicates whether the assertion
                             specified as an argument returns the value
                             OM_TRUE. It takes the value OM_TRUE if the values
                             are compared and matched; otherwise, it takes the
                             value OM_FALSE.

 DS_OBJECT_NAME              This attribute contains the distinguished name of
                             the target object of the operation. It is present
                             if the OM attribute DS_ALIAS_DEREFERENCED,
                             inherited from the superclass DS_C_COMMON_RESULTS,
                             is OM_TRUE.


ΓòÉΓòÉΓòÉ 11.15. DS_C_CONTEXT ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_CONTEXT contains per-operation arguments that are
accepted by most of the interface functions.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 15. OM Attributes of DS_C_CONTEXT                         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE      Γöé VALUE SYNTAX    Γöé  VALUE  Γöé   VALUE  Γöé VALUE INITIALLY  Γöé
Γöé             Γöé          Γöé  LENGTH  Γöé  NUMBER  Γöé          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                   COMMON ARGUMENTS                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_EXT         Γöé Object(DS_C_EXT)  Γöé   -   Γöé   0 or   Γöé NULL       Γöé
Γöé             Γöé          Γöé      Γöé   more   Γöé          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_OPERATION_PROGRESS  Γöé Object(DS_C    Γöé   -   Γöé    1   Γöé DS_C_OPERATION  Γöé
Γöé             Γöé _OPERATION     Γöé      Γöé       Γöé _NOT_STARTED   Γöé
Γöé             Γöé _PROGRESS     Γöé      Γöé       Γöé          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ALIASED_RDNS     Γöé OM_S_INTEGER    Γöé   -   Γöé  0 or 1  Γöé 0         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                   SERVICE CONTROLS                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_CHAINING_PROHIB   Γöé OM_S_BOOLEAN    Γöé   -   Γöé    1   Γöé OM_TRUE      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_DONT_DEREFERENCE   Γöé OM_S_BOOLEAN    Γöé   -   Γöé    1   Γöé OM_FALSE     Γöé
Γöé _ALIASES        Γöé          Γöé      Γöé       Γöé          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_DONT_USE_COPY    Γöé OM_S_BOOLEAN    Γöé   -   Γöé    1   Γöé OM_TRUE      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_LOCAL_SCOPE     Γöé OM_S_BOOLEAN    Γöé   -   Γöé    1   Γöé OM_FALSE     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_PREFER_CHAINING   Γöé OM_S_BOOLEAN    Γöé   -   Γöé    1   Γöé OM_FALSE     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_PRIORITY       Γöé Enum(DS_Priority) Γöé   -   Γöé    1   Γöé DS_MEDIUM     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_SCOPE_OF_REFERRAL  Γöé Enum(DS_Scope   Γöé   -   Γöé  0 or 1  Γöé DS_COUNTRY    Γöé
Γöé             Γöé _of_Referral)   Γöé      Γöé       Γöé          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_SIZE_LIMIT      Γöé OM_S_INTEGER    Γöé   -   Γöé  0 or 1  Γöé -         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_TIME_LIMIT      Γöé OM_S_INTEGER    Γöé   -   Γöé  0 or 1  Γöé -         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                   LOCAL CONTROLS                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ASYNCHRONOUS     Γöé OM_S_BOOLEAN    Γöé   -   Γöé    1   Γöé OM_FALSE     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_AUTOMATIC      Γöé OM_S_BOOLEAN    Γöé   -   Γöé    1   Γöé OM_TRUE      Γöé
Γöé _CONTINUATION      Γöé          Γöé      Γöé       Γöé          Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

The context gathers several arguments passed to interface functions that are
presumed to be relatively static for a given directory user during a particular
directory interaction. The context is passed as an argument to each function
that interrogates or updates the directory. Although it is generally assumed
that the context is changed infrequently, the value of each argument can be
changed between every operation if required. The DS_ASYNCHRONOUS argument must
not be changed. Each argument is represented by one of the OM attributes of the
DS_C_CONTEXT OM class.

The context contains the common arguments defined in the standards (see The
Directory:  Abstract Service Definition, ISO 9594-3, CCITT X.511), except that
all security information is omitted. These are made up of a number of service
controls explained in the following text, possible extensions in the DS_EXT OM
attribute, and operation progress and alias dereferencing information in the
DS_OPERATION_PROGRESS OM attribute. It also contains a number of arguments that
provide local control over the interface.

The OM attributes of the DS_C_CONTEXT OM class are as follows:

   o  Common Arguments

           DS_EXT                          This attribute represents any future
                                           standardized extensions that need to
                                           be applied to the Directory Service
                                           operation. The DCE XDS
                                           implementation does not evaluate
                                           this optional OM attribute.

           DS_OPERATION_PROGRESS           This attribute represents the state
                                           that the Directory Service assumes
                                           at the start of the operation. This
                                           OM attribute normally takes its
                                           default value,
                                           DS_OPERATION_NOT_STARTED (described
                                           in the DS_C_OPERATION_PROGRESS OM
                                           class definition).

           DS_ALIASED_RDNS                 This attribute indicates to the
                                           Directory Service that the object
                                           component of the operation parameter
                                           is created by dereferencing of an
                                           alias on an earlier operation
                                           attempt. This value is set in the
                                           referral response of the previous
                                           operation.

   o  Service Controls

           DS_CHAINING_PROHIB              This attribute indicates that
                                           chaining and other methods of
                                           distributing the request around the
                                           Directory Service are prohibited.

           DS_DONT_DEREFERENCE_ALIASES     This attribute indicates that any
                                           alias used to identify the target
                                           entry of an operation is not
                                           dereferenced. This allows
                                           interrogation of alias entries
                                           (aliases are never dereferenced
                                           during updates).

           DS_DONT_USE_COPY                This attribute indicates that the
                                           request can only be satisfied by
                                           accessing directory entries and not
                                           by using copies of entries. This
                                           includes both copies maintained in
                                           other DSAs by bilateral agreement
                                           and copies cached locally.

           DS_LOCAL_SCOPE                  This attribute indicates that the
                                           directory request will be satisfied
                                           locally. The meaning of this option
                                           is configured by an administrator.
                                           This option typically restricts the
                                           request to a single DSA or DMD.

           DS_PREFER_CHAINING              This attribute indicates that
                                           chaining is preferred to referrals
                                           when necessary. The Directory
                                           Service is not obliged to follow
                                           this preference, and can return a
                                           referral even if it is set.

           DS_PRIORITY                     This attribute indicates the
                                           priority, relative to other
                                           directory requests, to which the
                                           Directory Service attempts to
                                           satisfy. This is not a guaranteed
                                           service since there is no queuing
                                           throughout the directory. Its value
                                           must be one of the following:

                                             -  DS_LOW
                                             -  DS_MEDIUM
                                             -  DS_HIGH

           DS_SCOPE_OF_REFERRAL            This attribute indicates the part of
                                           the directory where referrals are
                                           limited. This includes referral
                                           errors and partial outcome
                                           qualifiers. Its value must be one of
                                           the following:

                                             -  DS_COUNTRY, meaning DSAs within
                                                the country where the request
                                                originates.

                                             -  DS_DMD, meaning DSAs within the
                                                DMD where the request
                                                originates.

                                           DS_SCOPE_OF_REFERRAL is an optional
                                           attribute. The lack of this
                                           attribute in a DS_C_CONTEXT object
                                           indicates that the scope is not
                                           limited.

           DS_SIZE_LIMIT                   If present, this attribute indicates
                                           the maximum number of objects that
                                           ds_list or ds_search needs to return
                                           information. If this limit is
                                           exceeded, information is returned
                                           about exactly this number of
                                           objects. The objects that are chosen
                                           are not specified because this can
                                           depend on the timing of interactions
                                           between DSAs, among other reasons.

           DS_TIME_LIMIT                   If present, this attribute indicates
                                           the maximum elapsed time, in
                                           seconds, where the service needs to
                                           be provided (not the processing time
                                           devoted to the request). If this
                                           limit is reached, a service error
                                           (DS_E_TIME_LIMIT_EXCEEDED) is
                                           returned, except for the ds_list or
                                           ds_search operations, which return
                                           an arbitrary selection of the
                                           accumulated results.

   o  Local Controls

           DS_ASYNCHRONOUS (Optional Functionality) The interface currently
                                           operates only synchronously (within
                                           the same thread) as detailed in
                                           Synchronous Operations. There is
                                           only one possible value:

                                           OM_FALSE, meaning that the operation
                                           is performed sequentially
                                           (synchronously) with the application
                                           being blocked until a result or
                                           error is returned.

           DS_AUTOMATIC_CONTINUATION       This attribute indicates the
                                           requestor's requirement for
                                           continuation reference handling,
                                           including referrals and those in
                                           partial outcome qualifiers. The
                                           value is one of the following:

                                             -  OM_FALSE, meaning that the
                                                interface returns all
                                                continuation references to the
                                                application program.

                                             -  OM_TRUE, meaning that
                                                continuation references are
                                                automatically processed and the
                                                subsequent results are returned
                                                to the application instead of
                                                the continuation references,
                                                whenever practical. This is a
                                                much simpler option than
                                                OM_FALSE unless the application
                                                has special requirements.

 Note:  Continuation references can still be returned to the application if,
        for example, the relevant DSA cannot be contacted.

 Applications can assume that an object of OM class DS_C_CONTEXT, created with
 default values of all its OM attributes, works with all the interface
 functions. The DS_DEFAULT_CONTEXT constant can be used as an argument to
 interface functions instead of creating an OM object with default values.


ΓòÉΓòÉΓòÉ 11.16. DS_C_CONTINUATION_REF ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_CONTINUATION_REF contains the information that
enables a partially completed directory request to be continued (for example,
following a referral).

An application cannot create or modify instances of this OM class. An instance
of this OM class has the OM attributes of its superclass, OM_C_OBJECT, in
addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 16. OM Attribute of DS_C_CONTINUATION_REF                     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ACCESS_POINTS      Γöé Object(DS_C_ACCESS_POINT)  Γöé   -   Γöé  1 or  Γöé   -   Γöé
Γöé              Γöé               Γöé     Γöé  more  Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ALIASED_RDNS      Γöé OM_S_INTEGER        Γöé   -   Γöé   1   Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_OPERATION_PROGRESS   Γöé Object(DS_C_OPERATION_   Γöé   -   Γöé   1   Γöé   -   Γöé
Γöé              Γöé PROGRESS)          Γöé     Γöé     Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_RDNS_RESOLVED      Γöé OM_S_INTEGER        Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_TARGET_OBJECT      Γöé Object(DS_C_NAME)      Γöé   -   Γöé   1   Γöé   -   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_ACCESS_POINTS                      This attribute indicates the names and
                                       presentation addresses of the DSAs from
                                       where the directory request is
                                       continued.

 DS_ALIASED_RDNS                       This attribute indicates how many (if
                                       any) of the RDNs in the target name are
                                       produced by dereferencing an alias. Its
                                       value is 0 (zero) if no aliases are
                                       dereferenced. This value needs to be
                                       used in the DS_C_CONTEXT of any
                                       continued operation.

 DS_OPERATION_PROGRESS                 This attribute indicates the state where
                                       the directory request must be continued.
                                       This value needs to be used in the
                                       DS_C_CONTEXT of any continued operation.

 DS_RDNS_RESOLVED                      This attribute indicates the number of
                                       RDNs in the supplied object name that
                                       are resolved (using internal references)
                                       and not just assumed to be correct
                                       (using cross-references).

 DS_TARGET_OBJECT                      This attribute indicates the name of the
                                       object that the continuation must focus.


ΓòÉΓòÉΓòÉ 11.17. DS_C_DS_DN ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_DS_DN represents a name of a directory object.

An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_NAME, in addition to the OM attribute listed in the
following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 17. OM Attribute of DS_C_DS_DN                          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_RNDS          Γöé Object(DS_C_DS_RDN)     Γöé   -   Γöé  0 or  Γöé   -   Γöé
Γöé              Γöé               Γöé     Γöé  more  Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_RDNS                               This attribute indicates the sequence of
                                       RDNs that define the path through the
                                       DIT from its root to the object that the
                                       DS_C_DS_DN indicates. The DS_C_DS_DN of
                                       the root of the directory is the null
                                       name (no DS_RDNS values). The order of
                                       the values is significant; the first
                                       value is closest to the root and the
                                       last value is the RDN of the object.


ΓòÉΓòÉΓòÉ 11.18. DS_C_DS_RDN ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_DS_RDN is a relative distinguished name. An RDN
uniquely identifies an immediate subordinate of an object whose entry is
displayed in the DIT.

An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_RELATIVE_NAME, in addition to the OM attribute listed in
the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 18. OM Attribute of DS_C_DS_RDN                          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTES       Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_AVAS          Γöé Object(DS_C_AVA)      Γöé   -   Γöé  1 or  Γöé   -   Γöé
Γöé              Γöé               Γöé     Γöé  more  Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_AVAS                               This attribute indicates the DS_AVAS
                                       that are marked by the DIB as components
                                       of the object's RDN. The assertion is
                                       TRUE of the object but not of any of its
                                       siblings, and the attribute type and
                                       value are displayed in the object's
                                       directory entry. The order of the
                                       DS_AVAS is not significant.


ΓòÉΓòÉΓòÉ 11.19. DS_C_ENTRY_INFO ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_ENTRY_INFO contains selected information from a
single directory entry.

An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ATTRIBUTE_LIST, in addition to the OM attributes listed in
the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 19. OM Attributes of DS_C_ENTRY_INFO                       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTES       Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_FROM_ ENTRY       Γöé OM_S_BOOLEAN        Γöé   -   Γöé   1   Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_OBJECT_NAME       Γöé Object(DS_C_NAME)      Γöé   -   Γöé   1   Γöé   -   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

The OM attribute DS_ATTRIBUTES is inherited from the superclass
DS_C_ATTRIBUTE_LIST. It contains the information extracted from the directory
entry of the target object. The type of each attribute requested and located is
indicated in the list as are its values, if types and values are requested.

The OM class-specific OM attributes are as follows:

 DS_FROM_ENTRY                         This attribute indicates whether the
                                       information is extracted from the
                                       specified object's entry, rather than
                                       from a copy of the entry.

 DS_OBJECT_NAME                        This attribute contains the object's
                                       distinguished name.


ΓòÉΓòÉΓòÉ 11.20. DS_C_ENTRY_INFO_SELECTION ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_ENTRY_INFO_SELECTION identifies the information to
be extracted from a directory entry.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 20. OM Attributes of DS_C_ENTRY_INFO_SELECTION                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE       Γöé VALUE SYNTAX       Γöé  VALUE Γöé  VALUE Γöé    VALUE   Γöé
Γöé              Γöé              Γöé LENGTH Γöé NUMBER Γöé   INITIALLY  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ALL_ATTRIBUTES     Γöé OM_S_BOOLEAN       Γöé   -  Γöé   1  Γöé   OM_TRUE   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ATTRIBUTES_SELECTED  Γöé String(OM_S_OBJECT    Γöé   -  Γöé  0 or  Γöé     -    Γöé
Γöé              Γöé _IDENTIFIER_STRING)    Γöé     Γöé  more  Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_INFO_TYPE       Γöé Enum(DS_Information    Γöé   -  Γöé   1  Γöé   DS_TYPES   Γöé
Γöé              Γöé _Type)          Γöé     Γöé     Γöé  _AND_VALUES  Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_ALL_ATTRIBUTES                     This attribute indicates which
                                       attributes are relevant. It can take one
                                       of the following values:

                                         o  OM_FALSE, meaning that information
                                            is only requested on those
                                            attributes that are listed in the
                                            OM attribute
                                            DS_ATTRIBUTES_SELECTED.

                                         o  OM_TRUE, meaning that information
                                            is requested on all attributes in
                                            the directory entry. Any values of
                                            the OM attribute
                                            DS_ATTRIBUTES_SELECTED are ignored
                                            in this case.

 DS_ATTRIBUTES_SELECTED                This attribute lists the types of
                                       attributes in the entry from which
                                       information will be extracted. The value
                                       of this OM attribute is used only if the
                                       value of DS_ALL_ATTRIBUTES is OM_FALSE
                                       If an empty list is supplied, no
                                       attribute data is returned that could be
                                       used to verify the existence of an entry
                                       for a distinguished name.

 DS_INFO_TYPE                          This attribute identifies what
                                       information will be extracted from each
                                       attribute identified. It must take one
                                       of the following values:

                                         o  DS_TYPES_ONLY, meaning that only
                                            the attribute types of the selected
                                            attributes in the entry are
                                            returned.

                                         o  DS_TYPES_AND_VALUES, meaning that
                                            both the attribute types and the
                                            attribute values of the selected
                                            attributes in the entry are
                                            returned.


ΓòÉΓòÉΓòÉ 11.21. DS_C_ENTRY_MOD ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_ENTRY_MOD describes a single modification to a
specified attribute of a directory entry.

An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ATTRIBUTE, in addition to the OM attribute listed in the
following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 21. OM Attribute of DS_C_ENTRY_MOD                        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE       Γöé VALUE SYNTAX       Γöé  VALUE Γöé  VALUE Γöé  VALUE INI-  Γöé
Γöé              Γöé              Γöé LENGTH Γöé NUMBER Γöé   TIALLY   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_MOD_TYPE        Γöé Enum(DS_Modification_TypeΓöé   -  Γöé   1  Γöé   DS_ADD   Γöé
Γöé              Γöé              Γöé     Γöé     Γöé  _ATTRIBUTE  Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

The attribute type to be modified, and the associated values, are specified in
the OM attributes DS_ATTRIBUTE_TYPE and DS_ATTRIBUTE_VALUES that are inherited
from the DS_C_ATTRIBUTE superclass.

 DS_MOD_TYPE          This attribute identifies the type of modification. It
                      must have one of the following values:

                        o  DS_ADD_ATTRIBUTE, meaning that the specified
                           attribute is absent and will be added with the
                           specified values.

                        o  DS_ADD_VALUES, meaning that the specified attribute
                           is present and that one or more specified values
                           will be added to it.

                        o  DS_REMOVE_ATTRIBUTE, meaning that the specified
                           attribute is present and will be removed. Any values
                           present in the OM attribute DS_ATTRIBUTE_VALUES are
                           ignored.

                        o  DS_REMOVE_VALUES, meaning that the specified
                           attribute is present and that one or more specified
                           values will be removed from it.


ΓòÉΓòÉΓòÉ 11.22. DS_C_ENTRY_MOD_LIST ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_ENTRY_MOD_LIST contains a sequence of changes to
be made to a directory entry.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attribute listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 22. OM Attribute of DS_C_ENTRY_MOD_LIST                      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_CHANGES         Γöé Object(DS_C_ENTRY_MOD)   Γöé   -   Γöé  1 or  Γöé   -   Γöé
Γöé              Γöé               Γöé     Γöé  more  Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_CHANGES            This attribute identifies the modifications to be made
                       (in the order specified) to the directory entry of the
                       specified object.


ΓòÉΓòÉΓòÉ 11.23. DS_C_ERROR ΓòÉΓòÉΓòÉ

The OM class DS_C_ERROR contains the parameters common to all errors.

It is an abstract OM class with the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attribute listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 23. OM Attribute of DS_C_ERROR                          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_PROBLEM         Γöé Enum(DS_Problem)      Γöé   -   Γöé   1   Γöé   -   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

Details of errors are returned in an instance of a subclass of this OM class.
Each such subclass represents a particular kind of error and is one of the
following:

   o  DS_C_ABANDON_FAILED
   o  DS_C_ATTRIBUTE_PROBLEM
   o  DS_C_COMMUNICATIONS_ERROR
   o  DS_C_LIBRARY_ERROR
   o  DS_C_NAME_ERROR
   o  DS_C_SECURITY_ERROR
   o  DS_C_SERVICE_ERROR
   o  DS_C_SYSTEM_ERROR
   o  DS_C_UPDATE_ERROR

 A number of possible values are defined for these subclasses. DCE XDS does not
 return other values for error conditions described in this section.
 Information on system errors can be found in DS_C_SYSTEM_ERROR. The following
 is a list of the error values. Each error OM class section defines the
 possible error values associated with that class. For a description of the
 errors please refer to the DFS Client Guide and Reference.

   o  DS_E_ADMIN_LIMIT_EXCEEDED
   o  DS_E_AFFECTS_MULTIPLE_DSAS
   o  DS_E_ALIAS_DEREFERENCING_PROBLEM
   o  DS_E_ALIAS_PROBLEM
   o  DS_E_ATTRIBUTE_OR_VALUE_EXISTS
   o  DS_E_BAD_ARGUMENT
   o  DS_E_BAD_CLASS
   o  DS_E_BAD_CONTEXT
   o  DS_E_BAD_NAME
   o  DS_E_BAD_SESSION
   o  DS_E_BAD_WORKSPACE
   o  DS_E_BUSY
   o  DS_E_CANNOT_ABANDON
   o  DS_E_CHAINING_REQUIRED
   o  DS_E_COMMUNICATIONS_PROBLEM
   o  DS_E_CONSTRAINT_VIOLATION
   o  DS_E_DIT_ERROR
   o  DS_E_ENTRY_EXISTS
   o  DS_E_INAPPROP_AUTHENTICATION
   o  DS_E_INAPPROP_MATCHING
   o  DS_E_INSUFFICIENT_ACCESS_RIGHTS
   o  DS_E_INVALID_ATTRIBUTE_SYNTAX
   o  DS_E_INVALID_ATTRIBUTE_VALUE
   o  DS_E_INVALID_CREDENTIALS
   o  DS_E_INVALID_REF
   o  DS_E_INVALID_SIGNATURE
   o  DS_E_LOOP_DETECTED
   o  DS_E_MISCELLANEOUS
   o  DS_E_MISSING_TYPE
   o  DS_E_MIXED_SYNCHRONOUS
   o  DS_E_NAMING_VIOLATION
   o  DS_E_NO_INFO
   o  DS_E_NO_SUCH_ATTRIBUTE_OR_VALUE
   o  DS_E_NO_SUCH_OBJECT
   o  DS_E_NO_SUCH_OPERATION
   o  DS_E_NOT_ALLOWED_ON_NON_LEAF
   o  DS_E_NOT_ALLOWED_ON_RDN
   o  DS_E_NOT_SUPPORTED
   o  DS_E_OBJECT_CLASS_MOD_PROHIB
   o  DS_E_OBJECT_CLASS_VIOLATION
   o  DS_E_OUT_OF_SCOPE
   o  DS_E_PROTECTION_REQUIRED
   o  DS_E_TIME_LIMIT_EXCEEDED
   o  DS_E_TOO_LATE
   o  DS_E_TOO_MANY_OPERATIONS
   o  DS_E_TOO_MANY_SESSIONS
   o  DS_E_UNABLE_TO_PROCEED
   o  DS_E_UNAVAILABLE
   o  DS_E_UNAVAILABLE_CRIT_EXT
   o  DS_E_UNDEFINED_ATTRIBUTE_TYPE
   o  DS_E_UNWILLING_TO_PERFORM


ΓòÉΓòÉΓòÉ 11.24. DS_C_EXT ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_EXT indicates that a standardized extension to the
Directory Service is outlined in the standards. Such extensions will only be
standardized in post-1988 versions of the standards. Therefore, this OM class
is not used by the XDS API and is only included for X/Open conformance
purposes.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 24. OM Attribute of DS_C_EXT                           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE       Γöé VALUE SYNTAX       Γöé  VALUE Γöé  VALUE Γöé    VALUE   Γöé
Γöé              Γöé              Γöé LENGTH Γöé NUMBER Γöé   INITIALLY  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_CRIT          Γöé OM_S_BOOLEAN       Γöé   -  Γöé   1  Γöé   OM_FALSE   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_IDENT         Γöé OM_S_INTEGER       Γöé   -  Γöé   1  Γöé     -    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ITEM_PARAMETERS    Γöé Any            Γöé   -  Γöé   1  Γöé     -    Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_CRIT                           This attribute must have one of the
                                   following values:

                                     o  OM_FALSE, meaning that the originator
                                        permits the operation to be performed
                                        even if the extension is not available.

                                     o  OM_TRUE, meaning that the originator
                                        mandates that the extended operation be
                                        performed. If the extended operation is
                                        not performed, an error is reported.

 DS_IDENT                          This attribute identifies the service
                                   extension.

 DS_ITEM_PARAMETERS                This OM attribute supplies the parameters of
                                   the extension. Its syntax is determined by
                                   the value of DS_IDENT.


ΓòÉΓòÉΓòÉ 11.25. DS_C_FILTER ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_FILTER is used to select or reject an object on
the basis of information in its directory entry. At any point in time, an
attribute filter has a value relative to every object. The value is FALSE,
TRUE, or undefined. The object is selected if, and only if, the filter's value
is TRUE.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 25. OM Attributes of DS_C_FILTER                         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_FILTER_ITEMS      Γöé Object(DS_C_FILTER_ITEM)  Γöé   -   Γöé  0 or  Γöé   -   Γöé
Γöé              Γöé               Γöé     Γöé  more  Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_FILTERS         Γöé Object(DS_C_FILTER)     Γöé   -   Γöé  0 or  Γöé   -   Γöé
Γöé              Γöé               Γöé     Γöé  more  Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_FILTER_TYPE       Γöé Enum(DS_Filter_Type)    Γöé   -   Γöé   1   Γöé  DS_AND  Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

A filter is a collection of less elaborate filters and elementary
DS_FILTER_ITEMS, together with a Boolean operation. The filter value is
undefined if, and only if, all the component DS_FILTERS and DS_FILTER_ITEMS are
undefined. Otherwise, the filter has a Boolean value with respect to any
directory entry. This value can be determined by evaluating each of the nested
components and combining their values using the Boolean operation. The
components whose values are undefined are ignored.

 DS_FILTER_ITEMS              This attribute is a collection of assertions,
                              each relating to just one attribute of a
                              directory entry.

 DS_FILTERS                   This attribute is a collection of simpler
                              filters.

 DS_FILTER_TYPE               This attribute is the filter's type. It can have
                              any of the following values:

                                o  DS_AND, meaning that the filter is the
                                   logical conjunction of its components. The
                                   filter is TRUE unless any of the nested
                                   filters or filter items is FALSE. If there
                                   are no nested components, the filter is
                                   TRUE.

                                o  DS_OR, meaning that the filter is the
                                   logical disjunction of its components. The
                                   filter is FALSE unless any of the nested
                                   filters or filter items is TRUE. If there
                                   are no nested components, the filter is
                                   FALSE.

                                o  DS_NOT, meaning that the result of this
                                   filter is reversed. There must be exactly
                                   one nested filter or filter item. The filter
                                   is TRUE if the enclosed filter or filter
                                   item is FALSE, and is FALSE if the enclosed
                                   filter or filter item is TRUE.


ΓòÉΓòÉΓòÉ 11.26. DS_C_FILTER_ITEM ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_FILTER_ITEM is a component of DS_C_FILTER. It is
an assertion about the existence or values of a single attribute type in a
directory entry.

An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ATTRIBUTE, in addition to the OM attributes listed in the
following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 26. OM Attributes of DS_C_FILTER_ITEM                       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_FILTER_ITEM_TYPE    Γöé Enum(DS_Filter_Item_Type)  Γöé   -   Γöé   1   Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_FINAL_SUBSTRING     Γöé String(*)          Γöé  1 or  Γöé  0 or 1 Γöé   -   Γöé
Γöé              Γöé               Γöé  more  Γöé     Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_INITIAL_SUBSTRING    Γöé String(*)          Γöé  1 or  Γöé  0 or 1 Γöé   -   Γöé
Γöé              Γöé               Γöé  more  Γöé     Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

Note:  OM attributes DS_ATTRIBUTE_TYPE and DS_ATTRIBUTE_VALUES are inherited
       from the superclass DS_C_ATTRIBUTE.

 The value of the filter item is undefined in the following cases:

   o  The DS_ATTRIBUTE_TYPE is not known.

   o  None of the DS_ATTRIBUTE_VALUES conform to the attribute syntax defined
      for that attribute type.

   o  The DS_FILTER_ITEM_TYPE uses a matching rule that is not defined for the
      attribute syntax.

 Access control restrictions can also cause the value to be undefined.

 DS_FILTER_ITEM_TYPE            This attribute identifies the type of filter
                                item and, therefore, the nature of the filter.
                                The filter item can adopt any of the following
                                values:

                                  o  DS_APPROXIMATE_MATCH, meaning that the
                                     filter is TRUE if the directory entry
                                     contains at least one value of the
                                     specified type that is approximately equal
                                     to that specified (the meaning of
                                     approximately equal is implementation
                                     dependent); otherwise, the filter is
                                     FALSE.

                                     Rules for approximate matching are defined
                                     locally. For example, an approximate match
                                     may take into account spelling variations
                                     or employ phonetic comparison rules. In
                                     the absence of any such capabilities, a
                                     DSA needs to treat an approximate match as
                                     a test for equality. DCE GDS supports
                                     phonetic comparisons. There must be
                                     exactly one value of the OM attribute
                                     DS_ATTRIBUTE_VALUES.

                                  o  DS_EQUALITY, meaning that the filter is
                                     TRUE if the entry contains at least one
                                     value of the specified type that is equal
                                     to the value specified, according to the
                                     equality matching rule in force;
                                     otherwise, the filter is FALSE. There must
                                     be exactly one value of the OM attribute
                                     DS_ATTRIBUTE_VALUES.

                                  o  DS_GREATER_OR_EQUAL, meaning that the
                                     filter item is TRUE if, and only if, at
                                     least one value of the attribute is
                                     greater than or equal to the supplied
                                     value. There must be exactly one value of
                                     the OM attribute DS_ATTRIBUTE_VALUES.

                                  o  DS_LESS_OR_EQUAL, meaning that the filter
                                     item is TRUE if, and only if, at least one
                                     value of the attribute is less than or
                                     equal to the supplied value. There must be
                                     exactly one value of the OM attribute
                                     DS_ATTRIBUTE_VALUES.

                                  o  DS_PRESENT, meaning that the filter is
                                     TRUE if the entry contains an attribute of
                                     the specified type; otherwise, it is
                                     FALSE.

                                     Any values of the OM attribute
                                     DS_ATTRIBUTE_VALUES are ignored.

                                  o  DS_SUBSTRINGS, meaning that the filter is
                                     TRUE if the entry contains at least one
                                     value of the specified attribute type that
                                     contains all of the specified substrings
                                     in the given order; otherwise, the filter
                                     is FALSE.

                                     Any number of substrings can be given as
                                     values of the OM attribute
                                     DS_ATTRIBUTE_VALUES. Similarly, no
                                     substrings can be specified. There can
                                     also be a substring in
                                     DS_INITIAL_SUBSTRING or
                                     DS_FINAL_SUBSTRING, or both. The
                                     substrings do not overlap, but they can be
                                     separated from each other or from the ends
                                     of the attribute value by zero or more
                                     string elements. However, at least one
                                     attribute of type DS_ATTRIBUTE_VALUES,
                                     DS_INITIAL_SUBSTRING, or
                                     DS_FINAL_SUBSTRING must exist.

 DS_FINAL_SUBSTRING             If present, this attribute is the substring
                                that will match the final part of an attribute
                                value in the entry. This attribute can only
                                exist if the DS_FILTER_ITEM_TYPE is equal to
                                DS_SUBSTRINGS.

 DS_INITIAL_SUBSTRING           If present, this attribute is the substring
                                that will match the initial part of an
                                attribute value in the entry.


ΓòÉΓòÉΓòÉ 11.27. DS_C_LIBRARY_ERROR ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_LIBRARY_ERROR reports an error detected by the
interface function library.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ERROR, and no additional OM attributes.

Each function has several possible errors that can be detected by the library
itself and that are returned directly by the subroutine. These errors occur
when the library itself is incapable of performing an action, submitting a
service request, or deciphering a response from the Directory Service.

The OM attribute DS_PROBLEM, which is inherited from the superclass DS_C_ERROR,
identifies the particular library error that occurred. (In reference pages, the
ERRORS section of each function description lists the errors that the
respective function can return.) Its value is one of the following:

   o  DS_E_BAD_ARGUMENT
   o  DS_E_BAD_CLASS
   o  DS_E_BAD_CONTEXT
   o  DS_E_BAD_NAME
   o  DS_E_BAD_SESSION
   o  DS_E_MISCELLANEOUS
   o  DS_E_MISSING_TYPE
   o  DS_E_MIXED_SYNCHRONOUS
   o  DS_E_NOT_SUPPORTED
   o  DS_E_TOO_MANY_OPERATIONS
   o  DS_E_TOO_MANY_SESSIONS


ΓòÉΓòÉΓòÉ 11.28. DS_C_LIST_INFO ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_LIST_INFO is part of the results of ds_list.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_COMMON_RESULTS, in addition to the OM attributes listed in
the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 27. OM Attributes of DS_C_LIST_INFO                        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_OBJECT_NAME       Γöé Object(DS_C_NAME)      Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_PARTIAL         Γöé Object(DS_C_PARTIAL_    Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
Γöé _OUTCOME_QUAL       Γöé OUTCOME_QUAL)        Γöé     Γöé     Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_SUBORDINATES      Γöé Object(DS_C_LIST_INFO_ITEM)Γöé   -   Γöé  0 or  Γöé   -   Γöé
Γöé              Γöé               Γöé     Γöé  more  Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_OBJECT_NAME                           This attribute is the distinguished
                                          name of the target object of the
                                          operation. It is present if the OM
                                          attribute DS_ALIAS_DEREFERENCED,
                                          inherited from the superclass
                                          DS_C_COMMON_RESULTS is OM_TRUE.

 DS_PARTIAL_OUTCOME_QUAL                  This OM attribute value is present if
                                          the list of subordinates is
                                          incomplete. The DSA or DSAs that
                                          provided this list did not complete
                                          the search for some reason. The
                                          partial outcome qualifier contains
                                          details of why the search is not
                                          completed and which areas of the
                                          directory have not been searched.

 DS_SUBORDINATES                          This attribute contains information
                                          about zero or more subordinate
                                          objects identified by ds_list.


ΓòÉΓòÉΓòÉ 11.29. DS_C_LIST_INFO_ITEM ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_LIST_INFO_ITEM comprises details returned by
ds_list of a single subordinate object.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 28. OM Attributes of DS_C_LIST_INFO_ITEM                     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ALIAS_ENTRY       Γöé OM_S_BOOLEAN        Γöé   -   Γöé   1   Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_FROM_ENTRY       Γöé OM_S_BOOLEAN        Γöé   -   Γöé   1   Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_RDN           Γöé Object(DS_C_RELATIVE_NAME) Γöé   -   Γöé   1   Γöé   -   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_ALIAS_ENTRY              This attribute indicates whether the object is an
                             alias.

 DS_FROM_ENTRY               This attribute indicates whether information about
                             the object was obtained directly from its
                             directory entry, rather than from a copy of the
                             entry.

 DS_RDN                      This attribute contains the RDN of the object. If
                             this is the name of an alias entry, as indicated
                             by DS_ALIAS_ENTRY, it is not dereferenced.


ΓòÉΓòÉΓòÉ 11.30. DS_C_LIST_RESULT ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_LIST_RESULT comprises the results of a successful
call to ds_list.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 29. OM Attributes of DS_C_LIST_RESULT                       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_LIST_INFO        Γöé Object(DS_C_LIST_INFO)   Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_UNCORRELATED_LIST    Γöé Object(DS_C_LIST_RESULT)  Γöé   -   Γöé  0 or  Γöé   -   Γöé
Γöé _INFO           Γöé               Γöé     Γöé  more  Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

Note:  No instance contains values of both OM attributes.

 DS_LIST_INFO         This attribute contains the full results of ds_list or
                      just part of them.

 DS_UNCORRELATED_LIST_INFO When the DUA requests a protection request of
                      signed, the information returned can contain a number of
                      sets of results originating from, and signed by,
                      different components of the directory. Implementations
                      can reflect this structure by nesting DS_LIST_RESULT OM
                      objects as values of this OM attribute. Alternatively,
                      they can collapse all results into a single value of the
                      OM attribute DS_LIST_INFO. The DCE Directory Service does
                      not support the optional feature of signed results;
                      therefore, this OM attribute is never present.


ΓòÉΓòÉΓòÉ 11.31. DS_C_NAME ΓòÉΓòÉΓòÉ

The OM class DS_C_NAME represents a name of an object in the directory or a
part of such a name.

It is an abstract class, that has the attributes of its superclass,
OM_C_OBJECT, and no other OM attributes.

A name uniquely distinguishes the object from all other objects whose entries
are displayed in the DIT. However, an object can have more than one name (that
is, a name need not be unique). A DN is unique. There are no other DNs that
identify the same object. An RDN is part of a name and only distinguishes the
object from others that are its siblings.

Most of the interface functions take a name parameter, where the value must be
an instance of one of the subclasses of this OM class. Therefore, this OM class
is useful for amalgamating all possible representations of names.

The DCE XDS implementation defines one subclass of this OM class and a single
representation for names (that is, DS_C_DS_DN, which provides a representation
for names, including distinguished names).


ΓòÉΓòÉΓòÉ 11.32. DS_C_NAME_ERROR ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_NAME_ERROR reports a name-related Directory
Service error.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ERROR, in addition to the OM attributes listed in the
following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 30. OM Attributes of DS_C_NAME_ERROR                       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_MATCHED         Γöé Object(DS_C_NAME)      Γöé   -   Γöé   1   Γöé   -   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_MATCHED              This attribute identifies the initial part (up to, but
                         excluding, the first RDN that is unrecognized) of the
                         name that is supplied, or of the name resulting from
                         dereferencing an alias. It names the lowest entry
                         (object or alias) in the DIT that is matched.

 The OM attribute DS_PROBLEM, which is inherited from the superclass
 DS_C_ERROR, identifies the cause of the failure. Its value is one of the
 following:

   o  DS_E_ALIAS_DEREFERENCING_PROBLEM
   o  DS_E_ALIAS_PROBLEM
   o  DS_E_INVALID_ATTRIBUTE_VALUE
   o  DS_E_NO_SUCH_OBJECT


ΓòÉΓòÉΓòÉ 11.33. DS_C_OPERATION_PROGRESS ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_OPERATION_PROGRESS specifies the progress or
processing state of a directory request.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 31. OM Attributes of DS_C_OPERATION_PROGRESS                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_NAME_RESOLUTION     Γöé Enum(DS_Name_Resolution   Γöé   -   Γöé   1   Γöé   -   Γöé
Γöé _PHASE           Γöé _Phase)           Γöé     Γöé     Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_NEXT_RDN_TO_BE     Γöé OM_S_INTEGER        Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
Γöé _RESOLVED         Γöé               Γöé     Γöé     Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

The target name mentioned as follows is the name upon which processing of the
directory request is currently focused.

 DS_NAME_RESOLUTION_PHASE                  This attribute indicates what phase
                                           is reached in handling the target
                                           name. It must have one of the
                                           following values:

                                             o  DS_COMPLETED, meaning that the
                                                DSA holding the target object
                                                is reached.

                                             o  DS_NOT_STARTED, meaning that so
                                                far a DSA is not reached with a
                                                naming context containing the
                                                initial RDNs of the name.

                                             o  DS_PROCEEDING, meaning that the
                                                initial part of the name has
                                                been recognized, although the
                                                DSA holding the target object
                                                has not yet been reached.

 DS_NEXT_RDN_TO_BE_RESOLVED                This attribute indicates to the DSA
                                           which of the RDNs in the target name
                                           is next to be resolved. It takes the
                                           form of an integer in the range from
                                           one to the number of RDNs in the
                                           name. This OM attribute only has a
                                           value if the value of
                                           DS_NAME_RESOLUTION_PHASE is
                                           DS_PROCEEDING.

 The constant DS_OPERATION_NOT_STARTED can be used in the DS_C_CONTEXT of an
 operation instead of an instance of this OM class.


ΓòÉΓòÉΓòÉ 11.34. DS_C_PARTIAL_OUTCOME_QUAL ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_PARTIAL_OUTCOME_QUAL explains to what extent the
results of a call to ds_list or ds_search are incomplete and why.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 32. OM Attribute of DS_C_PARTIAL_OUTCOME_QUAL                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_LIMIT_PROBLEM      Γöé Enum(DS_Limit_Problem)   Γöé   -   Γöé   1   Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_UNAVAILABLE_CRIT_EXT  Γöé OM_S_BOOLEAN        Γöé   -   Γöé   1   Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_UNEXPLORED       Γöé Object(DS_C_CONTINUATION  Γöé   -   Γöé  0 or  Γöé   -   Γöé
Γöé              Γöé _REF)            Γöé     Γöé  more  Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_LIMIT_PROBLEM                         This attribute explains fully or
                                          partly why the results are
                                          incomplete. It can have one of the
                                          following values:

                                            o  DS_ADMIN_LIMIT_EXCEEDED, meaning
                                               that an administrative limit is
                                               reached.

                                            o  DS_NO_LIMIT_EXCEEDED, meaning
                                               there is no limit problem.

                                            o  DS_SIZE_LIMIT_EXCEEDED meaning
                                               the maximum number of objects
                                               specified as a service control
                                               is reached.

                                            o  DS_TIME_LIMIT_EXCEEDED, meaning
                                               the maximum number of seconds
                                               specified as a service control
                                               is reached.

 DS_UNAVAILABLE_CRIT_EXT                  If OM_TRUE, this attribute indicates
                                          that some part of the Directory
                                          Service cannot provide a requested
                                          critical service extension. The user
                                          requested one or more standard
                                          service extensions by including
                                          values of the OM attribute DS_EXT in
                                          the DS_C_CONTEXT supplied for the
                                          operation. Furthermore, the user
                                          indicated that some of these
                                          extensions are essential by setting
                                          the OM attribute DS_CRIT in the
                                          extension to OM_TRUE. Some of the
                                          critical extensions cannot be
                                          performed by one particular DSA or by
                                          a number of DSAs. In general, it is
                                          not possible to determine which DSA
                                          could not perform which particular
                                          extension.

 DS_UNEXPLORED                            This attribute identifies any regions
                                          of the directory that are left
                                          unexplored in such a way that the
                                          directory request can be continued.
                                          Only continuation references within
                                          the scope specified by the
                                          DS_SCOPE_OF_REFERRAL service control
                                          are included.


ΓòÉΓòÉΓòÉ 11.35. DS_C_PRESENTATION_ADDRESS ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_PRESENTATION_ADDRESS is a presentation address of
an OSI application entity, which is used for OSI communications with this
instance.

An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ADDRESS, in addition to the OM attributes listed in the
following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 33. OM Attributes of DS_C_PRESENTATION_ADDRESS                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_N_ADDRESSES       Γöé String(OM_S_OCTET_STRING)  Γöé   -   Γöé  1 or  Γöé   -   Γöé
Γöé              Γöé               Γöé     Γöé  more  Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_P_SELECTOR       Γöé String(OM_S_OCTET_STRING)  Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_S_SELECTOR       Γöé String(OM_S_OCTET_STRING)  Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_T_SELECTOR       Γöé String(OM_S_OCTET_STRING)  Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_N_ADDRESSES             This attribute is the network address of the
                            application entity.

 DS_P_SELECTOR              This attribute is the presentation selector.

 DS_S_SELECTOR              This attribute is the session selector.

 DS_T_SELECTOR              This attribute is the transport selector.


ΓòÉΓòÉΓòÉ 11.36. DS_C_READ_RESULT ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_READ_RESULT contains the result of a successful
call to  ds_read. An application is not permitted to create or modify instances
of this OM class. An instance of this OM class has the OM attributes of its
superclasses, OM_C_OBJECT and DS_C_COMMON_RESULTS, in addition to the OM
attribute listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 34. OM Attributes of DS_C_READ_RESULT                       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ENTRY          Γöé Object(DS_C_ENTRY_INFO)   Γöé   -   Γöé   1   Γöé   -   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_ENTRY                   This attribute contains the information extracted
                            from the directory entry of the target object.


ΓòÉΓòÉΓòÉ 11.37. DS_C_REFERRAL ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_REFERRAL reports failure to perform an operation
and redirects the requestor to one or more access points better equipped to
perform the operation.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_CONTINUATION_REF, and no additional OM attributes.

The referral is a continuation reference by means of which the operation can
progress.


ΓòÉΓòÉΓòÉ 11.38. DS_C_RELATIVE_NAME ΓòÉΓòÉΓòÉ

The OM class DS_C_RELATIVE_NAME represents the RDNs of objects in the
directory. It is an abstract class, which has the attributes of its superclass,
OM_C_OBJECT, and no other OM attributes.

An RDN is part of a name and only distinguishes the object from others that are
its siblings. This OM class is used to accumulate all possible representations
of RDNs. An argument of interface functions that is an RDN (or an OM attribute
value that is an RDN) is an instance of one of the subclasses of this OM class.

The DCE XDS API defines one subclass of this OM class  and, therefore, a single
representation for RDNs (that is, DS_C_DS_RDN, which provides a representation
for RDNs).


ΓòÉΓòÉΓòÉ 11.39. DS_C_SEARCH_INFO ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_SEARCH_INFO is part of the result of ds_search.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclasses,
OM_Object and DS_C_COMMON_RESULTS, in addition to the OM attributes listed in
the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 35. OM Attributes of DS_C_SEARCH_INFO                       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ENTRIES         Γöé Object(DS_C_ENTRY_INFO)   Γöé   -   Γöé  0 or  Γöé   -   Γöé
Γöé              Γöé               Γöé     Γöé  more  Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_OBJECT_NAME       Γöé Object(DS_C_NAME)      Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_PARTIAL_OUTCOME_QUAL  Γöé Object(DS_C_PARTIAL     Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
Γöé              Γöé _OUTCOME_QUAL)       Γöé     Γöé     Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_ENTRIES                                This attribute contains information
                                           about zero or more objects found by
                                           ds_search that matched the given
                                           selection criteria.

 DS_OBJECT_NAME                            This attribute contains the
                                           distinguished name of the target
                                           object of the operation. It is
                                           present if the OM attribute
                                           DS_ALIAS_DEREFERENCED, inherited
                                           from the superclass
                                           DS_C_COMMON_RESULTS, is OM_TRUE.

 DS_PARTIAL_OUTCOME_QUAL                   This OM attribute value is only
                                           present if the list of entries is
                                           incomplete. The DSA or DSAs that
                                           provided this list did not complete
                                           the search for some reason. The
                                           partial outcome qualifier contains
                                           details of why the search was not
                                           completed and which areas of the
                                           directory were not searched.


ΓòÉΓòÉΓòÉ 11.40. DS_C_SEARCH_RESULT ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_SEARCH_RESULT contains the result of a successful
call to ds_search.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 36. OM Attributes of DS_C_SEARCH_RESULT                      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE        Γöé VALUE SYNTAX        Γöé  VALUE  Γöé  VALUE  Γöé  VALUE  Γöé
Γöé              Γöé               Γöé  LENGTH Γöé  NUMBER Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_SEARCH_INFO       Γöé Object(DS_C_SEARCH_INFO)  Γöé   -   Γöé  0 or 1 Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_UNCORRELATED _SEARCH  Γöé Object(DS_C_SEARCH_RESULT) Γöé   -   Γöé  0 or  Γöé   -   Γöé
Γöé _INFO           Γöé               Γöé     Γöé  more  Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

Note:  No instance contains values of both OM attributes.

 DS_SEARCH_INFO                            This attribute contains the full
                                           result of ds_search or part of the
                                           result.

 DS_UNCORRELATED_SEARCH_INFO               When the DUA requests a protection
                                           request of signed, the information
                                           returned can contain a number of
                                           sets of results originating from and
                                           signed by different components of
                                           the Directory Service.
                                           Implementations can reflect this
                                           structure by nesting
                                           DS_C_SEARCH_RESULT OM objects as
                                           values of this OM attribute.
                                           Alternatively, they can collapse all
                                           results into a single value of the
                                           OM attribute DS_SEARCH_INFO. The DCE
                                           Directory Service does not support
                                           the optional feature of signed
                                           results; therefore, this OM
                                           attribute is never present.


ΓòÉΓòÉΓòÉ 11.41. DS_C_SECURITY_ERROR ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_SECURITY_ERROR reports a security-related
Directory Service error.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ERROR, and no additional OM attributes.

The OM attribute DS_PROBLEM, which is inherited from the superclass DS_C_ERROR,
identifies the cause of this failure. Its value is one of the following:

   o  DS_E_INAPPROP_AUTHENTICATION
   o  DS_E_INSUFFICIENT_ACCESS_RIGHTS
   o  DS_E_INVALID_CREDENTIALS
   o  DS_E_INVALID_SIGNATURE
   o  DS_E_NO_INFO
   o  DS_E_PROTECTION_REQUIRED


ΓòÉΓòÉΓòÉ 11.42. DS_C_SERVICE_ERROR ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_SERVICE_ERROR reports a Directory Service error
related to the provision of the service.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ERROR, and no additional OM attributes.

The OM attribute DS_PROBLEM, which is inherited from the superclass DS_C_ERROR,
identifies the cause of the failure. Its value is one of the following:

   o  DS_E_ADMIN_LIMIT_EXCEEDED
   o  DS_E_BUSY
   o  DS_E_CHAINING_REQUIRED
   o  DS_E_DIT_ERROR
   o  DS_E_INVALID_REF
   o  DS_E_LOOP_DETECTED
   o  DS_E_OUT_OF_SCOPE
   o  DS_E_TIME_LIMIT_EXCEEDED
   o  DS_E_UNABLE_TO_PROCEED
   o  DS_E_UNAVAILABLE
   o  DS_E_UNAVAILABLE_CRIT_EXT
   o  DS_E_UNWILLING_TO_PERFORM


ΓòÉΓòÉΓòÉ 11.43. DS_C_SESSION ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_SESSION identifies a particular link from the
application program to a DUA.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 37. OM Attributes of DS_C_SESSION                         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE       Γöé VALUE SYNTAX       Γöé  VALUE Γöé  VALUE Γöé    VALUE   Γöé
Γöé              Γöé              Γöé LENGTH Γöé NUMBER Γöé   INITIALLY  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_DSA_ADDRESS      Γöé Object(DS_C_ADDRESS)   Γöé   -  Γöé 0 or 1 Γöé   local(1)   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_DSA_NAME        Γöé Object(DS_C_NAME)     Γöé   -  Γöé 0 or 1 Γöé   local(2)   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_FILE          Γöé OM_S_INTEGER       Γöé   -  Γöé   1  Γöé  See the text  Γöé
Γöé _DESCRIPTOR        Γöé              Γöé     Γöé     Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_REQUESTER       Γöé Object(DS_C_NAME)     Γöé   -  Γöé 0 or 1 Γöé    NULL    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé (1) The default value of this OM attribute is set to the address and name of the    Γöé
Γöé   default DSA entry in the local cache.                        Γöé
Γöé (2) If this cache entry is not present, then these OM attributes are absent.      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

The DS_C_SESSION gathers all the information that describes a particular
directory interaction. The parameters that will control such a session are set
up in an instance of this OM class, which is then passed as an argument to
ds_bind. This sets the OM attributes that describe the actual characteristics
of this session and then starts the session. A session started in this way must
pass to each interface function as the first argument. The result of modifying
an initiated session is unspecified. Finally, ds_unbind is used to terminate
the session, after which the parameters can be modified and a new session
started using the same instance, if required. Multiple concurrent sessions can
run using multiple instances of this OM class.

The OM attributes of a session are as follows:

 DS_DSA_ADDRESS             This attribute indicates the address of the default
                            DSA named by DS_DSA_NAME.

 DS_DSA_NAME                This attribute indicates the distinguished name of
                            the DSA that is used by default to service
                            directory requests.

 DS_FILE_DESCRIPTOR (Optional Functionality) This OM attribute is not used by
                            DCE XDS and is always set to
                            DS_NO_VALID_FILE_DESCRIPTOR.

 DS_REQUESTOR               This attribute is the distinguished name of the
                            user of this Directory Service session.

 Applications can assume that an object of OM class DS_C_SESSION, created with
 default values of all its OM attributes, works with all the interface
 functions. Local administrators need to ensure that this is the case. Such a
 session can be created by passing the constant DS_DEFAULT_SESSION as an
 argument to ds_bind.


ΓòÉΓòÉΓòÉ 11.44. DS_C_SYSTEM_ERROR ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_SYSTEM_ERROR reports an error that occurred in the
underlying operating system.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ERROR, and no additional OM attributes, although there can
be additional implementation-defined OM attributes.

The OM attribute DS_PROBLEM, which is inherited from the superclass DS_C_ERROR,
identifies the cause of the failure. Its value is the same as that of errno
defined in the C language.

If such an error persists, a DS_C_LIBRARY_ERROR (DS_E_MISCELLANEOUS) is
reported.


ΓòÉΓòÉΓòÉ 11.45. DS_C_UPDATE_ERROR ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_UPDATE_ERROR reports a Directory Service error
peculiar to a modification operation.

An application is not permitted to create or modify instances of this OM class.
An instance of this OM class has the OM attributes of its superclasses,
OM_C_OBJECT and DS_C_ERROR, and no additional OM attributes.

The OM attribute DS_PROBLEM, which is inherited from the superclass DS_C_ERROR,
identifies the cause of the failure. Its value is one of the following:

   o  DS_E_AFFECTS_MULTIPLE_DSAS
   o  DS_E_ENTRY_EXISTS
   o  DS_E_NAMING_VIOLATION
   o  DS_E_NOT_ALLOWED_ON_NON_LEAF
   o  DS_E_NOT_ALLOWED_ON_RDN
   o  DS_E_OBJECT_CLASS_MOD_PROHIB
   o  DS_E_OBJECT_CLASS_VIOLATION


ΓòÉΓòÉΓòÉ 12. Basic Directory Contents Package ΓòÉΓòÉΓòÉ

The standards define a number of attribute types (known as the selected
attribute types), attribute syntaxes, attribute sets, and object classes (known
as the selected object classes). These definitions allow the creation and
maintenance of directory entries for a number of common objects so that the
representation of all such objects is the same throughout the directory. They
include such objects as Country, Person, and Organization.(**)

This section outlines names for each of these items, and defines OM classes to
represent those that are not represented directly by OM syntaxes. The values of
attributes in the directory are not restricted to those discussed in this
section, and new attribute types and syntaxes can be created at any time. (For
further information on how the values of other syntaxes are represented in the
interface, see Attribute and Attribute Value Assertion).

The constants and OM classes in this section are defined in addition to those
in XDS Class Definitions, because they are not essential to the working of the
interface but instead allow directory entries to be utilized. The definitions
belong to the Basic Directory Contents Package (BDCP), which is supported by
the DCE XDS API following negotiation of its use with ds_version.

The object identifier associated with the BDC Package is {iso(1)
identified-organization(3) icd-ecma(0012) member-company(2) dec(1011) xopen(28)
bdcp(1)} with the following encoding:

\x2B\xC\x2\x87\x73\x1C\x1

This identifier is represented by the constant DS_BASIC_DIR_CONTENTS_PKG. The C
constants associated with this package are in the xdsbdcp.h header file (see
the DCE for OS/2 Warp: Application Development Reference).

The concepts and notation used are introduced in Introduction to OM Classes. A
complete explanation of the meaning of the attributes and object classes is not
given since this is beyond the scope of this guide. The purpose here is simply
to present the representation of these items in the interface.

The selected attribute types are presented first, followed by the selected
object classes. Next, the OM class hierarchy and OM class definitions required
to support the selected attribute types are presented.

Note:  This package should only be needed if a cell name is defined using the
       X.500 format (for example, C=us/O=ibm/OU=austin). As in XDS Class
       Definitions, all definitions for this package are provided for
       completeness; however, only those OM objects required for an X.500 cell
       name definition should be needed for XDS/XOM over CDS.


ΓòÉΓòÉΓòÉ 12.1. Selected Attribute Types ΓòÉΓòÉΓòÉ

This section presents the attribute types defined in the standards that are to
be used in directory entries. Each directory entry is composed of a number of
attributes, each of which comprises an attribute type together with one or more
attribute values. The form of each value of an attribute is determined by the
attribute syntax associated with the attribute's type.

In the interface, attributes are displayed as instances of OM class
DS_C_ATTRIBUTE with the attribute type represented as the value of the OM
attribute DS_ATTRIBUTE_TYPE, and the attribute value (or values) represented as
the value (or values) of the OM attribute DS_ATTRIBUTE_VALUES. Each attribute
type has an object identifier, assigned in the standards, which is the value of
the OM attribute DS_ATTRIBUTE_TYPE These object identifiers are represented in
the interface by constants with the same name as the directory attribute, and
are prefixed with DS_A_ so that they can be easily identified.

"Object Identifiers for Selected Attribute Types" shows the names of the
attribute types defined in the standards, together with the Basic Encoding
Rules (BERs) for encoding of the object identifiers associated with each of
them. "Representation of Values for Selected Attribute Types" shows the names
of the attribute types, together with the OM value syntax that is used in the
interface to represent values of that attribute type. "Representation of Values
for Selected Attribute Types" also includes the range of lengths permitted for
the string types. This indicates whether the attribute can be multivalued and
which matching rules are provided for the syntax. Following the table is a
brief description of each attribute.

The standards define matching rules that are used for deciding whether two
values are equal (E), for ordering (O) two values, and for identifying one
value as a substring (S) of another in Directory Service operations. Specific
matching rules are given in this section for certain attributes. In addition,
the following general rules apply as indicated:

   o  All attribute values whose syntax is String(OM_S_NUMERIC_STRING),
      String(OM_S_PRINTABLE_STRING), or String(OM_S_TELETEX_STRING) are
      considered insignificant for the following reasons:

        -  Differences caused by the presence of spaces preceding the first
           printing character;
        -  Spaces following the last printing character; and
        -  More than one consecutive space anywhere within the value.

   o  For all attribute values whose syntax is String(OM_S_TELETEX_STRING),
      differences in the case of alphabetical characters are considered
      insignificant.

 Note:  The third and fourth columns of the following table contain the
        contents octets of the BER encoding of the object identifier. All these
        object identifiers stem from the root {joint-iso-ccitt(2) ds(5)
        attributeType(4)}.

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  Γöé Table 38. Object Identifiers for Selected Attribute Types                Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé      Γöé                    Γöé  OBJECT ID Γöé    OBJECT ID BER   Γöé
  Γöé  PACKAGE  Γöé ATTRIBUTE TYPE            Γöé   BER   Γöé    (HEXADECIMAL)   Γöé
  Γöé      Γöé                    Γöé  (DECIMAL) Γöé             Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_ALIASED_OBJECT_NAME       Γöé  85, 4, 1  Γöé    \x55\x04\x01    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_BUSINESS_CATEGORY        Γöé  85, 4, 15 Γöé    \x55\x04\x0F    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_COMMON_NAME           Γöé  85, 4, 3  Γöé    \x55\x04\x03    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_COUNTRY_NAME           Γöé  85, 4, 6  Γöé    \x55\x04\x06    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_DESCRIPTION           Γöé  85, 4, 13 Γöé    \x55\x04\x0D    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_DEST_INDICATOR          Γöé  85, 4, 27 Γöé    \x55\x04\x1B    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_FACSIMILE_PHONE_NBR       Γöé  85, 4, 23 Γöé    \x55\x04\x17    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_INTERNAT_ISDN_NBR        Γöé  85, 4, 25 Γöé    \x55\x04\x19    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_KNOWLEDGE_INFO          Γöé  85, 4, 2  Γöé    \x55\x04\x02    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_LOCALITY_NAME          Γöé  85, 4, 7  Γöé    \x55\x04\x07    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_MEMBER              Γöé  85, 4, 31 Γöé    \x55\x04\x1F    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_OBJECT_CLASS           Γöé  85, 4, 0  Γöé    \x55\x04\x00    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_ORG_NAME             Γöé  85, 4, 10 Γöé    \x55\x04\x0A    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_ORG_UNIT_NAME          Γöé  85, 4, 11 Γöé    \x55\x04\x0B    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_OWNER              Γöé  85, 4, 32 Γöé    \x55\x04\x20    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_PHYS_DELIV_OFF_NAME       Γöé  85, 4, 19 Γöé    \x55\x04\x13    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_POST_OFFICE_BOX         Γöé  85, 4, 18 Γöé    \x55\x04\x12    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_POSTAL_ADDRESS          Γöé  85, 4, 16 Γöé    \x55\x04\x10    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_POSTAL_CODE           Γöé  85, 4, 17 Γöé    \x55\x04\x11    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_PREF_DELIV_METHOD        Γöé  85, 4, 28 Γöé    \x55\x04\x1C    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_PRESENTATION_ADDRESS       Γöé  85, 4, 29 Γöé    \x55\x04\x1D    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_REGISTERED_ADDRESS        Γöé  85, 4, 26 Γöé    \x55\x04\x1A    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_ROLE_OCCUPANT          Γöé  85, 4, 33 Γöé    \x55\x04\x21    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_SEARCH_GUIDE           Γöé  85, 4, 14 Γöé    \x55\x04\x0E    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_SEE_ALSO             Γöé  85, 4, 34 Γöé    \x55\x04\x22    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_SERIAL_NBR            Γöé  85, 4, 5  Γöé    \x55\x04\x05    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_STATE_OR_PROV_NAME        Γöé  85, 4, 8  Γöé    \x55\x04\x08    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_STREET_ADDRESS          Γöé  85, 4, 9  Γöé    \x55\x04\x09    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_SUPPORT_APPLIC_CONTEXT      Γöé  85, 4, 3  Γöé    \x55\x04\x1E    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_SURNAME             Γöé  85, 4, 4  Γöé    \x55\x04\x04    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_PHONE_NBR            Γöé  85, 4, 20 Γöé    \x55\x04\x14    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_TELETEX_TERM_IDENT        Γöé  85, 4, 22 Γöé    \x55\x04\x16    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_TELEX_NBR            Γöé  85, 4, 21 Γöé    \x55\x04\x15    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_TITLE              Γöé  85, 4, 12 Γöé    \x55\x04\x0C    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_USER_PASSWORD          Γöé  85, 4, 35 Γöé    \x55\x04\x23    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_A_X121_ADDRESS           Γöé  85, 4, 24 Γöé    \x55\x04\x18    Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  Γöé Table 39. Representation of Values for Selected Attribute Types                Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé ATTRIBUTE TYPE        Γöé OM VALUE SYNTAX       Γöé  VALUE  Γöé  MULTI  Γöé  MATCHING  Γöé
  Γöé                Γöé               Γöé  LENGTH  Γöé  VALUED  Γöé   RULES   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_ALIASED_OBJECT_NAME   Γöé Object(DS_C_NAME)      Γöé   -   Γöé   No   Γöé    E    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_BUSINESS_CATEGORY    Γöé String(OM_S_TELETEX_STRING)Γöé  1-128  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_COMMON_NAME       Γöé String(OM_S_TELETEX_STRING)Γöé  1-64  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_COUNTRY_NAME       Γöé String(OM_S_        Γöé   2   Γöé   No   Γöé    E    Γöé
  Γöé                Γöé PRINTABLE_STRING)(1)    Γöé      Γöé      Γöé       Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_DESCRIPTION       Γöé String(OM_S_TELETEX_STRING)Γöé  1-1024  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_DEST_INDICATOR      Γöé String(OM_S_        Γöé  1-128  Γöé   Yes  Γöé   E, S   Γöé
  Γöé                Γöé PRINTABLE_STRING)(2)    Γöé      Γöé      Γöé       Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_FACSIMILE_PHONE_NBR   Γöé Object(DS_C_FACSIMILE_PHONEΓöéNBR) -   Γöé   Yes  Γöé    -    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_INTERNAT_ISDN_NBR    Γöé String(OM_S_NUMERIC_STRING)Γöé3) 1-16  Γöé   Yes  Γöé    -    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_KNOWLEDGE_INFO      Γöé String(OM_S_TELETEX_STRING)Γöé   -   Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_LOCALITY_NAME      Γöé String(OM_S_TELETEX_STRING)Γöé  1-128  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_MEMBER          Γöé Object(DS_C_NAME)      Γöé   -   Γöé   Yes  Γöé    E    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_OBJECT_CLASS       Γöé String(OM_S_OBJECT_IDENTIFIΓöéR_STR-NG) Γöé   Yes  Γöé    E    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_ORG_NAME         Γöé String(OM_S_TELETEX_STRING)Γöé  1-64  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_ORG_UNIT_NAME      Γöé String(OM_S_TELETEX_STRING)Γöé  1-64  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_OWNER          Γöé Object(DS_C_NAME)      Γöé   -   Γöé   Yes  Γöé    E    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_PHYS_DELIV_OFF_NAME   Γöé String(OM_S_TELETEX_STRING)Γöé  1-128  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_POST_OFFICE_BOX     Γöé String(OM_S_TELETEX_STRING)Γöé  1-40  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_POSTAL_ADDRESS      Γöé Object(DS_C_POSTAL_ADDRESS)Γöé   -   Γöé   Yes  Γöé    E    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_POSTAL_CODE       Γöé String(OM_S_TELETEX_STRING)Γöé  1-40  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_PREF_DELIV_METHOD    Γöé Enum(DS_PREFERRED      Γöé   -   Γöé   Yes  Γöé    -    Γöé
  Γöé                Γöé DELIVERY_METHOD)      Γöé      Γöé      Γöé       Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_PRESENTATION_ADDRESS   Γöé Object(DS_C_PRESENTATION_ADΓöéRESS)-   Γöé   No   Γöé    E    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_REGISTERED-ADDRESS    Γöé Object(DS_C_POSTAL_ADDRESS)Γöé   -   Γöé   Yes  Γöé    -    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_ROLE_OCCUPANT      Γöé Object(DS_C_NAME)      Γöé   -   Γöé   Yes  Γöé    E    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_SEARCH_GUIDE       Γöé Object(DS_C_SEARCH_GUIDE)  Γöé   -   Γöé   Yes  Γöé    -    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_SEE_ALSO         Γöé Object(DS_C_NAME)      Γöé   -   Γöé   Yes  Γöé    E    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_SERIAL_NBR        Γöé String(OM_S_PRINTABLE_STRINΓöé)  1-64  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_STATE_OR_PROV_NAME    Γöé String(OM_S_TELETEX_STRING)Γöé  1-128  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_STREET_ADDRESS      Γöé String(OM_S_TELETEX_STRING)Γöé  1-128  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_SUPPORT_APPLIC_CONTEXT  Γöé String(OM_S_OBJECT_IDENTIFIΓöéR_STR-NG) Γöé   Yes  Γöé    E    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_SURNAME         Γöé String(OM_S_TELETEX_STRING)Γöé  1-64  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_PHONE_NBR        Γöé String(OM_S_PRINTABLE_STRINΓöé)(41-32  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_TELETEX_TERM_IDENT    Γöé Object(DS_C_TELETEX_TERM_IDΓöéNT)  -   Γöé   Yes  Γöé    -    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_TELEX_NBR        Γöé Object(DS_C_TELEX_NBR)   Γöé   -   Γöé   Yes  Γöé    -    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_TITLE          Γöé String(OM_S_TELETEX_STRING)Γöé  1-64  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_USER_PASSWORD      Γöé String(OM_S_OCTET_STRING)  Γöé  0-128  Γöé   Yes  Γöé    -    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DS_A_X121_ADDRESS       Γöé String(OM_S_NUMERIC_STRING)Γöé5) 1-15  Γöé   Yes  Γöé   E, S   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé (1) As permitted by ISO 3166.                                 Γöé
  Γöé (2) As permitted by Recommendations F.1 and F.31.                       Γöé
  Γöé (3) As permitted by E164.                                   Γöé
  Γöé (4) As permitted by E123 (for example, [phone]).                     Γöé
  Γöé (5) As permitted by X.121.                                   Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 Throughout the descriptions that follow, the term object indicates the
 directory object whose directory entry contains the corresponding directory
 attributes.

 DS_A_ALIASED_OBJECT_NAME            This attribute occurs only in alias
                                     entries. It assigns the Distinguished Name
                                     (DN) of the object provided with an alias
                                     using the entry in which this attribute
                                     occurs. An alias is an alternative to an
                                     object's DN. Any object can (but need not)
                                     have one or more aliases. The Directory
                                     Service is said to dereference an alias
                                     whenever it replaces the alias during name
                                     processing with the distinguished name
                                     associated with it by means of this
                                     attribute.

 DS_A_BUSINESS_CATEGORY              This attribute provides descriptions of
                                     the businesses in which the object is
                                     engaged.

 DS_A_COMMON_NAME                    This attribute provides the names by which
                                     the object is commonly known in the
                                     context defined by its position in the
                                     DIT. The names can conform to the naming
                                     convention of the country or culture with
                                     which the object is associated. They can
                                     be ambiguous.

 DS_A_COUNTRY_NAME                   This attribute identifies the country in
                                     which the object is located or with which
                                     it is associated in some other important
                                     way. The matching rules require that
                                     differences in the case of alphabetical
                                     characters be considered insignificant. It
                                     has a length of two characters and its
                                     values are those listed in ISO 3166.

 DS_A_DESCRIPTION                    This attribute gives informative
                                     descriptions of the object.

 DS_A_DEST_INDICATOR                 This attribute provides the country-city
                                     pairs by means of which the object can be
                                     reached by way of the public telegram
                                     service. The matching rules require that
                                     differences in the case of alphabetical
                                     characters be considered insignificant.

 DS_A_FACSIMILE_PHONE_NBR            This attribute provides the telephone
                                     numbers for facsimile terminals (and their
                                     parameters, if required) by means of which
                                     the object can be reached or with which it
                                     is associated in some other important way.

 DS_A_INTERNAT_ISDN_NBR              This attribute provides the international
                                     ISDN numbers by means of which the object
                                     can be reached or with which it is
                                     associated in some other important way.
                                     The matching rules require that
                                     differences caused by the presence of
                                     spaces be considered insignificant.

 DS_A_KNOWLEDGE_INFO                 This attribute occurs only in entries that
                                     describe a DSA. It provides a
                                     human-intelligible accumulated description
                                     of the directory knowledge possessed by
                                     the DSA.

 DS_A_LOCALITY_NAME                  This attribute identifies geographical
                                     areas or localities. When used as part of
                                     a directory name, it specifies the
                                     localities in which the object is located
                                     or with which it is associated in some
                                     other important way.

 DS_A_MEMBER                         This attribute gives the names of objects
                                     that are considered members of the present
                                     object; for example, a distribution list
                                     for electronic mail.

 DS_A_OBJECT_CLASS                   This attribute identifies the object
                                     classes to which the object belongs, and
                                     also identifies their superclasses. All
                                     such object classes that have object
                                     identifiers assigned to them are present,
                                     except that object class DS_O_TOP need not
                                     (but can) be present provided that some
                                     other value is present. This attribute
                                     must be present in every entry and cannot
                                     be modified. For a further discussion, see
                                     OM Class Hierarchy.

 DS_A_ORG_NAME                       This attribute identifies organizations.
                                     When used as part of a directory name, it
                                     specifies an organization with which the
                                     object is affiliated. Several values can
                                     identify the same organization in
                                     different ways.

 DS_A_ORG_UNIT_NAME                  This attribute identifies organizational
                                     units. When used as part of a directory
                                     name, it specifies an organizational unit
                                     with which the object is affiliated. The
                                     units are understood to be parts of the
                                     organization that the DS_A_ORG_NAME
                                     attribute indicates. Several values can
                                     identify the same unit in different ways.

 DS_A_OWNER                          This attribute gives the names of objects
                                     that have responsibility for the object.

 DS_A_PHYS_DELIV_OFF_NAME            This attribute gives the names of cities,
                                     towns, villages, and so on, that contain
                                     physical delivery offices through which
                                     the object can take delivery of physical
                                     mail.

 DS_A_POST_OFFICE_BOX                This attribute identifies post office
                                     boxes at which the object can take
                                     delivery of physical mail. This
                                     information is also displayed as part of
                                     the DS_A_POSTAL_ADDRESS attribute, if it
                                     is present.

 DS_A_POSTAL_ADDRESS                 This attribute gives the postal addresses
                                     at which the object can take delivery of
                                     physical mail. The matching rules require
                                     that differences in the case of
                                     alphabetical characters be considered
                                     insignificant.

 DS_A_POSTAL_CODE                    This attribute gives the postal codes that
                                     are assigned to areas or buildings through
                                     which the object can take delivery of
                                     physical mail. This information is also
                                     displayed as part of the
                                     DS_A_POSTAL_ADDRESS attribute, if it is
                                     present.

 DS_A_PREF_DELIV_METHOD              This attribute gives the object's
                                     preferred methods of communication, in the
                                     order of preference. The values are as
                                     follows:

                                          DS_ANY_DELIV_METHOD             The
                                                                          object
                                                                          has
                                                                          no
                                                                          preference.

                                          DS_G3_FACSIMILE_DELIV           By
                                                                          way
                                                                          of
                                                                          the
                                                                          Group
                                                                          3
                                                                          facsimile.

                                          DS_G4_FACSIMILE_DELIV           By
                                                                          way
                                                                          of
                                                                          the
                                                                          Group
                                                                          4
                                                                          facsimile.

                                          DS_IA5_TERMINAL_DELIV           By
                                                                          way
                                                                          of
                                                                          the
                                                                          IA5
                                                                          text.

                                          DS_MHS_DELIV                    By
                                                                          way
                                                                          of
                                                                          X.400.

                                          DS_PHYS_DELIV                   By
                                                                          way
                                                                          of
                                                                          the
                                                                          postal
                                                                          or
                                                                          other
                                                                          physical
                                                                          delivery
                                                                          system.

                                          DS_PHONE_DELIV                  By
                                                                          way
                                                                          of
                                                                          telephone.

                                          DS_TELETEX_DELIV                By
                                                                          way
                                                                          of
                                                                          teletex.

                                          DS_TELEX_DELIV                  By
                                                                          way
                                                                          of
                                                                          telex.

                                          DS_VIDEOTEX_DELIV               By
                                                                          way
                                                                          of
                                                                          videotex.

 DS_A_PRESENTATION_ADDRESS           This attribute contains the OSI
                                     presentation address of the object, which
                                     is an OSI application entity. The matching
                                     rule for a presented value to match a
                                     value stored in the directory is that the
                                     P-Selector, S-Selector, and T-Selector of
                                     the two presentation addresses must be
                                     equal, and the addresses of the presented
                                     value must be a subset of those of the
                                     stored value.

 DS_A_REGISTERED_ADDRESS             This attribute contains mnemonics by means
                                     of which the object can be reached by way
                                     of the public telegram service, according
                                     to Recommendation F.1. A mnemonic
                                     identifies an object in the context of a
                                     particular city, and is registered in the
                                     country containing the city. The matching
                                     rules require that differences in the case
                                     of alphabetical characters be considered
                                     insignificant.

 DS_A_ROLE_OCCUPANT                  This attribute occurs only in entries that
                                     describe an organizational role. It gives
                                     the names of objects that fulfill the
                                     organizational role.

 DS_A_SEARCH_GUIDE                   This attribute contains the criteria that
                                     can be used to build filters for
                                     conducting searches in which the object is
                                     the base object.

 DS_A_SEE_ALSO                       This attribute contains the names of
                                     objects that represent other aspects of
                                     the real world object that the present
                                     object represents.

 DS_A_SERIAL_NBR                     This attribute contains the serial numbers
                                     of a device.

 DS_A_STATE_OR_PROV_NAME             This attribute specifies a state or
                                     province. When used as part of a directory
                                     name, it identifies states, provinces, or
                                     other geographical regions in which the
                                     object is located or with which it is
                                     associated in some other important way.

 DS_A_STREET_ADDRESS                 This attribute identifies a site for the
                                     local distribution and physical delivery
                                     of mail. When used as part of a directory
                                     name, it identifies the street address
                                     (for example, street name and house
                                     number) at which the object is located or
                                     with which it is associated in some other
                                     important way.

 DS_A_SUPPORT_APPLIC_CONTEXT         This attribute occurs only in entries that
                                     describe an OSI application entity. It
                                     identifies OSI application contexts
                                     supported by the object.

 DS_A_SURNAME                        This attribute occurs only in entries that
                                     describe individuals. The surname by which
                                     the individual is commonly known, normally
                                     inherited from the individual's parent (or
                                     parents) or taken at marriage, as
                                     determined by the custom of the country or
                                     culture with which the individual is
                                     associated.

 DS_A_PHONE_NBR                      This attribute identifies telephones by
                                     means of which the object can be reached
                                     or with which it is associated in some
                                     other important way. The matching rules
                                     require that differences caused by the
                                     presence of spaces and dashes be
                                     considered insignificant.

 DS_A_TELETEX_TERM_IDENT             This attribute contains descriptions of
                                     teletex terminals by means of which the
                                     object can be reached or with which it is
                                     associated in some other important way.

 DS_A_TELEX_NBR                      This attribute contains descriptions of
                                     telex terminals by means of which the
                                     object can be reached or with which it is
                                     associated in some other important way.

 DS_A_TITLE                          This attribute identifies positions or
                                     functions of the object within its
                                     organization.

 DS_A_USER_PASSWORD                  This attribute contains the passwords
                                     assigned to the object.

 DS_A_X121_ADDRESS                   This attribute identifies points on the
                                     public data network at which the object
                                     can be reached or with which it is
                                     associated in some other important way.
                                     The matching rules require that
                                     differences caused by the presence of
                                     spaces be considered insignificant.


ΓòÉΓòÉΓòÉ 12.2. Selected Object Classes ΓòÉΓòÉΓòÉ

This section presents the object classes that are defined in the standards.
Object classes are groups of directory entries that share certain
characteristics. The object classes are arranged into a lattice, based on the
object class DS_O_TOP. In a lattice, each element, except a leaf, has one or
more immediate subordinates but also has one or more immediate superiors. This
contrasts with a tree, where each element has exactly one immediate superior.
Object classes closer to DS_O_TOP are called superclasses, and those further
away are called subclasses. This relationship is not connected to any other
such relationship in this guide.

Each directory entry belongs to an object class, and to all the superclasses of
that object class. Each entry has an attribute named DS_A_OBJECT_CLASS, which
was discussed in the previous section, and which identifies the object classes
to which the entry belongs. The values of this attribute are object
identifiers, which are represented in the interface by constants with the same
name as the object class, prefixed by DS_O_.

Associated with each object class are zero or more mandatory and zero or more
optional attributes. Each directory entry must contain all the mandatory
attributes and can (but need not) contain the optional attributes associated
with the object class and its superclasses.

The object classes defined in the standards are shown in the following table,
together with their object identifiers.

Note:  The third and fourth columns of the following table contain the contents
       octets of the BER encoding of the object identifier. All these object
       identifiers stem from the root {joint-iso-ccitt(2) ds(5)
       objectClass(6)}.

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  Γöé Table 40. Object Identifiers for Selected Object Classes                Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé      Γöé                    Γöé  OBJECT ID Γöé    OBJECT ID BER   Γöé
  Γöé  PACKAGE  Γöé ATTRIBUTE TYPE            Γöé   BER   Γöé    HEXADECIMAL    Γöé
  Γöé      Γöé                    Γöé  DECIMAL  Γöé             Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_ALIAS              Γöé  85, 6, 1  Γöé    \x55\x06\x01    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_APPLIC_ENTITY          Γöé  85, 6, 12 Γöé    \x55\x06\x0C    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_APPLIC_PROCESS          Γöé  85, 6, 11 Γöé    \x55\x06\x0B    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_COUNTRY             Γöé  85, 6, 2  Γöé    \x55\x06\x02    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_DEVICE              Γöé  85, 6, 14 Γöé    \x55\x06\x0E    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_DSA               Γöé  85, 6, 13 Γöé    \x55\x06\x0D    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_GROUP_OF_NAMES          Γöé  85, 6, 9  Γöé    \x55\x06\x09    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_LOCALITY             Γöé  85, 6, 3  Γöé    \x55\x06\x03    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_ORG               Γöé  85, 6, 4  Γöé    \x55\x06\x04    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_ORG_PERSON            Γöé  85, 6, 7  Γöé    \x55\x06\x07    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_ORG_ROLE             Γöé  85, 6, 8  Γöé    \x55\x06\x08    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_ORG_UNIT             Γöé  85, 6, 5  Γöé    \x55\x06\x05    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_PERSON              Γöé  85, 6, 6  Γöé    \x55\x06\x06    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_RESIDENTIAL_PERSON        Γöé  85, 6, 10 Γöé    \x55\x06\x0A    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé   BDCP  Γöé DS_O_TOP               Γöé  85, 6, 0  Γöé    \x55\x06\x00    Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ


ΓòÉΓòÉΓòÉ 12.3. OM Class Hierarchy ΓòÉΓòÉΓòÉ

The remainder of this section defines the additional OM classes used to
represent values of the selected attributes described in Selected Attribute
Types. Some of the selected attributes are represented by OM classes that are
used in the interface itself, and hence are defined in XDS Class Definitions
(for example, DS_C_NAME). As mentioned in the introductory text to this
section, an explanation of the purpose of these attributes is beyond the scope
of this guide.

This section shows the hierarchical organization of the OM classes that are
defined in the following sections, and it shows which OM classes inherit
additional OM attributes from their OM superclasses. In the following list,
subclassification is indicated by indentation, and the names of abstract OM
classes are in italics. For example, DS_C_POSTAL_ADDRESS is an immediate
subclass of the abstract OM class OM_C_OBJECT.

OM_C_OBJECT

      DS_C_FACSIMILE_PHONE_NBR
      DS_C_POSTAL_ADDRESS
      DS_C_SEARCH_CRITERION
      DS_C_SEARCH_GUIDE
      DS_C_TELETEX_TERM_IDENT
      DS_C_TELEX_NBR

 None of the OM classes in the preceding list are encodable using om_encode and
 om_decode.


ΓòÉΓòÉΓòÉ 12.4. DS_C_FACSIMILE_PHONE_NBR ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_FACSIMILE_PHONE_NBR identifies and describes a
facsimile terminal, if required.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 41. OM Attributes of DS_C_FACSIMILE_PHONE_NBR                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE      Γöé VALUE SYNTAX       Γöé   VALUE  Γöé   VALUE  Γöé  VALUE  Γöé
Γöé             Γöé             Γöé  LENGTH  Γöé  NUMBER  Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_PARAMETERS      Γöé Object(MH_C_G3_FAX    Γöé    -   Γöé  0 or 1  Γöé   -   Γöé
Γöé             Γöé _NBPS)(1)        Γöé       Γöé       Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_PHONE_NBR      Γöé String(OM_S_PRINTABLE  Γöé   1-32   Γöé    1   Γöé   -   Γöé
Γöé             Γöé _STRING)(2)       Γöé       Γöé       Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé (1) As defined in the X.400 API Specifications.                     Γöé
Γöé (2) As permitted by E.123 (for example, [phone]).                 Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_PARAMETERS            If present, this attribute identifies the facsimile
                          terminal's advanced capabilities.

 DS_PHONE_NBR             This attribute contains a telephone number by means
                          of which the facsimile terminal is accessed.


ΓòÉΓòÉΓòÉ 12.5. DS_C_POSTAL_ADDRESS ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_POSTAL_ADDRESS is a postal address.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attribute listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 42. OM Attribute of DS_C_POSTAL_ADDRESS                      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE      Γöé VALUE SYNTAX       Γöé   VALUE  Γöé   VALUE  Γöé  VALUE  Γöé
Γöé             Γöé             Γöé  LENGTH  Γöé  NUMBER  Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_POSTAL_ADDRESS    Γöé String(OM_S_TELETEX   Γöé   1-30   Γöé   1-6   Γöé   -   Γöé
Γöé             Γöé _STRING)         Γöé       Γöé       Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_POSTAL_ADDRESS          Each value of this OM attribute is one line of the
                            postal address. It typically includes a name,
                            street address, city name, state or province name,
                            postal code, and possibly a country name.


ΓòÉΓòÉΓòÉ 12.6. DS_C_SEARCH_CRITERION ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_SEARCH_CRITERION is a component of a
DS_C_SEARCH_GUIDE OM object.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 43. OM Attributes of DS_C_SEARCH_CRITERION                    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE      Γöé VALUE SYNTAX       Γöé   VALUE  Γöé   VALUE  Γöé  VALUE  Γöé
Γöé             Γöé             Γöé  LENGTH  Γöé  NUMBER  Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ATTRIBUTE_TYPE    Γöé String(OM_S_OBJECT    Γöé    -   Γöé  0 or 1  Γöé   -   Γöé
Γöé             Γöé _IDENTIFIER_STRING)   Γöé       Γöé       Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_CRITERIA       Γöé Object(DS_C_SEARCH    Γöé    -   Γöé  0 or more Γöé   -   Γöé
Γöé             Γöé _CRITERION)       Γöé       Γöé       Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_FILTER_ITEM_TYPE   Γöé Enum(DS_Filter_Item_TypeΓöé    -   Γöé  0 or 1  Γöé   -   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_FILTER_TYPE     Γöé Enum(DS_Filter_Type)   Γöé    -   Γöé    1   Γöé  DS_ITEM  Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

A DS_C_SEARCH_CRITERION suggests how to build part of a filter to be used when
searching the directory. Its meaning depends on the value of its OM attribute
DS_FILTER_TYPE. If the value is DS_ITEM, then the criterion suggests building
an instance of OM class DS_C_FILTER_ITEM. If DS_FILTER_TYPE has any other
value, it suggests building an instance of OM class DS_C_FILTER.

 DS_ATTRIBUTE_TYPE          This attribute indicates the attribute type to be
                            used in the suggested DS_C_FILTER_ITEM. This OM
                            attribute is only present when the value of
                            DS_FILTER_TYPE is DS_ITEM.

 DS_CRITERIA                This attribute contains nested search criteria.
                            This OM attribute is not present when the value of
                            DS_FILTER_TYPE is DS_ITEM.

 DS_FILTER_ITEM_TYPE        This attribute indicates the type of suggested
                            filter item. Its value can be one of the following:

                                 DS_APPROXIMATE_MATCH
                                 DS_EQUALITY
                                 DS_GREATER_OR_EQUAL
                                 DS_LESS_OR_EQUAL
                                 DS_SUBSTRINGS

 However, the filter item cannot have the value DS_PRESENT. This OM attribute
 is only present when the value of DS_FILTER_TYPE is DS_ITEM.

 DS_FILTER_TYPE             This attribute indicates the type of suggested
                            filter. The value DS_ITEM means that the suggested
                            component is a filter item, not a filter. The other
                            values suggest the corresponding type of filter.
                            Its value is one of the following:

                                 DS_AND
                                 DS_ITEM
                                 DS_NOT
                                 DS_OR


ΓòÉΓòÉΓòÉ 12.7. DS_C_SEARCH_GUIDE ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_SEARCH_GUIDE suggests a criterion for searching
the directory for particular entries. It can be used to build a DS_C_FILTER
parameter for ds_search operations that are based on the object in whose entry
the search guide occurs.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 44. OM Attributes of DS_C_SEARCH_GUIDE                      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE      Γöé VALUE SYNTAX       Γöé   VALUE  Γöé   VALUE  Γöé  VALUE  Γöé
Γöé             Γöé             Γöé  LENGTH  Γöé  NUMBER  Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_OBJECT_CLASS     Γöé String(OM_S_OBJECT    Γöé    -   Γöé  0 or 1  Γöé   -   Γöé
Γöé             Γöé _IDENTIFIER_ STRING)   Γöé       Γöé       Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_CRITERIA       Γöé Object(DS_C_SEARCH    Γöé    -   Γöé    1   Γöé   -   Γöé
Γöé             Γöé _CRITERION)       Γöé       Γöé       Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_OBJECT_CLASS            This attribute identifies the object class of the
                            entries to which the search guide applies. If this
                            OM attribute is absent, the search guide applies to
                            objects of any class.

 DS_CRITERIA                This attribute contains the suggested search
                            criteria.


ΓòÉΓòÉΓòÉ 12.8. DS_C_TELETEX_TERM_IDENT ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_TELETEX_TERM_IDENT identifies and describes a
teletex terminal.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 45. OM Attributes of DS_C_TELETEX_TERM_IDENT                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE      Γöé VALUE SYNTAX       Γöé   VALUE  Γöé   VALUE  Γöé  VALUE  Γöé
Γöé             Γöé             Γöé  LENGTH  Γöé  NUMBER  Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_PARAMETERS      Γöé Object(MH_C_TELETEX   Γöé    -   Γöé  0 or 1  Γöé   -   Γöé
Γöé             Γöé _NBPS)(1)        Γöé       Γöé       Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_TELETEX_TERM     Γöé String(OM_S_PRINTABLE  Γöé  1-1024  Γöé    1   Γöé   -   Γöé
Γöé             Γöé _STRING)(2)       Γöé       Γöé       Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé (1) As defined in the X.400 API Specifications.                     Γöé
Γöé (2) As permitted by F.200.                               Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_PARAMETERS              This attribute identifies the teletex terminal's
                            advanced capabilities.

 DS_TELETEX_TERM            This attribute identifies the teletex terminal.


ΓòÉΓòÉΓòÉ 12.9. DS_C_TELEX_NBR ΓòÉΓòÉΓòÉ

An instance of OM class DS_C_TELEX_NBR identifies and describes a telex
terminal.

An instance of this OM class has the OM attributes of its superclass,
OM_C_OBJECT, in addition to the OM attributes listed in the following table.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 46. OM Attributes of DS_C_TELEX_NBR                        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM ATTRIBUTE      Γöé VALUE SYNTAX       Γöé   VALUE  Γöé   VALUE  Γöé  VALUE  Γöé
Γöé             Γöé             Γöé  LENGTH  Γöé  NUMBER  Γöé INITIALLY Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_ANSWERBACK      Γöé String(OM_S_PRINTABLE  Γöé   1-8   Γöé    1   Γöé   -   Γöé
Γöé             Γöé _STRING)         Γöé       Γöé       Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_COUNTRY_CODE     Γöé String(OM_S_PRINTABLE  Γöé   1-4   Γöé    1   Γöé   -   Γöé
Γöé             Γöé _STRING)         Γöé       Γöé       Γöé      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DS_TELETEX_NBR     Γöé String(OM_S_PRINTABLE  Γöé   1-14   Γöé    1   Γöé   -   Γöé
Γöé             Γöé _STRING)         Γöé       Γöé       Γöé      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 DS_ANSWERBACK              This attribute contains the code with which the
                            telex terminal acknowledges calls placed to it.

 DS_COUNTRY_CODE            This attribute contains the identifier of the
                            country through which the telex terminal is
                            accessed.

 DS_TELEX_NBR               This attribute contains the number by means of
                            which the telex terminal is addressed.


ΓòÉΓòÉΓòÉ 13. Information Syntaxes ΓòÉΓòÉΓòÉ

This section defines the syntaxes permitted for attribute values. The syntaxes
are closely aligned with the types and type constructors of ASN.1. The OM_value
data type specifies how a value of each syntax is represented in the C
interface (see XOM Service Interface).


ΓòÉΓòÉΓòÉ 13.1. Syntax Templates ΓòÉΓòÉΓòÉ

The names of certain syntaxes are constructed from syntax templates. A syntax
template is a lexical construct comprising a primary identifier followed by an
asterisk enclosed in parentheses:

identifier (*)

A syntax template encompasses a group of related syntaxes. Any member of the
group, without distinction, is indicated by the primary identifier (identifier)
alone. A particular member is indicated by the template with the asterisk (*)
replaced by one of a set of secondary identifiers associated with the template:

identifier1(identifier2)


ΓòÉΓòÉΓòÉ 13.2. Syntaxes ΓòÉΓòÉΓòÉ

A variety of syntaxes are defined. Most are functionally equivalent to ASN.1
types, as documented in Relationship to ASN.1 Simple Types and ending with
Relationship to ASN.1 Type Constructors.

The following syntaxes are defined:

 OM_S_BOOLEAN            A value of this syntax is a Boolean. That is, it can
                         be OM_TRUE or OM_FALSE.

 Enum(*)                 A value of any syntax encompassed by this syntax
                         template is one of a set of values associated with the
                         syntax. The only significant characteristic of the
                         values is that they are distinct.

                         The group of syntaxes encompassed by this template is
                         open-ended. Zero or more members are added to the
                         group by each package definition. The secondary
                         identifiers that indicate the members are also
                         assigned there.

 OM_S_INTEGER            A value of this syntax is a positive or negative
                         integer.

 OM_S_NULL               The one value of this syntax is a valueless place
                         holder.

 Object(*)               A value of any syntax encompassed by this syntax
                         template is an object, which is any instance of a
                         class associated with the syntax.

                         The group of syntaxes encompassed by this template is
                         open-ended. One member is added to the group by each
                         class definition. The secondary identifier that
                         indicates the member is the name of the class.

 String(*)               A value of any syntax encompassed by this syntax
                         template is a string (as defined in Strings) whose
                         form and meaning are associated with the syntax.

                         The group of syntaxes encompassed by this template is
                         closed. One syntax is defined for each ASN.1 string
                         type. The secondary identifier that indicates the
                         member is, in general, the first word of the type's
                         name.


ΓòÉΓòÉΓòÉ 13.3. Strings ΓòÉΓòÉΓòÉ

A string is an ordered sequence of zero or more bits, octets, or characters
accompanied by the string's length.

The value length of a string is the number of bits in a bit string, octets in
an octet string, or characters in a character string. Any constraints on the
value length of a string are specified in the appropriate class definitions.
The length is confined to the range 0 to 2[32].

Note:  The length of a character string does not necessarily equal the number
       of characters it comprises because, for example, a single character can
       be represented using several octets.

 The elements of a string are numbered. The position of the first element is
 zero (0). The positions of successive elements are successive positive
 integers.

 The syntaxes that form the string group are identified in the following table,
 which gives the secondary identifier assigned to each such syntax.

 Note:  The identifiers in the first, second, and third columns of "String
        Syntax Identifiers" indicate the syntaxes of bit, octet, and character
        strings, respectively. The String group comprises all syntaxes
        identified in the table.

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  Γöé Table 47. String Syntax Identifiers                           Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé BIT STRING    Γöé OCTET STRING IDENTIFIER      Γöé CHARACTER STRING IDENTIFIER    Γöé
  Γöé IDENTIFIER    Γöé                  Γöé                  Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé OM_S_BIT_STRING Γöé OM_S_ENCODING_STRING(1)      Γöé OM_S_GENERAL_STRING(2)      Γöé
  Γöé         Γöé OM_S_OBJECT_IDENTIFIER_STRING(3)  Γöé OM_S_OCTET_STRING         Γöé
  Γöé         Γöé OM_S_GENERALISED_TIME_STRING(2)  Γöé OM_S_GRAPHIC_STRING(2)      Γöé
  Γöé         Γöé                  Γöé OM_S_IA5_STRING(2)        Γöé
  Γöé         Γöé                  Γöé OM_S_NUMERIC_STRING        Γöé
  Γöé         Γöé                  Γöé OM_S_OBJECT_DESCRIPTOR_STRING(2) Γöé
  Γöé         Γöé                  Γöé OM_S_PRINTABLE_STRING(2)     Γöé
  Γöé         Γöé                  Γöé OM_S_TELETEX_STRING(2)      Γöé
  Γöé         Γöé                  Γöé OM_S_UTC_TIME_STRING(2)      Γöé
  Γöé         Γöé                  Γöé OM_S_VIDEOTEX_STRING(2)      Γöé
  Γöé         Γöé                  Γöé OM_S_VISIBLE_STRING(2)      Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé (1) The octets are those that BER permits for the contents octets of the encoding of a Γöé
  Γöé   value of any ASN.1 type.                              Γöé
  Γöé                                             Γöé
  Γöé (2) The characters are those permitted by ASN.1's type of the corresponding name.    Γöé
  Γöé   Values of these syntaxes are represented in their BER encoded form.  The octets by Γöé
  Γöé   means of which they are represented are those that BER permits for the contents   Γöé
  Γöé   octets of a primitive encoding of a value of that type.               Γöé
  Γöé                                             Γöé
  Γöé (3) The octets are those that BER permits for the contents octets of the encoding of a Γöé
  Γöé   value of ASN.1's object identifier type.                      Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ


ΓòÉΓòÉΓòÉ 13.4. Representation of String Values ΓòÉΓòÉΓòÉ

In the service interface, a string value is represented by a string data type.
This is defined in the previous Strings section. The length of a string is the
number of octets by which it is represented at the interface. It is confined to
the range 0 to 2[32].

The length of a character does not need to be equal to the number of characters
it comprises because, for example, a single character can be represented using
several octets.

It might be necessary to segment large string values when passing them across
the interface. A segment is any zero or more contiguous octets of a string
value. Segment boundaries are without semantic significance.


ΓòÉΓòÉΓòÉ 13.5. Relationship to ASN.1 Simple Types ΓòÉΓòÉΓòÉ

As shown in "Syntax for ASN.1 Simple Types", for every ASN.1 simple type,
except Real, there is an OM syntax that is functionally equivalent to it. The
simple types are listed in the first column of the table; the corresponding
syntaxes are listed in the second column.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 48. Syntax for ASN.1 Simple Types                         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé TYPE BIT STRING IDENTIFIER  Γöé SYNTAX OCTET STRING IDENTIFIER              Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Bit String          Γöé String(OM_S_BIT_STRING)                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Boolean           Γöé OM_S_BOOLEAN                       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Integer           Γöé OM_S_INTEGER                       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Null             Γöé OM_S_NULL                         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Object Identifier      Γöé String(OM_S_OBJECT_IDENTIFIER_STRING)           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Octet String         Γöé String(OM_S_OCTET_STRING)                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Real             Γöé None(1)                          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé (1) A future edition of XOM might define a syntax corresponding to this type.      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ


ΓòÉΓòÉΓòÉ 13.6. Relationship to ASN.1 Useful Types ΓòÉΓòÉΓòÉ

As shown in "Syntax for ASN.1 Types", for every ASN.1 useful type, there is an
OM syntax that is functionally equivalent to it. The useful types are listed in
the first column of the table; the corresponding syntaxes are listed in the
second column.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 49. Syntax for ASN.1 Types                            Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé TYPE             Γöé SYNTAX                          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé External           Γöé Object(OM_C_EXTERNAL)                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Generalized Time       Γöé String(OM_S_GENERALISED_TIME_STRING)           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Object Descriptor      Γöé String(OM_S_OBJECT_DESCRIPTOR_STRING)           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Universal Time        Γöé String(OM_S_UTC_TIME_STRING)               Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ


ΓòÉΓòÉΓòÉ 13.7. Relationship to ASN.1 Character String Types ΓòÉΓòÉΓòÉ

As shown in "Syntax for ASN.1 Character String Types", for every ASN.1
character string type, there is an OM syntax that is functionally equivalent to
it. The ASN.1 character string types are listed in the first column of the
table; the corresponding syntax is listed in the second column.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 50. Syntax for ASN.1 Character String Types                    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé TYPE             Γöé SYNTAX                          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé General String        Γöé String(OM_S_GENEREL_STRING)                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Graphic String        Γöé String(OM_S_GRAPHIC_STRING)                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé IA5 String          Γöé String(OM_S_IA5_STRING)                  Γöé
Γöé               Γöé String(OM_S_LOCAL_STRING)                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Numeric String        Γöé String(OM_S_NUMERIC_STRING)                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Printable String       Γöé String(OM_S_PRINTABLE_STRING)               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Teletex String        Γöé String(OM_S_TELETEX_STRING)                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Videotex String       Γöé String(OM_S_VIDEOTEX_STRING)               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Visible String        Γöé String(OM_S_VISIBLE_STRING)                Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ


ΓòÉΓòÉΓòÉ 13.8. Relationship to ASN.1 Type Constructors ΓòÉΓòÉΓòÉ

As shown in "Syntax for ASN.1 Type Constructors", there are functionally
equivalent OM syntaxes for some (but not all) ASN.1 type constructors. The
constructors are listed in the first column of the table; the corresponding
syntaxes are listed in the second column.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 51. Syntax for ASN.1 Type Constructors                      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé TYPE CONSTRUCTOR       Γöé SYNTAX                          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Any             Γöé String(OM_S_ENCODING_STRING)               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Choice            Γöé OM_S_OBJECT                        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Enumerated          Γöé OM_S_ENUMERATION                     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Selection          Γöé None(1)                          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Sequence           Γöé OM_S_OBJECT                        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Sequence Of         Γöé OM_S_OBJECT                        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Set             Γöé OM_S_OBJECT                        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Set Of            Γöé OM_S_OBJECT                        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Tagged            Γöé None(2)                          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé (1) This type constructor, a purely specification-time phenomenon, has no corre-    Γöé
Γöé   sponding syntax.                                  Γöé
Γöé (2) This type constructor is used to distinguish the alternatives of a choice or the  Γöé
Γöé   elements of a sequence or set.  This function is performed by attribute types.   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

The effects of the principal type constructors can be achieved, in any of a
variety of ways, using objects to group attributes, or using attributes to
group values. An OM application designer can (but need not) model these
constructors as classes of the following kinds:

   o  Choice - An attribute type can be defined for each alternative with just
      one being permitted in an instance of the class.

   o  Sequence or Set - An attribute type can be defined for each sequence or
      set element. If an element is optional, then the attribute has zero or
      one values.

   o  Sequence Of or Set Of - A single multivalued attribute can be defined.

 An ASN.1 definition of an Enumerated Type component of a structured type is
 generally mapped to an OM attribute with an OM syntax OM_S_ENUMERATION in this
 interface. Where the ASN.1 component is optional, this is generally indicated
 by an additional member of the enumeration, rather than by the omission of the
 OM attribute. This leads to simpler programming in the application.


ΓòÉΓòÉΓòÉ 14. XOM Service Interface ΓòÉΓòÉΓòÉ

This section describes the following aspects of the XOM service interface:

   o  The conformance of the DCE X/Open OSI-Abstract-Data Manipulation (XOM)
      implementation to the X/Open specification.

   o  The data types whose data values are the parameters and results of the
      functions that the service makes available to the client.

   o  An overview of the functions that the service makes available to the
      client. For a complete description of these functions, see the
      corresponding reference pages in the DCE for OS/2 Warp: Application
      Development Reference.

   o  The return codes that indicate the outcomes (in particular, the
      exceptions) that the functions can report.

 See the \opt\dcelocal\examples\xdsxom directory for examples of using the XOM
 interface.


ΓòÉΓòÉΓòÉ 14.1. Standards Conformance ΓòÉΓòÉΓòÉ

The DCE XOM implementation conforms to the following specification: X/Open CAE
Specification, OSI-Abstract-Data Manipulation (XOM) (November 1991).

The following apply to the DCE XOM implementation:

   o  Multiple workspaces for XDS objects are supported.

   o  The OM package is supported.

   o  The om_encode and om_decode functions are not supported. The transfer of
      objects between workspaces is not envisaged within the DCE environment.
      The OM classes used by the DCE XDS/XOM API are not encodable.

   o  Translation to local character sets is not provided.


ΓòÉΓòÉΓòÉ 14.2. XOM Data Types ΓòÉΓòÉΓòÉ

The data types of the XOM service interface are defined in this section and
listed in the following table. These data types are repeated in the XOM
reference pages (see xom.h in the DCE for OS/2 Warp: Application Development
Reference).

 Data Type                  Description

 OM_boolean                 Type definition for a Boolean data value.

 OM_descriptor              Type definition for describing an attribute type
                            and value.

 OM_enumeration             Type definition for an Enumerated data value.

 OM_exclusions              Type definition for the exclusions parameter for
                            om_get.

 OM_integer                 Type definition for an Integer data value.

 OM_modification            Type definition for the modification parameter for
                            om_put.

 OM_object                  Type definition for a handle to either a private or
                            a public object.

 OM_object_identifier       Type definition for an Object Identifier data
                            value.

 OM_private_object          Type definition for a handle to an object in an
                            implementation-defined, or private, representation.

 OM_public_object           Type definition for a defined representation of an
                            object that can be directly interrogated by a
                            programmer.

 OM_return_code             Type definition for a value returned from all OM
                            functions, indicating either that the function
                            succeeded or why it failed.

 OM_string                  Type definition for a data value of one of the
                            String syntaxes.

 OM_syntax                  Type definition for identifying a syntax type.

 OM_type                    Type definition for identifying an OM attribute
                            type.

 OM_type_list               Type definition for enumerating a sequence of OM
                            attribute types.

 OM_value                   Type definition for representing any data value.

 OM_value_length            Type definition for indicating the number of bits,
                            octets, or characters in a string.

 OM_value_position          Type definition for designating a particular
                            location within a String data value.

 OM_workspace               Type definition for identifying an
                            application-specific API that implements OM, such
                            as directory or message handling.

 Some data types are defined in terms of the following intermediate data types,
 whose precise definitions in C are defined by the system:

 OM_sint       The positive and negative integers that can be represented in 16
               bits

 OM_sint16     The positive and negative integers that can be represented in 16
               bits

 OM_sint32     The positive and negative integers that can be represented in 32
               bits

 OM_uint       The non-negative integers that can be represented in 16 bits

 OM_uint16     The non-negative integers that can be represented in 16 bits

 OM_uint32     The non-negative integers that can be represented in 32 bits

 Note:  The OM_sint and OM_uint data types are defined by the range of integers
        they must accommodate. As typically declared in the C interface, they
        are defined by the range of integers permitted by the host machine's
        word size. The latter range, however, always encompasses the former.

 The type definitions for these data types are as follows:

  typedef int             OM_sint;
  typedef short           OM_sint16;
  typedef long int        OM_sint32;
  typedef unsigned        OM_uint;
  typedef unsigned short  OM_uint16;
  typedef long unsigned   OM_uint32;


ΓòÉΓòÉΓòÉ 14.2.1. OM_boolean ΓòÉΓòÉΓòÉ

The C declaration for an OM_boolean data value is as follows:

typedef OM_uint32 OM_boolean;

A value of this data type is a Boolean (that is, either FALSE or TRUE).

FALSE (OM_FALSE) is indicated by 0 (zero). TRUE is indicated by any other
integer, although the symbolic constant OM_TRUE refers to the integer 1
specifically.


ΓòÉΓòÉΓòÉ 14.2.2. OM_descriptor ΓòÉΓòÉΓòÉ

The OM_descriptor data type is used to describe an attribute type and value.
Its C declaration is as follows:

typedef struct OM_descriptor_struct
{
OM_type        type;
OM_syntax      syntax;
union  OM_value_union value;
}  OM_descriptor;

Note:  Other components are encoded in high bits of the syntax member.

 See the OM_value data type in OM_value or xom.h in the DCE for OS/2
 Warp:Application Development Reference for a description of the OM_value_union
 structure.

 A value of this type is a descriptor, which embodies an attribute value. An
 array of descriptors can represent all the values of all the attributes of an
 object, and is the representation called OM_public_object. A descriptor has
 the following components:

 type                     An OM_type data type identifies the data type of the
                          attribute value.

 syntax                   An OM_syntax data type identifies the syntax of the
                          attribute value. Components 3 to 7 (that is, the
                          components long-string through private that follow)
                          are encoded in the high-order bits of this structure
                          member. Therefore, the syntax always needs to be
                          masked with the constant OM_S_SYNTAX.

                          For example:

                                                    my_syntax = my_public_object[3].syntax &
                                                                   OM_S_SYNTAX;

                                                    my_public_object[4].syntax =
                                                    my_syntax + (my_public_object[4].syntax &
                                                    ~OM_S_SYNTAX);

 long-string              An OM_boolean data type is OM_TRUE only if the
                          descriptor is a service-generated descriptor and the
                          length of the value is greater than an implementation
                          defined limit.

                          This component occupies bit 15 (0x8000) of the syntax
                          and is represented by the constant OM_S_LONG_STRING.

 no-value                 An OM_boolean data type is OM_TRUE only if the
                          descriptor is a service-generated descriptor and the
                          value is not present because OM_EXCLUDE_VALUES or
                          OM_EXCLUDE_MULTIPLES is set in om_get.

                          This component occupies bit 14 (0x4000) of the syntax
                          and is represented by the constant OM_S_NO_VALUE.

 local-string             An OM_boolean data type, significant only if the
                          syntax is one of the string syntaxes. It is OM_TRUE
                          only if the string is represented in an
                          implementation-defined local character set. The local
                          character set can be more amenable for use as
                          keyboard input or display output than the nonlocal
                          character set, and can include specific treatment of
                          line termination sequences. Certain interface
                          functions can convert information in string syntaxes
                          to or from the local representation, which can result
                          in a loss of information.

                          This component occupies bit 13 (0x2000) of the syntax
                          and is represented by the constant OM_S_LOCAL_STRING.
                          The DCE XOM implementation does not support
                          translation of strings to a local character set.

 service-generated        An OM_boolean data type is OM_TRUE only if the
                          descriptor is a service-generated descriptor and the
                          first descriptor of a public object, or the defined
                          part of a private object. (See XOM in the DCE for
                          OS/2 Warp: Application Development Reference.) This
                          component occupies bit 12 (0x1000) of the syntax and
                          is represented by the constant
                          OM_S_SERVICE_GENERATED.

 private                  An OM_boolean data type is OM_TRUE only if the
                          descriptor in the service-generated public object
                          contains a reference to the handle of a private
                          subobject, or in the defined part of a private
                          object.

                          Note:  This applies only when the descriptor is a
                                 service-generated descriptor. The client need
                                 not set this bit in a client-generated
                                 descriptor that contains a reference to a
                                 private object. In the C interface, this
                                 component occupies bit 11 (0x0800) of the
                                 syntax and is represented by the constant
                                 OM_S_PRIVATE.

 value                    An OM_value data type identifies the attribute value.


ΓòÉΓòÉΓòÉ 14.2.3. OM_enumeration ΓòÉΓòÉΓòÉ

The OM_enumeration data type is used to indicate an Enumerated data value. Its
C declaration is as follows:

typedef OM_sint32 OM_enumeration;

A value of this data type is an attribute value whose syntax is
OM_S_ENUMERATION.


ΓòÉΓòÉΓòÉ 14.2.4. OM_exclusions ΓòÉΓòÉΓòÉ

The OM_exclusions data type is used for the exclusions parameter of om_get. Its
C declaration is as follows:

typedef OM_uint OM_exclusions;

A value of this data type is an unordered set of one or more values, all of
which are distinct. Each value indicates an exclusion, as defined by om_get,
and is chosen from the following set:

   o  OM_EXCLUDE_ALL_BUT_THESE_TYPES
   o  OM_EXCLUDE_MULTIPLES
   o  OM_EXCLUDE_ALL_BUT_THESE_VALUES
   o  OM_EXCLUDE_VALUES
   o  OM_EXCLUDE_SUBOBJECTS
   o  OM_EXCLUDE_DESCRIPTORS

 Alternatively, the single value OM_NO_EXCLUSIONS can be chosen as this selects
 the entire object. Each value except OM_NO_EXCLUSIONS is represented by a
 distinct bit. The presence of the value is represented as 1; its absence is
 represented as 0 (zero). Thus, multiple exclusions are requested by ORing the
 values that indicate the individual exclusions.


ΓòÉΓòÉΓòÉ 14.2.5. OM_integer ΓòÉΓòÉΓòÉ

The OM_integer data type is used to indicate an integer data value. Its C
declaration is as follows:

typedef OM_sint32 OM_integer;

A value of this data type is an attribute value whose syntax is OM_S_INTEGER.


ΓòÉΓòÉΓòÉ 14.2.6. OM_modification ΓòÉΓòÉΓòÉ

The OM_modification data type is used for the modification parameter of om_put.
Its C declaration is as follows:

typedef OM_uint OM_modification;

A value of this data type indicates a kind of modification, as defined by
om_put. It is chosen from the following set:

   o  OM_INSERT_AT_BEGINNING
   o  OM_INSERT_AT_CERTAIN_POINT
   o  OM_INSERT_AT_END
   o  OM_REPLACE_ALL
   o  OM_REPLACE_CERTAIN_VALUES


ΓòÉΓòÉΓòÉ 14.2.7. OM_object ΓòÉΓòÉΓòÉ

The OM_object data type is used as a handle to either a private or a public
object. Its C declaration is as follows:

typedef struct OM_descriptor_struct *OM_object;

A value of this data type represents an object, which can be either public or
private. It is an ordered sequence of one or more instances of the
OM_descriptor data type. Refer to OM_private_object and OM_public_object data
types for restrictions on that sequence.


ΓòÉΓòÉΓòÉ 14.2.8. OM_object_identifier ΓòÉΓòÉΓòÉ

The OM_object_identifier data type is used as an ASN.1 object identifier. Its C
declaration is as follows:

typedef OM_string OM_object_identifier;

A value of this data type contains an octet string that comprises the contents
octets of the BER encoding of an ASN.1 object identifier.


ΓòÉΓòÉΓòÉ 14.2.9. C Declaration of Object Identifiers ΓòÉΓòÉΓòÉ

Every application program that uses a class or another object identifier must
explicitly import it into every compilation unit (C source module) that uses
it. Each such class or object identifier name must be explicitly exported from
just one compilation module. Most application programs find it convenient to
export all the names they use from the same compilation unit. Exporting and
importing is performed using the following two macros:

   o  The importing macro makes the class or other object identifier constants
      available within a compilation unit.

        -  OM_IMPORT(class_name)
        -  OM_IMPORT(OID_name)

   o  The exporting macro allocates memory for the constants that represent the
      class or another object identifier.

        -  OM_EXPORT(class_name)
        -  OM_EXPORT(OID_name)

 Object identifiers are defined in the appropriate header files, with the
 definition identifier having the prefix OMP_O_ followed by the variable name
 for the object identifier. The constant itself provides the hexadecimal value
 of the object identifier string.


ΓòÉΓòÉΓòÉ 14.2.10. Use of Object Identifiers in C ΓòÉΓòÉΓòÉ

The OM_OID_DESC(type, OID_name) macro initializes a descriptor. It sets the
type component to that given, sets the syntax component to
OM_S_OBJECT_IDENTIFIER_STRING, and sets the value component to the specified
object identifier.

The OM_NULL_DESCRIPTOR macro initializes a descriptor to mark the end of a
client-allocated public object.

For each class there is a global variable of type OM_STRING with the same name.
For example, the External class has a variable called OM_C_EXTERNAL. This is
also the case for other object identifiers. For example, the object identifier
for BER rules has a variable called OM_BER. This global variable can be
supplied as a parameter to functions when required.

This variable is valid only when it is exported by an OM_EXPORT macro and
imported by an OM_IMPORT macro in the compilation units that use it. This
variable cannot form part of a descriptor, but the value of its length and
elements components can be used. The following code fragment provides examples
of the use of the macros and constants.

/* Examples of the use of the macros and constants */

#include <xom.h>

OM_IMPORT(OM__C_ENCODING)
OM_IMPORT(OM_CANONICAL_BER)

/* The following sequence must appear in just one compilation
*  unit in place of the above:
*
*  #include <xom.h>
*
*  OM_EXPORT(OM_C_ENCODING)
*  OM_EXPORT(OM_CANONICAL_BER)
*/
main()
{
/* Use #1 - Define a public object of class Encoding
*          (Note: xxxx is a Message Handling class which can be
*           encoded)
*/
OM_descriptor my_public_object[] = {
      OM_OID_DESC(OM_CLASS, OM_C_ENCODING),
      OM_OID_DESC(OM_OBJECT_CLASS, MA_C_xxxx),
      { OM_OBJECT_ENCODING, OM_S_ENCODING_STRING, some_BER_value},
      OM_OID_DESC(OM_RULES, OM_CANONICAL_BER),
      OM_NULL_DESCRIPTOR
      };

/* Use #2 - Pass class Encoding as a parameter to om_instance() */
return_code = om_instance(my_object, OM_C_ENCODING,
  &boolean_result);
}


ΓòÉΓòÉΓòÉ 14.2.11. OM_private_object ΓòÉΓòÉΓòÉ

The OM_private_object data type is used as a handle to an object in an
implementation-defined or private representation. Its C declaration is as
follows:

typedef OM_object OM_private_object;

A value of this data type is the designator or handle to a private object. It
comprises a single descriptor whose type component is OM_PRIVATE_OBJECT and
whose syntax and value components are unspecified.

Note:  The descriptor's syntax and value components are essential to the
       service's proper operation with respect to the private object.


ΓòÉΓòÉΓòÉ 14.2.12. OM_public_object ΓòÉΓòÉΓòÉ

The OM_public_object data type is used to define an object that can be directly
accessed by a programmer. Its C declaration is as follows:

typedef OM_object OM_public_object;

A value of this data type is a public object which comprises one or more
(usually more) descriptors. All but the last of which represent values of
attributes of the object.

The descriptors for the values of a particular attribute with two or more
values are adjacent to one another in the sequence. Their order is that of the
values they represent. The order of the resulting groups of descriptors is
unspecified.

Since the Class attribute specific to the Object class is represented among the
descriptors, it must be represented before any other attributes. Regardless of
whether or not the Class attribute is present, the syntax field of the first
descriptor must have the OM_S_SERVICE_GENERATED bit set or cleared
appropriately.

The last descriptor signals the end of the sequence of descriptors. The last
descriptor's type component is OM_NO_MORE_TYPES and its syntax component is
OM_S_NO_MORE_SYNTAXES. The last descriptor's value component is unspecified.


ΓòÉΓòÉΓòÉ 14.2.13. OM_return_code ΓòÉΓòÉΓòÉ

The OM_return_code data type is used for a value that is returned from all OM
functions indicating either that the function succeeded or why it failed. Its C
declaration is as follows:

typedef OM_uint OM_return_code;

A value of this data type is the integer in the range 0 to 2[16] that indicates
an outcome of an interface function. It is chosen from the set specified in XOM
Return Codes.

Integers in the narrower range 0 to 2[15] are used to indicate the return codes
they define.


ΓòÉΓòÉΓòÉ 14.2.14. OM_string ΓòÉΓòÉΓòÉ

The OM_string data type is used for a data value of String syntax. Its C
declaration is as follows:

typedef OM_uint32 OM_string_length;
typedef struct {
      OM_string_length length;
      void *elements;
} OM_string;

#define OM_STRING(string)\
      { (OM_string_length)(sizeof(string)-1), (string) }

A value of this data type is a string (that is, an instance of a String
syntax). A string is specified either in terms of its length or whether or not
it ends with NULL. A string has the following components:

 length(OM_string_length)            The number of octets by means of which the
                                     string is represented, or the
                                     OM_LENGTH_UNSPECIFIED value if the string
                                     ends with NULL.

 elements                            The string's elements. The bits of a bit
                                     string are represented as a sequence of
                                     octets (see the following figure). The
                                     first octet stores the number of unused
                                     bits in the last octet. The bits in the
                                     bit string, commencing with the first bit
                                     and proceeding to the trailing bit, are
                                     placed in bits 7 to 0 of the second octet.
                                     These are followed by bits 7 to 0 of the
                                     third octet, then by bits 7 to 0 of each
                                     octet in turn, followed by as many bits as
                                     are required of the final octet,
                                     commencing with bit 7.


  OM _ StringElements

 The service supplies a string value with a specified length. The client can
 supply a string value to the service in either form, either with a specified
 length or ended with NULL.

 The characters of a character string are represented as any sequence of octets
 permitted as the primitive contents octets of the BER encoding of an ASN.1
 type value. The ASN.1 type defines the type of character string. A 0 (zero)
 value character follows the characters of the character string, but is not
 encompassed by the length component. Thus, depending upon the type of
 character string, the 0 (zero) value character can delimit the characters of
 the character string.

 The OM_STRING macro is provided for creating a data value of this data type,
 given only the value of its elements component. The macro, however, applies to
 octet strings and character strings, but not to bit strings.


ΓòÉΓòÉΓòÉ 14.2.15. OM_syntax ΓòÉΓòÉΓòÉ

The OM_syntax data type is used to identify a syntax type. Its C declaration is
as follows:

typedef OM_uint16 OM_syntax;

A value of this data type is an integer in the range 0 to 2[9], that denotes an
individual syntax or a set of syntaxes taken together.

The value is chosen from among the following:

   o  OM_S_BIT_STRING
   o  OM_S_BOOLEAN
   o  OM_S_ENCODING_STRING
   o  OM_S_ENUMERATION
   o  OM_S_GENERAL_STRING
   o  OM_S_GENERALISED_TIME_STRING
   o  OM_S_GRAPHIC_STRING
   o  OM_S_IA5_STRING
   o  OM_S_INTEGER
   o  OM_S_NULL
   o  OM_S_NUMERIC_STRING
   o  OM_S_OBJECT
   o  OM_S_OBJECT_DESCRIPTOR_STRING
   o  OM_S_OBJECT_IDENTIFIER_STRING
   o  OM_S_OCTET_STRING
   o  OM_S_PRINTABLE_STRING
   o  OM_S_TELETEX_STRING
   o  OM_S_VIDEOTEX_STRING
   o  OM_S_VISIBLE_STRING
   o  OM_S_UTC_TIME_STRING

 Integers in the narrower range 0 to 2[9] to denote the syntaxes they define.
 The integers in the range 2[9] to 2[10] are reserved for vendor extensions.
 Wherever possible, the integers used are the same as the corresponding ASN.1
 universal class number.


ΓòÉΓòÉΓòÉ 14.2.16. OM_type ΓòÉΓòÉΓòÉ

The OM_type data type is used to identify an OM attribute type. Its C
declaration is as follows:

typedef OM_uint16 OM_type;

A value of this data type is an integer in the range 0 to 2[16] that denotes a
type in the context of a package. However, the values listed below are assigned
meanings by the respective data types.

 Value                      Data Type

 OM_NO_MORE_TYPES           OM_type_list

 OM_PRIVATE_OBJECT          OM_private_object

 Integers in the narrower range 0 to 2[9] to indicate the types they define.


ΓòÉΓòÉΓòÉ 14.2.17. OM_type_list ΓòÉΓòÉΓòÉ

The OM_type_list data type is used to enumerate a sequence of OM attribute
types. Its C declaration is as follows:

typedef OM_type *OM_type_list;

A value of this data type is an ordered sequence of zero or more type numbers,
each of which is an instance of the OM_type data type.

An additional data value, OM_NO_MORE_TYPES, follows and thus delimits the
sequence. The C representation of the sequence is an array.


ΓòÉΓòÉΓòÉ 14.2.18. OM_value ΓòÉΓòÉΓòÉ

The OM_value data type is used to represent any data value. Its C declaration
is as follows:

typedef struct {
      OM_uint32 padding;
      OM_object object;
} OM_padded_object;

typedef union OM_value_union {
      OM_string            string;
      OM_boolean           boolean;
      OM_enumeration       enumeration;
      OM_integer           integer;
      OM_padded_object  object;
} OM_value;

Note:  The first type definition (in particular, its padding component) aligns
       the object component with the elements component of the string component
       in the second type definition. This facilitates initialization in C.

 The identifier OM_value_union is defined for reasons of compilation order. It
 is used in the definition of the OM_descriptor data type.

 A value of this data type is an attribute value. It has no components if the
 value's syntax is OM_S_NO_MORE_SYNTAXES or OM_S_NO_VALUE. Otherwise, it has
 one of the following components:

 string           The value if its syntax is a string syntax

 boolean          The value if its syntax is OM_S_BOOLEAN

 enumeration      The value if its syntax is OM_S_ENUMERATION

 integer          The value if its syntax is OM_S_INTEGER

 object           The value if its syntax is OM_S_OBJECT

 Note:  A value of this data type is only displayed as a component of a
        descriptor. Thus, it is always accompanied by indicators of the value's
        syntax. The latter indicator reveals which component is present.


ΓòÉΓòÉΓòÉ 14.2.19. OM_value_length ΓòÉΓòÉΓòÉ

The OM_value_length data type is used to indicate the number of bits, octets,
or characters in a string. Its C declaration is as follows:

typedef OM_uint32 OM_value_length;

A value of this data type is an integer in the range 0 to 2[32] that represents
the number of bits in a bit string, octets in an octet string, or characters in
a character string.

Note:  This data type is not used in the definition of the interface. It is
       provided for use by client programmers for defining attribute
       constraints.


ΓòÉΓòÉΓòÉ 14.2.20. OM_value_position ΓòÉΓòÉΓòÉ

The OM_value_position data type is used to indicate an attribute value's
position within an attribute. Its C declaration is as follows:

typedef OM_uint32 OM_value_position;

A value of this data type is an integer in the range 0 to 2[32] -1 that
indicates the position of a value within an attribute. However, the value
OM_ALL_VALUES has the meaning assigned to it by om_get.


ΓòÉΓòÉΓòÉ 14.2.21. OM_workspace ΓòÉΓòÉΓòÉ

The OM_workspace data type is used to identify an application-specific API that
implements OM, for example, directory or message handling. Its C declaration is
as follows:

typedef void *OM_workspace;

A value of this data type is the designator or handle for a workspace.


ΓòÉΓòÉΓòÉ 14.3. XOM Functions ΓòÉΓòÉΓòÉ

The purpose and range of capabilities of the XOM service interface functions
are summarized below. For a full description of these functions, refer to the
DCE for OS/2 Warp: Application Development Reference.

 om_copy              This function creates an independent copy of an existing
                      private object and all its subobjects. The copy is placed
                      in the workspace of the original object, or in another
                      workspace specified by the DCE client.

 om_copy_value        This function replaces an existing attribute value or
                      inserts a new value in one private object with a copy of
                      an existing attribute value found in another. Both values
                      must be strings.

 om_create            This function creates a new private object that is an
                      instance of a particular class. The object can be
                      initialized with the attribute values specified as
                      initial in the class definition.

                      The service does not permit the client to explicitly
                      create instances of all classes, but rather only those
                      indicated by a package's definition as having this
                      property.

 om_decode            This function is note supported by the DCE XOM interface;
                      it returns an OM_FUNCTION_DECLINED error.

 om_delete            This function deletes a service-generated public object,
                      or makes a private object inaccessible.

 om_encode            This function is not supported by the DCE XOM interface;
                      it returns an OM_FUNCTION_DECLINED error.

 om_get               This function creates a new public object that is an
                      exact but independent copy of an existing private object.
                      The client can request certain exclusions, each of which
                      reduces the copy to a part of the original. The client
                      can also request that values be converted from one syntax
                      to another before they are returned.

                      The copy can exclude:

                        o  Attributes of types other than those specified,
                        o  Values at positions other than those specified
                           within an attribute,
                        o  Values of multivalued attributes,
                        o  Copies of, (not handles for), subobjects, or
                        o  All attribute values.

                      Excluding all attribute values reveals only an
                      attribute's presence.

 om_instance          This function determines whether an object is an instance
                      of a particular class. The client can determine an
                      object's class simply by inspection. This function is
                      useful because it reveals that an object is an instance
                      of a particular class, even if the object is an instance
                      of a subclass of that class.

 om_put               This function places or replaces in one private object
                      copies of the attribute values of another public or
                      private object.

                      The source values can be inserted before any existing
                      destination values, before the value at a specified
                      position in the destination attribute, or after any
                      existing destination values. Alternatively, the source
                      values can be substituted for any existing destination
                      values or for the values at specified positions in the
                      destination attribute.

 om_read              This function reads a segment of a value of an attribute
                      of a private object. The value must be a string. The
                      value can first be converted from one syntax to another.
                      This function enables the client to read an arbitrarily
                      long value without requiring that the service place a
                      copy of the entire value in memory.

 om_remove            This function removes and discards particular values of
                      an attribute of a private object. The attribute itself is
                      removed if no values remain.

 om_write             This function writes a segment of an attribute value to a
                      private object. The value must be a string. The segment
                      can first be converted from one syntax to another. The
                      written segment becomes the value's last segment because
                      any elements beyond it are discarded. The function
                      enables the client to write an arbitrarily long value
                      without having to place a copy of the entire value in
                      memory.


ΓòÉΓòÉΓòÉ 14.4. XOM Return Codes ΓòÉΓòÉΓòÉ

This section defines the return codes of the service interface and thus the
exceptions that can prevent the successful completion of an interface function.

Refer to the  ERRORS section of the reference pages for a list of the errors
that each function can return.

The return code values are as follows:


ΓòÉΓòÉΓòÉ 14.4.1. 0 ΓòÉΓòÉΓòÉ

 0         OM_SUCCESS

           Explanation: The function completed successfully.


ΓòÉΓòÉΓòÉ 14.4.2. 1 ΓòÉΓòÉΓòÉ

 1         OM_ENCODING_INVALID

           Explanation: The octets that constitute the value of an encoding's
           Object Encoding attribute are invalid.


ΓòÉΓòÉΓòÉ 14.4.3. 2 ΓòÉΓòÉΓòÉ

 2         OM_FUNCTION_DECLINED

           Explanation: The function does not apply to the object to which it
           is addressed.


ΓòÉΓòÉΓòÉ 14.4.4. 3 ΓòÉΓòÉΓòÉ

 3         OM_FUNCTION_INTERRUPTED

           Explanation: The function is aborted by an external force. For
           example, a keystroke designated for this purpose at a user
           interface.


ΓòÉΓòÉΓòÉ 14.4.5. 4 ΓòÉΓòÉΓòÉ

 4         OM_MEMORY_INSUFFICIENT

           Explanation: The service cannot allocate the main memory it needs to
           complete the function.


ΓòÉΓòÉΓòÉ 14.4.6. 5 ΓòÉΓòÉΓòÉ

 5         OM_NETWORK_ERROR

           Explanation: The service could not successfully employ the network
           upon which its implementation depends.


ΓòÉΓòÉΓòÉ 14.4.7. 6 ΓòÉΓòÉΓòÉ

 6         OM_NO_SUCH_CLASS

           Explanation: A purported class identifier is not defined.


ΓòÉΓòÉΓòÉ 14.4.8. 7 ΓòÉΓòÉΓòÉ

 7         OM_NO_SUCH_EXCLUSION

           Explanation: A purported exclusion identifier is not defined.


ΓòÉΓòÉΓòÉ 14.4.9. 8 ΓòÉΓòÉΓòÉ

 8         OM_NO_SUCH_MODIFICATION

           Explanation: A purported modification identifier is not defined.


ΓòÉΓòÉΓòÉ 14.4.10. 9 ΓòÉΓòÉΓòÉ

 9         OM_NO_SUCH_OBJECT

           Explanation: A purported object is nonexistent, or the purported
           handle is invalid.


ΓòÉΓòÉΓòÉ 14.4.11. 10 ΓòÉΓòÉΓòÉ

 10        OM_NO_SUCH_RULES

           Explanation: A purported rules identifier is not defined.


ΓòÉΓòÉΓòÉ 14.4.12. 11 ΓòÉΓòÉΓòÉ

 11        OM_NO_SUCH_SYNTAX

           Explanation: A purported syntax identifier is not defined.


ΓòÉΓòÉΓòÉ 14.4.13. 12 ΓòÉΓòÉΓòÉ

 12        OM_NO_SUCH_TYPE

           Explanation: A purported type identifier is not defined.


ΓòÉΓòÉΓòÉ 14.4.14. 13 ΓòÉΓòÉΓòÉ

 13        OM_NO_SUCH_WORKSPACE

           Explanation: A purported workspace is nonexistent.


ΓòÉΓòÉΓòÉ 14.4.15. 14 ΓòÉΓòÉΓòÉ

 14        OM_NOT_AN_ENCODING

           Explanation: An object is not an instance of the Encoding class.


ΓòÉΓòÉΓòÉ 14.4.16. 15 ΓòÉΓòÉΓòÉ

 15        OM_NOT_CONCRETE

           Explanation: A class is abstract, not concrete.


ΓòÉΓòÉΓòÉ 14.4.17. 16 ΓòÉΓòÉΓòÉ

 16        OM_NOT_PRESENT

           Explanation: An attribute value is absent, not present.


ΓòÉΓòÉΓòÉ 14.4.18. 17 ΓòÉΓòÉΓòÉ

 17        OM_NOT_PRIVATE

           Explanation: An object is public, not private.


ΓòÉΓòÉΓòÉ 14.4.19. 18 ΓòÉΓòÉΓòÉ

 18        OM_NOT_THE_SERVICES

           Explanation: An object is a client-generated object, rather than a
           service-generated or private object.


ΓòÉΓòÉΓòÉ 14.4.20. 19 ΓòÉΓòÉΓòÉ

 19        OM_PERMANENT_ERROR

           Explanation: The service encountered a permanent difficulty other
           than those indicated by other return codes.


ΓòÉΓòÉΓòÉ 14.4.21. 20 ΓòÉΓòÉΓòÉ

 20        OM_POINTER_INVALID

           Explanation: In the C interface, an invalid pointer is supplied as a
           function parameter, or as the receptacle for a function result.


ΓòÉΓòÉΓòÉ 14.4.22. 21 ΓòÉΓòÉΓòÉ

 21        OM_SYSTEM_ERROR

           Explanation: The service could not successfully employ the operating
           system upon which its implementation depends.


ΓòÉΓòÉΓòÉ 14.4.23. 22 ΓòÉΓòÉΓòÉ

 22        OM_TEMPORARY_ERROR

           Explanation: The service encountered a temporary difficulty other
           than those indicated by other return codes.


ΓòÉΓòÉΓòÉ 14.4.24. 23 ΓòÉΓòÉΓòÉ

 23        OM_TOO_MANY_VALUES

           Explanation: An implementation limit prevents a further attribute
           value from being added to an object. This limit is undefined.


ΓòÉΓòÉΓòÉ 14.4.25. 24 ΓòÉΓòÉΓòÉ

 24        OM_VALUES_NOT_ADJACENT

           Explanation: The descriptors for the values of a particular
           attribute are not adjacent.


ΓòÉΓòÉΓòÉ 14.4.26. 25 ΓòÉΓòÉΓòÉ

 25        OM_WRONG_VALUE_LENGTH

           Explanation: An attribute has, or would have, a value that violates
           the value length constraints in force.


ΓòÉΓòÉΓòÉ 14.4.27. 26 ΓòÉΓòÉΓòÉ

 26        OM_WRONG_VALUE_MAKEUP

           Explanation: An attribute has, or would have, a value that violates
           a constraint on the value's syntax.


ΓòÉΓòÉΓòÉ 14.4.28. 27 ΓòÉΓòÉΓòÉ

 27        OM_WRONG_VALUE_NUMBER

           Explanation: An attribute has, or would have, a value that violates
           the value number constraints in force.


ΓòÉΓòÉΓòÉ 14.4.29. 28 ΓòÉΓòÉΓòÉ

 28        OM_WRONG_VALUE_POSITION

           Explanation: The use defined for value position in the parameter or
           parameters of a function is invalid.


ΓòÉΓòÉΓòÉ 14.4.30. 29 ΓòÉΓòÉΓòÉ

 29        OM_WRONG_VALUE_SYNTAX

           Explanation: An attribute has, or would have, a value whose syntax
           is not permitted.


ΓòÉΓòÉΓòÉ 14.4.31. 30 ΓòÉΓòÉΓòÉ

 30        OM_WRONG_VALUE_TYPE

           Explanation: An object has, or would have, an attribute whose type
           is not permitted.


ΓòÉΓòÉΓòÉ 15. Object Management Package ΓòÉΓòÉΓòÉ

This section defines the Object Management Package (OMP). The object identifier
(referred to as om) assigned to the package, as defined by this guide, is the
object identifier specified in ASN.1 as {joint-iso-ccitt(2) mhs-motis(6)
group(6) white(1) api(2) om(4)}.


ΓòÉΓòÉΓòÉ 15.1. Class Hierarchy ΓòÉΓòÉΓòÉ

This section shows the hierarchical organization of the OM classes.
Subclassification is indicated by indentation, and the names of abstract
classes are in italics. For example, OM_C_ENCODING is an immediate subclass of
OM_C_OBJECT, an abstract class. The names of classes to which om_encode applies
are in boldface. (DCE XOM does not support the encoding of any OM classes.) The
om_create function applies to all concrete classes.

   o  OM_C_OBJECT

        -  OM_C_ENCODING
        -  OM_C_EXTERNAL


ΓòÉΓòÉΓòÉ 15.2. Class Definitions ΓòÉΓòÉΓòÉ

The following sections define the OM classes.

   o  OM_C_ENCODING
   o  OM_C_EXTERNAL
   o  OM_C_OBJECT


ΓòÉΓòÉΓòÉ 15.2.1. OM_C_ENCODING ΓòÉΓòÉΓòÉ

An instance of class OM_C_ENCODING is an object represented in a form suitable
for transmission between workspaces, for transport through a network, or for
storage in a file. Encoding can also be a suitable way of indicating to an
intermediate service provider (for example, a directory, or message transfer
system) an object that it does not recognize.

This class has the attributes of its superclass, OM_C_OBJECT, in addition to
the specific attributes listed in "Attributes Specific to OM_C_ENCODING".

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 52. Attributes Specific to OM_C_ENCODING                     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé              Γöé                  Γöé  VALUE Γöé  VALUE Γöé VALUE Γöé
Γöé ATTRIBUTE         Γöé VALUE SYNTAX            Γöé LENGTH Γöé NUMBER Γöé  INI- Γöé
Γöé              Γöé                  Γöé     Γöé     Γöé TIALLYΓöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM_OBJECT_CLASS      Γöé String(OM_S_OBJECT         Γöé   -  Γöé   1  Γöé  -  Γöé
Γöé              Γöé _IDENTIFIER_STRING)        Γöé     Γöé     Γöé    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM_OBJECT_ENCODING    Γöé String(1)             Γöé   -  Γöé   1  Γöé  -  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM_RULES         Γöé String(OM_S_OBJECT         Γöé   -  Γöé   1  Γöé  ber  Γöé
Γöé              Γöé _IDENTIFIER_STRING)        Γöé     Γöé     Γöé    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé (1) If the Rules attribute is ber or canonical-ber, the syntax of the present attri-  Γöé
Γöé   bute must be String (OM_S_ENCODING_STRING).                     Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 OM_OBJECT_CLASS                 This attribute identifies the class of the
                                 object that the Object Encoding attribute
                                 encodes. The class must be concrete.

 OM_OBJECT_ENCODING              This attribute is the encoding itself.

 OM_RULES                        This attribute identifies the set of rules
                                 that are followed to produce the Object
                                 Encoding attribute. Among the defined values
                                 of this attribute are those represented as
                                 follows:

                                      OM_BER                   This value is
                                                               specified in
                                                               ASN.1 as
                                                               {joint-iso-ccitt(2)
                                                               asn1(1)
                                                               basic-encoding(1)}.
                                                               This value
                                                               indicates the
                                                               BER. (See Clause
                                                               25.2 of
                                                               Recommendation
                                                               X.209,
                                                               "Specification
                                                               of Basic
                                                               Encoding Rules
                                                               for Abstract
                                                               Syntax Notation
                                                               1 (ASN.1),"
                                                               CCITT Blue Book,
                                                               Fascicle VIII.4,
                                                               International
                                                               Telecommunications
                                                               Union, 1988.
                                                               Also published
                                                               by ISO as ISO
                                                               8825.)

                                      OM_CANONICAL_BER         This value is
                                                               specified in
                                                               ASN.1 as
                                                               {joint-iso-ccitt(2)
                                                               mhs-motis(6)
                                                               group(6)
                                                               white(1) api(2)
                                                               om(4)
                                                               canonical-ber(4)}.
                                                               This value
                                                               indicates the
                                                               canonical BER.
                                                               (See Clause 8.7
                                                               of CCITT Blue
                                                               Book,
                                                               International
                                                               Telecommunications
                                                               Union, 1988.
                                                               Also published
                                                               by ISO as ISO
                                                               9594-8.)

 Note:  In general, an instance of this class cannot appear as a value whose
        syntax is Object (C) if C is not OM_C_ENCODING, even if the class of
        the object encoded is C.


ΓòÉΓòÉΓòÉ 15.2.2. OM_C_EXTERNAL ΓòÉΓòÉΓòÉ

An instance of class OM_C_EXTERNAL is a data value and one or more information
items that describe the data value and identify its data type. This class
corresponds to ASN.1's External type, and thus the class and the attributes
specific to it are described indirectly in the specification of ASN.1. (See
Clause 34 of Recommendation X.208, "Specification of Abstract Syntax Notation 1
(ASN.1)," CCITT Blue Book, Fascicle VIII.4, International Telecommunications
Union, 1988. Also published by ISO as ISO 8824.)

This class has the attributes of its superclass, OM_C_OBJECT, in addition to
the OM attributes specific to this class that are listed in "Attributes
Specific to OM_C_EXTERNAL".

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 53. Attributes Specific to OM_C_EXTERNAL                     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé              Γöé                  Γöé  VALUE Γöé  VALUE Γöé VALUE Γöé
Γöé ATTRIBUTE         Γöé VALUE SYNTAX            Γöé LENGTH Γöé NUMBER Γöé  INI- Γöé
Γöé              Γöé                  Γöé     Γöé     Γöé TIALLYΓöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM_ARBITRARY_ENCODING   Γöé String(OM_S_BIT          Γöé   -  Γöé  0 or  Γöé  -  Γöé
Γöé              Γöé _STRING)              Γöé     Γöé  1(1)  Γöé    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM_ASN1_ENCODING     Γöé String(OM_S_ENCODING        Γöé   -  Γöé  0 or  Γöé  -  Γöé
Γöé              Γöé _STRING)              Γöé     Γöé  1(1)  Γöé    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM_DATA_VALUE_DESCRIPTOR Γöé String(OM_S_OBJECT         Γöé   -  Γöé 0 or 1 Γöé  -  Γöé
Γöé              Γöé _DESCRIPTOR_STRING)        Γöé     Γöé     Γöé    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM_DIRECT_REFERENCE    Γöé String(OM_S_OBJECT         Γöé   -  Γöé 0 or 1 Γöé  -  Γöé
Γöé              Γöé _IDENTIFIER_STRING)        Γöé     Γöé     Γöé    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM_INDIRECT_REFERENCE   Γöé OM_S_INTEGER            Γöé   -  Γöé 0 or 1 Γöé  -  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM_OCTET_ALIGNED_ENCODINGΓöé String(OM_S_OCTET         Γöé   -  Γöé  0 or  Γöé  -  Γöé
Γöé              Γöé _STRING)              Γöé     Γöé  1(1)  Γöé    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé (1) Only one of these three attributes is present.                   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 OM_ARBITRARY_ENCODING                     This attribute is a representation
                                           of the data value as a bit string.

 OM_ASN1_ENCODING                          The data value. This attribute can
                                           be present only if the data type is
                                           an ASN.1 type.

                                           If this attribute value's syntax is
                                           an Object syntax, the data value's
                                           representation is that produced by
                                           om_encode when its Object parameter
                                           is the attribute value and its Rules
                                           parameter is ber. Thus, the object's
                                           class must be one to which om_encode
                                           applies.

 OM_DATA_VALUE_DESCRIPTOR                  This attribute contains a
                                           description of the data value.

 OM_DIRECT_REFERENCE                       This attribute contains a direct
                                           reference to the data type.

 OM_INDIRECT_REFERENCE                     This attribute contains an indirect
                                           reference to the data type.

 OM_OCTET_ALIGNED_ENCODING                 This attribute contains a
                                           representation of the data value as
                                           an octet string.


ΓòÉΓòÉΓòÉ 15.2.3. OM_C_OBJECT ΓòÉΓòÉΓòÉ

The class OM_C_OBJECT represents information objects of any variety. This
abstract class is distinguished by the fact that it has no superclass and that
all other classes are its subclasses.

The attribute specific to this class is listed in "Attributes Specific to
OM_C_OBJECT".

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 54. Attributes Specific to OM_C_OBJECT                      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé              Γöé                  Γöé  VALUE Γöé  VALUE Γöé VALUE Γöé
Γöé ATTRIBUTE         Γöé VALUE SYNTAX            Γöé LENGTH Γöé NUMBER Γöé  INI- Γöé
Γöé              Γöé                  Γöé     Γöé     Γöé TIALLYΓöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OM_CLASS         Γöé String(OM_S_OBJECT_IDENTIFIER   Γöé   -  Γöé   1  Γöé  -  Γöé
Γöé              Γöé _STRING)              Γöé     Γöé     Γöé    Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 OM_CLASS      This attribute identifies the object's class.


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

As permitted by ISO 3166.


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

These definitions are chiefly in The Directory: Selected Attribute Types (ISO
9594-6, CCITT X.520) and The Directory: Selected Object Classes (ISO 9594-7,
CCITT X.521) with additional material in The Directory: Overview of Concepts,
Models, and Services (ISO 9594-1, CCITT X.500) and The Directory:
Authentication Framework (ISO 9594-8, CCITT X.509).