Subject: OSF Distributed Computing Environment Frequently-asked questions
Supersedes: <dce-faq-1-826204082@mauney.com>
Date: 10 Apr 1996 12:34:18 GMT
Summary: Answers to frequently asked questions about
 the Open Software Foundation's Distributed Computing Environment (DCE).
 It provides a brief overview of what DCE is, pointers to sources of
 more information on DCE, and answers to common technical questions.

Posted-By: auto-faq 3.1.1.2
Archive-name: dce/faq
Revision: 1.13 1995/12/11 14:23:15
Posting-frequency: monthly

This is the long-awaited beta-test version of the new
DCE Turbo FAQ '95, converted to 3 tiers for scalability.
This being the first release of the new version, it is
your golden opportunity to catch omissions, misstatements
and outright blunders.  Please send your corrections and comments to
faq@mauney.com

  This document answers some Frequently Asked Questions concerning
  the OSF Distributed Computing Environment.
  It is posted monthly to comp.soft-sys.dce, as well as
  comp.answers, and news.answers.

The questions (and answers)  in this FAQ have been divided
into 3 tiers, for convenience, scalability, and because its
just the cool thing to do.

Tier 1, User support, contains general questions about DCE
Tier 2, Application support, contains technical questions about DCE
Tier 3, Data Management, contains pointers to further information
        about DCE

------------------------------------------------------------------
Tier 0 -- Header files

  The document is maintained by Jon Mauney, jon@mauney.com
  Suggestions, corrections, and updates are actively sought.

  This FAQ is available by anonymous ftp from
        ftp.dstc.edu.au in /pub/DCE/FAQ
  and is available for browsing at the OSF's WWW server.
        http://www.osf.org/dce/faq-mauney.html

  Last modified on December 9, 1995

-------------------------------------------------------------------
Tier 1 -- Front-end, user support

Q 1.01: What is DCE?
Q 1.02: What are the advantages of DCE?
Q 1.03: What platforms support DCE?
Q 1.04: What products use DCE?
Q 1.05: Is DCE an official standard?
Q 1.06: The DCE threads uses draft 4 of the standard, but
  Posix threads standard has moved beyond draft 4.
  Will DCE change to the most recent standard?
Q 1.07: Is anyone using DCE for real-life mission-critical systems?
Q 1.08: What is the relationship between DCE and CORBA?
Q 1.09: Is DCE IDL the same as all the other IDL's in the world?

Tier 2 -- Application support

Q 2.01: Several of the other questions concern "interfaces".
      What is meant by an interface in DCE RPC?
Q 2.02: Can a DCE client import multiple interfaces?
Q 2.03: Can a DCE client connect to multiple servers?
Q 2.04: Can a DCE server export multiple interfaces?
Q 2.05: Can a process be both a server and a client?
Q 2.06: How do I perform asynchronous RPC?
Q 2.07: How can a server keep track of multiple clients?
Q 2.08: How can a server detect that a client as exited or crashed?
Q 2.09: How can a server identify the client that has called it?
Q 2.10: How efficient is DCE RPC?
Q 2.11: What is the practical limit on the size of a DCE cell?
Q 2.12: How much memory and disk space is required for DCE services?
Q 2.13: Where can I find an ACL manager to include in my application?
Q 2.14: Is it possible for a machine to be a member of more than one DCE cell?
Q 2.15:  How do I configure cells to find each other using DNS?
Q 2.16: Is it possible for a user in one cell to use secure services
  in another cell? 
Q 2.17: Can I move idl-compiled stubs from one platform to another and rebuild 
      the object files locally?
Q 2.18: Does DCE Security interoperate with other Kerberos systems?
Q 2.19: Will Windows NT communicate with DCE?
Q 2.20: Can I use DCE from C++?
Q 2.21: Can I write an application that uses DCE and X11/Motif?
Q 2.22: How can I control the number of concurrent client connections
        and the size of the request queue on a server?
Q 2.23: My server gets a stack error when sending large objects.  How
       can I avoid this?
Q 2.24: Can I allow DCE clients and servers to communicate
        across a firewall?
        Can I control the endpoints assigned to DCE servers?
Q 2.25: How do I get clients to connect to the nearest server?
Q 2.26: How are UUIDs generated?  
Q 2.27: How can I pass a UUID as a parameter in an RPC?
        What is the format of a uuid_t structure?
Q 2.28: How can I pass a binding handle as an ordinary parameter in an RPC?
Q 2.29: Is DCE RPC compatible with ONC RPC?

Tier 3 -- Data management

Q 3.01: Where can I get online information about DCE?
Q 3.02: What books are published on DCE?
Q 3.03: Where can I get more information about DCE and DCE-related products?
Q 3.04: What are DCE RFCs, and how can I get them?
Q 3.05: Where can I get the Public Domain version of DCE?
Q 3.06: Is there a DCE Users Group I can join?
Q 3.07: Are there any example programs available on-line?


-------------------------------------------------------------------
The answers please:
-------------------------------------------------------------------
Tier 1 -- Front-end User Support
==================================================================

Q 1.01: What is DCE?

A:

   DCE is the Distributed Computing Environment, from the
   Open Software Foundation. (It is called "the DCE" by sticklers
   for grammatical consistency.)

   DCE consists of multiple components which have been integrated
   to work closely together.  They are the Remote Procedure Call
   (RPC), the Cell and Global Directory Services (CDS and GDS), the
   Security Service, DCE Threads, Distributed Time Service
   (DTS),and Distributed File Service (DFS).  The Threads, RPC, CDS,
   Security, and DTS components are commonly referred to as the 
   "secure core" and are the required components of any DCE installation.
   DFS is an optional component.  DCE also includes administration tools
   to manage these components.

   DCE is called "middleware" or "enabling technology."  It is not
   intended to exist alone, but instead should be bundled into a
   vendor's operating system offering, or integrated in by a third-party
   vendor.  DCE's security and distributed filesystem, for example, 
   can completely replace their current, non-network, analogs.
   DCE is not an application in itself, but is used to build custom
   applications or to support purchased applications.

==================================================================
Q 1.02: What are the advantages of DCE?

A:

   First, DCE provides services that can be found in other computer
   networking environments, but packages them so as to make them
   much easier to use.  For example, the DCE Remote Procedure Call
   (RPC) facility provides a way of communicating between software
   modules running on different systems that is much simpler to code
   than older methods, such as using socket calls.
   
   Second, DCE provides new capabilities that go beyond what was
   available previously. The DCE Security Service provides a
   reliable way of determining if a user of a distributed system
   should be allowed to perform a certain action, for example.  This
   is very useful for most distributed applications, yet the design
   and implementation effort entailed in providing such a capability
   would be prohibitive for an individual developer.
   
   Third, DCE integrates components in a manner that makes them more
   valuable together than separately.  For example, the DCE RPC uses
   threads in such a way that a developer can implement a
   multi-threaded server without ever explicitly creating or
   destroying a thread.
   
   Finally, DCE supports both portability and interoperability by
   providing the developer with capabilities that hide differences
   among the various hardware, software and networking elements an
   application will deal with in a large network.  For example, the
   RPC automatically converts data from the format used by one
   computer to that used by another.
   
   Portability is a measure of the ease with which a piece of
   software that executes on one type of computer can be made to
   execute on a different type of computer. Interoperability is a
   measure of the ability of computers of different types to
   participate in the same distributed system.
