Yes. First of all, since you can call C functions from C++ you can access all the DCE services from a C++ program. But that will not give you the benefits of C++. There are several packages that provide a C++ interface to DCE. They different quite a bit in style and approach, so you'll need to consider them carefully in light of your own needs and preferences. Objtran was produced by Citibank, and is available by anonymous ftp at ftp://wilma.cs.brown.edu/pub/Objtran.tar.

The Open Group maintains an Open Software Registry, which contains information about DCE products, among others. Access is free, but you must register. The registry is available on-line at http://www.opensoftware.com/ Once you get in, you can search for DCE, and your favorite platform or other criteria. Hint: A search using "DCE" as the product name will find only those products whose listed name starts with DCE.

First, DCE provides services that can be found in other computer networking environments, but packages them so as to make them much easier to use. For example, the DCE Remote Procedure Call (RPC) facility provides a way of communicating between software modules running on different systems that is much simpler to code than older methods, such as using socket calls. Second, DCE provides new capabilities that go beyond what was available previously.

DCE RFCs are requests for comments for ongoing DCE development. They are similar in concept to the Internet RFCs. Nothing in there is promised from by Open Group. They are a formal way to pass ideas among DCE development partners. You can access them by WWW (or gopher) by: http://www.pilgrim.umass.edu/pub/osf_dce/RFC/rfc-index.html

DCE is fully supported on most major platforms, including all major Unix platforms and many non-Unix platforms. Most vendors support at least the "secure core" which means all of the DCE services except the Distributed File Service and X.500 interface to the Global Directory Service. Some products are client-only, which means that the actual servers for the DCE services are not provided: Directory Service, Security Service, Time Service.

The OSF calls the specification an Application Environment Specification, or AES. The AES documents both the software programming interfaces and also the communications protocols employed by DCE. Thus it would be possible, in theory, for someone to build a compatible implementation without using the code from the Open Group. The AES for RPC, Time, and Directory services have been accepted as standards by X/Open. The AES for Security is currently undergoing review.

There is not a lot of direct relationship. DCE and CORBA are tools to help you build distributed systems. Each has its advantages and disadvantages. Use of one will not hinder future use of the other. DCE provides a lower-level programming model than does CORBA. DCE is not fully "Object-Oriented". DCE has far better inter-operability than (current) CORBA products. DCE is an optional interoperability mechanism in the CORBA 2.0 specification.

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

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

DCE does not track this information, does not supply any tools to help collect this information, does not provide any hooks in the security server to allow you to collect this information. If you must track who is logged in, you'll need to build your own service to maintain the information. An obvious approach is to capture login and logout events and report them to some central location; this requires that you be able to instrument all login/logout commands on hosts within your cell.

Windows NT comes with an RPC which interoperates with DCE RPC. Windows 95 apparently provides this interface as well. However, it is not quite the same as DCE. The wire-level protocol is the same as DCE RPC, so applications running on NT can communicate with DCE applications on other platforms. However, the application source code is not instantly portable. Microsoft changed the format of procedure names and moved the status result from a parameter to the function value.

Documentation on DCE should be supplied with vendor products. The Open Group sells complete sets of documentation. The DCE set consists of 14 volumes. The three volumes of specifications (AES) can be purchased separately. Information on DCE documentation available from The Open Group can be found at: http://www.opengroup.org/publications/catalog/dz.htm. Order documentation by contacting The Open Group via E-mail at: sales-team@opengroup.

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

Yes. Besides the Open Group itself, there are local DCE users groups in several areas. Changes in the set of users groups have proven difficult to track in this FAQ, so contact the Open Group to find the user group nearest you.

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

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

Yes. A client can connect to multiple servers providing different services, and/or multiple servers providing the same service. To use multiple servers with the same interface, the client must obtain a binding handle for each server and use explicit handles in the RPC.

Yes. A server can provide service on multiple interfaces simultaneously. A common example is a server that exports an application interface and a management interface. To code such an application, repeat the calls to rpc_server_register_if(), rpc_ep_register(), (and rpc_ns_binding_export() if you do that sort of thing in your server) for each interface, before calling rpc_server_listen().

