Document revision date: 15 July 2002

When using automation in an authenticated or an unauthenticated mode, a call from a Windows 2000 client to an OpenVMS server might result in an 'Invoke call failed' error or an NTARPC-E-BAD_STUB_DATA error with certain data types.

This occurs because of a problem in the Windows operating system. Contact Microsoft to obtain the fix for this issue. (Request the hot fix associated with Knowledge Base article Q316406.)

1.3.3 ERROR_ACCESS_DENIED (C0000005 or 80070005)

COM for OpenVMS in an authenticated mode might report intermittent C0000005 or 80070005 errors when running an OpenVMS client to a Windows 2000 server. This problem is currently being investigated. Contact customer support to obtain any available updates.

1.3.4 NetBEUI as Listed Protocol in DCOMCNFG

If you have NetBEUI listed as a default protocol in DCOMCNFG, you might see various errors when running sample programs between OpenVMS and Windows 2000. To correct these problems, remove NetBEUI from the list of default protocols and reboot your Windows system.

1.3.5 Windows 2000 Clients Inactive for an Extended Period of Time - Reports 'Automation error'

In an authenticated mode, if you are running Windows 2000 clients for an extended amount of time with OpenVMS servers, you may see errors. The error messages indicate an automation error has occurred and return the following error:

800706BF - NTARPC-E-CALL_FAILED_DNE

This occurs because of a problem in the SSPI (security) layer that blocks communication between the client and server, mistakenly running down the server process. Contact your support center for an SSPI update and an updated DCE$LIB_SHR.EXE.

1.3.6 OpenVMS Client Hangs When Trying to Invoke a Server if Machine Name Cannot Be Resolved

When running remotely, your OpenVMS client application and DCOM$RPCSS can hang indefinitely. This can occur because the OpenVMS system cannot resolve the system name into a TCP/IP address. This is caused by a problem in the RPC run time. Contact your support center for an update to DCE$LIB_SHR.EXE.

If this situation occurs, restart DCOM$RPCSS. To prevent this problem from occurring, verify that you have an entry for the remote system in the local IP database on OpenVMS.

1.4 Problems Fixed in the Current Release

The following notes describe problems that have been fixed in COM Version 1.2 for OpenVMS.

1.4.1 Windows 2000 Interoperation Requires Compaq DCE Version 3.0 for OpenVMS

As part of our interoperability testing, Compaq has identified a problem in the authentication layer that prevents authenticated COM requests between an OpenVMS COM client application and a Windows 2000 COM server application. In this case, the system returns an 80070005 (E_ACCESSDENIED) error from a call to CoCreateInstanceEx in the COM client application. The problem does not occur with requests between Windows 2000 COM client applications and OpenVMS COM server applications.

The solution to this problem is to install the Compaq DCE Version 3.0 for OpenVMS kit. (COM needs only the RPC run time, but to get the RPC run time you must install the DCE kit.)

This problem occurs only on OpenVMS Version 7.2-1. The DCE for OpenVMS Version 3.0 RPC run time ships with the OpenVMS operating system beginning with OpenVMS Version 7.3. Once you upgrade to OpenVMS Version 7.3, you no longer need to install the DCE kit.

1.4.2 Memory Leak Seen in DCE/RPC Process When Running Between Windows Client and OpenVMS Server in Unauthenticated Mode

If you are running in unauthenticated mode between a Windows client and a COM for OpenVMS server application, you might see a memory leak in the DCE/RPC layer. This memory leak can cause the DCE process to hang over a period of time, which will prevent COM applications from running. A new DCE$LIB_SHR.EXE file that corrects this problem will be available on the next DCE TIMA kit from your Compaq Support Center.

1.4.3 Excessive Messages in DCOM$RPCSS.OUT

Because of interoperability problems with Windows 2000, you may have seen some additional messages in your DCOM$RPCSS.OUT file with earlier versions of COM for OpenVMS.

If you are running in an authenticated mode, the following message is displayed:

RPC_CN_AUTH_VFY_CLIENT_REQ on server failed

If you are running in an unauthenticated mode, the following message is displayed:

RPC_CN_AUTH_CREATE_INFO failed

These messages have been fixed in an update to DCE$LIB_SHR.EXE. Contact your support center to obtain the update.

1.4.4 Marshaling an Interface with More Than 32 Methods

In previous versions of COM for OpenVMS, the MIDL compiler generated server proxy code that only allowed the first 32 methods in an interface to be marshaled correctly. This limitation has been corrected. This problem did not occur if the interface used the Automation marshaler.

1.4.5 Trusted-Domain Authentication Feature Requires ECO

Compaq has discovered a number of problems associated with COM applications running between systems in different domains with trusts established between the domains in Advanced Server Version 7.2A. Some of these problems can be corrected by installing the latest Advanced Server for OpenVMS Version 7.2A ECO kit or Advanced Server for OpenVMS Version 7.3. Other problems that may still occur are listed in the following sections. If you experience these problems, please contact your Compaq Support Center for additional information.

1.4.6 DCERPC-E-UNKNOWNREJECT Failure (EE128302)

OpenVMS COM clients sometimes report this error when communicating with NT COM components. This is due to a problem in the RPC run time. A fix for this problem is available from Compaq Support Centers. Contact your Support Center and ask for the update to DCE$LIB_SHR.EXE.

1.4.7 DCERPC-E-WHOAREYOUFAILED Failure (EE1282FA)

OpenVMS COM clients sometimes report this error when communicating with NT COM components. This is due to a problem in the RPC run time. A fix for this problem is available from Compaq Support Centers. Contact your Support Center and ask for the update to DCE$LIB_SHR.EXE.

1.4.8 NTARPC-E-PROTOCOL_ERROR Failure (800706C0)

OpenVMS COM clients sometimes report this error when communicating with NT COM components. This is due to a problem in the RPC run time. A fix for this problem is available from Compaq Support Centers. Contact your Support Center and ask for the update to DCE$LIB_SHR.EXE.

1.4.9 Cached IID Value Not Equal to Registry Value Failure

Compaq's testing has shown that OpenVMS processes that run more than 2000 iterations of a COM for OpenVMS application may receive this error. The error is caused by a bug in the registry client that returns a failure status after a process has made over 16,000 OpenKey requests. A fix for this problem is available from Compaq Support Centers. Contact your Support Center and ask for the update to SYS$NTA.EXE.

1.4.10 IGNORE_EXTAUTH Support

Support for the IGNORE_EXTAUTH flag in the SECURITY_POLICY SYSGEN parameter is now available in a patch kit from Compaq Support Centers. Contact your Support Center and ask for the update to VMS$VMS_ACMESHR.EXE.

1.5 Known Problems (without Fixes) in the Current Release

The following notes describe the known problems associated with COM Version 1.2 for OpenVMS. These problems currently do not have fixes.

1.5.1 Kernel Threads and Upcalls Not Supported

COM for OpenVMS applications cannot be built with kernel threads or upcalls enabled. This support will be available in a future release.

1.5.2 Errors Seen Between OpenVMS Systems Running COM Version 1.2 Under Heavy Load

Testing by Compaq has uncovered the errors E-OUTOFMEMORY (8007000E), DCERPC-E-WHOAREYOUFAILED (EE1282FA) and CO_E_SERVER_EXEC_FAILURE (80080005) between OpenVMS systems running heavy load tests with COM Version 1.2 for OpenVMS. This problem was not seen when the tests were run locally or between Windows NT/Windows 2000 and OpenVMS systems.

1.6 Limitations and Restrictions

The following sections contain general release note information.

1.6.1 DCOM$RPCSS May Stall on Cluster Restart (PPL-W-SYSERROR)

If a system running DCOM$RPCSS in a cluster crashes and restarts, the DCOM$RPCSS process may hang during startup. In this condition, the process name remains DCOM$STARTUP-** and the SYS$STARTUP:DCOM$RPCSS.OUT file contains the following error message:

%PPL-W-SYSERROR, system service error -SYSTEM-W-VALNOTVALID, value block is not valid

To recover from this condition, stop COM for OpenVMS on each node in the cluster using the following command:

$ @SYS$STARTUP:DCOM$SHUTDOWN

Then restart COM for OpenVMS on each node in the cluster using the following command:

$ @SYS$STARTUP:DCOM$STARTUP

1.6.2 MIDL Limitations and Restrictions

The following release notes pertain to MIDL.

1.6.2.1 MIDL -w Switch

The MIDL compiler allows you to specify either -w or -warn to throttle the level of warnings generated by the compiler. The MIDL compiler for OpenVMS supports only the -w switch.

1.6.2.2 SAFEARRAY Limitation

Because the COM for OpenVMS MIDL compiler is based on Microsoft's MIDL compiler V3.00.44, COM for OpenVMS supports the use of SAFEARRAYs only inside a LIBRARY block in an .IDL file. Microsoft's MIDL compiler V3.00.44 has the same limitation.

1.6.3 DCOM$CNFG Limitations and Restrictions

The following release note pertains to DCOM$CNFG when run in a cluster.

1.6.3.1 DCOM$CNFG Utility and Disabling Applications: Possible Unintended Side Effects

The COM for OpenVMS DCOM$CNFG utility includes several options that allow a developer to modify application properties (for example, changing the location of the computer on which an application can run). If you select one of these options, you are modifying an OpenVMS Registry entry.

Because the OpenVMS Registry supports a single database in a cluster, modifying one of these options affects all nodes in the cluster that are running COM for OpenVMS.

For example, if you use the System-wide Default Properties submenu option 1 to disable COM for OpenVMS, you effectively disable COM for OpenVMS on the entire cluster. In the same way, if you use the Application Location submenu option 1 to prevent an application from running on this computer, you effectively prevent the application from running on any computer in the cluster.

1.6.4 Other Limitations and Restrictions

The following are additional limitations with COM for OpenVMS.

1.6.4.1 Windows XP Not Supported

Compaq has not tested COM Version 1.2 with Windows XP. Therefore, Windows XP is not supported in COM Version 1.2 for OpenVMS. Full support for Windows XP will be available in a future release.

1.6.4.2 COM Version 1.0 for OpenVMS and COM Version 1.2 for OpenVMS Not Supported in the Same Cluster

When you install and configure COM Version 1.2 for OpenVMS on any node in a cluster, you make clusterwide modifications to the OpenVMS Registry that prevent COM Version 1.0 for OpenVMS from running on any other node in the same cluster.

1.6.4.3 Threading Model Supported by COM for OpenVMS

COM Version 1.2 for OpenVMS supports only the multithreaded apartment (MTA, also known as free threads) model for application servers. The MTA model allows a component to have more than one thread. However, you must ensure that your code is thread safe.

The threading model initialization call is as follows:

CoInitializeEx( NULL, COINIT_MULTITHREADED )

Because CoInitialize() implies the single-threaded apartment (STA) model, you cannot use it in place of CoInitializeEx() in a server application.

1.6.4.4 Enhanced NTLM in Windows NT SP4 and Later Versions Not Supported

In Windows NT SP4, Microsoft introduced enhanced NTLM support. COM Version 1.2 for OpenVMS does not support enhanced NTLM.

If you want to use COM Version 1.2 for OpenVMS with SP4 or later, you must be sure that enhanced NTLM is disabled.

Compaq's ongoing testing has identified the following limitation with SP4 or later and enhanced NTLM disabled: authentication requests fail if you use passwords that are longer than 12 characters.

1.6.4.5 Specifying Activation Security in CoCreateInstanceEx