==================================================================
Q 1.03: What platforms support DCE?

A:

  DCE is supported on most Unix platforms and many non-Unix platforms.
  Most vendors support at least the "secure core" which means all of the
  DCE services except the Distributed File Service and X.500 interface
  to the Global Directory Service.

  Some products are client-only, which means that the actual servers
  for the DCE services are not provided: Directory Service, Security
  Service, Time Service. Client machines can use these services,
  they simply cannot run the server programs;  another machine
  in the cell must run the server programs.  Application programs
  can be built and run the application servers on these "client-only"
  systems.

  This table summarizes the DCE implementations currently available:
   (This information changes frequently; check with the OSF or
   specific vendors for the latest details. Updates to this list
   are solicited)
  
   -------------------------------------------------------------
   Platform                     Comments
   -------------------------------------------------------------
Unix platforms:
   DEC-OSF/1 on Alpha AXP:      Secure core and DFS
   Ultrix                       "Starter kit"
   HP-UX:                       Secure Core and DFS 
   DG/UX                        Secure Core and X.500
   AIX:                         Secure core and DFS
   SunOS,                       Secure Core, X.500
   Solaris:                     Secure core and DFS
                                Implementation by Transarc, also re-sold by Sun
   Irix                         Secure Core
   SCO                          Secure Core was expected by August 1994
   AT&T GIS, SVR4 on Intel      Secure Core
   Sinix (Mips and Intel)       Secure Core, DFS, and X.500
   Stratus XA/R                 Secure Core developers kit
   Cray Unicos                  Secure Core Client, and DFS server
   System V on Intel            Secure Core, avail. from Gradient Technologies
   Pyramid DC/OSx (SVR4)        Secure Core
   Hitachi HI-OSF/1-MJ (osf/1)  Secure Core, with Japanese on-line doc
   Hitachi HI-UX/WE2            Secure Core
   Sony NEWS (SVR4)             Secure Core
   Fujitsu DS/90 (SVR4)         Secure Core
   Unixware...Secure Core, from Gradient
   Sequent
Non-Unix platforms:
   Tandem NonStop Kernel        Secure core
   OpenVms (Vax, and Alpha AXP) Secure core 
   Microsoft Windows:           Client-only, avail. from Gradient Technologies
                                   Gradient's port is also sold by Siemens,
.                           IBM, and Digital.
                                Unimetrics has announced DFS client products
                                   for Windows
   Macintosh                    Gradient has announced that their secure-core
                                product will begin early availability
                                "around the holiday season" 1995.
....Open Environment Corporation has a Macintosh
....client that allows access to DCE servers by
....way of an OEC server on another machine.
   Windows NT:                  out-of-the-box, NT contains a
                                subset of DCE RPC.
                                        See Q 2.19 for further discussion.
....Gradient has full secure core DCE for NT
                                Digital Equipment Corporation has
                                  a DCE client available today, and has
                                  announced intent to support full DCE
   Windows 95...Digital is porting their DCE product to Win95
                                Gradient has secure core
   OS/2:                        Secure core
   HP 3000 with MPE/iX          Limited availability, general availability
                                projected for mid '95
   VM                           Kapsch AG supports DCE client and the
....  security server on IBM's VM and VM/ESA
   VM/ESA                       IBM has announced intent to support 
                                  "selected components" of DCE on VM/ESA
                                Kapsch AG supports DCE client and the
....  security server on IBM's VM and VM/ESA
   MVS                          client only
   IBM AS/400                   client only 
   BS2000                       Client Only
   Bull DPX/20                  Secure Core, X.500, DFS
   GCOS on Bull DPS 9xxx/7xxx   threadless client only
   
==================================================================
Q 1.04: What products use DCE?

A:

   The OSF has a living document called DCE Product Listing.  It contains
   information pertaining to products and services related to DCE 
   technology.
   The list is available on-line at http://www.osf.org/comm/lit/dce-prod-cat
   To receive a paper copy or to add a product or service to the 
   listing contact:
      DCE Product Listing
      c/o Open Software Foundation
      11 Cambridge Center
      Cambridge, MA  02142
      Fax - +1.617.225.2782
      ellen@osf.org


==================================================================
Q 1.05: Is DCE an official standard?

A:

   OSF calls the specification an Application Environment Specification,
   or AES. The  AES documents both the software programming interfaces and 
   also the communications protocols employed by DCE.  Thus it would be
   possible, in theory, for someone to build a compatible
   implementation without using the code from OSF.
   The AES for RPC, Time, and  Directory services have been accepted as 
   standards by by X/Open.  The AES for Security is currently undergoing
   review.
      
   DCE Threads follow the Posix Threads draft standard 1003.4a draft
   4.  DCE Access Control Lists (ACLs) are based on POSIX.6 Draft
   12.  The Distributed Time Service (DTS) uses time formats defined
   by international standards and in POSIX.4.  The Global Directory
   Service (GDS) complies with the X.500 international standard.
   (Although DCE complies with the 1988 version of X.500, not
   the 1992 version.)

   ISO is considering an RPC standard based on the X/Open document.
   
   DCE's status as a de facto standard is even stronger.  Almost
   every major hardware and software vendor has committed to
   providing DCE on its platform.  These vendors include not only
   OSF stalwarts such as IBM, DEC and HP, but also other key vendors
   such as Novell, Inc.  See Q 1.03 for a list of DCE vendors.  In addition,
   a number of major user organizations (e.g., the European Economic
   Community) have already embraced DCE as their standard for
   distributed applications.

==================================================================
Q 1.06: The DCE threads uses draft 4 of the standard, but
  Posix threads standard has moved beyond draft 4.
  Will DCE change to the most recent standard?

A:

   It is hard to predict exactly what will happen. 
   But OSF prefers to follow standards rather then invent them. 
   Once the threads document is approved as a standard, it would be
   obvious for the DCE to migrate to it.

==================================================================
Q 1.07: Is anyone using DCE for real-life mission-critical systems?