Certainly it is reasonable to plan on cells with thousands of nodes and perhaps tens of thousands of users. The University of Michigan Center for Information Technology Integration has done a study in which they added 50,000 entries to the Cell Directory and to the security registry. Their results are reported in technical reports 93-12 and 94-1. See Q 3.01 for the ftp site for CITI tech reports. Lexis-Nexis has a more recent study in which they added 400,000 accounts to the DCE registry.

According to a paper present by Dan Hamel of Transarc, at the Decorum conference in February 1994, the following can be used as rough guidelines: end-user machines: Each dce_login creates new credential files, which can build up. Space usage can range from less than 1k to over 100k. The security server as shipped by the Open Group keeps all security registry information resident in main memory, which means that the security host machine needs memory as well as disk.

No. A machine can only be in a single cell. However, it is possible for cells to cooperate. See the next question. DCE v1.1 will allow for "hierarchical cells", which may solve the problem, depending on why you want to have a machine in two cells.

The X11/Xt/Motif libraries may not be thread-safe. For example, suppose one thread calls a function in Xt, which calls a nonthreadsafe malloc(), which then gets preempted. The next thread may call a threadsafe malloc() that comes with DCE. When control returns to the first malloc(), any assumptions about the state of the heap are invalid. Also, Motif/Xt/Xlib are not currently reentrant wrt/themselves. You can't have multiple threads concurrently manipulating any Motif/Xt/Xlib global state.

No. DCE and ONC both use the concept of the Remote Procedure Call, but the wire protocols that they use are not compatible. You will need to use either DCE for both client and server, or ONC for both client and server; both products are available for most platforms. It is possible for a single program to use both DCE and ONC. Thus a server could be built to server both DCE and ONC clients, or a gateway could be built to accept one kind of RPC and forward to a server of another kind.

A#6.2: === See the CAVEAT in Q#6.1 === There are a few aspects to this, so it has been split into various questions in this section of the FAQ. You should read each of those questions when so directed, below. The following instructions assume that you have already installed your ORCA languages; various files and directories will be moved from their original locations. If you haven't already done so, change the auxtype of (original_orca_directory)/shell/Editor to hex DC00 (see Q#14.1).

Yes, and more every day. Tokio Marine and Fire Insurance, Co., Lehman Brothers, and Charles Schwab have all publically described their ongoing rollout of DCE based applications. The Open Group's Web server has a section that includes some reports on 'real-world' experiences from companies using DCE in production. Intellisoft published a 48-page "advutorial" (that means advertisement and tutorial) with the help of many DCE vendors, totally devoted to the above.

Except for exceptional circumstances, all DCE servers should periodically change their long-term key. However, neither the servers provided by DCE nor those written by you or third parties will do this out-of-the-box. The way to have a server update its key is by spawning a thread that calls sec_key_mgmt_manage_key() (which never returns under normal circumstances). As distributed by Open Group, DCE has no password expirations set, so sec_key_mgmt_manage_key() won't actually do anything.

Bruno Traverson (September, 1998)42: The DCE components required for OrbixSecurity - which can be bought from Transarc (Solaris), Gradient (Windows) or HP for HP-DCE, are essentially the Security libraries. In more detail, the components required are : DCE runtime library 2. DCE Daemon 3. CDS clerk 4. Security clerk DCE server hosts (in addition to client host components) require: CDS server 2. DTS server 3. Security server 4. Audit server You will need at least one server host per cell.

The control-s and control-q keys now do flow control by default, unless you have turned this off with stty -ixon or redefined the keys which control it with stty start or stty stop. (This is done by the system, not zsh; the shell simply respects these settings.) In other words, \C-s stops all output to the terminal, while \C-q resumes it. There is an option NO_FLOW_CONTROL to stop zsh from allowing flow control and hence restoring the use of the keys: put setopt noflowcontrol in your .

Unfortunately not. DCE 1.0.x releases had a limitation in this key mgmt call, in that it would not wake up until shortly before the key was due to expire (based on the expiration data that it obtained when the call was started or the last time through the loop after a change). DCE 1.1 should no longer have this problem, as the call wakes up every 10 minutes to see whether the expiration time has changed. Preferably, upgrade them all to an DCE 1.1 or later.