The pServerInfo parameter of the CoCreateInstanceEx API allows you to specify a user name and password that will be used for authentication on the remote server system. The user name and password are part of the COAUTHIDENTITY structure inside the COAUTHINFO structure, which is inside the COSERVERINFO structure that is passed as the pServerInfo parameter to CoCreateInstanceEx .

The current NTLM security implementation on OpenVMS does not support this feature for COM client applications on OpenVMS. This feature is supported for COM clients on Windows NT communicating with COM servers on OpenVMS.

1.6.4.6 RPC Communication Failures Caused by Advanced Server

In a cross-domain environment, under some load situations, COM applications may report errors that are a side effect of the Compaq Advanced Server for OpenVMS having lost a connection between domain controllers. The Compaq Advanced Server for OpenVMS reports this error as follows:

NET5719: No domain controller for the domain 'xxxxx' is available.

A series of these events over a limited time interval may lead to COM applications reporting RPC communications failures (%x8007071c). In this situation, a stop and start of DCOM$RPCSS may be required to clear the error.

See Section 5.4.6 for more information. If the NET5719 events persist, contact your Compaq Support Center.

1.6.4.7 RPC Cannot Support Failure (800706E4) Error Message

If you attempt to use the single-threaded apartment (STA) model, some COM APIs may display the following return status code:

(800706E4)

This model is not supported in COM Version 1.2 for OpenVMS. For more information, see Section 1.6.4.3.

For the latest OpenVMS Registry information, refer to the OpenVMS Release Notes for the current version of the operating system.

Component Object Model (COM) is a technology from Microsoft that lets developers create distributed network objects. First introduced by Microsoft in its Windows 3.x product, COM was initially called Object Linking and Embedding (OLE). COM provides a widely available, powerful mechanism for customers to adopt and adapt to a new style multivendor distributed computing, while minimizing new software investment.

Compaq and Microsoft jointly developed the COM specification. First released as NetOLE (Network OLE) and then renamed DCOM (Distributed COM), the COM specification now includes network functionality. That is, COM now supports distributed network objects.

COM is an object-based programming model designed to promote software interoperability. COM allows two or more applications (or components) to cooperate with one another easily, even if the objects are written by different vendors at different times and in different programming languages, or if they are running on different machines with different operating systems. To support its interoperability features, COM defines and implements mechanisms that allow applications to connect to each other as software objects.

COM implementations are available on Windows NT, Windows 95, Windows 98, OpenVMS, and Compaq Tru64^tm UNIX, as well as other UNIX platforms.

3.1.1 Suggested Reading

The following resources can provide you with more information on COM and related topics:

• Third-party books on COM:
  • COM Beyond Microsoft/Designing and Implementing COM Servers on Compaq Platforms, Terence P. Sherlock and Gene Cronin, Digital Press, Boston, MA, 2000. ISBN: 1-55558-226-5.
  • Inside COM/Microsoft's Component Object Model, Dale Rogerson, Microsoft Press, Redmond, WA, 1997. ISBN: 1-57231-349-8.
    The examples in this document are taken from Dale Rogerson's book and are used with the publisher's permission.
  • Essential COM, Don Box, Addison Wesley Longman, Reading, MA, 1998. ISBN: 0-201-63446-5.
  • Effective COM, Don Box, Keith Brown, Tim Ewald, and Chris Sells, Addison Wesley Longman, Reading, MA, 1998. ISBN: 0-201-37968-6.
  • DCOM Explained, Rosemary Rock-Evans, Digital Press, Woburn, MA, 1998. ISBN: 1-55558-216-8.
    Provides a good introduction to DCOM and COM, and discusses COM implementations on various platforms.
  • Understanding ActiveX and OLE, David Chappell, Microsoft Press, Redmond, WA, 1996. ISBN: 1-57231-216-5.
• Websites:
  • The Component Object Model Specification, available from the Microsoft COM website:

    www.microsoft.com/com

COM for OpenVMS is Compaq's implementation of Microsoft's Windows NT 4.0 Service Pack 5 (SP5) Component Object Model (COM) software on the OpenVMS Alpha operating system.

