PQ51052: 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 PQ51052 addresses various problems *
*                      in WebSphere Application Server V4.0    *
*                      for z/OS and OS/390.                    *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
This APAR provides trace enhancements to the WebSphere
Application Server V4.0 for z/OS and OS/390 adapter support.

A REXX script fails with BBON3000E Unexpected error:
java.lang.ArrayIndexOutOfBoundsException when a call to
CB390CFG is made without specifying a -output value. The cause
is incorrect checking on the client side of SM scripting for
the setting of a parameter value for the "output" parameter.

In the Administration application for WebSphere for z/OS
Version 4.00.003a, when defining a datasource instance, one of
the fields that needs to be specified is "Database Name".
The "Database Name" label is very misleading because what needs
to be specified is "Location Name". There is fly-over help that
explains this, but it may not be read by a customer. When the
database name is entered a SQL error -904 is received and the
connection will not work. Attribute "Database Name" for J2EE
Resource type DB2datasource needs to be called "Location name"
in db2datasource.xml.

NullPointerException recieved during UserTransaction.begin().
If UserTransaction reference is saved by ejbCreate and used in
a subsequent call on the bean, a java.lang.NullPointerException
results. The failure is due to UserTransaction not correctly
enlisting the current EJB in a transaction.

During adding a server, customer recieved message
  BBON1137E Create working directory
  /WebSphere390/CB390/working/BBOASR2 for server BBOASR2 failed.

The problem was that the customer did not have the 'required'
OWNER/GROUP for the TARGETDIR (WebSphere390/CB390). It was not
owned by the WebSphere System Management server region user
(default: CBSYMSR1), and the WebSphere cfg group (default:
 CBCFG1).

CORBA::Request attribute m_Flags (bbooreq.h) erronously
indicates that the request was a oneway request
(CORBA::INV_NO_RESPONSE) in the WebSphere server region (SR).
This caused an error in the OLT with the trace display.
The Request object m_Flags value was not reset between
Request's received into the SR.  Once the
CORBA::INV_NO_RESPONSE flag was set into the
CORBA::Request used on a SR thread, then subsequent requests
also had the flag on. The OLT saved information from the client
based on the client's setting of m_Flags (which did not indicate
a oneway).  This information was propagated to the SR where the
value of m_Flags was erronously changed.

When generating large amounts of SMF data a program check may
occur in a control region. A SIGSEV signal occurs along with
MSG/BBOU0036W when the SMF component of WebSphere tries to
return large areas of dataspace storage. No data are lost
(since this happens at cleanup time) but a dump message shows
up on the console indicating that BBOOSMF function reset
failed. The control region output indicates a storage violation
has occurred and the thread has been restarted. The errors
occurs because method SmfStorage.obtain does not correctly
initialize the attribute that points to the next block. So
during SmfStorage.reset, the method tries to release a buffer
at an invalid address.

When executing bbomcfg, if TARGETDIR has owner or group IDs
without associated user or group names (which might happen,
e.g., if a tar archive is unpacked using UID 0), the error
message displayed by bbomcfg contains a non-initialized REXX
variable. Examples of the error message are:

if TARGETDIR was, e.g.,
drwxr-xr-x   2 2210     2211        8192 Aug  3 03:28 blub
which might happen if it was unpacked from a tar archive using
UID 0, then the bbomcfg error message will look similar to:

Owner of target directory /blub (UIDINFO.1) is not equal to SM
sr userid name CBSYMSR1
Please correct (e.g., chown on target directory), and resubmit.

Similarly, if TARGETDIR was, e.g.,
drwxr-xr-x   2 CBSYMSR1 2211        8192 Aug  3 03:28 blub
then the bbomcfg error message will look similar to:

Group of target directory /blub (GIDINFO.1) is not equal to CB
cfg group name CBCFG1
Please correct (e.g., chown on target directory), and resubmit.
where UIDINFO.1 and GIDINFO.1 are uninitialized REXX variables.

WebSphere Application Server V4.0 for z/OS and OS/390
Installation and Customization (GA22-7834-01) page 34 indicates
specifying 'no limit' for J2EE Application Servers WLM
application environment setting for limit on starting server
address space for a subsystem instance. Parts BBOINSTR in
installation dataset BBO.SBBOPLIB and BBOINJPN in installation
dataset BBO.SBBOSLIB need to be updated to specify this setting.

A javax.naming.NameNotFoundException occurs when WebSphere
Application Server for z/OS and OS/390 V4.0 is a client to
WebSphere Application Server V4.0. This problem occurs when the
client is on z/OS or OS/390 trying to resolve a name in a
WebSphere Application Server V4.0 name space. An exception of
IDL:org.omg/CosNaming/NamingContext/NotFound:1.0 can be seen in
the trace of communication in the client if TRACEDETAIL=(3). The
exception thrown in java is javax.naming.NameNotFoundException.