A:

   Yes, and more every day.  Tokio Marine and Fire Insurance,
   Co., Lehman Brothers, and Charles Schwab have all publically
   described their ongoing rollout of DCE based applications.

   OSF's Web server has a section that includes some reports on 'real-world'
   experiences from companies using DCE in production.

   Intellisoft published a  48-page "advutorial" (that
   means advertisement and tutorial) with the help of
   many DCE vendors, totally devoted to the above. There are storeis about
   DCE in production, technical essays, etc. 
   The supplement is on-line and available via Intellisoft's web site
   (http://www.isoft.com -- click on "DCE and The Enterprise" ).

   Transarc's web server includes a page in which they describe solutions
   used by some of their customers.
   http://www.transarc.com/Public/ProdServ/Solutions/index.html  

==================================================================
Q 1.08: What is the relationship between DCE and CORBA?

A:

  The short answer:  

       There is not a lot of direct relationship.  DCE and CORBA
       are tools to help you build distributed systems.  Each has
       its advantages and disadvantages.  Use of one will not 
       hinder future use of the other.

       DCE provides a lower-level programming model than does CORBA.
       DCE is not fully "Object-Oriented".  DCE has far better
       inter-operability than (current) CORBA products.
       DCE is an optional interoperability mechanism in the
       CORBA 2.0 specification.

  The long answer:
     In order to understand the relationship between DCE and the Common
     Object Request Broker Architecture (CORBA) of the Object Management
     Group (OMG), it is necessary to consider the past, the present and the
     future.

   Past - Historically, the object paradigm has been viewed as a break
     with procedural styles of the past.  Objects, which encapsulate data
     and procedures behind an external interface, are often contrasted with
     other approaches where procedures and data are treated separately.

     In this context, DCE is a descendant of the procedural school which
     emphasizes the decomposition of programs into procedures and achieves
     distribution by locating some of those procedures remotely.  Thus there
     was a tendency for the object community, including the OMG, to view DCE
     as technology which was obsolete before it was available.

     However this view ignored the fact that designers of distributed
     systems had for a long time recognized that the most successful
     approach to developing distributed systems was to created encapsulated
     objects that can only be accessed via well defined interfaces.  Thus
     the cornerstone of DCE RPC is the interface definition language (IDL)
     which allows the external attributes of a set of server operations to
     be specified.

     Furthermore, the name-based binding mechanisms of DCE were extended to
     include the ability to bind to a server based on the object instances
     which it supports.  These object binding mechanisms also allow the
     transparent selection among multiple implementations of the same server
     operations based on the type of the specified object.  In object
     terminology this is called polymorphism.

     The DCE notion of a server supporting interfaces consisting of one or
     more operations is so close to the notion of an object which provides
     one or more methods, that it should be no surprise that CORBA defines
     an IDL which differs from DCE IDL in only a few significant respects.

     Principal among these is that in CORBA IDL every call must specify an
     object, which is used in determining the server to use.  DCE can do
     this as well, but there is more work involved and it is optional.
     Another difference is that CORBA IDL allows an interface to be defined
     as a extension of one or more other interfaces, this is called
     interface inheritance.  DCE does not permit interface inheritance, but
     may in the future.  Implementation inheritance is not specified by
     either DCE or CORBA.

     The use of object oriented techniques and principles should not be
     confused with using an object oriented language.  Object oriented
     designs can be expressed in procedural languages, and in fact most of
     the current object environments supported C before supporting C++ or
     Smalltalk.  Therefore, the fact that the DCE API is implemented in C is
     no barrier to using it to create a distributed object system.  In fact,
     CORBA specified C language bindings first.

   Present - CORBA should not be viewed in isolation, but in the context
     of all of the OMG's standardization efforts.  OMG has defined a
     reference architecture (OMA) and has defined or is defining standards
     in a broad range of areas, including: databases, events, lifecycle,
     transactions, persistence, security, naming and relationships.  Viewed
     in this way, OMG's activities are much more ambitious and broader in
     scope than DCE.

     A recent addition to CORBA, as a part of the CORBA 2.0 work was the
     definition of the means of interoperability between ORBs.  CORBA 2.0
     defines one mandatory and two optional mechanisms.  The mandatory means
     is a new, lightweight protocol called UNO.  The optional means are 1)
     via a gateway and 2) via an alternative protocol definition.  At the
     present the only alternative protocol that has been defined is DCE
     RPC.

     Many people who had hoped that DCE would be selected as the mandatory
     protocol were disappointed at this result.  However, it should be
     observed that DCE is endorsed as alternative protocol and that several
     vendors have committed to providing ORBs that interoperate via DCE.

     Another difference between DCE and the OMG standards is one of general
     philosophy.  DCE has been defined quite rigorously in a series of
     documents published by X/Open.  There is a set of conformance tests
     that are available to anyone.  Any product passing these rigorous tests
     can be branded as DCE, without necessarily being based on the OSF
     code.  Several vendors, including Microsoft and Tandem have reverse
     engineered significant portions of DCE.

     OMG standards vary considerably in their level of detail, but in
     general, aim at a much looser level of standardization.  In some cases,
     the standard merely specifies an object interface and some general
     semantics.  This approach is a deliberate attempt to encourage diverse
     solutions which may be applicable in different environments.  Even
     where specifications are relatively tight, for example in the area of
     CORBA portability, there is still room for considerable interpretation,
     as witness the fact that there is at least one company that provides
     consulting services on how to make CORBA applications compliant in
     practice.

     At the present time, CORBA-compliant products and products that work
     with them do not provide a scaleable infrastructure suitable for large
     environments.  Key features such as concurrency mechanisms, security
     and distributed transactions are not currently available.  In contrast,
     DCE provides proven heterogeneous interoperability and most of the
     capabilities required by robust, production applications.  Additional
     capabilities can be obtained by means of third products, such as
     transaction monitors built upon DCE.  This situation will change over
     the next 2-3 years from a combination of standardization work by OMG
     and new product development by vendors.

   Future - Most authorities agree that in the long term object technology
     will be the basis for building large scale distributed systems.  In
     addition to the principle of encapsulation, object- based systems allow
     systems to be built up, evolve and be reconfigured as needed because of
     their ability to dynamically bind requesters to objects that provide
     services.

     There are many specific issues concerning the properties of distributed
     object systems that are the subject of research and debate.  It is also
     clear that there are some features of existing local object
     environments and languages that will not scale effectively to large
     scale distributed systems -- dynamic inheritance is one. Never the
     less, the general direction of the future is clear.

     Clearly, the high level of interest in OMG defined standards comes not
     from current products, but from their exciting future potential.  There
     is a natural tendency to compare DCE's current capabilities with the
     promise of CORBA's future.  However, DCE is also evolving and will
     likely add additional object oriented features in the future.  For
     example, HP is offering a DCE C++ class library which is expected to
     eventually become a standard part of DCE.

     Where DCE was built by integrating existing software, OMG has chosen by
     and large to start with a clean sheet of paper.  The idea is to be
     better able to implement object oriented constructs without the baggage
     of features carried over from previous systems.  However, OMG faces
     great challenges.  Object theory is currently in a great state of
     flux.  Experts disagree on very fundamental issues about what features
     are necessary, useful or harmful.

     Developing standards under these conditions is extremely challenging.
     OMG's approach to date has been to compromise and allow multiple
     alternatives.  It is unclear whether this will succeed in the long
     run.

     Does the conclusion that future distributed systems will be object-
     based mean that it is a mistake to build distributed systems today
     using DCE?  The answer is no for several reasons.  First, many
     organizations cannot afford to do nothing for several years.  End users
     have pressing needs for robust, scaleable systems today.  For many
     organizations, waiting would mean attempting to catch up with
     competitors who will have a tremendous head start.

     Second, as this brief discussion has shown, it is possible to employ
     object techniques when developing distributed applications using DCE.
     Carefully designed systems will be able to take advantage DCE features
     such as dynamic binding and polymorphism and converge with
     CORBA-compliant systems as they mature.

     Third, if object environments are to be successful in supporting
     industrial-strength distributed systems, they will have to address the
     problems that DCE addresses.  The skills and techniques developed in
     working with DCE will be directly applicable to distributed systems
     environments of the future.  This applies not only software developers,
     but also to operations personnel, planners, even business managers.

     Further, the likelihood that DCE will be at least one technology for
     CORBA interoperability, implies that the eventually migration of
     applications which use DCE directly to an object environment should not
     present any insurmountable difficulties.

     Finally, your direct experience in developing and operating robust
     distributed systems will provide you with great insight into the
     important characteristics of distributed systems environments as they
     apply to your organization's applications.  This knowledge is vital to
     the shaping of successful tools of the future.  History has shown that
     vendors and standards bodies, left to their own devices, will often
     miss the mark.

