home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / dce / faq
Encoding:
Internet Message Format  |  1998-10-28  |  84.7 KB

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.kodak.com!news-nysernet-16.sprintlink.net!news-east.sprintlink.net!news-peer.sprintlink.net!news-backup-west.sprintlink.net!news.sprintlink.net!199.72.1.44!interpath.net!tophat!mauney
  2. From: mauney@mauney.com (Jon Mauney)
  3. Newsgroups: comp.soft-sys.dce,comp.answers,news.answers
  4. Subject: OSF Distributed Computing Environment Frequently-asked questions
  5. Supersedes: <dce-faq-1-895664954@mauney.com>
  6. Followup-To: comp.soft-sys.dce
  7. Date: 28 Oct 1998 02:41:09 GMT
  8. Organization: Mauney Computer Consulting
  9. Lines: 2009
  10. Approved: news-answers-request@MIT.EDU
  11. Distribution: world
  12. Expires: 01 Dec 98 22:36:26 EDT
  13. Message-ID: <dce-faq-1-909542186@mauney.com>
  14. Reply-To: jon@mauney.com (Jon Mauney)
  15. NNTP-Posting-Host: jtec.mauney.com
  16. Summary: Answers to frequently asked questions about
  17.  the Open Software Foundation's Distributed Computing Environment (DCE).
  18.  It provides a brief overview of what DCE is, pointers to sources of
  19.  more information on DCE, and answers to common technical questions.
  20. Keywords: DCE Distributed Computing FAQ
  21. Originator: mauney@tophat
  22. Xref: senator-bedfellow.mit.edu comp.soft-sys.dce:7941 comp.answers:33589 news.answers:143033
  23.  
  24. Posted-By: auto-faq 3.1.1.2
  25. Archive-name: dce/faq
  26. Revision: 1.36 1998/10/28 02:36:18
  27. Posting-frequency: monthly
  28.  
  29.       DCE  Frequently Asked Questions
  30.  
  31.   This document answers some Frequently Asked Questions concerning
  32.   the OSF Distributed Computing Environment.
  33.   It is posted monthly to comp.soft-sys.dce, as well as
  34.   comp.answers, and news.answers.
  35.  
  36. The questions (and answers)  in this FAQ have been divided
  37. into 3 tiers, for convenience, scalability, and because its
  38. just the cool thing to do.
  39.  
  40. (*) Tier 1, User support, contains general questions about DCE
  41. (*) Tier 2, Application support, contains technical questions about DCE
  42. (*) Tier 3, Data Management, contains pointers to further information
  43.         about DCE
  44.  
  45.  
  46. --------------------------------------------------------------
  47. Tier 0 -- Header files
  48.  
  49.   The document is maintained by Jon Mauney, mauney@ivc.com
  50.  
  51.   Suggestions, corrections, and updates are actively sought.
  52.  
  53. This FAQ is available for browsing on the web
  54.   http://www.ivc.com/~mauney/dce-faq.html
  55.  
  56.   This FAQ is posted on Usenet to comp.answers and comp.soft-sys.dce
  57.   and is available for anonymous ftp from sites that archive those
  58.   newsgroups, such as rtfm.mit.edu and fine mirror sites worldwide.
  59.  
  60.   Last modified on 23 October 1998
  61.  
  62.  
  63.  Changes since it was last posted on May 22, 1998
  64.  
  65.  Q 1.07 : updated link to Transarc solutions page.
  66.  
  67. Q 2p-02: remove link to Lexis-Nexis whitepaper on cell size.
  68.  
  69. Q 3.05: update information about Linux DCE
  70.  
  71. Q 3.01: add pointer to Transarc's online documentation
  72.  
  73. Q 3.02: add mention of Campbell's AFS book
  74.  
  75.  Changes since it was posted on March 12, 1998
  76.  
  77.  
  78.   Q 1.03 : updated info on NT, OS/390
  79.  
  80.   Q 2cc-05,3.01,3.07: updated the URLs for Transarc's web site
  81.  
  82.   Q 2r-07, 2p-06, 2s-01, 2r-14, 2cc-02: Added URLs for examples at
  83.     Transarc's web site.
  84.  
  85.   Added Q2p-07: Should I choose UDP or TCP for my RPC?
  86.  
  87.  
  88.  Changes since it was last posted on January 17, 1998
  89.  
  90.  
  91.  3.01  Add link to IBM's AIX DCE web page
  92.  
  93.  Changes since it was last posted on November 6, 1997
  94.  
  95.  
  96.  2p02  Add information on IBM enhancements to security server to permit
  97.    large number of DCE principals to be created.
  98.  
  99.  2cc06 Add clarification that cross-cell delegation is possible in
  100.    restricted circumstances.
  101.  
  102.  3.01  Add link to Keys Botzum's DCE&Encina question and answer page
  103.  
  104.  3.05  Add links to Linux DCE web pages by Andrew Sandoval and by Jim Doyle.
  105.  
  106. --------------------------------------------------------------
  107. Tier 1 -- Front-end, user support
  108.  
  109. Q 1.01: What is DCE?
  110. Q 1.02: What are the advantages of DCE?
  111. Q 1.03: What platforms support DCE?
  112. Q 1.04: What products use DCE?
  113. Q 1.05: Is DCE an official standard?
  114. Q 1.06: The DCE threads uses draft 4 of the standard, but
  115.   Posix threads standard has moved beyond draft 4.
  116.   Will DCE change to the most recent standard?
  117. Q 1.07: Is anyone using DCE for real-life mission-critical systems?
  118. Q 1.08: What is the relationship between DCE and CORBA?
  119. Q 1.09: Is DCE IDL the same as all the other IDL's in the world?
  120. Q 1.10: Now that OSF is the Open Group, should we talk about OG DCE?
  121.  
  122.  
  123. Tier 2 -- Application support
  124.  
  125. Sub-interfaces:
  126.  RPC and IDL
  127.  Compatibility
  128.  Performance
  129.  Cell Configuration
  130.  Security
  131.  
  132. Sub-interface:  RPC and IDL
  133. Q 2r-01: Several of the other questions concern "interfaces".
  134.       What is meant by an interface in DCE RPC?
  135. Q 2r-02: Can a DCE client import multiple interfaces?
  136. Q 2r-03: Can a DCE client connect to multiple servers?
  137. Q 2r-04: Can a DCE server export multiple interfaces?
  138. Q 2r-05: Can a process be both a server and a client?
  139. Q 2r-06: How do I perform asynchronous RPC?
  140. Q 2r-07: How can a server keep track of multiple clients?
  141. Q 2r-08: How can a server detect that a client as exited or crashed?
  142. Q 2r-09: How can a server identify the client that has called it?
  143. Q 2r-10: Can I move idl-compiled stubs from one platform to another and
  144.         rebuild the object files locally?
  145. Q 2r-11: How are UUIDs generated?  
  146. Q 2r-12: How can I pass a UUID as a parameter in an RPC?
  147.         What is the format of a uuid_t structure?
  148. Q 2r-13: How can I pass a binding handle as an ordinary parameter in an RPC?
  149. Q 2r-14:  How do I keep my server from
  150.   advertising all the host machine's network addresses with CDS? 
  151. Q2r-15: How do I share type declarations between two
  152.   or more IDL files?
  153. Q 2r-16: How can I control the timeout of a context handle?
  154. Q 2r-17: A server has moved or otherwise changed its binding information.
  155.    How do I make the client obtain the new binding ?
  156.  
  157. Sub-Interface: Performance
  158. Q 2p-01: How efficient is DCE RPC?
  159. Q 2p-02: What is the practical limit on the size of a DCE cell?
  160. Q 2p-03: How much memory and disk space is required for DCE services?
  161. Q 2p-04: How can I control the number of concurrent client connections
  162.         and the size of the request queue on a server?
  163. Q 2p-05: My server gets a stack error when sending large objects.  How
  164.        can I avoid this?
  165. Q 2p-06: How do I get clients to connect to the nearest server?
  166. Q 2p-07: Should I choose UDP or TCP for my RPC?
  167.  
  168. Sub-Interface: Compatibility
  169. Q 2c-01: Will Windows NT communicate with DCE?
  170. Q 2c-02: Can I use DCE from C++?
  171. Q 2c-03: Can I write an application that uses DCE and X11/Motif?
  172. Q 2c-04: Is DCE RPC compatible with ONC RPC?
  173. Q 2c-05: Is XDR compatible with NDR?
  174.  
  175. Sub-Interface: Cell Configuration
  176. Q 2cc-01: Is it possible for a machine to be a member of more than one DCE cell?
  177. Q 2cc-02:  How do I configure cells to find each other using DNS?
  178. Q 2cc-03: Is it possible for a user in one cell to use secure services
  179.       in another cell? 
  180. Q 2cc-04:: How do I change the name of my cell?
  181. Q 2cc-05:: How do I change the IP address of
  182.       a host in my cell?
  183. Q 2cc-06:: How do I do inter-cell delegation?
  184. Q 2cc-07:: How can I find out who is currently logged in to a DCE cell?
  185.  
  186.  
  187. Sub-Interface: Security
  188. Q 2s-01: Where can I find an ACL manager to include in my application?
  189. Q 2s-02: Does DCE Security interoperate with other Kerberos systems?
  190. Q 2s-03: Can I allow DCE clients and servers to communicate
  191.         across a firewall?
  192.         Can I control the endpoints assigned to DCE servers?
  193. Q 2s-04: Do DCE servers automatically update their long term secret keys?
  194. Q 2s-05: What problems might I cause by changing the expiration time
  195.     or password lifespan in a running cell?
  196.  Q2s-06: How do I begin to force password changes,
  197.     without getting into the trouble described in the previous question?
  198. Q 2s_07:  Do all versions of DCE support the sec_key_mgmt_manage_key() 
  199.     functionality in the same way?
  200. Q 2s_08:  How can I work around the key_mgmt problem if I have older client
  201.      machines, but DCE 1.1+ based servers?
  202.  
  203.  
  204.  
  205. Tier 3 -- Data management
  206.  
  207. Q 3.01: Where can I get online information about DCE?
  208. Q 3.02: What books are published on DCE?
  209. Q 3.03: Where can I get more information about DCE and DCE-related products?
  210. Q 3.04: What are DCE RFCs, and how can I get them?
  211. Q 3.05: Where can I get the Public Domain version of DCE?
  212. Q 3.06: Is there a DCE Users Group I can join?
  213. Q 3.07: Are there any example programs available on-line?
  214.  
  215.  
  216. --------------------------------------------------------------
  217. The answers please:
  218. --------------------------------------------------------------
  219.       Tier 1 -- Front-end User Support
  220. --------------------------------------------------------------
  221.  
  222. Q 1.01:  What is DCE?
  223.  
  224. A:
  225.    DCE is the Distributed Computing Environment, from the
  226.    Open Software Foundation. (It is called "the DCE" by sticklers
  227.    for grammatical consistency.) (The Open Software Foundation
  228.    is now called the Open Group.)
  229.  
  230.    DCE consists of multiple components which have been integrated
  231.    to work closely together.  They are the Remote Procedure Call
  232.    (RPC), the Cell and Global Directory Services (CDS and GDS), the
  233.    Security Service, DCE Threads, Distributed Time Service
  234.    (DTS),and Distributed File Service (DFS).  The Threads, RPC, CDS,
  235.    Security, and DTS components are commonly referred to as the 
  236.    "secure core" and are the required components of any DCE installation.
  237.    DFS is an optional component.  DCE also includes administration tools
  238.    to manage these components.
  239.  
  240.    DCE is called "middleware" or "enabling technology."  It is not
  241.    intended to exist alone, but instead should be bundled into a
  242.    vendor's operating system offering, or integrated in by a third-party
  243.    vendor.  DCE's security and distributed filesystem, for example, 
  244.    can completely replace their current, non-network, analogs.
  245.    DCE is not an application in itself, but is used to build custom
  246.    applications or to support purchased applications.
  247.  
  248. --------------------------------------------------------------
  249. Q 1.02:  What are the advantages of DCE?
  250.  
  251. A:
  252.  
  253.    First, DCE provides services that can be found in other computer
  254.    networking environments, but packages them so as to make them
  255.    much easier to use.  For example, the DCE Remote Procedure Call
  256.    (RPC) facility provides a way of communicating between software
  257.    modules running on different systems that is much simpler to code
  258.    than older methods, such as using socket calls.
  259.  
  260.    Second, DCE provides new capabilities that go beyond what was
  261.    available previously. The DCE Security Service provides a
  262.    reliable way of determining if a user of a distributed system
  263.    should be allowed to perform a certain action, for example.  This
  264.    is very useful for most distributed applications, yet the design
  265.    and implementation effort entailed in providing such a capability
  266.    would be prohibitive for an individual developer.
  267.  
  268.    Third, DCE integrates components in a manner that makes them more
  269.    valuable together than separately.  For example, the DCE RPC uses
  270.    threads in such a way that a developer can implement a
  271.    multi-threaded server without ever explicitly creating or
  272.    destroying a thread.
  273.  
  274.    Finally, DCE supports both portability and interoperability by
  275.    providing the developer with capabilities that hide differences
  276.    among the various hardware, software and networking elements an
  277.    application will deal with in a large network.  For example, the
  278.    RPC automatically converts data from the format used by one
  279.    computer to that used by another.
  280.  
  281.    Portability is a measure of the ease with which a piece of
  282.    software that executes on one type of computer can be made to
  283.    execute on a different type of computer. Interoperability is a
  284.    measure of the ability of computers of different types to
  285.    participate in the same distributed system.
  286. --------------------------------------------------------------
  287. Q 1.03:  What platforms support DCE?
  288.  
  289. A:
  290.  
  291.   DCE is fully supported on most major platforms, including all major
  292.   Unix platforms and many non-Unix platforms.
  293.   Most vendors support at least the "secure core" which means all of the
  294.   DCE services except the Distributed File Service and X.500 interface
  295.   to the Global Directory Service.
  296.  
  297.   Some products are client-only, which means that the actual servers
  298.   for the DCE services are not provided: Directory Service, Security
  299.   Service, Time Service. Client machines can use these services,
  300.   they simply cannot run the server programs;  another machine
  301.   in the cell must run the server programs.  Application programs
  302.   can be built and run the application servers on these "client-only"
  303.   systems.
  304.  
  305.   The status of DCE implementations changes frequently; check with the
  306.   specific vendors for the latest details, or see the DCE product
  307.   list (see the next question). Updates to this FAQ
  308.   are solicited.
  309.   This table summarizes the DCE implementations currently available:
  310.  
  311.   
  312.    -------------------------------------------------------------
  313.    Platform                     Comments
  314.    -------------------------------------------------------------
  315. Unix platforms:
  316.    Digital UNIX:                Secure core, DFS, and X.500
  317.    Ultrix                       had a "Starter kit", but of course Ultrix is
  318.                   no longer supported...
  319.    HP-UX:                       Secure Core, DFS , and X.500 
  320.    DG/UX                        Secure Core and X.500
  321.    AIX:                         Secure core, DFS, and X.500
  322.    SunOS,                       Secure Core
  323.    Solaris:                     Secure core and DFS
  324.                                 Implementation by Transarc, also re-sold by Sun
  325.    Irix                         Secure Core, DFS, X.500
  326.    SCO                          Secure Core was expected by August 1994
  327.    AT&T GIS, SVR4 on Intel      Secure Core
  328.    Sinix (Mips and Intel)       Secure Core, DFS, and X.500
  329.    Cray Unicos                  Secure Core Client, and DFS server
  330.    Pyramid DC/OSx (SVR4)        Secure Core
  331.    Hitachi HI-OSF/1-MJ (osf/1)  Secure Core, with Japanese on-line doc
  332.    Hitachi HI-UX/WE2            Secure Core
  333.    Sony NEWS (SVR4)             Secure Core
  334.    Fujitsu DS/90 (SVR4)         Secure Core
  335.    System V on Intel:           Secure Core, from Gradient Technologies
  336.       Unixware, Sequent Dynix, NCR MP-RAS, Unisys
  337.    Dascom AD V1.1 (OSF/1 on Intel) Secure Core Client
  338.  
  339. Non-Unix platforms:
  340.    Tandem NonStop Kernel        Secure core
  341.    OpenVms (Vax, and Alpha AXP) Secure core, X.500 support
  342.    Microsoft Windows:           Client-only, available from Gradient Technologies
  343.                                    Gradient's port is also sold by Siemens,
  344.                                 and IBM.
  345.                                 Unimetrics has announced DFS client products
  346.                                    for Windows
  347.                                 Transarc has a "DFS-Light" client for Windows
  348.    Macintosh                    Client only, from Gradient Technologies
  349.                 Open Environment Corporation has a Macintosh
  350.                 client that allows access to DCE servers by
  351.                 way of an OEC server on another machine.
  352.    Windows NT:                  out-of-the-box, NT contains a subset of
  353.                                 DCE RPC. See Q 2c-01 for further discussion.
  354.                 Gradient has full secure core DCE+DFS for NT
  355.                                 Digital has secure core
  356.                 IBM has secure core
  357.                                 Transarc has DFS client and server and a
  358.                    "DFS-Light" client for WinNT
  359.    Windows 95            Client only, from Gradient
  360.                          Client only, from Digital
  361.                 Transarc has a "DFS-Light" client for Win95
  362.    OS/2:                        Secure core
  363.    HP 3000 with MPE/iX          Secure Core
  364.    VM                           Kapsch AG supports DCE client and the
  365.                   security server on IBM's VM and VM/ESA
  366.    VM/ESA                       IBM has announced intent to support 
  367.                                   "selected components" of DCE on VM/ESA.
  368.                   These components boil down to secure client
  369.                   without DTS
  370.                                 Kapsch AG supports DCE client and the
  371.                   security server on IBM's VM and VM/ESA
  372.    IBM OS/390 (MVS)        secure core + DFS
  373.    IBM AS/400                   client only 
  374.    BS2000                       Client Only
  375.    Bull DPX/20                  Secure Core, X.500, DFS
  376.    GCOS on Bull DPS 9xxx/7xxx   threadless client only
  377.  
  378.  
  379. --------------------------------------------------------------
  380. Q 1.04:  What products use DCE?
  381.  
  382. A:
  383.  
  384.    The Open Group maintains an Open Software Registry, which contains
  385.    information about DCE products, among others.  Access is free, but
  386.    you must register.
  387.    The registry is available on-line at http://www.opensoftware.com/
  388.    Once you get in, you can search for DCE, and your favorite platform
  389.    or other criteria.
  390. Hint: A search using "DCE" as the product name will find only
  391.    those products whose listed name starts with DCE.  If you want
  392.    to find products like "PC-DCE", "Nonstop DCE", and "Kapsch-DCE/VM", search
  393.    for "*DCE" instead.  If you want to find DCE-related products like Encina
  394.    or Dazel, go to the advanced search and choose the Keyword DCE.
  395.  Note to vendors, not all DCE implementations show up under a keyword
  396.    search for DCE, so check your listings.
  397.  
  398. --------------------------------------------------------------
  399. Q 1.05:  Is DCE an official standard?
  400.  
  401. A:
  402.  
  403.    The OSF calls the specification an Application Environment Specification,
  404.    or AES. The  AES documents both the software programming interfaces and 
  405.    also the communications protocols employed by DCE.  Thus it would be
  406.    possible, in theory, for someone to build a compatible
  407.    implementation without using the code from the Open Group.
  408.    The AES for RPC, Time, and  Directory services have been accepted as 
  409.    standards by X/Open.  The AES for Security is currently undergoing
  410.    review.
  411.  
  412.    DCE Threads follow the Posix Threads draft standard 1003.4a draft
  413.    4.  DCE Access Control Lists (ACLs) are based on POSIX.6 Draft
  414.    12.  The Distributed Time Service (DTS) uses time formats defined
  415.    by international standards and in POSIX.4.  The Global Directory
  416.    Service (GDS) complies with the X.500 international standard.
  417.    (Although DCE complies with the 1988 version of X.500, not
  418.    the 1992 version.)
  419.  
  420.    ISO is considering an RPC standard based on the X/Open document.
  421.  
  422.    DCE's status as a de facto standard is even stronger.  Almost
  423.    every major hardware and software vendor has committed to
  424.    providing DCE on its platform.  These vendors include not only
  425.    Open Group stalwarts such as IBM, DEC and HP, but also other key vendors
  426.    such as Novell, Inc.  See Q 1.03 for a list of DCE vendors.  In addition,
  427.    a number of major user organizations (e.g., the European Economic
  428.    Community) have already embraced DCE as their standard for
  429.    distributed applications.
  430.  
  431. --------------------------------------------------------------
  432. Q 1.06:  The DCE threads uses draft 4 of the standard, but
  433.   Posix threads standard has moved beyond draft 4.
  434.   Will DCE change to the most recent standard?
  435.  
  436. A:
  437.  
  438.    It is hard to predict exactly what will happen. 
  439.    But Open Group prefers to follow standards rather then invent them. 
  440.    Now that Posix has settled on the standard, we can expect
  441.    the DCE to migrate to it.
  442.  
  443. --------------------------------------------------------------
  444. Q 1.07:  Is anyone using DCE for real-life mission-critical systems?
  445.  
  446. A:
  447.  
  448.    Yes, and more every day.  Tokio Marine and Fire Insurance,
  449.    Co., Lehman Brothers, and Charles Schwab have all publically
  450.    described their ongoing rollout of DCE based applications.
  451.  
  452.    The Open Group's Web server has a section that includes some reports on
  453.    'real-world' experiences from companies using DCE in production.
  454.  
  455.    Intellisoft published a  48-page "advutorial" (that
  456.    means advertisement and tutorial) with the help of
  457.    many DCE vendors, totally devoted to the above. There are storeis about
  458.    DCE in production, technical essays, etc. 
  459.    The supplement is on-line and available via Intellisoft's web site
  460.    (http://www.isoft.com/publications.html -- click on "DCE and The Enterprise" ).
  461.  
  462.    Transarc's web server includes a page in which they describe solutions
  463.    used by some of their customers.
  464.  
  465. http://www.transarc.com/dfs/public/www/htdocs/.hosts/external/Solutions/index.html
  466.  
  467. --------------------------------------------------------------
  468. Q 1.08:  What is the relationship between DCE and CORBA?
  469.  
  470. A:
  471.  
  472.   The short answer:  
  473.  
  474.        There is not a lot of direct relationship.  DCE and CORBA
  475.        are tools to help you build distributed systems.  Each has
  476.        its advantages and disadvantages.  Use of one will not 
  477.        hinder future use of the other.
  478.  
  479.        DCE provides a lower-level programming model than does CORBA.
  480.        DCE is not fully "Object-Oriented".  DCE has far better
  481.        inter-operability than (current) CORBA products.
  482.        DCE is an optional interoperability mechanism in the
  483.        CORBA 2.0 specification.
  484.  
  485.   The long answer:
  486.      In order to understand the relationship between DCE and the Common
  487.      Object Request Broker Architecture (CORBA) of the Object Management
  488.      Group (OMG), it is necessary to consider the past, the present and the
  489.      future.
  490.  
  491.    Past - Historically, the object paradigm has been viewed as a break
  492.      with procedural styles of the past.  Objects, which encapsulate data
  493.      and procedures behind an external interface, are often contrasted with
  494.      other approaches where procedures and data are treated separately.
  495.  
  496.      In this context, DCE is a descendant of the procedural school which
  497.      emphasizes the decomposition of programs into procedures and achieves
  498.      distribution by locating some of those procedures remotely.  Thus there
  499.      was a tendency for the object community, including the OMG, to view DCE
  500.      as technology which was obsolete before it was available.
  501.  
  502.      However this view ignored the fact that designers of distributed
  503.      systems had for a long time recognized that the most successful
  504.      approach to developing distributed systems was to created encapsulated
  505.      objects that can only be accessed via well defined interfaces.  Thus
  506.      the cornerstone of DCE RPC is the interface definition language (IDL)
  507.      which allows the external attributes of a set of server operations to
  508.      be specified.
  509.  
  510.      Furthermore, the name-based binding mechanisms of DCE were extended to
  511.      include the ability to bind to a server based on the object instances
  512.      which it supports.  These object binding mechanisms also allow the
  513.      transparent selection among multiple implementations of the same server
  514.      operations based on the type of the specified object.  In object
  515.      terminology this is called polymorphism.
  516.  
  517.      The DCE notion of a server supporting interfaces consisting of one or
  518.      more operations is so close to the notion of an object which provides
  519.      one or more methods, that it should be no surprise that CORBA defines
  520.      an IDL which differs from DCE IDL in only a few significant respects.
  521.  
  522.      Principal among these is that in CORBA IDL every call must specify an
  523.      object, which is used in determining the server to use.  DCE can do
  524.      this as well, but there is more work involved and it is optional.
  525.      Another difference is that CORBA IDL allows an interface to be defined
  526.      as a extension of one or more other interfaces, this is called
  527.      interface inheritance.  DCE does not permit interface inheritance, but
  528.      may in the future.  Implementation inheritance is not specified by
  529.      either DCE or CORBA.
  530.  
  531.      The use of object oriented techniques and principles should not be
  532.      confused with using an object oriented language.  Object oriented
  533.      designs can be expressed in procedural languages, and in fact most of
  534.      the current object environments supported C before supporting C++ or
  535.      Smalltalk.  Therefore, the fact that the DCE API is implemented in C is
  536.      no barrier to using it to create a distributed object system.  In fact,
  537.      CORBA specified C language bindings first.
  538.  
  539.    Present - CORBA should not be viewed in isolation, but in the context
  540.      of all of the OMG's standardization efforts.  OMG has defined a
  541.      reference architecture (OMA) and has defined or is defining standards
  542.      in a broad range of areas, including: databases, events, lifecycle,
  543.      transactions, persistence, security, naming and relationships.  Viewed
  544.      in this way, OMG's activities are much more ambitious and broader in
  545.      scope than DCE.
  546.  
  547.      A recent addition to CORBA, as a part of the CORBA 2.0 work was the
  548.      definition of the means of interoperability between ORBs.  CORBA 2.0
  549.      defines one mandatory and two optional mechanisms.  The mandatory means
  550.      is a new, lightweight protocol called UNO.  The optional means are 1)
  551.      via a gateway and 2) via an alternative protocol definition.  At the
  552.      present the only alternative protocol that has been defined is DCE
  553.      RPC.
  554.  
  555.      Many people who had hoped that DCE would be selected as the mandatory
  556.      protocol were disappointed at this result.  However, it should be
  557.      observed that DCE is endorsed as alternative protocol and that several
  558.      vendors have committed to providing ORBs that interoperate via DCE.
  559.  
  560.      Another difference between DCE and the OMG standards is one of general
  561.      philosophy.  DCE has been defined quite rigorously in a series of
  562.      documents published by X/Open.  There is a set of conformance tests
  563.      that are available to anyone.  Any product passing these rigorous tests
  564.      can be branded as DCE, without necessarily being based on the OpenGroup
  565.      code.  Several vendors, including Microsoft and Tandem have reverse
  566.      engineered significant portions of DCE.
  567.  
  568.      OMG standards vary considerably in their level of detail, but in
  569.      general, aim at a much looser level of standardization.  In some cases,
  570.      the standard merely specifies an object interface and some general
  571.      semantics.  This approach is a deliberate attempt to encourage diverse
  572.      solutions which may be applicable in different environments.  Even
  573.      where specifications are relatively tight, for example in the area of
  574.      CORBA portability, there is still room for considerable interpretation,
  575.      as witness the fact that there is at least one company that provides
  576.      consulting services on how to make CORBA applications compliant in
  577.      practice.
  578.  
  579.      At the present time, CORBA-compliant products and products that work
  580.      with them do not provide a scaleable infrastructure suitable for large
  581.      environments.  Key features such as concurrency mechanisms, security
  582.      and distributed transactions are not currently available.  In contrast,
  583.      DCE provides proven heterogeneous interoperability and most of the
  584.      capabilities required by robust, production applications.  Additional
  585.      capabilities can be obtained by means of third products, such as
  586.      transaction monitors built upon DCE.  This situation will change over
  587.      the next 2-3 years from a combination of standardization work by OMG
  588.      and new product development by vendors.
  589.  
  590.    Future - Most authorities agree that in the long term object technology
  591.      will be the basis for building large scale distributed systems.  In
  592.      addition to the principle of encapsulation, object- based systems allow
  593.      systems to be built up, evolve and be reconfigured as needed because of
  594.      their ability to dynamically bind requesters to objects that provide
  595.      services.
  596.  
  597.      There are many specific issues concerning the properties of distributed
  598.      object systems that are the subject of research and debate.  It is also
  599.      clear that there are some features of existing local object
  600.      environments and languages that will not scale effectively to large
  601.      scale distributed systems -- dynamic inheritance is one. Never the
  602.      less, the general direction of the future is clear.
  603.  
  604.      Clearly, the high level of interest in OMG defined standards comes not
  605.      from current products, but from their exciting future potential.  There
  606.      is a natural tendency to compare DCE's current capabilities with the
  607.      promise of CORBA's future.  However, DCE is also evolving and will
  608.      likely add additional object oriented features in the future.  For
  609.      example, HP is offering a DCE C++ class library which is expected to
  610.      eventually become a standard part of DCE.
  611.  
  612.      Where DCE was built by integrating existing software, OMG has chosen by
  613.      and large to start with a clean sheet of paper.  The idea is to be
  614.      better able to implement object oriented constructs without the baggage
  615.      of features carried over from previous systems.  However, OMG faces
  616.      great challenges.  Object theory is currently in a great state of
  617.      flux.  Experts disagree on very fundamental issues about what features
  618.      are necessary, useful or harmful.
  619.  
  620.      Developing standards under these conditions is extremely challenging.
  621.      OMG's approach to date has been to compromise and allow multiple
  622.      alternatives.  It is unclear whether this will succeed in the long
  623.      run.
  624.  
  625.      Does the conclusion that future distributed systems will be object-
  626.      based mean that it is a mistake to build distributed systems today
  627.      using DCE?  The answer is no for several reasons.  First, many
  628.      organizations cannot afford to do nothing for several years.  End users
  629.      have pressing needs for robust, scaleable systems today.  For many
  630.      organizations, waiting would mean attempting to catch up with
  631.      competitors who will have a tremendous head start.
  632.  
  633.      Second, as this brief discussion has shown, it is possible to employ
  634.      object techniques when developing distributed applications using DCE.
  635.      Carefully designed systems will be able to take advantage DCE features
  636.      such as dynamic binding and polymorphism and converge with
  637.      CORBA-compliant systems as they mature.
  638.  
  639.      Third, if object environments are to be successful in supporting
  640.      industrial-strength distributed systems, they will have to address the
  641.      problems that DCE addresses.  The skills and techniques developed in
  642.      working with DCE will be directly applicable to distributed systems
  643.      environments of the future.  This applies not only software developers,
  644.      but also to operations personnel, planners, even business managers.
  645.  
  646.      Further, the likelihood that DCE will be at least one technology for
  647.      CORBA interoperability, implies that the eventually migration of
  648.      applications which use DCE directly to an object environment should not
  649.      present any insurmountable difficulties.
  650.  
  651.      Finally, your direct experience in developing and operating robust
  652.      distributed systems will provide you with great insight into the
  653.      important characteristics of distributed systems environments as they
  654.      apply to your organization's applications.  This knowledge is vital to
  655.      the shaping of successful tools of the future.  History has shown that
  656.      vendors and standards bodies, left to their own devices, will often
  657.      miss the mark.
  658.  
  659. --------------------------------------------------------------
  660. Q 1.09:  Is DCE IDL the same as all the other IDL's in the world?
  661.  
  662. A:
  663.  
  664.     No.
  665.  
  666.     IDL stands for "Interface Definition Language," and the idea
  667.     of using a special language to define the interface between
  668.     entities is not unique to DCE.  In particular, OMG's IDL for CORBA
  669.     is used for the same purpose as DCE's, but the two languages
  670.     are not identical; see Q 1.08 for more information.  There are
  671.     other Interface Definition Languages as well.
  672.     IDL also stands for "Interactive Data Language", which
  673.     is a completely unrelated product.
  674.  
  675.     When asking or answering a question about IDL, one should be
  676.     careful about specifying which IDL is involved.
  677.  
  678. --------------------------------------------------------------
  679.  
  680. Q 1.10: Now that OSF is the Open Group, should we talk about OG DCE?
  681.  
  682. A:
  683.   No. "OSF DCE" is the registered trademark, and will apparently remain the
  684.   name of the product.
  685.  
  686. --------------------------------------------------------------
  687. --------------------------------------------------------------
  688.       Tier 2 -- Application Support
  689.  
  690. RPC and IDL
  691. --------------------------------------------------------------
  692. Q 2r-01:  Several of the other questions concern "interfaces".
  693.       What is meant by an interface in DCE RPC?
  694.  
  695. A:
  696.  
  697.    An interface is a set of remote procedure call operations and
  698.    associated data.  Every interface contains one or more
  699.    operations.  An operation is an actual remote procedure.  Each
  700.    operation may have input and output parameters associated with
  701.    it, just like any procedure call.
  702.  
  703. --------------------------------------------------------------
  704. Q 2r-02:  Can a DCE client import multiple interfaces?
  705.  
  706. A:
  707.  
  708.    Yes. A client can use as many different services as it needs.
  709.    To code such a client, simply include the header files for
  710.    all the RPC interfaces used, and code each call the same way
  711.    you would if using that interface in isolation.
  712.  
  713. --------------------------------------------------------------
  714. Q 2r-03:  Can a DCE client connect to multiple servers?
  715.  
  716. A:
  717.  
  718.    Yes. A client can connect to multiple servers providing different
  719.    services, and/or multiple servers providing the same service.
  720.  
  721.    To use multiple servers with the same interface, the client must
  722.    obtain a binding handle for each server and use explicit handles
  723.    in the RPC.
  724.  
  725. --------------------------------------------------------------
  726. Q 2r-04:  Can a DCE server export multiple interfaces?
  727.  
  728. A:
  729.  
  730.    Yes. A server can provide service on multiple interfaces
  731.    simultaneously.  A common example is a server that exports an
  732.    application interface and a management interface.
  733.  
  734.    To code such an application, repeat the calls to rpc_server_register_if(),
  735.    rpc_ep_register(), (and rpc_ns_binding_export() if you do that sort
  736.    of thing in your server) for each interface, before calling
  737.    rpc_server_listen().
  738.  
  739. --------------------------------------------------------------
  740. Q 2r-05:  Can a process be both a server and a client?
  741.  
  742. A:
  743.  
  744.    Yes.  There are two scenarios.
  745.  
  746.         1) A program might act as a server for interface A,
  747.           and also as a client for interface B.  This is easy.
  748.           The program merely imports interface B like a normal
  749.           client and exports interface A like a normal server.
  750.         2) A program might want to provide a service, and also
  751.           act as a client to other servers that provide the same
  752.           service.  In this case, the programmer must expend more
  753.           effort.  The problem is that the names of the server-side
  754.           functions (manager routines) clash with the names of the
  755.           client stubs.  The solution is to manually build an
  756.           entry point vector for the server, and use different names
  757.           for the manager routines. For  details on using entry point
  758.           vectors, see the Lockhart book (Q 3.02).
  759.  
  760.     Note that most server programs also act as clients, since they
  761.     usually access the endpoint mapper (rpcd), and the security
  762.     service;  these actions use RPCs, though it may not
  763.     be obvious in the code.
  764.  
  765. --------------------------------------------------------------
  766. Q 2r-06:  How do I perform asynchronous RPC?
  767.  
  768. A:
  769.  
  770.    DCE-RPC is synchronous. The way to make an asynchronous call is
  771.    to create a thread for each RPC call.  You should be able to have
  772.    dozens, if not hundreds, of threads with no problem.
  773.  
  774. --------------------------------------------------------------
  775. Q 2r-07:  How can a server keep track of multiple clients?
  776.       For example, to know what information has already been
  777.       provided to a client, and thus vary subsequent responses.
  778.  
  779. A:
  780.  
  781.    The DCE RPC mechanism includes a "context handle" which can be
  782.    created by a server and returned to a client.  The handle is used
  783.    on subsequent RPCs to identify the client.
  784.  
  785.    http://www.transarc.com/Public/Support/dce/prog_examples/rpc/context_handles/context_handles.html
  786.    includes sample code for a greet-type client/server
  787.    that uses context handles.
  788.  
  789.  
  790. --------------------------------------------------------------
  791. Q 2r-08:  How can a server detect that a client has exited or crashed?
  792.  
  793. A:
  794.  
  795.    The context handle provides this ability.  When a context handle
  796.    is created and passed to the client, the DCE runtime library
  797.    keeps track of the connection between client and server;
  798.    this may be done in the network code as in the case of TCP,
  799.    or by DCE-specific ping messages if a connectionless protocol is used.
  800.    When the client dies, the server is notified and executes a "rundown"
  801.    function to clean up its data structures.
  802.  
  803. --------------------------------------------------------------
  804. Q 2r-09:  How can a server identify the client that has called it?
  805.  
  806. A:
  807.  
  808.   The details vary, depending on exactly what you want to
  809.   identify about the client, but it all comes down to handles.
  810.   The server must receive a binding handle in order receive
  811.   information about the client.  If there is not a binding
  812.   handle in the parameter list as defined in the IDL file, then
  813.   use the [explicit_handle] attribute in the ACF file to add
  814.   one when building the server.
  815.  
  816.   If you want to identify the host machine on which the client
  817.   is executing, simply convert the binding handle to a string
  818.   binding using rpc_binding_to_string_binding() and then
  819.   extract the address using rpc_string_binding_parse().
  820.   When the server receives the handle, it contains the client
  821.   address.
  822.  
  823.   If you want to identify the human user who is running the client program,
  824.   you can get that from the authentication information in the handle.
  825.   rpc_binding_inq_auth_client() will give you the caller's PAC,
  826.   which contains, among other things, the principal's  uuid
  827.   and name.
  828.  
  829.   If you want to identify the particular client process so your
  830.   server can keep data specific to each client, then you need
  831.   to look into context handles as described in Q 2r-07.
  832.  
  833. --------------------------------------------------------------
  834. Q 2r-10:  Can I move idl-compiled stubs from one platform to another and
  835.        rebuild the object files locally?
  836.  
  837. A:
  838.  
  839.     No.  You must run the IDL compiler separately on each platform.
  840.  
  841.     The IDL compiler builds the client and server stubs to handle
  842.     network communication and data marshalling, which are 
  843.     platform-specific activities.  Therefore the stub code is not
  844.     portable and must be re-created on each platform.  Likewise, while
  845.     the task of the stub does not change, the set of service routines
  846.     called from the stub may be changed by the vendor for any given
  847.     platform.  Therefore stubs for the same RPC may look very different
  848.     on different platforms.
  849.  
  850. --------------------------------------------------------------
  851. Q 2r-11:  How are UUIDs generated?  
  852.  
  853. A:
  854.  
  855.   The DCE AES specifies the method for generating UUIDs, in case
  856.   you want the gory details.  In short, the UUID is a combination
  857.   of the network address and current time at the moment and place
  858.   it was generated.  Assuming that network addresses are unique
  859.   and that time never runs backwards, this guarantees that UUIDs
  860.   really are unique.
  861.  
  862.   Some implementations of uuidgen use the hardware address of the
  863.   ethernet adapter, some use the IP address of the host.
  864.  
  865.   It is possible to run uuidgen on machines without any network
  866.   connection.  In this case, the host must be assigned an address.
  867.   The AES specifies a file that can hold the network address.
  868.  
  869.   The code for generating UUIDs is part of the publically available
  870.   DCE source code. See Q 3.05: for information
  871.   on obtaining the code.
  872.  
  873. --------------------------------------------------------------
  874. Q 2r-12:  How can I pass a UUID as a parameter in an RPC?
  875.          What is the format of a uuid_t structure?
  876.  
  877. A:
  878.  
  879.   The uuid_t structure is defined in <dce/nbase.idl>
  880.   All you have to do is import this into your .idl file
  881.   and pass parameters of that type all day long.
  882.  
  883.   Note that uuid's passed as parameters are just ordinary data.
  884.   If you want the uuid to affect the interface or object
  885.   in the rpc, they must be attached to the binding handle.
  886.  
  887.  
  888. --------------------------------------------------------------
  889. Q 2r-13:  How can I pass a binding handle as an ordinary parameter in an RPC?
  890.  
  891. A:
  892.  
  893.   The binding handle is an opaque type and cannot be marshalled
  894.   as data.  A parameter of type handle_t must be the first parameter
  895.   and will serve to specify the binding of the RPC; an attempt
  896.   to use a handle_t as other than the first parameter will be flagged
  897.   as an error by the IDL compiler.
  898.  
  899.   To send a handle from one process to another, convert it to
  900.   a string binding and pass the string as a parameter.
  901.  
  902.  
  903. --------------------------------------------------------------
  904. Q 2r-14:  How do I keep my server from
  905.   advertising all the host machine's network addresses with CDS? 
  906.  
  907. A: 
  908.   If a server machine has two (or more) network interfaces, it will
  909.   have at least that many network addresses.  A typical server program
  910.   will export binding handles to CDS for every protocol sequence
  911.   on every network interface.  If some of these interfaces are unreachable
  912.   from some clients, binding may be delayed while the client cycles
  913.   through the useless handles.
  914.  
  915.   To limit a particular server,
  916.   set the environment variables RPC_UNSUPPORTED_NETIFS and/or
  917.   RPC_UNSUPPORTED_NETADDRS to exclude the interface or specific addresses
  918.   that you don't want your server to use.  On HP, set RPC_SUPPORTED_NETADDRS
  919.   instead, to give a list of addresses you do want to use.  Look in your
  920.   vendor's documentation for syntax and to verify that they support this
  921.   feature; it is not standardized by Open Group.
  922.   You must set the environment before starting the server, of course,
  923.   and you may have to manually remove CDS entries that are already present.
  924.  
  925. --------------------------------------------------------------
  926. Q2r-15: How do I share type declarations between two or more IDL files?
  927.  
  928. A:
  929.   Imagine a program that uses two interfaces, in two idl files, and
  930.   these two interfaces share many of the same structures
  931.   which must be typedef'ed in the idl file.  A C-programmer's first
  932.   instinct would be to #include a header file in both idl files, and
  933.   this would appear to work, because the IDL compile generally runs
  934.   the C preprocessor. But when the application code is compiled and
  935.   #includes both of the generated *.h files, the C compiler will
  936.   complain about duplicated declarations of these structures.
  937.  
  938.   You should instead put the shared declarations in a separate .idl file,
  939.   compile it separately with the idl compiler, and "import"
  940.   the .idl file into all the other idl files that need it.
  941.  
  942.   This way, each definition will appear in exactly 1 generated .h file,
  943.   where it will be protected by the usual #ifdef to prevent multiple
  944.   declarations.
  945.  
  946.   Some shops have an explicit style guideline that says an idl file
  947.   should contain either type definitions or function declarations,
  948.   but not both.  You might want to try it.
  949.  
  950. --------------------------------------------------------------
  951.  
  952. Q 2r-16: How can I control the timeout of a context handle?
  953.   Sometimes, the context-rundown routine gets called immediately when the 
  954.   client is killed, and sometimes it takes a (relatively) long time. Why?
  955.  
  956. A: 
  957.   The DCE runtime calls the context rundown routine as soon as it notices
  958.   that the connection with the client has been lost.  Exactly when the runtime
  959.   will notice depends on the communications protocol.
  960.  
  961.   If the conversation is using a connection-oriented protocol like TCP,
  962.   then the runtime depends on the protocol to notify it of a lost connection;
  963.   if the client crashes or exits, the speed with which the server is
  964.   notified depends on the TCP implementation and may be quick or very slow.
  965.   If the socket is shut down gracefully, the rundown may be called
  966.   immediately; otherwise it all depends on the timeout parameters in TCP.
  967.   You may be able to adjust the timing by changing parameters in your
  968.   network stack, but it will affect the whole system, not just DCE.
  969.  
  970.   With a connectionless protocol like UDP, the runtime generates its own
  971.   keepalive messages to test the "connection". (Actually, they are
  972.   "I'm Not Dead Yet" messages from the client.) If the client exits, the
  973.   server will assume the connection is down after a number of missed
  974.   messages.
  975.  
  976.   Thus the speed with which your server is notified after a client crashes
  977.   may vary from platform to platform due to differences in TCP implementation,
  978.   and from minute to minute on the same platform depending on whether the
  979.   client happens to use a TCP or UDP binding handle.
  980.  
  981.   Moral: context rundown allows the server to clean up, but is not
  982.   a real-time monitoring tool.
  983.  
  984. --------------------------------------------------------------
  985. Q 2r-17: A server has moved or otherwise changed its binding information.
  986.    How do I make the client obtain the new binding ?
  987. A: 
  988.   First, remember that a client must always be prepared to deal with
  989.   stale binding handles. Before starting to make RPCs, call 
  990.   rpc_mgmt_is_server_listening() to verify the handle, and continue
  991.   importing bindings until you get one that works.
  992.  
  993.   If the server information has changed recently, the information in
  994.   the client's cache may need updating.  Call rpc_ns_mgmt_set_exp_age()
  995.   with an expiration_age value of 0 to force an update.
  996.  
  997. --------------------------------------------------------------
  998. Performance
  999. --------------------------------------------------------------
  1000. Q 2p-01:  How efficient is DCE RPC?
  1001.  
  1002. A:
  1003.  
  1004.   Performance testing at several user organizations has shown that
  1005.   DCE RPC performance is similiar to other RPC implementations when
  1006.   doing the same things.  The throughput and response times for a
  1007.   series of remote procedure calls is similiar.
  1008.  
  1009.   The use of features in DCE not present in other implementations
  1010.   may consume additional time and resources.  For example,
  1011.   name-based binding may required additional time, depending on the
  1012.   number of directories traversed.  Using the packet integrity and
  1013.   packet privacy features of the security service can increase
  1014.   processing times as a linear function of message sizes.
  1015.  
  1016.   There are three papers providing preliminary performance data
  1017.   published in:
  1018.  
  1019.      DCE--The OSF Distributed Computing Environment, 
  1020.      Lecture Notes in Computer Science #731, Springer-Verlag,
  1021.      (see Q 3.02 for ISBN)
  1022.  
  1023.  
  1024.   IBM has done quite a bit of performance testing of DCE.  Many
  1025.   of the reports are available on line; go to IBM's corporate
  1026.   Web page, http://www.ibm.com, and choose the search feature to
  1027.   search for something like "dce performance".  To summarize a few
  1028.   of the results in these reports:
  1029.  
  1030. (*) RPC time increases linearly with the size of the data.
  1031. (*) Passing a large array in one RPC call is about the same speed
  1032.         as using a pipe
  1033. (*) Passing a large array in several RPC calls is slower than
  1034.         a single call using a pipe
  1035. (*) The "packet integrity" security level slows the RPC, nearly
  1036.         doubling the total time for calls.
  1037. (*) The "packet privacy" level incurs a several-fold increase in time.
  1038. (*) RPC is slower than simply making socket calls directly.
  1039. (*) The time spent on RPC overhead was a small fraction of the total
  1040.         processing time in a realistic business scenario.
  1041. (*) RPC is pretty fast on Intel procesors (running OS/2).
  1042.  
  1043.  
  1044. --------------------------------------------------------------
  1045. Q 2p-02:  What is the practical limit on the size of a DCE cell?
  1046.  
  1047. A:
  1048.  
  1049.   Good question. There are no hard and fast answers,  but there are
  1050.   some large-ish cells in operation.
  1051.  
  1052.   Certainly it is reasonable to plan on cells with thousands of
  1053.   nodes and perhaps tens of thousands of users.
  1054.  
  1055.   The University of Michigan Center for Information Technology
  1056.   Integration has done a study in which they added 50,000 entries
  1057.   to the Cell Directory and to the security registry.  Their results
  1058.   are reported in technical reports 93-12 and 94-1.  See Q 3.01 for
  1059.   the ftp site for CITI tech reports.
  1060.  
  1061.   Lexis-Nexis has a more recent study in which they added 400,000 accounts
  1062.   to the DCE registry. The write-up was available at their web site
  1063. http://www.lexis-nexis.com/
  1064. but if it is still there, you apparently must be a subscriber to see it.
  1065.  
  1066.   Several years ago
  1067.   IBM's DCE performance testing (see Q 2p-01 above for citation)
  1068.   includes load testing to simulate the environment of a large cell.
  1069.   A short, oversimplified, summary is that server machines based
  1070.   on 486/66 and P90 (running OS/2) could support the projected needs
  1071.   of a cell with 10,000 users.  An informal post on Usenet claimed that
  1072.   a test on an AIX platform had reached over 700,000 users created in the
  1073.   security server.
  1074.  
  1075.   IBM's OS/390 DCE server includes modifications to the security server to
  1076.   use a better backing store so that the entire set of principals need not
  1077.   be keep in-core.
  1078.  
  1079.  
  1080. --------------------------------------------------------------
  1081. Q 2p-03:  How much memory and disk space is required for DCE services?
  1082.  
  1083. A:
  1084.  
  1085.   This depends on the size of the cell, the number of users,
  1086.   number of services, etc.
  1087.  
  1088.   According to a paper present by Dan Hamel of Transarc, at the
  1089.   Decorum conference in February 1994, the following can be used
  1090.   as rough guidelines:
  1091.  
  1092. (*) Security server: 2k per principal/account
  1093.                      same at replicated sites
  1094. (*) Directory server: 10k per directory, 1k per object
  1095.                       same at replicated sites
  1096. (*) end-user machines: Each dce_login creates new credential files,
  1097.                       which can build up.  Space usage can range
  1098.                       from less than 1k to over 100k. 
  1099.  
  1100.   The security server as shipped by the Open Group keeps all security registry
  1101.   information resident in main memory, which means that the security
  1102.   host machine needs memory as well as disk.
  1103.  
  1104. --------------------------------------------------------------
  1105. Q 2p-04:  How can I control the number of concurrent client connections
  1106.         and the size of the request queue on a server?
  1107.  
  1108. A:
  1109.  
  1110.   The rpc_server_listen() call creates a pool of threads to
  1111.   handle incoming RPCs.  The server can be actively working on
  1112.   at most this many RPCs simultaneously.  The size of the pool 
  1113.   is controlled by a parameter to rpc_server_listen.  This is
  1114.   the primary place where you are expected to control the number
  1115.   of simultaneous connections.
  1116.  
  1117.   If you want to go deeper, into the question of what happens
  1118.   when all the server-listen threads are busy, things become
  1119.   tricky, because there are so many factors affecting the answer.
  1120.  
  1121.   If all the server threads are currently busy, incoming requests
  1122.   will be queued by the RPC runtime.  There is not an explicit
  1123.   API for controlling the size of this queue.  The rpc_use_protseq*()
  1124.   calls have a "max calls" parameter, but its effect is murky and
  1125.   it may be ignored completely by the implementation.
  1126.  
  1127.   If the RPC queue is full, the runtime will not accept any more
  1128.   network messages.  Incoming requests will therefore be held at
  1129.   the network protocol layer, which maintains a queue of its own.
  1130.   If the network layer's queue is full then the incoming message will
  1131.   be rejected and the client will be told that it is unable to connect
  1132.   to the server.
  1133.  
  1134.  
  1135. --------------------------------------------------------------
  1136. Q 2p-05:  My server gets a stack error when sending large objects.  How
  1137.         can I avoid this?
  1138.  
  1139. A:
  1140.  
  1141.   Each thread in a process is assigned a fixed area for its
  1142.   procedure-call stack.
  1143.   The stubs normally marshall and unmarshall parameters in space 
  1144.   allocated on the thread's stack.  If the parameters are large,
  1145.   the stack size may be exceeded.  In most thread implementations,
  1146.   the stack size cannot be increased after the thread is created.
  1147.   For threads created explicitly by your application, you can adjust
  1148.   the size of the thread stack by setting an attribute before calling 
  1149.   pthread_create().
  1150.   However, server threads are created automatically, so that method
  1151.   won't work; instead, call rpc_mgmt_set_server_stack_size() before
  1152.   starting the threads with rpc_server_listen().
  1153.  
  1154.   Another possibility is to use the [heap] attribute to have 
  1155.   some parameter types marshalled on the heap instead of the stack.
  1156.  
  1157.   You should know that current implementations of the IDL compiler
  1158.   generate recursive code to marshall linked lists.  Therefore, passing
  1159.   a long linked list may cause stack overflow due to all the
  1160.   recursive calls.
  1161.  
  1162. --------------------------------------------------------------
  1163. Q 2p-06:  How do I get clients to connect to the nearest server?
  1164.  
  1165. A:
  1166.  
  1167.   It's not easy.  Currently, vanilla DCE gives essentially no help.
  1168.  
  1169.   For clients for which you have source code, you can use the
  1170.   rpc_ns_binding_lookup*() routines to search through the binding
  1171.   handles and apply some custom logic to finding a nearby server.
  1172.  
  1173.   For standard DCE services, such as CDS and security queries,
  1174.   you get a random server, which could be anywhere in the cell.
  1175.   For the security service, you might be tempted to set the
  1176.   BIND_PE_SITE environment variable and the file
  1177.   /opt/dcelocal/etc/security/pe_site to hardwire each client host
  1178.   to its nearest security replica, but this is a hack with serious
  1179.   administrative downside: if the replica goes down or is moved,
  1180.   all the associated clients must be manually updated.
  1181.  
  1182.   Individual products may provide additional help. For example
  1183.   Transarc's DCE now includes a feature that lets clients connect to the
  1184.   closest CDS server. Details at 
  1185.   http://www.transarc.com/Public/Support/dce/admin_examples/directory/pref.html.
  1186.  
  1187. --------------------------------------------------------------
  1188. Q 2p-07: Should I choose UDP or TCP for my RPC?
  1189.  
  1190. A:
  1191.  
  1192.   First have you considered the advantages of using all protocol sequences?
  1193.   RPCs work the same either way.  DCE's implementation provides the same
  1194.   security and reliability over all communication protocols.  In most cases
  1195.   the performance is about the same as well.
  1196.  
  1197.   For some applications and some platforms, there may be reasons to prefer
  1198.   one protocol over another.  For instance, if your platform has a poor
  1199.   implementation of UDP, that could be a reason to prefer TCP, or vice-versa.
  1200.  
  1201.   For heavily-loaded servers, UDP is often recommended over TCP.
  1202.   In low-bandwidth networks, or when running servers under a debugger,
  1203.   TCP may be preferred.
  1204.  
  1205.   Transarc has a web page providing more information on the relative
  1206.   merits of UDP and TCP, at 
  1207.   
  1208.   http://www.transarc.com/Public/Support/dce/prog_examples/rpc/tcp_and_udp.html
  1209.  
  1210.  
  1211. --------------------------------------------------------------
  1212. Cell Configuration
  1213. --------------------------------------------------------------
  1214.  
  1215. --------------------------------------------------------------
  1216. Q 2cc-01:  Is it possible for a machine to be a member of more than one DCE cell?
  1217.  
  1218. A:
  1219.  
  1220.    No.  A machine can only be in a single cell. However, it is
  1221.    possible for cells to cooperate.  See the next question.
  1222.  
  1223.    DCE v1.1  will allow for "hierarchical cells", which may 
  1224.    solve the problem, depending on why you want to have a machine
  1225.    in two cells.
  1226.  
  1227. --------------------------------------------------------------
  1228. Q 2cc-02:   How do I configure cells to find each other using DNS?
  1229.  
  1230. A:
  1231.  
  1232.   In order for a client program in cell A to find a server in cell B,
  1233.   it must be able to find the CDS server in cell B;  once communication
  1234.   with CDS is established, everything else in the cell can be found.
  1235.   One of the ways to make the location of of the cell known is to
  1236.   create the proper entries in the Internet Domain Name Service (DNS).
  1237.  
  1238.   Suppose we want to make a cell available, and that the name
  1239.   of the cell is "/.../cell.mauney.com".  We must create
  1240.   two DNS entries.  One entry will provide the IP address of
  1241.   the machine that runs the CDS server within the cell.
  1242.   The other entry gives other details about the cell.
  1243.  
  1244.   The first entry, which advertises the location of the CDS server,
  1245.   can be either an MX or an AFSDB record type.  The DCE code
  1246.   will be happy to use either one, but you as a system administrator
  1247.   have to make a choice; both possibilities have drawbacks.
  1248.   The MX record type is intended for mail exchange, so using it
  1249.   for DCE is a bit of a kludge; and if you already
  1250.   have a machine in your name with the same hostname as your cell
  1251.   name and it ever participates in e-mail, then you'll have a conflict.
  1252.   On the other hand, the AFSDB record is new and not supported by
  1253.   all nameservers; you'll need Bind version 4.9.2 or later.
  1254.  
  1255.   The MX or AFSDB record relates the cell name to a host name.
  1256.   DCE ignores the "preference" value of an MX record.  With AFSDB,
  1257.   you should use sub-type 2.  E.g.,
  1258.  
  1259.     cell.mauney.com.  IN MX  200 tophat
  1260.  
  1261.   or
  1262.  
  1263.     cell.mauney.com.  IN AFSDB  2 tophat
  1264.  
  1265.   where "tophat" is the hostname of the machine that runs the CDS master
  1266.   server.
  1267.  
  1268.   The second piece of information in DNS is a TXT record giving
  1269.   UUIDs for the CDS master replica and clearinghouse.  You obtain
  1270.   the information with the command "cdscp show cell as dns", and
  1271.   copy the information verbatim into DNS.  E.g.
  1272.  
  1273.     cell.mauney.com.  IN TXT "1
  1274. 44007e75-08b4-11ce-9055-08002b32b23b Master /.../cell.mauney.com/tophat_ch  43373550-08b4-11ce-9055-08002b32b23b tophat.mauney.com"
  1275.  
  1276.  
  1277.   See 
  1278.   http://www.transarc.com/Public/Support/dce/admin_examples/misc/cross_cell.html
  1279.   for a description of how it works, and some troubleshooting
  1280.   hints in case it doesn't.
  1281.  
  1282. --------------------------------------------------------------
  1283. Q 2cc-03:  Is it possible for a user in one cell to use secure services
  1284.   in another cell? 
  1285.  
  1286. A:
  1287.  
  1288.   Yes.  The Access Control List (ACL) permits three entry types --
  1289.   foreign_user, foreign_group and foreign_other -- which specify the
  1290.   permissions available to users on other cells.  All that is
  1291.   required for intercell access, other than physical connectivity,
  1292.   is for the two cell's security services to be configured to know
  1293.   about each other.
  1294.  
  1295.   There is a command, the rgy_edit "cell" command, that must be run, once,
  1296.   by the cell admin of the two cells that wish to communicate.  After
  1297.   that, it's all transparent.
  1298.  
  1299.  
  1300. --------------------------------------------------------------
  1301. Q2cc-04:: How do I change the name of my cell?
  1302.  
  1303. A:
  1304.   You don't.
  1305.  
  1306.   The cell name in embedded into too many hidden places.  Live with
  1307.   the old cell name, or create a new cell and configure it to look
  1308.   like the old cell.
  1309.  
  1310.   If you haven't created your cell yet, learn this lesson and
  1311.   choose a cell name  you can live with.
  1312.  
  1313. --------------------------------------------------------------
  1314. Q2cc-05:: How do I change the IP address of
  1315.       a host in my cell?
  1316.  
  1317. A:
  1318.   Very Carefully.
  1319.   You need start this before changing the address of the machine.
  1320.  
  1321.   Transarc has several files of tips on the subject.
  1322.   See. http://www.transarc.com/Public/Support/dce/admin_examples/misc/ip.html. 
  1323.  
  1324.  
  1325. --------------------------------------------------------------
  1326. Q2cc-05:: How do I do inter-cell delegation?
  1327.  
  1328. A:
  1329.  
  1330.   Our initial answer to that question was:
  1331.   Inter-cell delegation is a poor idea from a security standpoint.
  1332.   Therefore, DCE does not implement it.  That answer may have been too
  1333.   absolute. It may be better to say that DCE severely restricts delegation
  1334.   because of the security problems.
  1335.  
  1336.   Keys Botzum's Q&A 
  1337.   http://www.transarc.com/~keys/encina/dce-enc-questions.htm
  1338.   says the following:
  1339.     The delegation chain of RPCs may cross only one cell boundary.  This means
  1340.     that with two cells you can not cross back into the originating cell,
  1341.     and any delegation involving 3 cells will not work at all.
  1342.  
  1343.  
  1344.  
  1345. --------------------------------------------------------------
  1346. Q 2cc-07:: How can I find out who is currently logged in to a DCE cell?
  1347.  
  1348. A:
  1349. You can't.
  1350.  
  1351. DCE does not track this information, 
  1352. does not supply any tools to help collect this information,
  1353. does not provide any hooks in the security server to allow you
  1354. to collect this information.
  1355.  
  1356. Answering the question of "who is logged in" is difficult,
  1357. in part because in the DCE architecture it is hard to decide exactly
  1358. what the question means.
  1359. For example, if a person is logged in to a DCE client machine,
  1360. but his DCE tickets have expired, does that person count as logged in
  1361. or not?
  1362.  
  1363. If you must track who is logged in, you'll need to build
  1364. your own service to maintain the information.
  1365. An obvious approach is to capture login and logout events and
  1366. report them to some central location; this requires that you be able
  1367. to instrument all login/logout commands on hosts within your cell.
  1368. Another approach would be a daemon that runs on each host and
  1369. periodically notices ticket files;  there are security concerns with this
  1370. approach.
  1371. Or you could just run "rwho" :-)
  1372.  
  1373.  
  1374.  
  1375. --------------------------------------------------------------
  1376. Security
  1377.  
  1378. --------------------------------------------------------------
  1379. Q 2s-01:  Where can I find an ACL manager to include in my application?
  1380.  
  1381. A:
  1382.  
  1383.     DCE version 1.1 includes a basic ACL manager library.
  1384.  
  1385.     HP's OODCE (DCE C++ class library) provides you with a default, 
  1386.     built-in ACL Manager with the server class.
  1387.  
  1388.     Transarc's Encina (transaction monitor) product includes
  1389.     an ACL manager.
  1390.  
  1391.     Lockhart's book contains a sample ACL manager. (see Q 3.02)
  1392.  
  1393.    Hu's book on DCE Security Programming contains a sample ACL manager.
  1394.    (see Q.3.02) 
  1395.  
  1396.     The code from both the Lockhart and Hu books is available on-line.
  1397.     See Q 3.07 for URLs.
  1398.  
  1399.   http://www.transarc.com/Public/Support/dce/prog_examples/security/acl_stuff/acl_stuff.html
  1400.   includes sample code for a greet-derived client/server pair where the
  1401.   server uses the DCE 1.1 ACL manager library
  1402.  
  1403.  
  1404. --------------------------------------------------------------
  1405. Q 2s-02:  Does DCE Security interoperate with other Kerberos systems?
  1406.  
  1407. A:
  1408.  
  1409.   Basically, no, or maybe yes, depending on what you want to do.
  1410.  
  1411.   To use authenticated DCE services, you must have credentials from
  1412.   the DCE security service; vanilla Kerberos v5 tickets aren't sufficient.
  1413.   But then, to use DCE services you must be using DCE RPC, so this
  1414.   is not really a problem.
  1415.  
  1416.   Going the other way, it is expected that a DCE security server
  1417.   can issue tickets that can be used by vanilla Kerberos applications.
  1418.   The Open Group was wary of promising this until the Kerberos v5 specs were
  1419.   published, but now that the Kerberos RFC has been published, Open Group
  1420.   anticipates guaranteeing interoperability sometime "soon".
  1421.  
  1422.   In a little more detail, the way to think about this is as follows:
  1423.  
  1424.         Kerberos offers 2 services (Authentication Service, Ticket
  1425.         Granting Service) over 1 communication mechanism (UDP port 88).
  1426.  
  1427.         DCE security offers 3 services (AS, TGS, Privilege Service) over
  1428.         2 communication mechanisms (UDP port 88, RPC).
  1429.  
  1430.         Where Kerberos and DCE security intersect (AS, TGS over UDP port
  1431.         88), the services are identical.
  1432.  
  1433.   DCE V1.1 supports the GSSAPI, so non-DCE services that use GSSAPI
  1434.   can be integrated with DCE security server.
  1435.  
  1436.  
  1437. --------------------------------------------------------------
  1438. Q 2s-03:  Can I control the endpoints assigned to DCE servers?
  1439.   For example, to allow DCE clients and servers to communicate
  1440.   across a firewall?
  1441.  
  1442. A:
  1443.  
  1444.   Yes.
  1445.  
  1446.   You can, of course, assign well-known endpoints to all your servers,
  1447.   but that is a truly bad idea, and won't work for services that you
  1448.   don't have source code for (such as CDS and the security registry).
  1449.  
  1450.   The endpoint mapper will examine the environment variable
  1451.   RPC_RESTRICTED_PORTS and choose endpoints only in that range.
  1452.   You can make the range as small as necessary, and configure your
  1453.   firewall to pass traffic only to those ports.
  1454.  
  1455.   The format of RPC_RESTRICTED_PORTS is a list of settings, separated by
  1456.   colons.  Each setting is of the form protocol[lo-hi].  E.g.
  1457.  
  1458.   export RPC_RESTRICTED_PORTS=ncacn_ip_tcp[5000-6000]:ncadg_ip_udp[5000-6000]
  1459.  
  1460.  
  1461. --------------------------------------------------------------
  1462. Q 2s-04: Do DCE servers automatically update their long term secret keys?
  1463.  
  1464. A:
  1465.     No.
  1466.  
  1467.     Except for exceptional circumstances, all DCE servers should
  1468.     periodically change their long-term key. However, neither the
  1469.     servers provided by DCE nor those written by you or third
  1470.     parties will do this out-of-the-box.
  1471.  
  1472.     The way to have a server update its key is by spawning a
  1473.     thread that calls sec_key_mgmt_manage_key() (which never returns under
  1474.     normal circumstances).  As distributed by Open Group, DCE has no password
  1475.     expirations set, so sec_key_mgmt_manage_key() won't actually do anything.
  1476.     You may set the password expiration time or lifespan using an admin
  1477.     tool such as rgy_edit or dcecp.
  1478.  
  1479.     In 1.0.x releases, DCE only enforced passwd expiration in the clients
  1480.     (such as printing a warning in dce_login).  As of DCE 1.1, however,
  1481.     the security server will no longer grant a TGT for an account who's
  1482.     password/key has expired, so servers that aren't correctly running the
  1483.     manage key code before their password expires will require
  1484.     administrative intervention to become operational again.
  1485.  
  1486.     The following table shows what the Open Group-provided servers do:
  1487.  
  1488.        cdsd -- yes; uses FILE:/krb5/v5srvtab
  1489.        dced -- yes (uses FILE:/krb5/v5srvtab and manages hosts/<machine>/self)
  1490.        dtsd -- not applicable; runs as the machine principal
  1491.        pwd_strengthd -- yes; uses FILE:/krb5/pwd_strength_tab
  1492.        secd (maintains three keys) -- not applicable
  1493.  
  1494.  
  1495. --------------------------------------------------------------
  1496. Q 2s-05:
  1497.     What problems might I cause by changing the expiration time
  1498.     or password lifespan in a running cell?
  1499.  
  1500.  
  1501. A:
  1502.     DCE v1.1 will not let you authenticate (acquire a TGT) with an expired
  1503.     password. As such, if you change the "password lifespan" policy from 
  1504.     "never" or a period longer than 30 days, to days, then every host
  1505.     principal, user and server account that has not (by coincidence) updated
  1506.     their password/key within the last 30 days, will be locked out.  Users 
  1507.     would not be able to log in, server applications would no longer be able
  1508.     to obtain credentials and the dceds would no longer be able to 
  1509.     obtain/refresh their machine credentials.
  1510.  
  1511. --------------------------------------------------------------
  1512.  
  1513. Q2s-06: How do I begin to force password changes,
  1514.     without getting into the trouble described in the previous question?
  1515.  
  1516. A: Set an explicit "expiration date" policy, some time in the near future.
  1517.     (Make sure it's at least 30 minutes from the current time, to give
  1518.     the key management threads time to catch the change and a couple of
  1519.     chances to make the change.) At that specified date/time, all users,
  1520.     server apps and machines should have updated their passwords/keys.
  1521.     Recover from any problems that occurred (machines down during that
  1522.     time, users forgetting...), then set the "password lifespan" policy
  1523.     field to the desired limit.
  1524.  
  1525. --------------------------------------------------------------
  1526. Q 2s_07:  Do all versions of DCE support the sec_key_mgmt_manage_key()
  1527.      functionality in the same way?
  1528.  
  1529. A:  Unfortunately not.  DCE 1.0.x releases had a limitation in
  1530.     this key mgmt call, in that it would not wake up until shortly before
  1531.     the key was due to expire (based on the expiration data that it obtained
  1532.     when the call was started or the last time through the loop after a
  1533.     change).  DCE 1.1 should no longer have this problem, as the call
  1534.     wakes up every 10 minutes to see whether the expiration time has
  1535.     changed.
  1536.  
  1537. --------------------------------------------------------------
  1538. Q 2s_08:  How can I work around the key_mgmt problem if I have older 
  1539.     client machines, but DCE 1.1+ based servers?
  1540.  
  1541. A:  Preferably, upgrade them all to an DCE 1.1 or later.  If this is not possible,
  1542.     manually change the keys for each older client:
  1543.     rgy_edit-> kta -p hosts/<hostname>/self -a -r
  1544.     (on each DCE 1.0.x-based client machine).  Do this for any accounts in the
  1545.     default keytable, and any servers running on older versions that also use
  1546.     the sec_key_mgmt_manage_key() call.
  1547.  
  1548.  
  1549. --------------------------------------------------------------
  1550. Compatibility
  1551. --------------------------------------------------------------
  1552. Q 2c-01:  Will Windows NT communicate with DCE?
  1553.  
  1554. A:
  1555.  
  1556.    Windows NT comes with an RPC which interoperates with DCE RPC.
  1557.    Windows 95 apparently provides this interface as well.
  1558.    However, it is not quite the same as DCE.
  1559.  
  1560.    The wire-level protocol is the same as DCE RPC, so applications
  1561.    running on NT can communicate with DCE applications on other
  1562.    platforms.  However, the application source code is not instantly
  1563.    portable.  Microsoft changed the format of procedure names
  1564.    and moved the status result from a parameter to the function value.
  1565.    This kind of change can be covered up by a set of preprocessor
  1566.    macros, but it is a change to be dealt with.
  1567.  
  1568.    A more serious consideration is that Microsoft's RPC does not
  1569.    use the standard DCE services, such as directory service and security.
  1570.    Thus applications that cross between Microsoft RPC and DCE will have
  1571.    to make unauthenticated calls and use string bindings.
  1572.    Digital bundles a Name Service Interface Daemon (nsid) into its
  1573.    DCE products.  The nsid fills in the gap and allows an NT client to
  1574.    get bindings from CDS.
  1575.  
  1576.    See the book "Distributing Applications Across DCE and Windows NT" 
  1577.    for more details (see Q 3.02).
  1578.  
  1579.    The good news is that DEC and Gradient both have DCE
  1580.    products for NT. Digital has a DCE client product available
  1581.    for both Intel and Alpha architectures.  Gradient has a full
  1582.    secure core product.
  1583.  
  1584.    Information on Digital's DCE on NT product is available at
  1585.           http://www.digital.com/info/Customer-Update/940412019.txt.html
  1586.    Information from Gradient can be obtained by sending email to
  1587.    info@gradient.com
  1588.    or at their Web site:
  1589.       http://www.gradient.com/products/products.htm
  1590.  
  1591.  
  1592. --------------------------------------------------------------
  1593.  
  1594. Q 2c-02:  Can I use DCE from C++?
  1595.  
  1596. A:
  1597.  
  1598.    Yes.  First of all, since you can call C functions from C++
  1599.    you can access all the DCE services from a C++ program.  But
  1600.    that will not give you the benefits of C++.
  1601.  
  1602.    There are several packages that provide a C++ interface to DCE.
  1603.    They different quite a bit in style and approach, so you'll
  1604.    need to consider them carefully in light of your own needs and
  1605.    preferences.
  1606.  
  1607.    Objtran was produced by Citibank, and is available by anonymous
  1608.    ftp at ftp://wilma.cs.brown.edu/pub/Objtran.tar.Z
  1609.  
  1610.    Hal Computer Systems developed a set of classes called  DCE++.
  1611.    That part of the company was spun off into Chisholm Technologies.
  1612.    For information on DCE++, see their web page:
  1613.    http://www.chistech.com/products/dce++.html
  1614.  
  1615.    Hewlett-Packard has a product called OODCE.  It is for sale,
  1616.    and currently supported only on HP-UX.  For technical information
  1617.    retrieve the OSF RFC #49 (see Q 3.05);  for sales
  1618.    information contact your HP sales office.
  1619.  
  1620.    DCE version 1.2.1 will include IDL support for C++.  The OSF (oops,
  1621.    the Open Group) recently announced that OODCE will be adopted as
  1622.    part of DCE in a future version.
  1623.  
  1624.    Transarc's Encina v2.0 includes Encina++, C++ support for Encina and DCE.
  1625.  
  1626.  
  1627. --------------------------------------------------------------
  1628.  
  1629. Q 2c-03:  Can I write an application that uses DCE and X11/Motif?
  1630.  
  1631. A:
  1632.  
  1633.   Yes but there are several serious pitfalls.
  1634.  
  1635.   The X11/Xt/Motif libraries may not be thread-safe.  For example,
  1636.   suppose one thread calls a function in Xt, which calls a nonthreadsafe
  1637.   malloc(), which then gets preempted.  The next thread may call
  1638.   a threadsafe malloc() that comes with DCE. When control returns to 
  1639.   the first malloc(), any assumptions about the state of the heap are
  1640.   invalid.
  1641.  
  1642.   Also, Motif/Xt/Xlib are not currently reentrant wrt/themselves.  You can't 
  1643.   have multiple threads concurrently manipulating any Motif/Xt/Xlib 
  1644.   global state. Fortunately this issue is under you control when 
  1645.   designing the application.  X11R6 includes a thread-safe version of
  1646.   Xlib, but it will be a while yet before the vendors are all delivering
  1647.   thread-safe Motif.
  1648.  
  1649.   A related issue is that XtAppMainLoop() waits in a select() for activity,
  1650.   coupled with the fact that DCE also waits in a select() for activity.
  1651.   Unless the two are select()s are cooperating, one or the other will be
  1652.   starved. This is a platform-specific issue, you should check with your
  1653.   DCE vendor for full details.  
  1654.   If it is a problem in your environment, the standard solution is to
  1655.   encapsulate the GUI in one process, the DCE client code in another process,
  1656.   and connect them with a simple IPC such as a Unix pipe.
  1657.  
  1658. --------------------------------------------------------------
  1659. Q 2c-04: Is DCE RPC compatible with ONC RPC?
  1660.  
  1661. A:
  1662.  
  1663.   No.  DCE and ONC both use the concept of the Remote Procedure Call,
  1664.   but the wire protocols that they use are not compatible.  You will
  1665.   need to use either DCE for both client and server, or ONC for
  1666.   both client and server;  both products are available for most platforms.
  1667.  
  1668.   It is possible for a single program to use both DCE and ONC.
  1669.   Thus a server could be built to server both DCE and ONC clients,
  1670.   or a gateway could be built to accept one kind of RPC and forward
  1671.   to a server of another kind.
  1672.  
  1673.  
  1674. --------------------------------------------------------------
  1675. Q 2c-05: Is XDR the same as, or compatible with, NDR?
  1676. If not, how do I convert from one to the other?
  1677.  
  1678. A:
  1679.   No
  1680.  
  1681.   (For those of you not fluent in three-letter abbreviations,
  1682.   XDR is eXternal Data Representation, the data format used on the wire
  1683.   by ONC, and NDR is Network Data Representation, used on the wire by DCE.)
  1684.   XDR and NDR use different methods for tagging data items.
  1685.  
  1686. --------------------------------------------------------------
  1687. --------------------------------------------------------------
  1688.  
  1689.  
  1690.       Tier 3 -- Data Management
  1691.  
  1692.  
  1693. --------------------------------------------------------------
  1694. Q 3.01:  Where can I get online information about DCE
  1695.  
  1696. A:
  1697.  
  1698.   First of all, the official documentation for DCE is not available 
  1699.   for anonymous ftp. But there are several sites providing
  1700.   lots of other information.  Here are some of the most useful:
  1701.  
  1702.   The Open Software Foundation maintains a WWW server with information
  1703.   about all the Open Group products, including DCE. 
  1704.         http://www.opengroup.org/tech/dce/
  1705.   takes you directly to the DCE index.
  1706.   Highlights of the Open Group's web server include a complete list of DCE
  1707.   products, the DCE Request for Comments documents (RFCs), the
  1708.   DCE product catalog (see Q 1.04) and a 
  1709.   hypertext version of the Frequently Asked Questions list.
  1710.  
  1711.   Project Pilgrim at the University of Massachussetts has a DCE homepage at
  1712.         http://info.pilgrim.umass.edu/pub/osf_dce/osf.html
  1713.   Their server provides a complete set of RFCS, searchable by http
  1714.   and also by gopher, at
  1715.         gopher://info.pilgrim.umass.edu/77/lib/.wais-sources/osf-dce-rfc.txt
  1716.   and a directory of contributed software, currently consisting of
  1717.   performance measurement utilities from Pilgrim, and book examples from
  1718.   O'Reilly&Associates.
  1719.  
  1720.   The Center for Information Technology Integration at the
  1721.   University of Michigan has several pieces of DCE information
  1722.   on their servers. The big attraction here is the set of
  1723.   CITI Technical Reports related to DCE.
  1724.   You can get to the tech-reports from the CITI web server,
  1725.         http://www.citi.umich.edu/techreports
  1726.  
  1727.   Transarc has some hints and examples available on the web.
  1728.   http://www.transarc.com/Public/Support/dce/dceIndex.html
  1729.   These are informal, practical discussions of how to handle real-world
  1730.   problems such as changing the IP address of the CDS server,
  1731.   implementing peer-to-peer RPC, handling key management, etc.
  1732.  
  1733.   Also at Transarc's Web Site, there is on-line documentation for the
  1734.   Solaris 2.5.1 DCE 1.1 product. This is the complete set of OSF DCE and DFS
  1735.   documentation with some additions for the Solaris port. 
  1736.  
  1737.   Keys Botzum maintains an information page at
  1738.   http://www.transarc.com/~keys/encina/dce-enc-questions.htm
  1739.   Look for the link to his personal question and answer page, which contains
  1740.   DCE and Encina information.
  1741.  
  1742.   Intellisoft's advutorial "DCE and The Enterprise"
  1743.   is on-line and available via Intellisoft's web site
  1744.   http://www.isoft.com 
  1745.  
  1746.   The PC Webopaedia http://www.sandybay.com/pc-web
  1747.   contains pointers to number of DCE-related web pages (including this FAQ),
  1748.   including magazine articles.  Use the search feature to find DCE links.
  1749.  
  1750.   IBM has a support web page for DCE on AIX at
  1751.   http://service.boulder.ibm.com/dssdce
  1752.  
  1753. --------------------------------------------------------------
  1754. Q 3.02:  What books are published on DCE?
  1755.  
  1756. A:
  1757.  
  1758.   Documentation on DCE should be suppiled with vendor products.  The
  1759.   Open Group sells complete sets of documentation. The DCE set consists of 
  1760.   14 volumes and costs $525.  Documentation for version 1.1 is 
  1761.   available.
  1762.   The three volumes of specifications (AES) can be purchased separately
  1763.   for $100 (plus shipping).
  1764.  
  1765.     Order documentation in the US by contacting: 
  1766.  
  1767.     OSF??? Direct Channels
  1768.     Phone: 617-621-7300
  1769.     E-mail:  direct@osf.org
  1770.  
  1771.  
  1772.     Contact OSF Direct in Europe, East Asia, and Africa
  1773.     at OSF's Brussels Office
  1774.  
  1775.         Open Software Foundation
  1776.         Avenue des Pleiades-laan 15
  1777.         1200 Brussels
  1778.         BELGIUM
  1779.     Phone: +32 2 772 8888, fax: +32 2 772 9228
  1780.  
  1781.  
  1782.     Contact OSF Direct in the Pacific region at
  1783.  
  1784.         Open Software Foundation
  1785.         11-10, Kita-Aoyama 2-chrome
  1786.         Minato-ku, Tokyo 107
  1787.         JAPAN
  1788.     Phone +813-3479-4740; fax: +813-3479-4760
  1789.  
  1790.  
  1791.  
  1792.   The DCE documentation is also published by Prentice-Hall.  These
  1793.   books contain about the same material as the Open Group manuals, but
  1794.   are edited to improve the presentation. 
  1795.  
  1796.  
  1797.         Introduction to DCE                     ISBN 0-13-490624-1
  1798.         DCE Administration Reference            ISBN 0-13-643818-0
  1799.         DCE User's Guide and Reference          ISBN 0-13-643842-3
  1800.         DCE Application Development Guide       ISBN 0-13-643826-1
  1801.         DCE Application Development Reference   ISBN 0-13-643834-2
  1802.         DCE Administration Guide
  1803.           Vol. 1, Introduction                  ISBN 0-13-176546-9
  1804.           Vol. 2, Core Components               ISBN 0-13-176553-1
  1805.           Vol. 3, Extended Services             ISBN 0-13-176561-2
  1806.         Application Environment Specification/Distributed Computing
  1807.           RPC Volume                            ISBN 0-13-043688-7
  1808.  
  1809.  
  1810.   Other books on DCE:
  1811.  
  1812.      Practical DCE Programming
  1813.           by Charles Knouse (Hewlett Packard)
  1814.           Prentice Hall ISBN 0-13-324419-9
  1815.      Understanding OSF DCE 1.1 for AIX and OS/2
  1816.       by Rolf Lendenmann.
  1817.           Prentice Hall, ISBN: 0-13-493750-3 (paper)
  1818.      Understanding DCE, by Rosenberry, Kenney, and Fisher
  1819.           O'Reilly, ISBN 1-56592-005-8
  1820.      Guide to writing DCE Appplications,2nd edition
  1821.           by Shirley,  Hu, and Magid
  1822.           O'Reilly, ISBN 1-56592-045-7
  1823.      Distributing Applications Across DCE and Windows NT,
  1824.            by Rosenberry and Teague
  1825.            O'Reilly, ISBN 1-56592-047-3
  1826.      DCE Security
  1827.           by Wei Hu
  1828.       O'Reilly,  ISBN 1-56592-134-8
  1829.      DCE: A Guide to Developing Portable Applications
  1830.       Michael T. Peterson
  1831.       McGraw/Hill (Ranade Workstation Series)
  1832.       ISBN 0079118003 (hard)
  1833.       ISBN 0079118011 (paper)
  1834.      OSF DCE: Guide to Developing Distributed Applications,
  1835.           by H. W. Lockhart, Jr, 
  1836.           McGraw-Hill,(Ranade Workstation Series)
  1837.           ISBN 0-07-911481-4
  1838.      DCE--The OSF Distributed Computing Environment, Client/Server Model
  1839.        and Beyond; Proceedings of the International Workshop on DCE, 1993
  1840.        Lecture Notes in Computer Science #731, Springer-Verlag,
  1841.        ISBN 3-540-57306-2
  1842.  
  1843.   And for you German-speaking DCE-ers:
  1844.  
  1845.   DCE--Das OSF Distributed Computing Environment, Einfuerhrung und Grundlagen,
  1846.         by Alexander Schill, Springer-Verlag, ISBN 3-540-55335-5
  1847.  
  1848.  
  1849.   There are currently no books on DFS, but there
  1850.   is a recently published book on AFS, the predecessor to DFS. AFS has
  1851.   very much the same architecture and goals of DFS, though DFS uses DCE
  1852.   services throughout and most of the actual command names have been changed.
  1853.   However, the concepts of cells, filesets, and the DFS database replication
  1854.   mechanisms are practically equivalent. The book is
  1855.  
  1856.   Managing AFS: The Andrew File System,
  1857.    by Richard Campbell, Prentice-Hall, ISBN 0-13-802729-3.
  1858.  
  1859.  
  1860. --------------------------------------------------------------
  1861. Q 3.03:  Where can I get more information about DCE and DCE-related products?
  1862.  
  1863. A:
  1864.  
  1865.   With WWW, access the URL: "http://www.opengroup.org/tech/dce/
  1866.  
  1867.   The general response to any query of the form "Where can I get a _____ for
  1868.   DCE?" is "Contact 
  1869.   direct@osf.org" (phone +1 617 621-7300).
  1870.  
  1871.     This mail list will reach the people at Open Group that maintain contacts with 
  1872.     just about everbody that has a DCE product to sell.  You can get a listing
  1873.     of the vendors and their products.  These include DCE RPC debugging 
  1874.     environments, C++ toolkits, Visual-BASIC  development environments, etc. 
  1875.  
  1876.     This mail list also reaches the people at Open Group that maintain the
  1877.     lists of documentation available, both from OSF, and from outside OSF, 
  1878.     about DCE (and about Motif, DME, and OSF/1).
  1879.  
  1880.   Transarc maintains a mail alias, 
  1881. info-dce@transarc.com, which carries
  1882.   discussions about DCE. Send to info-dce-request@transarc.com to join the list.
  1883.   (Transarc also has a list for Encina:
  1884.   info-encina@transarc.com.)
  1885.   For information on Transarc products, send
  1886.   mail to  tsg@transarc.com.
  1887.  
  1888.   For Users of DCE on MVS, there is a mailing list:
  1889.         
  1890.   mvsdce-l@psuvm.psu.edu
  1891.  
  1892.   and a Web page (under construction):
  1893.         http://dcewww.citi.umich.edu:8080/mvsdce
  1894.  
  1895.  
  1896. --------------------------------------------------------------
  1897. Q 3.04:  What are DCE RFCs, and how can I get them?
  1898.  
  1899. A:
  1900.  
  1901.     DCE RFCs are requests for comments for ongoing DCE development.  They
  1902.     are similar in concept to the Internet RFCs.  Nothing in there is
  1903.     promised from by Open Group.  They are a formal way to pass ideas among DCE
  1904.     development partners.
  1905.  
  1906.     You can access them by WWW (or gopher) by:
  1907.         http://www.pilgrim.umass.edu/pub/osf_dce/RFC/rfc-index.html
  1908.  
  1909.         gopher://info.pilgrim.umass.edu/77/lib/.wais-sources/osf-dce-rfc.txt
  1910.  
  1911.  
  1912. --------------------------------------------------------------
  1913.  
  1914. Q 3.05:  Where can I get the Public Domain version of DCE?
  1915.  
  1916. A:
  1917.  
  1918.     In October 1994, Digital Equipment Corporation and Hewlett-Packard
  1919.     released into the public domain the RPC implementation used by DCE.
  1920.     This code includes the IDL compiler and the RPC runtime.  It does
  1921.     not include any of the other services: DTS, CDS, Security, DFS.
  1922.     In fact, it is not a sufficient base for a client machine, as it
  1923.     does not include the CDS, DTS, and security clerk processes that
  1924.     are normally required.
  1925.  
  1926.     The code is available on the Internet from several servers:
  1927.  
  1928.        ftp://ftp.digital.com/pub/DEC/DCE/PD-DCE-RPC.tar.Z
  1929.  
  1930.        http://www.pilgrim.umass.edu/pub/osf_dce/contrib/PD-DCE-RPC.tar.Z
  1931.  
  1932.        http://www.osf.org/mall/dce/
  1933.  
  1934.     Be sure also to read the licensing information found in the
  1935.     same directories.
  1936.  
  1937.     Be warned that building anything from this release is not a simple
  1938.     matter.  DCE uses an older draft of the Posix threads standard,
  1939.     the IDL compiler does some odd things with YACC, and there is no
  1940.     simple configuration mechanism.
  1941.  
  1942.     Jim Doyle has a DCE client package for RedHat Linux, and is working on 
  1943.     porting all of DCE to Linux/FreeBSD. See:
  1944.     http://www.bu.edu/~jrd/FreeDCE/
  1945.  
  1946.     Andrew Sandoval has made a Linux port available. See:
  1947.     http://www.netwaysglobal.com/DCE/
  1948.  
  1949.     Michael Peterson's work on DCE and Pthreads for Linux is available at:
  1950.     http://www.aa.net/~mtp
  1951.  
  1952.  
  1953. --------------------------------------------------------------
  1954.  
  1955. Q 3.06:  Is there a DCE Users Group I can join?
  1956.  
  1957. A:
  1958.  
  1959.     Yes.  Besides the Open Group itself, 
  1960.     there are local DCE users groups in several areas.
  1961.     Changes in the set of users groups have proven difficult
  1962.     to track in this FAQ, so contact the Open Group to find the
  1963.     user group nearest you.
  1964.  
  1965.  
  1966. --------------------------------------------------------------
  1967.  
  1968. Q 3.07:  Are there any example programs available on-line?
  1969.  
  1970. A:
  1971.   Yes.
  1972.  
  1973.    The Open Group's web site includes the 
  1974.   Open Software Mall, and the Mall includes a list of
  1975.   
  1976.   DCE-related free software.  This is a good starting point for
  1977.   a search.  All of the following links are to be found in
  1978.   the Mall.
  1979.  
  1980.   The examples from Hal Lockhart's book are available at the OG Software
  1981.   Mall. Note that you must start at the  Mall homepage
  1982.   and register before you can retrieve software for the first time.
  1983.  
  1984.   The examples from the O'Reilly books (Shirley-Hu-Magid, Rosenberry-Teague,
  1985.   Hu) are available at
  1986.      ftp://ftp.ora.com/pub/examples/dce
  1987.  
  1988.   Gradient Technologies has 
  1989.   
  1990.   sample PC-DCE code available at their ftp site.
  1991.  
  1992.   Transarc's Web site has several code samples.
  1993.   http://www.transarc.com/Public/Support/dce/prog_examples/progIndex.html
  1994.  
  1995. --------------------------------------------------------------
  1996.       Tier 4 -- Acknowledgements
  1997.  
  1998. ACK:  Thanks to the following, who provided  netnews and email messages
  1999.    from which this information is gleaned.  All errors should be
  2000.    blamed on Jon Mauney. (Corrections are actively solicited.)
  2001.  
  2002.  
  2003.         Hal Lichtin,            Open Software Foundation
  2004.         Rich Salz,              Open Software Foundation
  2005.         Courtney Mark Grey,     Open Software Foundation
  2006.         Walt Tuvell             Open Software Foundation
  2007.         David Weisman           Open Software Foundation
  2008.         Matt Thomas,            Digital Equipment Corporation
  2009.         Jonathon Chinitz        Intellisoft
  2010.         Nat Mishkin             Atria Software
  2011.         Mark Hickey             OpenVision
  2012.     Keys Botzum        Transarc
  2013.     numerous others who have been accidentally omitted but
  2014.       whose contributions are highly valued.
  2015.  
  2016.  
  2017.    And special thanks to:
  2018.  
  2019.         Harold Lockhart, Jr.    Locus Computing Corporation
  2020.  
  2021.    who wrote several of the answers in this FAQ.
  2022.  
  2023.  
  2024.  
  2025. <img src="http://www.sandybay.com/pc-web/images/awards/selected.gif"
  2026. width="68" height="63" border="0" alt="Selected by PC Webopaedia">
  2027.  
  2028.  
  2029.  
  2030.  
  2031.  
  2032.