ClassCastException can be recieved during Util.copyObject()
following return of an Enumeration.

Call to ORBEJSBridge.invoke(), could return without
disassociating transaction previously active on thread from
container Transaction Manager, or doing security cleanup.

Client threads in webserver may not get responses back from the
server. The cause of the problem results from problem in
concurrent callback to one client. comm_outbound_request creates
a hash table if the request is for callback. WebSphere might
already have a hash table. If this is true we leak the old hash
table if we run serial callbacks back to the client space.
If the client space is a web server its very possible we
could have multiple concurrent callbacks going at once.  So what
happens is that request 1 drives a callback (callback request 1)
which creates a hash table, puts the callback request orbr in it
and sends the callback request. Request 2 comes along with
callback request 2 which creates a new hash table, overlays the
pointer in the session, and puts his ORBR in the new table and
sends his callback request. When a response comes for callback
request 1, we can't find the corresponding ORBR in the hash
table, so we issue a message and drop the response.  This hangs
request 1 and his associated client.  Eventually we eat all
(or most) of the threads in the client.

When an WebSphere Application Server V4.0 for z/OS and OS/390
client requests the WsnNameService object from a WebSphere
Application Server V4.0(WAS V4.0) the is_a request to the
WAS V4.0 bootstrap server for that object will fail because the
typeid that we send to the AE server is incorrect. The typeid
should be IDL:com.ibm/WsnBootstrap/WsnNameService:1.0 it was
IDL:com/ibm/WsnBootstrap/WsnNameService:1.0. If comm. detailed
trace is active the incorrect typeid can be observed.
Problem conclusion
This APAR provides trace enhancements to the WebSphere
Application Server V4.0 for z/OS and OS/390 adapter support.

CB390CFG has been modified to ensure that a parameter value is
set for the "output" parameter.

In db2datasource.xml the label was renamed to "Location name".
This does not affect already defined J2EE resources. Only when
creating a new resource the modified label is shown.

UserTransaction has been modified to correctly enlist the
current EJB in a transaction.

Shell script BBOMCFG was modified to check owner and group of
TARGETDIR. If it is not equal to OWNER and GROUP, it fails  with
a message indicating the error. Likewise, the mode of TARGETDIR
is checked. If owner has rights different from 7, and group
different from 5 or 7, . BBOMCFG fails with a message indicating
the error. Customers should then do appropriate chown/chmod
commands on TARGETDIR. The same should be done as solution if
the problem shows up after bootstrap.

Code has been added to the Associate_ORB_Request method
(bbooireq.cpp) to clear the m_Flags between CORBA::Request's.

Method SmfStorage.obtain has been modified to correctly
initialize the attribute that points to the next block, thus
allowing for the proper freeing of storage during
SmfStorage.reset processing.

BBOMCFG has been modified to check return values of getpwuid
and getgrgid. If nothing is returned, then TARGETDIR has owner
and/or group id without associated owner and/or group name
(i.e., a owner and/or group that is not defined in RACF). In
that case, we display the owner/group id in the error message.

Parts BBOINSTR in installation dataset BBO.SBBOPLIB and BBOINJPN
in installation dataset BBO.SBBOSLIB have been updated to
specify "no limit" for J2EE Application Servers WLM
application environment setting for the limit on starting server
address space for a subsystem instance.

WebSphere Application Server V4.0 uses multiple IORs to point to
various leafs in the names space. The incorrect IOR was being
used from the client code on OS/390. The product was updated
to select the correct IOR from the WsnNameService object. This
object points to the part of the name space where the
application Home/Factory was registered.

ORB.loadStub() was changed to always load a stub for the most
derived class, based on the typeid in an IOR.

Try-catch-finally clauses ORBEJSBridge have been restructured
such that transaction and security cleanup is always performed.

Module BBOOCOMM.CPP has been modified to use compare and swap to
serialize creation of the hash table since only one is needed.
This eliminates a storage leak when client is single threaded.
This eliminates the hash table being overlaid with a second one
when the client is multi threaded.

The idl that represents the WsnNameService interface was updated
to generate the correct typeid so that the Narrow and is_a
request will work.

The following publication was revised as a result
of APAR PQ51052:
________________________________________________________________
WebSphere Application Server V4.0 for z/OS and OS/390
Messages and Diagnosis
GA22-7837-00
________________________________________________________________
NOTE: Periodically, we refresh the documentation on our
Web site, so the changes might have been made before you
read this text. To access the latest on-line
documentation, go to the product library page at:

http://www.ibm.com/software/webservers/appserv/
________________________________________________________________
Chapter 13, pg. 462 (changed)
C9C24C01
Explanation: Adapter code encountered an unexpected system
  failure.