==================================================================
Q 1.09: Is DCE IDL the same as all the other IDL's in the world?

A:

    No.

    IDL stands for "Interface Definition Language," and the idea
    of using a special language to define the interface between
    entities is not unique to DCE.  In particular, CORBA's IDL
    is used for the same purpose as DCE's, but the two languages
    are not identical; see Q 1.08 for more information.  There are
    other Interface Definition Languages as well.
    IDL also stands for "Interactive Data Language", which
    is a completely unrelated product.

    When asking or answering a question about IDL, one should be
    careful about specifying which IDL is involved.


-------------------------------------------------------------------
-------------------------------------------------------------------
Tier 2 -- Application Support

==================================================================
Q 2.01: Several of the other questions concern "interfaces".
      What is meant by an interface in DCE RPC?

A:

   An interface is a set of remote procedure call operations and
   associated data.  Every interface contains one or more
   operations.  An operation is an actual remote procedure.  Each
   operation may have input and output parameters associated with
   it, just like any procedure call.

==================================================================
Q 2.02: Can a DCE client import multiple interfaces?

A:

   Yes. A client can use as many different services as it needs.
   To code such a client, simply include the header files for
   all the RPC interfaces used, and code each call the same way
   you would if using that interface in isolation.

==================================================================
Q 2.03: Can a DCE client connect to multiple servers?

A:
        
   Yes. A client can connect to multiple servers providing different
   services, and/or multiple servers providing the same service.
   
   To use multiple servers with the same interface, the client must
   obtain a binding handle for each server and use explicit handles
   in the RPC.
   
==================================================================
Q 2.04: Can a DCE server export multiple interfaces?

A:
        
   Yes. A server can provide service on multiple interfaces
   simultaneously.  A common example is a server which exports an
   application interface and a management interface.

   To code such an application, repeat the calls to rpc_server_register_if(),
   rpc_ep_register(), (and rpc_ns_binding_export() if you do that sort
   of thing in your server) for each interface, before calling
   rpc_server_listen().
   
==================================================================
Q 2.05: Can a process be both a server and a client?

A:

   Yes.  There are two scenarios.
        1) A program might act as a server for interface A,
          and also as a client for interface B.  This is easy.
          The program merely imports interface B like a normal
          client and exports interface A like a normal server.
        2) A program might want to provide a service, and also
          act as a client to other servers that provide the same
          service.  In this case, the programmer must expend more
          effort.  The problem is that the names of the server-side
          functions (manager routines) clash with the names of the
          client stubs.  The solution is to manually build an
          entry point vector for the server, and use different names
          for the manager routines. For  details on using entry point
          vectors, see the Lockhart book (Q 3.02).
    Note that most server programs also act as clients, since they
    usually access the endpoint mapper (rpcd), and the security
    service;  these actions use RPCs, though it may not
    be obvious in the code.

==================================================================
Q 2.06: How do I perform asynchronous RPC?

A:

   DCE-RPC is synchronous. The way to make an asynchronous call is
   to create a thread for each RPC call.  You should be able to have
   dozens, if not hundreds, of threads with no problem.
   
==================================================================
Q 2.07: How can a server keep track of multiple clients?
      For example, to know what information has already been
      provided to a client, and thus vary subsequent responses.

A:

   The DCE RPC mechanism includes a "context handle" which can be
   created by a server and returned to a client.  The handle is used
   on subsequent RPCs to identify the client.
   
==================================================================
Q 2.08: How can a server detect that a client has exited or crashed?

A:

   The context handle provides this ability.  When a context handle
   is created and passed to the client, the DCE runtime library
   keeps track of the connection between client and server;
   this may be done in the network code as in the case of TCP,
   or by DCE-specific ping messages if a connectionless protocol is used.
   When the client dies, the server is notified and executes a "rundown"
   function to clean up its data structures.
   
==================================================================
Q 2.09: How can a server identify the client that has called it?

A:

  The details vary, depending on exactly what you want to
  identify about the client, but it all comes down to handles.
  The server must receive a binding handle in order receive
  information about the client.  If there is not a binding
  handle in the parameter list as defined in the IDL file, then
  use the [explicit_handle] attribute in the ACF file to add
  one when building the server.

  If you want to identify the host machine on which the client
  is executing, simply convert the binding handle to a string
  binding using rpc_binding_to_string_binding() and then
  extract the address using rpc_string_binding_parse().
  When the server receives the handle, it contains the client
  address.

  If you want to identify the human user who is running the client program,
  you can get that from the authentication information in the handle.
  rpc_binding_inq_auth_client() will give you the caller's PAC,
  which contains, among other things, the principal's  uuid
  and name.

  If you want to identify the particular client process so your
  server can keep data specific to each client, then you need
  to look into context handles as described in q 2.07.
   
==================================================================
Q 2.10: How efficient is DCE RPC?

A:

  Performance testing at several user organizations has shown that
  DCE RPC performance is similiar to other RPC implementations when
  doing the same things.  The throughput and response times for a
  series of remote procedure calls is similiar.
  
  The use of features in DCE not present in other implementations
  may consume additional time and resources.  For example,
  name-based binding may required additional time, depending on the
  number of directories traversed.  Using the packet integrity and
  packet privacy features of the security service can increase
  processing times as a linear function of message sizes.

  There are three papers providing preliminary performance data
  published in:
     DCE--The OSF Distributed Computing Environment, 
     Lecture Notes in Computer Science #731, Springer-Verlag,
     (see Q 3.02 for ISBN)

  IBM has done quite a bit of performance testing of DCE.  Many
  of the reports are available on line; go to IBM's corporate
  Web page, http://www.ibm.com, and choose the search feature to
  search for something like "dce performance".  To summarize a few
  of the results in these reports:
     RPC time increases linearly with the size of the data.
     Passing a large array in one RPC call is about the same speed
        as using a pipe
     Passing a large array in several RPC calls is slower than
        a single call using a pipe
     The "packet integrity" security level slows the RPC, nearly
        doubling the total time for calls.
     The "packet privacy" level incurs a several-fold increase in time.
     RPC is slower than simply making socket calls directly.
     The time spent on RPC overhead was a small fraction of the total
        processing time in a realistic business scenario.
     RPC is pretty fast on Intel procesors (running OS/2).

==================================================================
Q 2.11: What is the practical limit on the size of a DCE cell?