In support of COM for OpenVMS, Compaq ported Windows NT infrastructure to OpenVMS, including a registry, event logger, NTLM security, and Win32 APIs. COM for OpenVMS is layered on The Open Group's Distributed Computing Environment (DCE) RPC. COM for OpenVMS supports communication among objects on different computers on a local area network (LAN), a wide area network (WAN), or the Internet. COM for OpenVMS is important to the Affinity for OpenVMS program because it delivers a key piece of connectivity with Windows NT.

Figure 3-1 shows the OpenVMS infrastructure.

Figure 3-1 OpenVMS Infrastructure and COM for OpenVMS

In Figure 3-1 the key pieces of the OpenVMS infrastructure are as follows:

Windows NT system
The smaller box on the left side of Figure 3-1 represents the Windows NT system.
OpenVMS Cluster/OpenVMS identity
The large box on the right side of Figure 3-1 represents the OpenVMS system. Within and around this box you can see several other boxes labeled with numbers. The following list describes these numbered items:

1. OpenVMS security
   This is the standard OpenVMS security (login, authentication, ACLs, and so on) available with all OpenVMS systems.
2. Compaq Advanced Server for OpenVMS
   The Compaq Advanced Server for OpenVMS provides authentication of Windows NT users to OpenVMS and provides a connection to the OpenVMS Registry and events viewer for Windows NT users.
3. Windows NT identity/Win32 APIs
   The OpenVMS Security, MSV1_0 ACME agent, Compaq Advanced Server for OpenVMS, OpenVMS Registry, event logger, and Win32 APIs (COM APIs) all contribute to the creation of a Windows NT identity within the OpenVMS system.
4. OpenVMS Registry
   The OpenVMS Registry, like the registry on Windows NT systems, allows you to store system, software, and hardware configuration information on OpenVMS. COM for OpenVMS uses the OpenVMS Registry to store information about COM applications. For detailed information about the OpenVMS Registry, see Part 2 of this document.
5. Event logger
   Like the event logger on Windows NT systems, the event logger on OpenVMS records informational, warning, and error messages about COM events. For detailed information about the OpenVMS Events, see Chapter 15.
6. Windows NT COM stack
   On the Windows NT system, COM requests and responses pass through the COM, RPC, SSPI (security), and Domain layers.
7. OpenVMS COM stack
   The OpenVMS system mirrors the Windows NT COM stack, with some additions. On the OpenVMS system, COM requests and responses pass through the COM, RPC, SSPI (security), MSV1_0 ACME agent, and Compaq Advanced Server for OpenVMS layers. The MSV1_0 ACME agent (shown as ACME in Figure 3-1) is an extension to the Authentication and Credential and Management (ACM) authority. Authentication is explained in detail in Chapter 8.
8. Connection through RPC layer
   The COM connection between the Windows NT system and OpenVMS is always through the RPC layer.

For developers, the COM for OpenVMS developer's kit provides a Microsoft Interface Definition Language (MIDL) compiler and C-style header files for application development. For more information about the OpenVMS MIDL compiler, see Section F.1.4.1.

OpenVMS now includes a function to get Windows NT credentials. For more information about getting Windows NT credentials through NTA$LOGON, see Section 5.1 and Chapter 8.

COM for OpenVMS also provides a free run-time environment on OpenVMS Alpha for the deployment of COM for OpenVMS client and server applications.

You can find a complete description of Microsoft's COM, including protocol specifications and programming documentation, at the Microsoft COM website at the following location:

www.microsoft.com/com

The COM for OpenVMS implementation is a subset of the full Microsoft COM implementation. For a complete list of the COM for OpenVMS APIs, supported interfaces, and implementation differences, see Appendix F.

While general interest in COM continues to grow, COM remains a sophisticated technology. It is not aimed at the naive user, but rather at skilled programmers, such as independent software vendors (ISVs) and large management information system (MIS) shops.

	privacy and legal statement
6539PRO_001.HTML