PQ48603: THIS APAR ADDRESSES DEFECTS IN WEBSPHERE APPLICATION SERVER V4.0 FOR Z/OS AND OS/390.

 A fix may be available

Obtain the fix for this APAR



APAR status
Closed as program error.

Error description
This APAR addresses defects in WebSphere Application Server
V4.0 for z/OS and OS/390.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: All users of WebSphere Application Server    *
*                 V4.0 for z/OS and OS/390.                    *
****************************************************************
* PROBLEM DESCRIPTION: APAR PQ48603 addresses various problems *
*                      in WebSphere Application Server V4.0    *
*                      for z/OS and OS/390.                    *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
APAR PQ48603 addresses the following
problems in WebSphere Application Server
V4.0 for z/OS and OS/390:

Object Builder commands:
        obgen, obimport, obexport, obmigrate,
        obcheck, importimpl,importidl"
received the following error message when executed on a z/OS
operating system:

OS not supported.
Supported OS: AIX, OS/390, Solaris, Windows 2000, and Windows NT
Using Windows as default.

Support for the z/OS operating system needs to be provided for
these Object Builder commands.

Message skeleton files BBOUMSEN and BBOUMSJP contain invalid
messages skeletons for messages BBOU0624I and BBOU0629W.

Applications will receive class load failures on a class that
ends in _stub.

ABENDS0C4, ABEND0C4, SIG_SEGV can occur after receiving a SIGPIP
signal. A SIGPIPE signal was "raised" and the WebSphere signal
handler, RasSignalHandler2 (bborexit.cpp), got control to
process it. RasSignalHandler2 incorrectly assumed the
existence of a BTCB (bbo3tcb.h). This led to the use of an
incorrect jmp_buf area (setjmp.h) on a longjmp invocation.  The
longjmp corrupted the execution environment which led to the
ABEND0C4.

nullPointerException can occur in a second server region
instance. The error is on a multi-threaded server. If each clien
accesses the same bean on different threads for the first time,
nullPointerException occurs because one thread gets back a
response that the bean metadata is loaded and it really isn't
yet. The client can recieve either CORBA::INTERNAL exception
minorcode C9C257C7 or C9C257CF. In the case of the C9C257C7
minorcode the container is unable to find the home associated
with the object that was passed to keyToObject. There will not b
any other indication in the server output of what the problem is
If the setting com.ibm.ejs.container.WrapperManager=event=enable
was put in the JRAS trace settings file then you would see a
message in the job log for the server of Malformed object key.
You would also see a stack trace that indicates a
nullPointerException in
com.ibm.ejs.container.BeanId.deserialize(BeanId.java:408)
or com.ibm.ejs.container.InvalidBeanIdException
in HomeOfHomes.createWrapper(HomeOfHomes.java:445)
If the minorcode was C9C257CF you could see one of the
following exceptions:
nullPointerException in
DocumentImplGen.listEnterpriseBeanBinding
(DocumentImplGen.java:82)
or
com.ibm.ws390.sm.mm.ExceptionBeanMetaDataMgr in
BeanMetaDataMgrImpl.getBeanMetaData(BeanMetaDataMgrImpl.java:342
or
java.lang.StringIndexOutOfBoundsException: String index out of
range: -1 in
NameFormatHelper.unquoted_string(NameFormatHelper.java
(Compiled Code))

ABEND0C4 ABENDS0C4 in get_pending_orb_request in bboocomm.cpp.
A locate driven from a server region to the local Daemon results
in an ABENDS0C4 processing the response in the Control region
when trying to drive the read_msg because the session object
pointer in the session handle being used is bad (not zero, it in
fact points to the session object in the daemon).

Storage leaks in Java can result in callback processing.
In the callback invoke processing in bbooejsb.cpp local
references to parameters passed on the invoke are not released.
The size of these leaks vary depending on data passed by the
application on the call. Hanging on to the reference prevents
Java from garbage collecting the storage.

Little endian clients experience failures due to responses
containing big endian IORs that should be little endian.
Problems include IORs returned as forward responses to requests
sent to the Daemon and an IOR marshalled into the response strea
of an EJB. The Daemon fails to convert the IOR it puts in a
forwarding response to a request to the proper endian before
sending it. An IOR marshalled into the response stream of an EJB
is not marshalled with the proper endian.
Problem conclusion
Support has been provided for Object Builder commands:
        obgen, obimport, obexport, obmigrate,
        obcheck, importimpl,importidl"
to recognize the z/OS operating system.

Message skeletons for messages BBOU0624I and BBOU0629W have been
corrected in messages skeleton files BBOUMSEN and BBOUMSJP.

WS390ApplicationManager.java was updated to correct the problem
of applications receiving class load failures on a classes that
have names that end with _stub. Code was updated to add
org.omg.stub. as a prefix to the class name being loaded and
retry the load.

Code has been added to our signal handler to verify that a BTCB
exists prior to using it.  Also, the code has been modified to
invoke the previously defined signal handler (previous to
WebSphere establishing its signal handlers), if any, if a valid
jmp_buf area could not be found when a SIGPIPE signal is
received.

Load of the Bean Metadata has been changed to be synchronized so
only one thread is loading bean metadata at a time. This was
done because when multiple threads were loading the same beans
metadata at the same time some of the threads may have gotten a
true response back from the loaded test when the metadata load
was not complete. Additionally, there were some single instance
objects that were getting initialized multiple times in the path
which was causing various different failures.

Module bboclspc.plx has been modified to correctly determine
the session object pointer.

Support has be changed to release local references to Java
objects after the invoke is done.

request-to-daemon processing in module bboocomm.cpp has been
corrected to format the forwarding IOR in the correct endian.
Also, the creation and writing of an object reference (IOR)
in Java has been corrected to consider the endianness of the
stream the reference is being written into.

APAR PQ48603 is associated with SERVICE LEVEL W400011 of
WebSphere Application Server V4.0 for z/OS and OS/390.
Temporary fix Comments
APAR information
APAR number PQ48603
Reported component name WASKBASE
Reported component ID 5655A9801
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2001-05-09
Closed date 2001-05-11
Last modified date 2001-06-05

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:
UQ54122

Modules/Macros
BBOCLSPC BBOLSYS BBOMIB10 BBOMSBO2 BBOMSBO8 BBOMSXML
BBOOCOMM BBOOEJSB BBORAS BBOREXIT BBOUBINF BBOUMSEN
BBOUMSJP BBOZ0229 BBOZ0266 BBOZ0267 BBOZ0268 BBOZ0269
BBOZ0270 BBOZ0271 BBOZ0272 BBOZ0273 BBOZ0274 BBOZ0285
BBOZ0286 BBOZ0287 BBOZ0288 BBOZ0289 BBOZ0290 BBOZ0291
BBOZ0292 BBOZ0293 BBOZ0757 BBOZ0758 BBOZ0812 BBOZ0813

Fix information
Fixed component name WASKBASE
Fixed component ID 5655A9801

Applicable component levels
R400 PSY UQ54122    UP01/05/25 P F105

  Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server for z/OS
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ48603
IBM Group: Software Group
Modified date: Jun 5, 2001