A:

  Good question.  It is still a bit early to have good practical
  experience with large-scale DCE installations.  But there are
  some large-ish cells in operation.
  
  Certainly it is reasonable to plan on cells with thousands of
  nodes and perhaps tens of thousands of users.

  The University of Michigan Center for Information Technology
  Integration has done a study in which they added 50,000 entries
  to the Cell Directory and to the security registry.  Their results
  are reported in technical reports 93-12 and 94-1.  See Q 3.01 for
  the ftp site for CITI tech reports.
  
  IBM's DCE performance testing (see Q 2.10 above for citation)
  includes load testing to simulate the environment of a large cell.
  A short, oversimplified, summary is that server machines based
  on 486/66 and P90 (running OS/2) could support the projected needs
  of a cell with 10,000 users.  You'll have to extrapolate for
  beefier servers and cells.

==================================================================
Q 2.12: How much memory and disk space is required for DCE services?

A:

  This depends on the size of the cell, the number of users,
  number of services, etc.

  According to a paper present by Dan Hamel of Transarc, at the
  Decorum conference in February 1994, the following can be used
  as rough guidelines:
    Security server: 2k per principal/account
                     same at replicated sites
    Directory server: 10k per directory, 1k per object
                      same at replicated sites
    end-user machines: Each dce_login creates new credential files,
                      which can build up.  Space usage can range
                      from less than 1k to over 100k. 

==================================================================
Q 2.13: Where can I find an ACL manager to include in my application?

A:

    DCE version 1.1 includes a basic ACL manager library.

    HP's OODCE (DCE C++ class library) provides you with a default, 
    built-in ACL Manager with the server class.

    Transarc's Encina (transaction monitor) product includes
    an ACL manager.

    Lockhart's book contains a sample ACL manager. (see Q 3.02)

==================================================================
Q 2.14: Is it possible for a machine to be a member of more than one DCE cell?

A:

   No.  A machine can only be in a single cell. However, it is
   possible for cells to cooperate.  See the next question.

   DCE v1.1  will allow for "hierarchical cells", which may 
   solve the problem, depending on why you want to have a machine
   in two cells.

==================================================================
Q 2.15:  How do I configure cells to find each other using DNS?

A:

  In order for a client program in cell A to find a server in cell B,
  it must be able to find the CDS server in cell B;  once communication
  with CDS is established, everything else in the cell can be found.
  One of the ways to make the location of of the cell known is to
  create the proper entries in the Internet Domain Name Service (DNS).

  Suppose we want to make a cell available, and that the name
  of the cell is "/.../cell.mauney.com".  We must create
  two DNS entries.  One entry will provide the IP address of
  the machine that runs the CDS server within the cell.
  The other entry gives other details about the cell.

  The first entry, which advertises the location of the CDS server,
  can be either an MX or an AFSDB record type.  The DCE code
  will be happy to use either one, but you as a system administrator
  have to make a choice; both possibilities have drawbacks.
  The MX record type is intended for mail exchange, so using it
  for DCE is a bit of a kludge; and if you already
  have a machine in your name with the same hostname as your cell
  name and it ever participates in e-mail, then you'll have a conflict.
  On the other hand, the AFSDB record is new and not supported by
  all nameservers; you'll need Bind version 4.9.2 or later.

  The MX or AFSDB record relates the cell name to a host name.
  DCE ignores the "preference" value of an MX record.  With AFSDB,
  you should use sub-type 2.  E.g.,
    cell.mauney.com.  IN MX  200 tophat
  or
    cell.mauney.com.  IN AFSDB  2 tophat
  where "tophat" is the hostname of the machine that runs the CDS master
  server.

  The second piece of information in DNS is a TXT record giving
  UUIDs for the CDS master replica and clearinghouse.  You obtain
  the information with the command "cdscp show cell as dns", and
  copy the information verbatim into DNS.  E.g.
    cell.mauney.com.  IN TXT "1
44007e75-08b4-11ce-9055-08002b32b23b Master /.../cell.mauney.com/tophat_ch  43373550-08b4-11ce-9055-08002b32b23b tophat.mauney.com"

  
==================================================================
Q 2.16: Is it possible for a user in one cell to use secure services
  in another cell? 

A:

  Yes.  The Access Control List (ACL) permits three entry types --
  foreign_user, foreign_group and foreign_other -- which specify the
  permissions available to users on other cells.  All that is
  required for intercell access, other than physical connectivity,
  is for the two cell's security services to be configured to know
  about each other.
  There is a command, the rgy_edit "cell" command, that must be run, once,
  by the cell admin of the two cells that wish to communicate.  After
  that, it's all transparent.

==================================================================
Q 2.17: Can I move idl-compiled stubs from one platform to another and rebuild
      the object files locally?

A:

    No.  You must run the IDL compiler separately on each platform.

    The IDL compiler builds the client and server stubs to handle
    network communication and data marshalling, which are platform-
    specific activities.  Therefore the stub code is not portable
    and must be re-created on each platform.  Likewise, while the
    task of the stub does not change, the set of service routines
    called from the stub may be changed by the vendor for any given
    platform.  Therefore stubs for the same RPC may look very different
    on different platforms.

==================================================================
Q 2.18: Does DCE Security interoperate with other Kerberos systems?

A:

  Basically, no, or maybe yes, depending on what you want to do.

  To use authenticated DCE services, you must have credentials from
  the DCE security service; vanilla Kerberos v5 tickets aren't sufficient.
  But then, to use DCE services you must be using DCE RPC, so this
  is not really a problem.

  Going the other way, it is expected that a DCE security server
  can issue tickets that can be used by vanilla Kerberos applications.
  The OSF was wary of promising this until the Kerberos v5 specs were
  published, but now that the Kerberos RFC has been published, OSF
  anticipates guaranteeing interoperability sometime "soon".

  In a little more detail, the way to think about this is as follows:

        Kerberos offers 2 services (Authentication Service, Ticket
        Granting Service) over 1 communication mechanism (UDP port 88).

        DCE security offers 3 services (AS, TGS, Privilege Service) over
        2 communication mechanisms (UDP port 88, RPC).

        Where Kerberos and DCE security intersect (AS, TGS over UDP port
        88), the services are identical.

  DCE V1.1 supports the GSSAPI, so non-DCE services that use GSSAPI
  can be integrated with DCE security server.

==================================================================
Q 2.19: Will Windows NT communicate with DCE?

A:

   Windows NT comes with an RPC which interoperates with DCE RPC.
   Windows 95 apparently provides this interface as well.
   However, it is not quite the same as DCE.

   The wire-level protocol is the same as DCE RPC, so applications
   running on NT can communicate with DCE applications on other
   platforms.  However, the application source code is not instantly
   portable.  Microsoft changed the format of procedure names
   and moved the status result from a parameter to the function value.
   This kind of change can be covered up by a set of preprocessor
   macros, but it is a change to be dealt with.

   A more serious consideration is that Microsoft's RPC does not
   use the standard DCE services, such as directory service and security.
   Thus applications that cross between Microsoft RPC and DCE will have
   to make unauthenticated calls and use string bindings.
   Digital bundles a Name Service Interface Daemon (nsid) into its
   DCE products.  The nsid fills in the gap and allows an NT client to
   get bindings from CDS.

   See the book "Distributing Applications Across DCE and Windows NT" 
   for more details (see Q 3.02).
   
   The good news is that DEC and Gradient both have DCE
   products for NT. Digital has a DCE client product available
   for both Intel and Alpha architectures.  Gradient has a full
   secure core product.

   Information on Digital's DCE on NT product is available at
          http://www.digital.com/info/Customer-Update/940412019.txt.html
   Information from Gradient can be obtained by sending email to
   info@gradient.com or at their Web site:
