Solstice Enterprise Manager 4.1 Troubleshooting Guide

Chapter 9

Troubleshooting C++ Application Development Problems

This chapter provides information on resolving problems with Solstice EM from a development perspective. For detailed information on working with Solstice EM from an application development perspective, see the Developing C++ Applications guide.

This chapter discusses the following topics:

• Section 9.1 Solstice EM API Problems
• Section 9.2 GDMO Problems

9.1 Solstice EM API Problems

9.1.1 PMI Album Derivation is Slow to Complete

Problem: When multiple GETs are scoped through the Portable Management Interface (PMI) with the responses buffered, performance degrades.

Probable Cause: When the MIS processes a GET, it sends a response to the PMI. Upon receiving the response, the PMI attempts to construct an image out of the response to be included in the Album. To do so, it needs the Meta Data Repository (MDR) information for the class. Upon checking the cache, it finds no such information and sends an ACTION to the MIS to get the MDR information. The MIS, however, cannot get to the ACTION until all the responses have been completed. Thus, the PMI queues the remaining responses until the ACTION is satisfied.

Solution: To avoid making the PMI wait for the MIS responses to complete, pre-cache the information from the MDR.

Replace the following code:
album.set_derivation("xxxxxx/LV(1)");
album .derive();

with the following code:
Image im(duNONE, <objectClass>);
im.boot;
album.set_derivation("xx xxxx/LV(1)");
album.derive ();

See Also: C++ API Reference for information about the specific syntax of API functions and classes and Developing C++ Applications guide.

9.1.2 Missing Application Error Messages

Problem: PMI calls are compiled in your application, but when you run the application, you do not see any error messages and it does not do what you expected.

Probable Cause: Verify that the appropriate error handling routines are called in your application.

See Also: C++ API Reference for information on the Error Class.

9.1.3 Rogue Wave Class Errors

Problem: Rogue Wave classes (for example, Tools.h++) display error messages during compilation that appear to blame the Rogue Wave class files. The errors will be similar to

"/opt/SUNWspro/.../include/CC/rw/regexp.h," line 74: Error: "}" expected instead of "(". And, "/opt/SUNWspro/.../include/CC/rw/regexp.h", line74: Error: no direct declarator preceding "(".

Solution: You must include the Rogue Wave classes before the PMI classes.

For example, if you had the following series of include statements:
#include <pmi/hi.hh>
#include <rw/cstring.h>
#include <rw/regexp.h>
#include <rw/rstream.h>

you should change the sequence to:
#include <rw/cstring.h>
#include <rw/regexp.h>
#include <rw/rstream.h>
#include <pmi/hi.hh>

See Also: Developing C++ Applications guide.

9.1.4 Synchronous Confirmed Requests Do Not Work in Event Callbacks

Problem: A synchronous, confirmed request (also called a "round-trip request") viewerapi_send_request( ) in an event callback (handler) was sent and did not work.

Probable Cause: This does not work because the response would come to the event queue of the sending process, but the sending process would not be able to examine the queue because it was already in an event callback. Only after the callback completes can the event queue be examined. Therefore, viewerapi_send_request() would be blocked until time-out, but the request may be sent out and executed successfully in the remote process.

Solution: Try these actions to solve the problem:

• Send an asynchronous request:
  viewerapi_start_send_request().
• Or in simple cases, send an unconfirmed request: viewerapi_send_request_unconfirmed().

If possible, do the synchronous, confirmed request outside the callback.

See Also: C++ API Reference guide For information about the specific syntax of API functions and classes.

9.2 GDMO Problems

9.2.1 Notification Error

Problem: You create a new GDMO document with your notification and add a mapping in every object so that your event will be logged as an emAlarmRecord.

Everything goes smoothly (no GDMO compilation errors), but when the event is sent, probableCause and specificProblems are not logged even though they were present in the event.

Your GDMO document looks like this:
myEvent NOTIFICATION
BEHAVIOUR snmAlarmEventBehaviour;
WITH INFORMATION SYNTAX Notification-ASN1Module.AlarmInfo
AND ATTRIBUTE IDS probableCause probableCause,
specificProblems specificProblems;
REGISTERED AS {em-mpa-notification 1};
myEventBehaviour
BEHAVIOUR
DEFINED AS
"This notification is used to send my event duh";

probableCause and specificProblems are defined in a different GDMO document and this was not caught during compilation. When the logRecord is created, the log module cannot find those attributes so it bypasses them.

Solution: The attributes should be defined as follows:
AND ATTRIBUTE IDS
probableCause
"Rec. X.721 | ISO/IEC 10165-2 : 1992": probableCause,
specificProblems
"Rec. X.721 | ISO/IEC 10165-2 : 1992":specificProblems;

For detailed information about GDMO, see the ITU X.722 ISO/IEC 10165-4 Guidelines for the Definition of Managed Objects (GDMO).