Trace Flag	Description
`K`	Precedes each trace message with a timestamp. When the K flag is specified, each trace message is displayed with the following format: `"Day Month Year Hour:Minute:Second Year" "trace_message_text"`

For a description of how to use the Trace facility to debug ObjectBroker client and server applications, refer to the ObjectBroker Administration Guide.

The obbmset and SET AGENT commands have new options that permit dynamic setting of tracing on running server applications and the ObjectBroker agent. the syntax of the options are as follows:

Unix, Windows NT, Windows 95 OpenVMS Description

-t

/TFLAGS

Dynamically changes the trace flags on the ObjectBroker agent or the server application.
To change the trace flags on the server application, include the -u option and the UUID of the server application on the command line. If you do not include the -u option and the UUID, only the trace flags on the ObjectBroker agent will be changed.

-f filename

/TFILE=filename

Changes the trace file from the default. Enter the name of the file to which you want to direct trace output.

-u uuid

/TUUID=uuid

Set or resets the trace flags on the specified server application through the ObjectBroker agent. Specify the UUID to indicate the particular instance of a server application. Use the obbmsho command to see a list of running server applications and their UUIDs.

-n computer-name

/NODE=node-name

Specifies the name of the node on which the server application or the ObjectBroker agent on which you want to set or reset trace flags is running. This option defaults to the node on which the ObjectBroker agent is running.

Unix, Windows NT, Windows 95	OpenVMS	Description
-t	/TFLAGS	Dynamically changes the trace flags on the ObjectBroker agent or the server application. To change the trace flags on the server application, include the -u option and the UUID of the server application on the command line. If you do not include the -u option and the UUID, only the trace flags on the ObjectBroker agent will be changed.
-f filename	/TFILE=filename	Changes the trace file from the default. Enter the name of the file to which you want to direct trace output.
-u uuid	/TUUID=uuid	Set or resets the trace flags on the specified server application through the ObjectBroker agent. Specify the UUID to indicate the particular instance of a server application. Use the obbmsho command to see a list of running server applications and their UUIDs.
-n computer-name	/NODE=node-name	Specifies the name of the node on which the server application or the ObjectBroker agent on which you want to set or reset trace flags is running. This option defaults to the node on which the ObjectBroker agent is running.

For a complete description of the obbmset and SET AGENT commands and their options, refer to ObjectBroker Commands and Utilities.

Event Logging

You can debug your client or server application using events seen by the ObjectBroker agent. You cannot access this information using the Trace facility. When you enable event logging:

On Windows NT, the ObjectBroker agent events are recorded in the Application log. Use the Event View option on the Administrative Tools menu to view the Application log.
On all other platforms, ObjectBroker agent events are recorded in a log file; use the obbmsho -A or SHOW AGENT command to determine the location of the log file, and then type or edit the log file to see the events.

Note that to enable error logging, you must be logged in to a privileged account.

Obbmdcfg Command Options

Use the obbmdcfg command options in the following table to log ObjectBroker agent events. See Table 1-1 for a list of all the events logged for each option.

Option Error Logging Level

-en

NONE

-ee

ERROR

-es

SECURITY

-eo

OBJECT

-ep

PROCESS

-ea

ALL

Option	Error Logging Level
`-en`	NONE
`-ee`	ERROR
`-es`	SECURITY
`-eo`	OBJECT
`-ep`	PROCESS
`-ea`	ALL

The default is -en (NONE).

The obbmdcfg command is used on the UNIX, Windows NT, and Windows 95 platforms. Refer to the ObjectBroker Commands and Utilities manual for a complete description of the obbmdcfg command. See ObjectBroker Designing and Building Applications for more information about logging agent events.

This command changes the permanent configuration but does not affect a currently running ObjectBroker agent.

MODIFY CONFIGURATION Command Options

Use the arguments to the /EVENT_LOGGING option of the MODIFY CONFIGURATION command in the following table to log ObjectBroker agent events. For example, to specify level ERROR, enter the following command:

$ MODIFY CONFIGURATION/EVENT_LOGGING=ERROR my-config

See Table 1-1 for a list of all the events logged for each option.

Argument Error Logging Level

NONE

NONE

ERROR

ERROR

SECURITY

SECURITY

OBJECT

OBJECT

PROCESS

PROCESS

ALL

ALL

Argument	Error Logging Level
NONE	NONE
ERROR	ERROR
SECURITY	SECURITY
OBJECT	OBJECT
PROCESS	PROCESS
ALL	ALL

The default is NONE.

The MODIFY CONFIGURATION command is used on the OpenVMS platform. Refer to the ObjectBroker Commands and Utilities manual for a complete description of the MODIFY CONFIGURATION command. See ObjectBroker Designing and Building Applications for more information about logging agent events.

This command changes the permanent configuration but does not affect a currently running ObjectBroker agent.

Modifying the Event Logging Level on a Running ObjectBroker Agent

When you change the event logging level in a configuration, you do not change the logging level of a currently running ObjectBroker agent; you simply specify the logging level to be used when an ObjectBroker agent is started using that configuration.

To modify the event logging level of the currently running ObjectBroker agent, perform the following steps:

Enter one of the following commands to determine the configuration name:

UNIX, Windows NT, and Windows 95
>obbshcfg
OpenVMS
$APPL/BRO SHOW CONFIG
Enter one of the following commands to modify the event logging level in the current configuration:

UNIX, Windows NT, and Windows 95
>obbshcfg -e level "config-name"
OpenVMS
$APPL/BRO MOD CONFIG /EVENT_LOGGING=level "config-name"
Enter one of the following commands to reopen the event log:

UNIX, Windows NT, and Windows 95
>obbmset -A -R
OpenVMS
$APPL/BRO SET AGENT /REOPEN LOG