.  http://www.gradient.com/store.htm

==================================================================

Q 2.20: Can I use DCE from C++?

A:

   Yes.  First of all, since you can call C functions from C++
   you can access all the DCE services from a C++ program.  But
   that will not give you the benefits of C++.

   There are several packages that provide a C++ interface to DCE.
   They different quite a bit in style and approach, so you'll
   need to consider them carefully in light of your own needs and
   preferences.

   Objtran was produced by Citibank, and is available by anonymous
   ftp at ftp://wilma.cs.brown.edu/pub/Objtran.tar.Z

   HaL Computer Systems has a system called DCE++.  It is available
   for free, but requires a license agreement.  For more information
   retrieve the file ftp://ftp.hal.com/dce++/license, or
   send email to arjun@hal.com

   Hewlett-Packard has a product called OODCE.  It is for sale,
   and currently supported only on HP-UX.  For technical information
   retrieve the OSF RFC #49 (see Q 3.05);  for sales information
   contact your HP sales office.

   Transarc's Encina v2.0 includes Encina++, C++ support for Encina and DCE.

   Support for C++ is expected to be included in DCE version 1.2,
   although it will take quite some time before products based
   on 1.2 are generally available.

==================================================================

Q 2.21: Can I write an application that uses DCE and X11/Motif?

A:

  Yes but there are several serious pitfalls.

  The X11/Xt/Motif libraries may not be thread-safe.  For example,
  suppose one thread calls a function in Xt, which calls a nonthreadsafe
  malloc(), which then gets preempted.  The next thread may call
  a threadsafe malloc() that comes with DCE. When control returns to 
  the first malloc(), any assumptions about the state of the heap are
  invalid.
 
  Also, Motif/Xt/Xlib are not currently reentrant wrt/themselves.  You can't 
  have multiple threads concurrently manipulating any Motif/Xt/Xlib 
  global state. Fortunately this issue is under you control when 
  designing the application.  X11R6 includes a thread-safe version of
  Xlib, but it will be a while yet before the vendors are all delivering
  thread-safe Motif.
  
  A related issue is that XtAppMainLoop() waits in a select() for activity,
  coupled with the fact that DCE also waits in a select() for activity.
  Unless the two are select()s are cooperating, one or the other will be
  starved. This is a platform-specific issue, you should check with your
  DCE vendor for full details.  
  If it is a problem in your environment, the standard solution is to
  encapsulate the GUI in one process, the DCE client code in another process,
  and connect them with a simple IPC such as a Unix pipe.


==================================================================
Q 2.22: How can I control the number of concurrent client connections
        and the size of the request queue on a server?

A:
  
  The rpc_server_listen() call creates a pool of threads to
  handle incoming RPCs.  The server can be actively working on
  at most this many RPCs simultaneously.  The size of the pool 
  is controlled by a parameter to rpc_server_listen.  This is
  the primary place where you are expected to control the number
  of simultaneous connections.

  If you want to go deeper, into the question of what happens
  when all the server-listen threads are busy, things become
  tricky, because there are so many factors affecting the answer.

  If all the server threads are currently busy, incoming requests
  will be queued by the RPC runtime.  There is not an explicit
  API for controlling the size of this queue.  The rpc_use_protseq*()
  calls have a "max calls" parameter, but its effect is murky and
  it may be ignored completely by the implementation.

  If the RPC queue is full, the runtime will not accept any more
  network messages.  Incoming requests will therefore be held at
  the network protocol layer, which maintains a queue of its own.
  If the network layer's queue is full then the incoming message will
  be rejected and the client will be told that it is unable to connect
  to the server.

==================================================================
Q 2.23: My server gets a stack error when sending large objects.  How
        can I avoid this?

A:

  Each thread in a process is assigned a fixed area for its
  procedure-call stack.
  The stubs normally marshall and unmarshall parameters in space 
  allocated on the thread's stack.  If the parameters are large,
  the stack size may be exceeded.  In most thread implementations,
  the stack size cannot be increased after the thread is created.
  For threads created explicitly by your application, you can adjust
  the size of the thread stack by setting an attribute before calling 
  pthread_create().
  However, server threads are created automatically, so that method
  won't work; instead, call rpc_mgmt_set_server_stack_size() before
  starting the threads with rpc_server_listen().

  Another possibility is to use the [heap] attribute to have 
  some parameter types marshalled on the heap instead of the stack.

==================================================================
Q 2.24: Can I control the endpoints assigned to DCE servers?
  For example, to allow DCE clients and servers to communicate
  across a firewall?

A:

  Yes.

  You can, of course, assign well-known endpoints to all your servers,
  but that is a truly bad idea, and won't work for services that you
  don't have source code for (such as CDS and the security registry).

  The endpoint mapper will examine the environment variable
  RPC_RESTRICTED_PORTS and choose endpoints only in that range.
  You can make the range as small as necessary, and configure your
  firewall to pass traffic only to those ports.

  The format of RPC_RESTRICTED_PORTS is a list of settings, separated by
  colons.  Each setting is of the form protocol[lo-hi].  E.g.
  export RPC_RESTRICTED_PORTS=ncacn_ip_tcp[5000-6000]:ncadg_ip_udp[5000-6000]

==================================================================
Q 2.25: How do I get clients to connect to the nearest server?

A:

  It's not easy.  Currently, DCE gives essentially no help.

  For clients for which you have source code, you can use the
  rpc_ns_binding_lookup*() routines to search through the binding
  handles and apply some custom logic to finding a nearby server.

  For standard DCE services, such as CDS and security queries,
  you get a random server, which could be anywhere in the cell.
  For the security service, you might be tempted to set the
  BIND_PE_SITE environment variable and the file
  /opt/dcelocal/etc/security/pe_site to hardwire each client host
  to its nearest security replica, but this is a hack with serious
  administrative downside: if the replica goes down or is moved,
  all the associated clients must be manually updated.

==================================================================
Q 2.26: How are UUIDs generated?  

A:

  The DCE AES specifies the method for generating UUIDs, in case
  you want the gory details.  In short, the UUID is a combination
  of the network address and current time at the moment and place
  it was generated.  Assuming that network addresses are unique
  and that time never runs backwards, this guarantees that UUIDs
  really are unique.

  Some implementations of uuidgen use the hardware address of the
  ethernet adapter, some use the IP address of the host.

  It is possible to run uuidgen on machines without any network
  connection.  In this case, the host must be assigned an address.
  The AES specifies a file that can hold the network address.

==================================================================
Q 2.27: How can I pass a UUID as a parameter in an RPC?
         What is the format of a uuid_t structure?

A:

  The uuid_t structure is defined in <dce/uuid.idl>
  All you have to do is import this into your .idl file
  and pass parameters of that type all day long.

  Note that uuid's passed as parameters are just ordinary data.
  If you want the uuid to affect the interface or object
  in the rpc, they must be attached to the binding handle.