User Response: Contact the IBM Support Center.
________________________________________________________________
Chapter 13, pg. 462 - 463 (changed)
C9C24C05
Explanation: Adapter code using APPC failed to allocate the
     conversation
User Response: Check APPC configuration to make sure APPC is up
     and running and that APPC connectivity exists between the
     two LUs. If trace level 1 (exception tracing) was active
     for the Adapter component, search the trace for the string
     "Error issuing APPC service". This trace entry will contain
     APPC error message text that describes the reason for the
     APPC Allocate failure. Lookup the APPC message explanation
     in the MVS publication " Writing TPs for APPC/MVS" and
     perform the action indicated for the APPC error message. If
     no tracing was active, rerun the application with trace
     level 1 or higher for the Adapter component and then locate
     the APPC error message text in the trace as indicated
     above.
________________________________________________________________
Chapter 13, pg. 463 (changed)
C9C24C06
Explanation: Adapter code using APPC failed while invoking the
     APPC send service.
User Response: If trace level 1 (exception tracing) was active
     for the Adapter component, search the trace for the string
     "Error issuing APPC service". This trace entry will contain
     APPC error message text that describes the reason for the
     APPC send failure. Lookup the APPC message explanation in
     the MVS publication " Writing TPs for APPC/MVS" and perform
     the action indicated for the APPC error message. If no
     tracing was active, rerun the application with trace level
     1 or higher for the Adapter component and then locate the
     APPC error message text in the trace as indicated above.
________________________________________________________________
Chapter 13, pg. 463 (changed)
C9C24C07
Explanation: Adapter code using APPC failed while invoking the
     APPC receive service.
User Response: If trace level 1 (exception tracing) was active
     for the Adapter component, search the trace for the string
     "Error issuing APPC service". This trace entry will contain
     APPC error message text that describes the reason for the
     APPC receive failure. Lookup the APPC message explanation
     in the MVS publication " Writing TPs for APPC/MVS" and
     perform the action indicated for the APPC error message.
     If no tracing was active, rerun the application with trace
     level 1 or higher for the Adapter component and then locate
     the APPC error message text in the trace as indicated
     above.
________________________________________________________________
Chapter 13, pg. 463 (changed)
C9C24C08
Explanation: Adapter code using APPC failed while invoking the
     APPC confirmed service.
User Response: If trace level 1 (exception tracing) was active
     for the Adapter component, search the trace for the string
     "Error issuing APPC service". This trace entry will contain
     APPC error message text that describes the reason for the
     APPC confirm failure. Lookup the APPC message explanation
     in the MVS publication " Writing TPs for APPC/MVS" and
     perform the action indicated for the APPC error message. If
     no tracing was active, rerun the application with trace
     level 1 or higher for the Adapter component and then locate
     the APPC error message text in the trace as indicated
     above.
________________________________________________________________
Chapter 13, pg. 463 (changed)
C9C24C09
Explanation: Adapter code using APPC failed while invoking the
     APPC deallocate service.
User Response: If trace level 1 (exception tracing) was active
     for the Adapter component, search the trace for the string
     "Error issuing APPC service". This trace entry will contain
     APPC error message text that describes the reason for the
     APPC deallocate failure. Lookup the APPC message
     explanation in the MVS publication "Writing TPs for
     APPC/MVS" and perform the action indicated for the APPC
     error message. If no tracing was active, rerun the
     application with trace level 1 or higher for the Adapter
     component and then locate the APPC error message text in
     the trace as indicated above.
________________________________________________________________
Chapter 13, pg. 463 (new message)
C9C24C0A
Explanation: Adapter code failed while using one of the CICSEXCI
     services.
User Response: Check the WAS error log for the string "CICSEXCI"
     for further diagnostic information.
________________________________________________________________
Chapter 13, pg. 463 (new message)
C9C24C0B
Explanation: Specified TPName (i.e., IMS transaction name)
     exceeds maximum length.
User Response: Specify a shorter name.  Consult IMS and APPC
     documentation for specific parameter requirements.

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

APAR is sysrouted FROM one or more of the following:

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

Modules/Macros
BBOAXCEI BBOAXIAI BBOIROOT BBOJBOUI BBOJBOUS BBOLSDEL
BBOMSBO BBOMSCO BBOOBOAI BBOOBOAT BBOOCOMM BBOOIREQ
BBOOORB BBOOSS BBOUBINF BBOZ0229 BBOZ0663 BBOZ0688
BBOZ0784 BBOZ0812 BBOZ0813 BBOZ0814    

Fix information
Fixed component name WASKBASE
Fixed component ID 5655A9801

Applicable component levels
R400 PSY UQ57091    UP01/09/04 P F108

  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 #: PQ51052
IBM Group: Software Group
Modified date: Sep 5, 2001