See the ObjectBroker Commands and Utilities manual for more information about these commands.

Event Logging Levels

You can use the obbmdcfg -e or MODIFY CONFIGURATION /EVENT_LOGGING command to control which ObjectBroker agent events are logged. This command allows you to select a level of events to be logged. Table 1-1 shows these levels and their respective events. Table 1 Event Logging Levels

Logging Level

Event NONE ERROR SECURITY OBJECT PROCESS ALL

ObjectBroker Agent
Startup
Shutdown
Information
Error
Warning

Y

Y

Y

Y
Y
Y

Y

Y
Y
Y

Y

Y
Y
Y

Y

Y
Y
Y

Y
Y
Y
Y
Y

Authentication
Startup
Shutdown
Invalid User Name
No Identity Found
No Proxy Found
Error
Warning

Y
Y

Y
Y

Y
Y
Y
Y
Y

Y

Y
Y
Y
Y
Y

Y

Y
Y
Y
Y
Y

Y
Y
Y
Y
Y
Y
Y

Application
Startup
Select
Set
Register
Unregister
Terminate
Dead

Y

Y

Y

Y
Y

Y

Y
Y
Y
Y
Y
Y
Y

Y
Y
Y
Y
Y
Y
Y

	Logging Level
Event	NONE	ERROR	SECURITY	OBJECT	PROCESS	ALL
ObjectBroker Agent Startup Shutdown Information Error Warning	Y Y	Y Y Y Y	Y Y Y Y	Y Y Y Y	Y Y Y Y	Y Y Y Y Y
Authentication Startup Shutdown Invalid User Name No Identity Found No Proxy Found Error Warning	Y Y	Y Y	Y Y Y Y Y	Y Y Y Y Y Y	Y Y Y Y Y Y	Y Y Y Y Y Y Y
Application Startup Select Set Register Unregister Terminate Dead	Y	Y	Y	Y Y Y	Y Y Y Y Y Y Y	Y Y Y Y Y Y Y

Changes in Generated Server Application Code

The following enhancements have been made to the generated server application code:

All generated method routines return a null value of the appropriate type for the routine. The data declaration and return statements are made outside the code preservation delimiters.
All generated notification routines now have code preservation delimiters.
There are now code preservation delimiters at the end of all modules. You may use these delimiters to preserve any user-written code.

Stopping Running Implementations

Before upgrading ObjectBroker or removing it from your system, you must stop all the running implementations. An option that stops all running implementations has been added to the obbmstp and the STOP SERVER_PROCESS commands.

The syntax is as follows:
Table 1
UNIX,
Windows NT,
Windows 95 OpenVMS Description

obbmstp -l

APPLIC/BROKER STOP SERVER_PROCESS /ALL

Stops all running implementations and returns a status message

Obbmstp -l -a

APPLIC/BROKER STOP SERVER_PROCESS /ALL /ABORT

Stops all running implementations including implementations with a Terminate status

**Table 1**
UNIX, Windows NT, Windows 95	OpenVMS	Description
`obbmstp -l`	`APPLIC/BROKER STOP SERVER_PROCESS /ALL`	Stops all running implementations and returns a status message
`Obbmstp -l -a`	`APPLIC/BROKER STOP SERVER_PROCESS /ALL /ABORT`	Stops all running implementations including implementations with a Terminate status

One of the following messages is returned:
Table 1
Message Description

OBB_INV_NOSRVTOSTOP

There are no running implementations.

OBB_CMD_CANTSTOPALL

There are insufficient privileges to stop all requested servers.

OBB_INV_NOTAUTHORIZED

Some of the running implementations have been stopped; however, the client is not authorized to stop all the running implementations.

**Table 1**
Message	Description
`OBB_INV_NOSRVTOSTOP`	There are no running implementations.
`OBB_CMD_CANTSTOPALL`	There are insufficient privileges to stop all requested servers.
`OBB_INV_NOTAUTHORIZED`	Some of the running implementations have been stopped; however, the client is not authorized to stop all the running implementations.

For a complete description of the obbmstp and STOP SERVER_PROCESS commands, refer to the ObjectBroker Commands and Utilities manual. For more information about upgrading your ObjectBroker release or removing ObjectBroker from your system, refer to the ObjectBroker Installation Guide.

Smaller Security Registry File

With this version of ObjectBroker, the size of the Security Registry file is significantly smaller than with previous versions of ObjectBroker, particularly when a large number of proxies has been defined.

Setting Proxies, Authorization, and Security on Multiple Entities

ObjectBroker Version 4.0 provides a new feature that lets you take the following actions on multiple entities by specifying those entities in input files:

Adding or removing multiple proxies
Granting or revoking authorization to multiple implementations
Setting security on multiple implementations

When you execute these actions using input files, the respective actions are completed in a single operation. For example, to add a proxy for each of the entries in the file my_proxy_file.dat, you can now enter the following command:

# obbaddpxy -f my_proxy_file.dat

New Command Options

ObjectBroker provides the following two new options that you can use with the commands that affect the above actions:

The -f option for UNIX, Windows 95, and Windows NT platforms (/INPUT option for OpenVMS), which specifies the name of the input file
The -b option for UNIX, Windows 95, and Windows NT platforms (/ABORT_ON_ERROR option for OpenVMS), which terminates the command if an error condition is generated. If the command terminates, none of the requested changes are applied.

Commands with Which You Can Use These New Options

The commands with which you can use these two new options are as follows:

Command UNIX, Windows NT and Windows 95 OpenVMS

Add proxy

obbaddpxy

APPLICATION/BROKER ADD PROXY

Remove proxy

obbrmpxy

APPLICATION/BROKER REMOVE PROXY

Grant authorization

obbgrath