==================================================================
Q 2.28: How can I pass a binding handle as an ordinary parameter in an RPC?

A:

  The binding handle is an opaque type and cannot be marshalled
  as data.  A parameter of type handle_t must be the first parameter
  and will serve to specify the binding of the RPC; an attempt
  to use a handle_t as other than the first parameter will be flagged
  as an error by the IDL compiler.

  To send a handle from one process to another, convert it to
  a string binding and pass the string as a parameter.

==================================================================
Q 2.29 Is DCE RPC compatible with ONC RPC?

A:

  No.  DCE and ONC both use the concept of the Remote Procedure Call,
  but the wire protocols that they use are not compatible.  You will
  need to use either DCE for both client and server, or ONC for
  both client and server;  both products are available for most platforms.

  It is possible for a single program to use both DCE and ONC.
  Thus a server could be built to server both DCE and ONC clients,
  or a gateway could be built to accept one kind of RPC and forward
  to a server of another kind.

-------------------------------------------------------------------
-------------------------------------------------------------------

Tier 3 -- Data Management


==================================================================
Q 3.01: Where can I get online information about DCE

A:

  First of all, the official documentation for DCE is not available 
  for anonymous ftp. But there are several sites providing
  lots of other information.  Here are some of the most useful:

  The Open Software Foundation maintains a WWW server with information
  about all the OSF products, including DCE. 
        http://www.osf.org/dce/index.html
  takes you directly to the DCE index.
  Highlights of the OSF's web server include a complete list of DCE
  products, the DCE Request for Comments documents (RFCs), the
  DCE product catalog (see Q 1.04) and a 
  hypertext version of the Frequently Asked Questions list.
 
  Project Pilgrim at the University of Massachussetts has a DCE homepage at
        http://info.pilgrim.umass.edu/pub/osf_dce/osf.html
  Their server provides a complete set of RFCS, searchable by http
  and also by gopher, at
        gopher://info.pilgrim.umass.edu/77/lib/.wais-sources/osf-dce-rfc.txt
  and a directory of contributed software, currently consisting of
  performance measurement utilities from Pilgrim, and book examples from
  O'Reilly&Associates.

  The Center for Information Technology Integration at the
  University of Michigan has several pieces of DCE information
  on their servers. The big attraction here is the set of
  CITI Technical Reports related to DCE, in gopher-searchable format.
  You can get to the tech-reports from the CITI homepage,
        http://www.citi.umich.edu
  or go directly to the gopher directory:
        gopher://citi.umich.edu/00/public/techreports
  CITI also offers the MVS DCE Users Group homepage
  (which is still under development). Included here
  are a set of IBM whitepapers on the subject, in postscript form.
        http://dcewww.citi.umich.edu:8080/mvsdce

  Transarc has some hints and examples available for anonymous ftp.
        ftp://grand.central.org:/afs/tr/public/ps/dce
  These are informal, practical discussions of how to handle real-world
  problems such as changing the IP address of the CDS server,
  implementing peer-to-peer RPC, handling key management, etc.

  Intellisoft's advutorial "DCE and The Enterprise"
  is on-line and available via Intellisoft's web site
  http://www.isoft.com 
 
 Many of the local DCE users groups maintain WWW pages.
  See Q 3.06 below, or http://www.osf.org/dce/ug-index.html
  for a list.

==================================================================
Q 3.02: What books are published on DCE?

A:

  Documentation on DCE should be suppiled with vendor products.  The
  OSF sells complete sets of documentation. The DCE set consists of 
  14 volumes and costs $525.  Documentation for version 1.1 is 
  available.
  The three volumes of specifications (AES) can be purchased separately
  for $100 (plus shipping).

    Order documentation in the US by contacting: 
    OSF Direct Channels
    Phone: 617-621-7300
    e-mail: direct@osf.org

    Contact OSF Direct in Europe, East Asia, and Africa
    at OSF's Brussels Office
        Open Software Foundation
        Avenue des Pleiades-laan 15
        1200 Brussels
        BELGIUM
    Phone: +32 2 772 8888, fax: +32 2 772 9228 

    Contact OSF Direct in the Pacific region at
        Open Software Foundation
        11-10, Kita-Aoyama 2-chrome
        Minato-ku, Tokyo 107
        JAPAN
    Phone +813-3479-4740; fax: +813-3479-4760


  The OSF documentation is also published by Prentice-Hall.  These
  books contain about the same material as the OSF manuals, but are edited
  to improve the presentation. 

        Introduction to DCE                     ISBN 0-13-490624-1
        DCE Administration Reference            ISBN 0-13-643818-0
        DCE User's Guide and Reference          ISBN 0-13-643842-3
        DCE Application Development Guide       ISBN 0-13-643826-1
        DCE Application Development Reference   ISBN 0-13-643834-2
        DCE Administration Guide
          Vol. 1, Introduction                  ISBN 0-13-176546-9
          Vol. 2, Core Components               ISBN 0-13-176553-1
          Vol. 3, Extended Services             ISBN 0-13-176561-2
        Application Environment Specification/Distributed Computing
          RPC Volume                            ISBN 0-13-043688-7

  Other books on DCE:
     Understanding DCE, by Rosenberry, Kenney, and Fisher
          O'Reilly, ISBN 1-56592-005-8
     Guide to writing DCE Appplications,2nd edition
          by Shirley,  Hu, and Magid
          O'Reilly, ISBN 1-56592-045-7
     Distributing Applications Across DCE and Windows NT,
           by Rosenberry and Teague
           O'Reilly, ISBN 1-56592-047-3
     DCE Security
          by Wei Hu
.  O'Reilly,  ISBN 1-56592-134-8
     DCE: A Guide to Developing Portable Applications
.  Michael T. Peterson
.  McGraw/Hill (Ranade Workstation Series)
.  ISBN 0079118003 (hard)
.  ISBN 0079118011 (paper)
     OSF DCE: Guide to Developing Distributed Applications,
          by H. W. Lockhart, Jr, 
          McGraw-Hill,(Ranade Workstation Series)
          ISBN 0-07-911481-4
     DCE--The OSF Distributed Computing Environment, Client/Server Model
       and Beyond; Proceedings of the International Workshop on DCE, 1993
       Lecture Notes in Computer Science #731, Springer-Verlag,
       ISBN 3-540-57306-2
  And for you German-speaking DCE-ers:
  DCE--Das OSF Distributed Computing Environment, Einfuerhrung und Grundlagen,
        by Alexander Schill, Springer-Verlag, ISBN 3-540-55335-5

==================================================================
Q 3.03: Where can I get more information about DCE and DCE-related products?

A:

  With WWW, access the URL: "http://www.osf.org/dce/index.html"

  The general response to any query of the form "Where can I get a _____ for
  DCE?" is "Contact direct@osf.org" (phone +1 617 621-7300).

    This mail list will reach the people at OSF that maintain contacts with 
    just about everbody that has a DCE product to sell.  You can get a listing
    of the vendors and their products.  These include DCE RPC debugging 
    environments, C++ toolkits, Visual-BASIC  development environments, etc. 

    This mail list also reaches the people at OSF that maintain the lists of 
    documentation available, both from OSF, and from outside OSF, about DCE
    (and about Motif, DME, and OSF/1).

  Transarc maintains a mailing, info-dce@transarc.com, which carries
  discussions about DCE.  (Transarc also has a list for Encina: 
  info-encina@transarc.com.)  For information on Transarc products, send
  mail to tsg@transarc.com.

  For Users of DCE on MVS, there is a mailing list:
        mvsdce-l@psuvm.psu.edu
  and a Web page (under construction):
        http://dcewww.citi.umich.edu:8080/mvsdce

