04.08-08.08.51 S6BMN020L Logon from sloewens-w540.na.tibco.com:54790, user=TN3270, terminal=3270@TBE, OAISESS(817)

04.08-08.09.00 S6BMN136L osee started. PID=17094 EE [DEFAULT]:0, VM(161)

04.08-08.09.01 S6BMN038E osee abended. PID=17094 EE [DEFAULT]:0 Exit code 9, MAIN(675)

04.08-08.10.01 S6BCM007E Socket operation failed, 'accept', errno=[Bad file number] DOMAINSOCK(513)

04.08-08.10.02 S6BMN127E Logon Failed, errno=[Resource temporarily unavailable] OAISESS(1056)

04.08-08.10.02 S6BCM007E Socket operation failed, 'shutdown', errno=[Bad file number] OSMNSOCK(559)

04.08-08.10.02 S6BCM007E Socket operation failed, 'send', errno=[Bad file number] OSMNSOCK(567)

04.08-08.10.02 S6BCM007E Socket operation failed, 'closeconnection', errno=[Bad file number] OSMNSOCK(586)

A core file is produced.

This problem exists only on Solaris versions 11.0 and later.

On Solaris, when osee or osBatch is first started, the ICU shared library pointed to by the /usr/lib/libicuuc.so symbolic link is loaded and various symbols within that library have to be dynamically resolved. It may be the case that the symbols within the ICU shared library have been renamed by appending a suffix that corresponds to the release of the ICU.

If osee or osBatch fail with one or more S6BIU007E messages, it is likely that no internal mapping of the ICU shared library name to a symbol rename format exists. One needs to be specified with the EE parameter 

ICUSYMRNMFMT. To determine an appropriate symbol rename format, the symbols within the ICU shared library pointed to by the /usr/lib/libicuuc.so symbolic link must be examined to understand how they have been renamed. For example, a Solaris 11.2 system may be such that /usr/lib/libicuuc.so is a symbolic link to /usr/lib/libicuuc.so.46.0. The following command may be used to determine how the ICU symbol u_init has been renamed.

$ /usr/ccs/bin/nm /usr/lib/libicuuc.so.46.0 | /usr/bin/grep u_init

[3925] | 298180| 120|FUNC |GLOB |0 |12 |u_init_46

Assuming that all stable ICU symbols have been renamed using the same "_46" suffix, a symbol rename format of %s_46 would then be appropriate.

Here are the details of the fix:

A new libxerces-c-3.1.so Xerces-C++ parser shared library has been built that depends on ICU functions that have not been "renamed", and leaves resolution of the ICU symbols to link-time of osee.

A new libosicusoname.so shared library that has an SONAME of libicuuc.so is now linked into osee after the Xerces-C++ shared library, and causes the ICU shared library pointed to by the /usr/lib/libicuuc.so symbolic link to be loaded at runtime.

A new libosicu.so library is now linked into osee after libosicusoname.so . It contains weak functions that correspond to the ICU functions needed by the Xerces-C++ shared library. These weak functions are needed in case the functions within the loaded ICU shared library have been "renamed" by having a suffix appended to them corresponding to the release of the ICU.

The libosicu.so shared library has an osICUResolve() interface used by osee at startup to setup function pointers to the renamed functions in the ICU shared library so that they may be called by the weak functions in libosicu.so.

Internally, there is logic to map the basename of the ICU shared library that has been loaded to an snprintf-compatible "symbol rename format" that may be used to derive the name of renamed ICU functions.

In the event that a look-up fails for a symbol rename format, a new Execution Environment parameter (ee.prm) named ICUSYMRNMFMT has been added that allows the symbol rename format to be specified explicitly.

The following messages have been added.

S6BIU001I ICU shared library: %

S6BIU003I ICU symbols successfully resolved

S6BIU005E Failed to get a handle to loaded dynamic library '%': %

S6BIU007E Failed to resolve ICU symbol '%': %

S6BIU010E Could not resolve library path for '%'

S6BIU012E Truncation occurred renaming ICU symbol '%'