APPLICATION/BROKER GRANT AUTHORIZATION

Revoke authorization

obbrvath

APPLICATION/BROKER REVOKE AUTHORIZATION

Set security

obbstsec

APPLICATION/BROKER SET SECURITY

Command	UNIX, Windows NT and Windows 95	OpenVMS
`Add proxy`	`obbaddpxy`	`APPLICATION/BROKER ADD PROXY`
`Remove proxy`	`obbrmpxy`	`APPLICATION/BROKER REMOVE PROXY`
`Grant authorization`	`obbgrath`	`APPLICATION/BROKER GRANT AUTHORIZATION`
`Revoke authorization`	`obbrvath`	`APPLICATION/BROKER REVOKE AUTHORIZATION`
`Set security`	`obbstsec`	`APPLICATION/BROKER SET SECURITY`

See the ObjectBroker Commands and Utilities manual for details on using these commands.

Generating the Input Files

Each of the commands that support the new options accept as input the output generated with the show proxy, show authorization, and show security commands. To make changes to multiple entries simultaneously, direct the output of the show command to a file, modify the entries in that file, and then input that file to the command that affects the desired changes.

For example, to change the security settings for multiple implementations on a UNIX system:

Enter the obbshsec command (show security), directing the output to a file:

# obbshsec > my-security-file
Edit the generated output file, entering the changes you want to subsequently make with the obbstsec command.
Enter the obbstsec command, specifying the file as input:

# obbstsec -f my-security-file

The following sections describe the input files that you can use with all the affected commands.

File for Adding or Removing Multiple Proxies

Each entry in the input file has the following format:

local_username remote_username remote_hostname

Note the following guidelines:

Each field is delimited by one or more tabs or blank spaces. Comments are allowed with the number sign (#) as the first character.
local_username and remote_username can contain blank spaces, as long as the blank spaces are surrounded by a pair of double quotation marks (").
Leading tabs or blank spaces are also allowed to use the output file of the show proxy command. The following lines and blank lines are interpreted as comments:
```
Local User		Remote User		Remote Host
------------		------------		------------
```

The input file for removing proxies may not contain remote_hostname or remote_username, as in the following example:

#local_username			remote_username			remote_hostname
#--------------			---------------			---------------
john_doe			d_smith
"john space"			" "			abc.zko.dec.com

File for Granting/Revoking Authorization of Multiple Implementations

Each entry in the input file has the following format:

ImplName U[sername]: user1 [user2] [usern] [method-name]

Note the following guidelines:

Each field starts on a new line. Indentation is not required. Comments are allowed with the number sign (#) as the first character.
Note the following guidelines for specifying ImplName:

ImplName can be an implementation name or an implementation ID. An Implementation ID that duplicates the information in the implementation name is ignored.
The implementation must be registered. If it is not registered, the implementation is treated as a method (or as an admin method).
Lists of implementations are accepted, as long as they are on a new line and the last implementation in the list is followed by one or more usernames.
The implementation name can contain blank spaces, as long as the blank spaces are surrounded by a pair of double quotation marks (").
The implementation must be followed by one or more usernames.
Note the following guidelines for specifying usernames:

You can specify multiple users on the same line by separating each username with a space or a tab.
The username must be preceded by the U[sername]: keyword.
Note the following guidelines for specifying methods:

The method or the admin method, which is optional, follows the username. If the method or the admin method are different for the user of an implementation, the user is treated as a separate input with the same implementation.
When the method name is Stop, GetInfo, or Select, the method is assumed to be an admin method; the current granting/revoking function limits these three method names for the admin method. When no method name is specified, it is assumed to be all methods, which is represented as * as specified with the show authorization command.
Leading tabs or blank spaces are allowed. In addition, the following lines and blank lines, generated as output from the show authorization command, are also interpreted as comments and do not have to be removed from the output file:
```
Implementation				Methods
--------------------------				------------------------
```

File for Setting Security on Multiple Implementations

Each entry in the input file has the following format:

ImplName Authentication SecurityContextDeletion SecurityPrincipal Model

Note the following guidelines:

Each field starts on a new line. Indentation is not required. Comments with the number sign (#) as the first character in the line are allowed.
ImplName can be an implementation name or an implementation ID. An Implementation ID that duplicates information in the implementation name is ignored.
Authentication and SecurityContextDeletion can be specified as e[nabled] or d[isabled]. If SecurityContextDeletion is enabled, both Authentication and SecurityContextDeletion should be enabled.
ImplName and SecurityPrincipal can contain blank spaces, as long as the blank spaces are surrounded by a pair of double quotation marks (").
Model can be specified as normal, open, or closed. This specification is case insensitive and must be provided.
Leading tabs or blank spaces are allowed.
If fewer than four values are provided, the following rules apply:

a.) If one value is provided, that value must specify Model.
b.) If two values are provided, the first value specifies either Authentication or SecurityPrincipal, and the second value specifies Model.
c.) If three values are provided, the first value specifies Authentication, the second value specifies either SecurityContextDeletion or SecurityPrincipal, and the third value specifies Model.

Additional Output for the Show Implementation Command

With ObjectBroker Version 3.0 and earlier, the obbmsho (or SHOW IMPLEMENTATION on OpenVMS) command shows only the registered implementation name and its UUID.

With ObjectBroker Version 4.0, the output of the show implementation command is expanded to include the following information for the implementation:

Activation account
Activation context
Activation environment
Activation policy
Activation string (the environment variable has been expanded)
Activation type
Methods activation type and name for each method
Timestamp for the registered implementation

All registered implementations store this information in the partition database. In many cases, especially if all implementations are shown, too much information could be provided.

The -v option for UNIX, Windows NT, and Windows 95 (or the /VERBOSE option for OpenVMS) has been provided to control this problem. If you specify the -v (or /VERBOSE) option, all of the information about an implementation or implementations is shown. Without the option, the obbmsho and SHOW IMPLEMENTATION commands provide the name and ID only.

Option Syntax

UNIX, Windows NT, and Windows 95

$ APPLIC/BROKER SHOW IMPLEMENTATION /VERBOSE

Example Output

The following is an example of the output produced with the new -v option to the obbmsho command (or the /VERBOSE option to the SHOW IMPLEMENTATION command on OpenVMS):

Network Tester Enhancements

The Network Tester utility has been enhanced to retrieve the transport information for the current configuration from the ObjectBroker registry. If the transport or provider is not specified with the command, the following occurs:

If only one transport is defined in the current configuration, the transport is used as the default.
If multiple transports are defined in the current configuration for the client application, the following occurs:
- If the Network Tester works with the first transport, it exits upon completion.
- If the Network Tester fails with the first transport, it retries the operation using the next transport.
If multiple transports are defined in the current configuration for the server application, the following occurs:
- If the Network Tester is started with the first transport, a message that says you can use the other transport if the first transport fails is issued.
- If the Network Tester cannot start with the first transport, it retries the operation using the next transport.

Enhanced Compile and Generate Commands

For obbcomp and obbgen commands on UNIX, Windows NT, and Windows 95, and the corresponding COMPILE and GENERATE commands on OpenVMS, a new option called Basename has been added. This option specifies the base name you use when determining the file specification of the generated include files.

The file specification is from either the base OMG IDL file or the base module, and can include the client include file, the server include file, and the typecode include file. To change the include file specifications, use the -B option on UNIX, Windows NT, and Windows 95, and the /BASENAME qualifier on OpenVMS to specify the base file for these include files. The base file name should not include a file extension.

The syntax for the enhanced compile and generate commands is as follows:

UNIX, Windows NT, and Windows 95

-B

Example:

# obbcomp -l cxx -c myapp.cxx -B appdef myapp.idl

OBB>COMPILE myapp.idl/LANGUAGE=CXX/STUBS=CLIENT=myapp.cxx-/ BASENAME=appdef

In the examples above, the generated client stubs go into myapp.cxx, and the corresponding include file is named appdef.hxx.

New Binding Policies

ObjectBroker Version 4.1 includes two additional binding policies: STATIC_BOUND, and AUTOMATIC_WITH_REBIND.

STATIC_BOUND

ObjectBroker Version 4.1 provides a new binding policy, OBB_BINDPOLICY_STATIC_BOUND, which allows you to establish a direct connection between the object and the server application, bypassing the agent. Response time is improved because the client can connect directly to the server. Since this is a binding policy, you do not need to specify it at registration time. You can set this binding policy with the function OBB_BOA_set_impl_binding.

AUTOMATIC_WITH_REBIND

With ObjectBroker Version 3.0 and earlier versions of ObjectBroker, an object reference, when bound to a server application, remains bound to that server application, even when the server application crashes or otherwise becomes unavailable because of a failed communication link. To recover, the client application must note this problem, release the object reference, create a new and unbound object reference, and retry the operation.

ObjectBroker Version 4.1 provides a new binding policy, OBB_BINDPOLICY_AUTOMATIC_WITH_REBIND, which causes a new server to be started when an object cannot find the server to which that object is initially bound. You can set this binding policy with the function OBB_BOA_set_impl_binding.

Skipping Duplicate Nodes for Server Selection

During resolution processing, ObjectBroker now tracks the nodes to which it attempts resolution, and does not revisit the same node more than once, even if the node appears multiple times in the node list because of redundant entries in OBB_LOCAL, OBB_DEFAULT_NODES, or OBB_ADVERTISEMENTS.

Enabling/Disabling Server Application Selection and Autostart

ObjectBroker Version 4.0 provides a new feature that allows the agent running on a particular computer to control whether requests to start a server application are permitted or denied. This feature is available in the obbmset (APPLICATION/BROKER SET AGENT on OpenVMS systems) command.

The syntax of the enable/disable server selection command switch is as follows:

UNIX, Windows NT, and Windows 95

obbmset -A -s{0|1}

OpenVMS

APPLICATION /BROKER SET AGENT /[NO]SERVER_SELECT

In the syntax above, the argument -s1 (or /SERVER_SELECT on OpenVMS systems) enables server selection and autostart (this is the default ). The argument -s0 (or /NOSERVER_SELECT on OpenVMS systems) disables server selection and autostart.

When server selection and autostart are disabled on a given node, the following line of text is displayed when you enter the obbmsho -A (APPLICATION /BROKER SHOW AGENT on OpenVMS) command, under the Attributes heading:

Server Selection and Autostart DISABLED

Agent Startup Event Added to Event Logging

An agent startup event was added to event logging. This event is enabled for logging by default, and it records contextual information about the agent at startup, including the level of events that is enabled for logging. Authentication error and warning events were also added, and the grouping of events was changed with regard to enabling and disabling them for logging. For more information, see the section entitled Event Logging under New Features in Version 4.0.

Features Removed from ObjectBroker V4.0

The features listed in the following sections were removed from ObjectBroker V4.0.

Removed DDE Listener and OLE Network Portal Support

In ObjectBroker V4.0, support has been retired for the DDE Listener and OLE Network Portal utilities. OLE connection functionality can be achieved by using the ObjectBroker Desktop Connection product.

Removed Visual Basic Bindings

In ObjectBroker Version 4.0, support has been retired for the Visual Basic bindings found in earlier versions.

New Features in ObjectBroker V3.0

The following features and functionality added to ObjectBroker Version 3.0 are still present in ObjectBroker Version 4.0 and 4.1. For more detailed information, refer to the ObjectBroker Version 3.0 Documentation Supplement.

Support was added for the following:

Implementation of CORBA Version 2.0 initialization
Invokable ObjectBroker Naming Service
Several performance enhancements to ObjectBroker in the following areas:

Additional caching
Handling of a large number of objects
Optimization for large sequences of base types
Improved server selection
Reduced hashing
Additional support for implementation groups
Support for the logging of proxy failures
On the Windows platforms (Windows NT, and Windows 95), online help is available for commands. To display the online help for a command, type the command name followed by a hyphen and question mark, as in the following example:
```
obbmsho -?
```
The system starts the Windows Help viewer, and displays information about the command.

Known Problems in ObjectBroker V4.1

This section lists and describes problems and restrictions that currently exist.

Upgrading from Previous Versions

If you are upgrading from ObjectBroker Version 2.7 or 3.0 to Version 4.1, you do not need to recompile and relink your programs, but for better operation, you should rebuild your programs.

If you are upgrading from ObjectBroker Version 4.0 to Version 4.1, you must recompile and relink your programs to ensure proper operation.

Windows 95

The problems listed in this section may occur when you use ObjectBroker on Windows 95 systems.

QuickStart and ObjectBroker Examples

The QuickStart feature and some ObjectBroker examples will not function correctly until OBBVAR32.BAT is called. ObjectBroker for Windows 95 provides this batch file to define the PATH, LIB, and INCLUDE environment variables that enable the use of ObjectBroker from the MS-DOS box.

When you use either QuickStart or the examples, it is recommended that OBBVAR32 be called from AUTOEXEC.BAT, specifying the location of Visual C++ as follows:

\Progra~1\Object~1\Bin\obbvar32 C:\Progra~1\Object~1 C:\Progra~1\DevStudio\VC

When calling OBBVAR32 from AUTOEXEC.BAT, you must specify short file names. This is a limitation of the Windows 95 operating system.

Activation Context

Activation context does not work properly on Windows 95 when the agent is set with debug server startup disabled. The environment variables are not set in the server process that is started.

The activation context will also not be set if the agent is set with debug server startup enabled and the agent fails to open a debug server startup log file.

A workaround for this problem is to enable debug server startup on the agent for Windows 95.

Be sure to delete the OBB*.LOG files that are created in the Windows temporary directory. The FAT file numbering scheme is limited to 99 file versions when the filenames have the same first characters.

QuickStart and Environment Space

QuickStart on Windows 95 may experience problems with the size of the MS-DOS environment space. By default, the environment size in the MS-DOS box on Windows 95 is the same as the environment size before Windows 95 is started. Attempts to run QuickStart may result in failure because not enough space remains for the environment variables that QuickStart defines.

The environment space available for all applications can be increased by adding the following line to CONFIG.SYS:

shell=c:\command.com c:\ /e:1024 /p

The /e switch creates a default environment of the specified size.

QuickStart File Name Constraints

QuickStart IDL filenames should not contain spaces or ~ characters. This limitation is imposed by the NMAKE tool provided with Visual C++. When QuickStart passes filenames that contain these characters, NMAKE displays an error message and cancels the compilation.

Passwords and LAN Manager Security Domain

If you use ObjectBroker for Windows 95 in a LAN Manager security domain, any password changes made on a system are known only to ObjectBroker on the system on which the change was made, and not on other systems in the domain.

CORBAservices Naming Service May Fail to Start

On Windows 95, CORBAservices Naming Service operations will fail if the OBBVAR32.BAT file has not been executed to define the PATH, LIB, and INCLUDE environment variables. This is because the directory containing the CORBAservices Naming Service server executable must be in the PATH for the server to be autostarted.

To avoid this problem, execute the OBBVAR32.BAT file to ensure that the directory containing the CORBAservices Naming Service server executable is in the PATH. By default, this directory is as follows:

drive:\progra~1\ObjectBroker\bin

Windows NT

The problems listed in this section may occur when you use ObjectBroker on Windows NT systems.

Development Kit

When the development version of the ObjectBroker kit is installed on Windows NT, ObjectBroker adds its appropriate pathnames to the system's lib and include environment variables. However, if individual users have defined their own lib or include environment variables, their own definition will override the system's definition. Users who are doing ObjectBroker development should make sure they have the appropriate %lib% and/or %include% in their private definition of these two environment variables.

The system's path environment variable is also modified by ObjectBroker when either the development kit or the run-time kit is installed; however, users should not modify their private definition of this variable. The system's path environment variable is not overridden, but is appended to the user's definition.

See the online help for the system control panel applet for more information about Windows NT environment variables.

Logging on for Server Application Startup

For any newly created account where the ObjectBroker agent automatically starts a server application, you must first log on to the account on which you run the server. Once you have logged on to the account, and have thereby verified your access, ObjectBroker can automatically start a server application from that account.

You do not need to log on to the account every time you start a server application. If you change your password on that account, you need to log on to that system again.

Passwords and LAN Manager Security Domain

If you use ObjectBroker for Windows NT in a LAN Manager security domain, any password changes made on a system are known only to ObjectBroker on the system on which the change was made, and not on other systems in the domain.

Node Name and User Name on Windows NT

For any account on Windows NT, the node name and user name must not be the same.

Windows NT Accounts Require a Default Path to Autostart Servers

For any account under which servers are autostarted, the default path for that account must point to an existing directory that is writable by that account.

Note that when a Windows NT user account is created, no default path is included in the user profile. In this case, the user's default environment includes one of the following default paths (depending on the existence of the associated directories):

<system-drive>:\users\default, or, if that does not exist,
<system-drive>:\users, or, if that does not exist,
<system-drive>:\

Note: The default path of <system-drive>:\ is not supported for ObjectBroker autostart.

UNIX

The problems listed in this section may occur when you use ObjectBroker on UNIX platforms.

Installation on UNIX Appears to Hang

At the end of the ObjectBroker installation, the online manual sections are updated using catman. Depending on the products you have installed on your system, this catman operation can take a long time (several minutes to an hour).

This has been most noticeable on Digital UNIX Version 4.0 systems, where installations can take up to 10 times longer than other installations. The processing may also take several minutes on HP-UX platforms.

Granting Authorization on UNIX Platforms

The ObjectBroker Programmers Reference manual and the online help indicate that ObjectBroker authorizations are granted using usernames. This is not correct on UNIX platforms; on these platforms, authorizations must be specified using the user identification (uid). The uid is obtained by using the UNIX command id[username].

The following example demonstrates how to grant authorization to local user snerd for the implementation CheckAcctImpl:

	#id snerd
	uid=340(snerd) gid=15(users) groups=0(system)
	#obbgrath -i CheckAcctImpl 340

For all non-UNIX platforms, the username must be used when granting authorizations.

Manpages

Note that this release contains manpages for ObjectBroker commands on UNIX systems. This release does not contain manpages for ObjectBroker routines.

The following are problems that may occur during and after the configuration of new manpages:

When installing ObjectBroker over a previous release, you may have extraneous manpages that have been in previous documents.
The following error messages may appear in the configuration of manpages during the installation of ObjectBroker Version 4.1 over previous versions:
```
CORBA_Container_describe_contents.3: No such file or directory
CORBA_InterfaceDef__get_base_interface.3:No such file or directory
CORBA_InterfaceDef_describe_interface.3: No such file or directory
CosNaming_BindingIterator_destroy.3: No such file or directory
CosNaming_BindingIterator_next_one.3: No such file or directory
```
Optionally on Digital UNIX systems, you can answer YES to the following question during the installation of ObjectBroker Version 4.1:
Do you want the OBBBASE*n files removed [yes]?
where the asterisk (*) represents either DEV (for the development kit) or RT (for the run-time kit), and n represents the kit version number (250, 251, 252, 253, 260, 261, 270, or 300).
You may also receive the following messages while configuring ObjectBroker manpages (OBBMANDEV270):
dsx_trace_object.3xds: No such file or directory getgrent.3sec: No such file or directory getpwent.3sec: No such file or directory om_copy.3xds: No such file or directory om_copy_value.3xds: No such file or directory om_create.3xds: No such file or directory om_get3xom: No such file or directory
These types of errors occur because the base manpages are deleted but the links remain. These links come from products other than ObjectBroker. You can remove these links when logged in as superuser.

Problems with Signals on UNIX

If you have an ObjectBroker application running on UNIX, and you use UNIX signals, a signal handler problem may occur.

ObjectBroker registers a signal handler of its own for SIGIO. If you register your own handler for this signal before ObjectBroker does, ObjectBroker recognizes that a previous handler was registered and remembers the address of that handler. When ObjectBroker's handler is called, it calls your handler in addition to its own signal processing code; however, the only standard argument across all ObjectBroker UNIX platforms that will be passed to your handler is the signal number (an int).

On Solaris systems, ObjectBroker also passes the platform-specific additional arguments: handler(int, siginfo_t *, ucontext_t *)

Solaris

The problems listed in this section may occur when you use ObjectBroker on Solaris systems.

The scripts used to set environment variables used by ObjectBroker define the variable MANPATH even if you choose not to install the ObjectBroker man pages. If ObjectBroker has been installed without having symbolic links installed from the /usr filesystem, and if the ObjectBroker man pages have not been installed, then the system may display errors like the following in response to man -k commands:
```
/opt/DECOBBDEV/man/windex: No such file or directory
```
To resolve this problem, remove the ObjectBroker man directory from your MANPATH environment variable.
If you install ObjectBroker on Solaris systems without having symbolic links installed from the /usr filesystem, the merging of the advertisement partitions of the ObjectBroker registry and the use of the CORBAservices Naming Service server will not work (these servers cannot automatically start up).

Use one of the following two workarounds to fix both server applications. Once done, either workaround will fix the problem for all users.

Workaround 1

Enter the following commands to create two symbolic links in the /bin directory:

# cd /bin
# ln -s /opt/DECOBBDEV/bin/obbregs obbregs
# ln -s /opt/DECOBBDEV/bin/obbnamesrv obbnamesrv

Workaround 2

Perform the following steps:

Export the implementation partition of the ObjectBroker registry:

# obbexreg -I implementations.dat

Edit the output file as follows:

Change To

/bin/obbregs

/opt/DECOBBDEV/bin/obbregs

/bin/obbnamesrv

/opt/DECOBBDEV/bin/obbnamesrv
Import the file to the implementation partition of the ObjectBroker registry:
```
# obbimreg -I implementations.dat
```

Change	To
`/bin/obbregs`	`/opt/DECOBBDEV/bin/obbregs`
`/bin/obbnamesrv`	`/opt/DECOBBDEV/bin/obbnamesrv`

HP-UX 11.00

The problems listed in this section may occur when using ObjectBroker on HP-UX 11.00 platforms.

Module Statement Required in IDL

The following restriction exists only on HP-UX 11.00 systems. A generated application will fail to compile if the IDL does not contain a module statement. In these cases, an error of the following type appears:

Error 741: Ill-formed conversion...

To work around this problem, include a module statement in the IDL. The following examples show BAD.IDL, which will cause a compilation failure in the generated client module, and GOOD.IDL, which will compile successfully.

BAD.IDL
//Fails on HP-UX 11; works on all other platforms
interface bar
      {
            void op();
      };

GOOD.IDL
//works on all platforms
module foo
      interface bar
          {
            void op
          };
};

File Substitution Required Before Using obbgui Command

The obbgui command that is supplied in the ObjectBroker kit for HP-UX 11.00 systems does not work properly. To get it to work properly, you must substitute some files from the ObjectBroker kit for HP-UX 10.20 systems after you have installed ObjectBroker on your HP-UX 11.00 system in the usual way.

To substitute the files, perform the following steps:

Mount the ObjectBroker installation CD-ROM. In this example, /cdrom is used as the mount point.

Extract the following directory from the HP-UX 10.20 kit using a command like this:

tar xvf /cdrom/objbrokr/hpux/obb_d_hpx10_x4103.kit \
DECOBBDEV/DECOBBDEV/opt/DECOBBDEV/lib/X11/uid

The following files will be extracted:

DECOBBDEV/DECOBBDEV/opt/DECOBBDEV/lib/X11/uid/obbadmin.uid
DECOBBDEV/DECOBBDEV/opt/DECOBBDEV/lib/X11/uid/obbcntxt.uid
DECOBBDEV/DECOBBDEV/opt/DECOBBDEV/lib/X11/uid/obbgui.uid
DECOBBDEV/DECOBBDEV/opt/DECOBBDEV/lib/X11/uid/obbimplv.uid
DECOBBDEV/DECOBBDEV/opt/DECOBBDEV/lib/X11/uid/obbnetst.uid
DECOBBDEV/DECOBBDEV/opt/DECOBBDEV/lib/X11/uid/obbrepos.uid

When logged in as superuser, copy these files over the ones that were placed on your HP-UX 11.00 system when you originally installed ObjectBroker, using a command like this:
```
cp DECOBBDEV/DECOBBDEV/opt/DECOBBDEV/lib/X11/uid/* \
/usr/lib/X11/uid
```
After completing these steps, the obbgui command will work properly on your HP-UX 11.00 system.

Supported Version of C++ Compiler Required

If you encounter the following type of error during code generation (of sequences of Strings, TypeCodes, and Objects) it means that you have a version of the aCC compiler not supported by ObjectBroker.

Error 187: "sstring.cxx", line 34 # Referenced object 'CORBA::Char' \
is not a member of class _ForSeq_var ["sstring.cxx", line 12]. 
_data[0] = _obj._data[0].operator CORBA::Char * ();

To fix this problem, upgrade to the supported version of the C++ HP11 compiler, which is HP aCC Version A.03.10.

OpenVMS

There is a restriction in the ObjectBroker VMS installation kit regarding the definition and use of the nodename. If you have either DECnet or DEC TCP/IP Services for OpenVMS network software installed and running on your VMS system, refer to the following table for nodename requirements. DEC TCP/IP Services software is sometimes referred to as UCX.

In the following table, SCSNODE is a SYSGEN parameter.

DECnet_Status UCX_Is_Running UCX_Is_Not_Running

DECnet is running

DECnet nodename = SCSNODE

DECnet nodename = SCSNODE

DECnet is not running

IP hostname = SCSNODE

Not applicable

DECnet_Status	UCX_Is_Running	UCX_Is_Not_Running
DECnet is running	DECnet nodename = SCSNODE	DECnet nodename = SCSNODE
DECnet is not running	IP hostname = SCSNODE	Not applicable

The preceding table shows that if you have DEC TCP/IP Services for OpenVMS (sometimes referred to as UCX) and DECnet installed on your system, then the DECnet nodename and the SCSNODE SYSGEN parameter must be the same for ObjectBroker to install properly.

If DECnet is not running (or is not installed) and you have DEC TCP/IP Services installed and running, the IP hostname for your OpenVMS system must match the SCSNODE SYSGEN parameter. Note that the SCSNODE parameter is limited to six characters.

If your OpenVMS network setup does not comply with these restrictions, ObjectBroker will not install properly.

C and C++

This sections lists problems related to C and C++ that currently exist.

C++ Server Method Cannot Delete "this" Pointer

A C++ server method cannot delete the this pointer from within the method. For example, the following statement may cause the server to crash within the generated dispatcher just after the method completes:

delete (this);

There is no workaround to allow delete (this) to work within a method; however, the server can accomplish similar behavior by doing the following:

Have the method mark the instance for deletion, and delete the instance later within the dispatch loop.
Have the method clear the association to ensure the instance will not be dispatched again. Do this by calling the associated_object modifier using a NIL object reference, or by disposing of the object reference.

This also requires that the server have its own dispatch loop for dispatching ObjectBroker events. The instance cleanup needs to be hooked into the dispatch loop. For example:

	in logoff method:

		delete_instance = this;
		associated_object( (void *)(myserver *)this,

CORBA::Object::_nil(local_ev), ev);

	in dispatch loop:

		delete_instance = 0;
		BOA->dispatch();
		if (delete_instance) delete delete_instance;

C++ Inventory Example and Mapping Features

The C++ inventory example supplied on the ObjectBroker kit does not use the support provided by ObjectBroker for associating object references with server class instances. The inventory example uses a mapping class to accomplish this.

For information about associating object references and server class instances, refer to the section about Generated Server Class in the ObjectBroker Version 3.0 Documentation Supplement.

Example for C++ Server-Side Bindings

If you are using C++ server bindings, refer to the example in the ObjectBroker Version 3.0 Documentation Supplement.

C++ and C Code Generation Problems

The following are known problems with C++ and C code generation:

Use the -std1 compiler option when compiling the C code that is produced by the commands obbgen -d or obbcomp -d on Digital UNIX systems. Specify this option in the command that compiles bank1sd.c shown in the chapter titled "Banking Example 1" of the ObjectBroker Guide to Examples. If you do not specify the -std1 compiler option, errors are displayed and no object file is produced.
If your IDL module name is long enough (when combined with the interface names) to require longname macros, you may get compile errors. You can work around this problem by shortening the length of your module name.
QuickStart C code generated for an ANY attribute does not correctly initialize memory in the server.
Code generated by QuickStart does not always free memory when it should. The C client application generated by QuickStart does not always do a CORBA_free() on memory returned from a server application. When preparing to return values from the server application to the client application, C code generated by QuickStart does not always allocate memory using OBBarg_malloc().

The following are known problems exclusive to C++ code generation:

Nested Implementations and Indentation

The indentation for generated implementation classes is incorrect when the implementation is contained within a module.
Interfaces and Operations with the Same Name

If an interface and an operation have the same name, the generated code does not compile. The workaround is to have different names for the interface and the operation.

C++ Code Regeneration Required

ObjectBroker Version 2.7 added an OBB::Object extension class to allow a server to retrieve an associated server instance from an object reference.

If your application has C++ source code that was generated by ObjectBroker Version 2.6, the C++ source code must be regenerated before it is compiled and linked against a later version of ObjectBroker.

For information about using the OBB::Object::associated_instance() accessor, refer to the ObjectBroker Version 3.0 Documentation Supplement.

BEA ObjectBroker Desktop Connection V1.0

There is a known problem with the ObjectBroker shell extensions and BEA ObjectBroker Desktop Connection V1.0. If you are planning to install BEA ObjectBroker Desktop Connection V1.0, delete the following files before installing the Desktop Connection but after installing ObjectBroker:

Windows NT:

obroker\bin\obbuiint.dll
obroker\bin\ouiapp.exe
obroker\bin\shellext.dll
Windows 95:

ObjectBroker\bin\obbuiint.dll
ObjectBroker\bin\ouiapp.exe
ObjectBroker\bin\shellext.dll

If the ObjectBroker shell extensions were in use prior to deleting these files, the DLL's may be loaded into memory. In this situation, you will not be able to delete these files and an error similar to the following is displayed:

Cannot delete shellext: The specified file is being used by Windows

If this occurs, reboot your system and then delete the files.

Object References

The following sections describe known problems with object references in ObjectBroker Versions 2.6 and later.

Filename Restrictions with Context Objects and Interface Repositories

ObjectBroker on Windows, Windows NT, and Windows 95 has a new restriction on filenames used for context objects and interface repositories. If the filenames specified for the context object or the interface repository end in numbers, unwanted behavior may occur when ObjectBroker attempts to read or write to those files.

The workaround is to use a filename that does not end in a number. For example, using the filename usr12.co may cause unwanted behavior. A better name is usr12f.co.

On Windows, there is a further restriction on the filenames used for the context object and the interface repository. This restriction stems from the maximum filename length allowed by the operating system (8 characters for name, 3 characters for extension). When ObjectBroker updates either the context object or the interface repository, it creates a new version of that file. It does this by taking the name specified by the user and appending the next greater version number to the name. Consequently, because of the versioning scheme, the user-specified filename also determines the number of revisions that are allowed to that file. The larger the user-specified file name, the fewer the revisions that can be made to it.

The change to the ObjectBroker versioning scheme was made to fix a problem with updating ObjectBroker database files that were being used by another program.

Because of the new naming convention, when the existing repository or context object is replaced using the create option (obbldrep -c or obbldctx -c), a new version is created without removing older versions.

Implementation Name Conflicts

If you receive an Invalid Implementation error message when you are registering an implementation, you may have an implementation naming conflict. This occurs when you use the obbreg -I command or the REGISTER IMPLEMENTATION command.

This error message can occur when you are registering an implementation whose name is already registered in the implementation partition of the ObjectBroker registry. (Note that implementation names must be unique.)

The Invalid Implementation error occurs instead of the Implementation is already registered error message because the implementation has a unique UUID, but not a unique name. The error is more likely to occur if you are using modules to scope implementations. You can determine if your implementation name is unique by entering the following command before your implementation has been registered:

obbmsho -R your-implementation-name

If an implementation with the same name as yours appears, you probably have a naming conflict. Here are two possible solutions:

Change your interface and implementations to unique names.
Add module scoping to the implementation. In addition, fully scope the implementation name in the registration attribute, ImplementationName.

An example of an implementation that is not scoped by a module is as follows:

implementation MMImplA
{
	activation_type ( program );
	activation_string ( "/usr/bin/myImpl" );
	implementation_identifier( "66a470e41d4c.0c.ae.08.00.00.00.00.00" );
	registration_attribute string ImplementationName = "MMImplA";
	registration_attribute string ServerInstanceId =
		"66a472a06184.0c.ae.08.00.00.00.00.00";
	method_dispatcher_routine MMImplA__dispatch ();
	registration_routine MMImplA__register ();
	invoke_one ( )
	implements ( MTHDMAP::ALL::invoke_one)
	invoke_builtin ( "MMImplA_invoke_one" )
	;
};

Here is the same implementation, scoped by a module:

module MTHDMAPIMPL {
	implementation MMImplA
	{
	activation_type ( program );
	activation_string ( "/usr/bin/myImpl" );
	implementation_identifier ("66a470e41d4c.0c.ae.08.00.00.00.00.00" );
	registration_attribute string ImplementationName =
		"MTHDMAPIMPL::MMImplA";
	registration_attribute string ServerInstanceId =
		"66a472a06184.0c.ae.08.00.00.00.00.00";
	method_dispatcher_routine MMImplA__dispatch ();
	registration_routine MMImplA__register ();
	invoke_one ( )
		implements ( MTHDMAP::ALL::invoke_one)
		invoke_builtin ( "MMImplA_invoke_one" )
		;
	};
};