==================================================================

Q 3.04: What are DCE RFCs, and how can I get them?

A:

    DCE RFCs are requests for comments for ongoing DCE development.  They
    are similar in concept to the Internet RFCs.  Nothing in there is
    promised from by OSF.  They are a formal way to pass ideas among DCE
    development partners.

    You can access them by WWW (or gopher) by:
        http://www.osf.org/dce/dce-rfc/
        gopher://info.pilgrim.umass.edu/77/lib/.wais-sources/osf-dce-rfc.txt


==================================================================

Q 3.05: Where can I get the Public Domain version of DCE?

A:

    In October 1994, Digital Equipment Corporation and Hewlett-Packard
    released into the public domain the RPC implementation used by DCE.
    This code includes the IDL compiler and the RPC runtime.  It does
    not include any of the other services: DTS, CDS, Security, DFS.
    In fact, it is not a sufficient base for a client machine, as it
    does not include the CDS, DTS, and security clerk processes that
    are normally required.

    The code is available on the Internet from several servers:
       ftp://ftp.digital.com/pub/DEC/DCE/PD-DCE-RPC.tar.Z
       http://www.pilgrim.umass.edu/pub/osf_dce/contrib/PD-DCE-RPC.tar.Z
       http://www.osf.org/dce/free-stuff/
    Be sure also to read the licensing information found in the
    same directories.

    The RPC code requires the available of Posix threads, draft 4.
    If your platform doesn't support Posix threads, a starting point
    can be found in:
       ftp://rtfm.mit.edu/pub/pthreads
    (but this code implements a later draft of the specification,
    so you have some work to do.)

    Be warned that building anything from this release is not a simple
    matter.  DCE uses an older draft of the Posix threads standard,
    the IDL compiler does some odd things with YACC, and there is not
    simple configuration mechanism.

    Jon Mauney is collecting information on people's experience with
    the public release of DCE RPC.  Look for an FAQ on PD-DCE real
    soon now.

==================================================================

Q 3.06: Is there a DCE Users Group I can join?

A:

    Yes.  Besides the OSF itself, there are a couple of possibilities.

     The formation of the i3D was announced on April 24, 1995.  The i3d
     is an international organization for users of OSF DCE or three
     tier architectures.  Three tier architecture is an distriuted
     systems approach that separates the presentation, processing logic
     and data access portions of an application.

     The i3D's mission is to build and nurture a community of users and
     vendors to promote and enable distributed computing using
     Three-Tiered Architecture, Open Software Foundation's Distributed
     Computing Environment (OSF DCE) and other related products and
     technologies.

     For more information about the i3D International Users Group, 
     contact i3D Headquarters at 312/644-6610.

    There are also local DCE users groups in several areas.

.Washington (DC) Area Distributed Computing Users Group
.For information: 
.    e-mail  wa-dce-users@osf.org
.    or Laks Prabhala laks@eos.hitc.com  301-925-0431

.Massachussetts DCE Users Group
.For information: 
.    Jaqui Lynch           lynch@cleo.bc.edu
.    http://dceusers.bc.edu/dceusers/dceusers.html
        Join their mailing list by sending email to majordomo@listserv.bc.edu
.    with the message "subscribe dceusers"

.DCE Users Group of Michgan
.For information: 
.    Janani Janakiraman    jej@umich.edu
          or dugm-request@citi.umich.edu (for group mailing list)
.    http://dcewww.citi.umich.edu:8080/dugm
.    http://dcewww.citi.umich.edu:8080/mvsdce/ (MVS/DCE user's group)

.Arizona DCE Users Group
.For information: 
.    Michael J. Danley     mdanley@next3.corp.mot.com
.    602-441-2887                
.    http://www.adug.org/

.New York City DCE Users Group
.For information: 
.    Ilya Goldberg     goldberg_ilya@jpmorgan.com
            http://www.eclipse.net/~igsys/dceug
.    212 235-5206

.The Twin Cities (Minneapolis and St. Paul)
.For information: 
.    William A. Estrem          3M Information Architecture Department
.    224-4E-21                  3M Center
.    St Paul, MN 55144-1000  
.    Office: 612 736-6853  Fax: 612 733-3502
.    waestrem@mmm.com
.    http://www.skypoint.com/members/probert/mndce.html

.Seattle, WA -- currently reorganizing
.For information: 
.    Lulu Figini  tec471@kbct.bems.boeing.com

.Denver, CO
.For information: 
.    Contact:  Chris House, US West
.    Phone:  303-762-3098   Fax: 303-762-3138 
.    Email: cmhouse@indss1.exte.uswc.uswest.com

.Southern California DCE Users Group
.For information: 
.        Steve Jenkins
.        Phone:  818-306-6438
.        Email:  Steven.Jenkins@jpl.nasa.gov

.        Mark Michael
.        Phone:  310-364-6759
.        Email:  mmichael@igate1.hac.com
.
.        Marcus Ross
.        Phone:  818-858-2040
.        Email:  Marcus_Ross@transarc.com

.Northern California DCE Users Group
.For information: 
.    Dipak Basu.. Open Horizon, Inc.
.    (415) 593-0298
.    e-mail: dbasu@openhorizon.com

.Western Canada DCE Users Group
.For information: 

.        Muiz Motani. Intelligent Distribution
.        72-6800 Lynas Lane
.        Richmond, B.C. V7C 5E2
.        Phone: (604)448-9293
.        Email: a11389@mindlink.bc.ca

.London (UK)
.For information: 
.    Contact:  Linda Sawyer, IBM
.    Tel. 44 818 18 4444
.    Email: linda_sawyer@uk.ibm.com

.Paris (France)
.For information: 
.    Pierre-Louis Neumann                    INRIA Rocquencourt
.    BP 105, 78153 Le Chesnay CEDEX          France
.    TEL 33 1 39 63 55 62                    FAX 33 1 39 63 50 34
.    Pierre-Louis.Neumann@inria.fr

-----------------------------------------------------------------------
Tier 4 -- Acknowledgements

ACK:  Thanks to the following, who provided  netnews and email messages
   from which this information is gleaned.  All errors should be
   blamed on Jon Mauney. (Corrections are actively solicited.)

        Hal Lichtin,            Open Software Foundation
        Rich Salz,              Open Software Foundation
        Courtney Mark Grey,     Open Software Foundation
        Walt Tuvell             Open Software Foundation
        David Weisman           Open Software Foundation
        Matt Thomas,            Digital Equipment Corporation
        Jonathon Chinitz        Intellisoft
        Nat Mishkin             Atria Software
        Mark Hickey             OpenVision

   And special thanks to:
        Harold Lockhart, Jr.    Locus Computing Corporation
   who wrote several of the answers in this FAQ.



