PQ59440: CREATING CONVERSATION USING THE SM/EUI, RECEIVE MSGS IN SM/EUI MMSG LOG: BBON0126E BBON0145I MINOR CODE C9C21454

APAR status
Closed as documentation error.

Error description
When creating a Conversation using the SM/EUI, the create fails
with error messages BBON0126E and BBON0145E in the Message log
of the SM/EUI. Both of htese error messages have the same minor
code C9C21454.
In the MVS console, we see other DSNxxx type messages:
DSNP011I ( DSNPXTN0 - MEDIA MANAGER SERVICES ERROR FOR
    DSNC710.DSNDBC.BBOMDB01.L097#ROJ.I0001.A001 MMRC=8
    DSMRC=00D70014 CONNECTION-ID=RRSAF, CORRELATION-ID=CB390,
    LUW-ID=*
.
DSNP007I ( DSNPXTN0 - EXTEND FAILED FOR
  DSNC710.DSNDB.BBOMDB01.L097#ROJ.I0001.A001
  RC=00D70014 CONNECTION-ID=RRSAF, CORRELATION-ID=CB390,LUW-ID=*
ADDITIONAL SYMPTOMS:
The following message may be seen in the SM/EUI when adding a
new conversation:
BBON0151E Corba System exception, server still connected
This can be seen when there are many 'old' conversations defined
in to SM/EUI.
Local fix
This problem has been found to occur when there are many 'old'
conversations defined in the SM/EUI.
A good practice to get into is to delete the old conversations
when creating the new applications.  The old applications store
information into the DB2 tables, and depending on the size of
the .ear files, the amount of storage being used can be large.
Problem summary
****************************************************************
* USERS AFFECTED: All users of WebSphere Application Server    *
*                 V4.0.1 for z/OS and OS/390                   *
****************************************************************
* PROBLEM DESCRIPTION: The WebSphere for z/OS: Installation    *
*                      and Customization publication should    *
*                      be updated to give instructions to      *
*                      avoid exceeding the DB2 tables.         *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
The WebSphere for z/OS: Installation and Customization
publication doesn't have any text on how to check the size of
the DB2 tables or what to do to decrease them in the event that
they are full or almost there.

The WebSphere for z/OS: Installation and Customization
publication should be updated to include directions for
determining the DB2 table size and what to do if they are full
or nearly full.
Problem conclusion
A change to V4.0.1 WebSphere for z/OS: Installation and
Customization will be available soon. To access the latest
online documentation, go to the product library page at:

www.ibm.com/software/webservers/appserv/zos_os390/

The following addition will go in at the end of Chapter 3:
________________________________________________________________

Chapter 3, pg. 219 (added section)

Managing DB2 space occupied by SM tables

Steps for determining the DB2 space currently occupied by the SM
tables

To determine the DB2 space currently occupied by the SM tables:

1. Determine the names of the "BLOB" tables associated with key
SM tables.

Example: SQL statement to display names/sizes of "BLOB" tables
associated with key SM tables (These are the tables most likely
to get large):
SELECT Y.TBNAME,
       X.TSNAME,
       Z.PQTY,
       Z.SECQTYI,
       Z.SPACE,
       Z.EXTENTS,
       Z.STATSTIME
FROM SYSIBM.SYSTABLES X,
     SYSIBM.SYSAUXRELS Y,
     SYSIBM.SYSTABLEPART Z
WHERE X.NAME = Y.AUXTBNAME
  AND X.TSNAME = Z.TSNAME
  AND Y.TBNAME IN ( BBOMT80_J2EEAPP ,
                    BBOMT81_MODULE ,
                    BBOMT82_COMPONENT ,
                    BBOMT83_METHOD ) ;
__________________
2. Use RUNSTATS to gather size data for SM tables

Example: Sample JCL to perform RUNSTATS for SM tables Replace
the "????????" in the first five statements with the TSNAME
values from Step 1. These are generated names and will likely
contain special characters (for example, L1$M@NJV).
//IBMUSERA JOB (ACCOUNT), NAME ,NOTIFY=IBMUSER
//*
//UTIL EXEC DSNUPROC,SYSTEM=DB2,UID= TEMP ,UTPROC=
//DSNUPROC.SYSIN DD *
RUNSTATS TABLESPACE BBOMDB01.???????? ;
RUNSTATS TABLESPACE BBOMDB01.???????? ;
RUNSTATS TABLESPACE BBOMDB01.???????? ;
RUNSTATS TABLESPACE BBOMDB01.???????? ;
RUNSTATS TABLESPACE BBOMDB01.???????? ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS00 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS02 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS04 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS06 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS10 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS15 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS19 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS23 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS25 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS27 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS29 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS31 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS33 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS35 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS37 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS39 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS41 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS43 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS45 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS48 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS51 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS52 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS53 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS54 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS56 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS58 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS60 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS62 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS64 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS66 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS68 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS70 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS72 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS74 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS76 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS80 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS81 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS82 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS83 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS84 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS85 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS86 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS87 ;
RUNSTATS TABLESPACE BBOMDB01.BBOMS90 ;
__________________
3. Display the size statistics for key SM DB2 "BLOB" tables by

rerunning the SELECT statement in Step 1. After RUNSTATS, it
will show valid statistics.
__________________
4. Display the size statistics for standard SM DB2 tables using
the following SELECT statement.

Note: RUNSTATS must be run before doing this to get correct
values.

Example: SQL statement to display sizes of SM tables (Most will
never get very large, but it is probably easiest to just look at
them all.)
SELECT X.NAME,
       Z.TSNAME,
       Z.PQTY,
       Z.SECQTYI,
       Z.SPACE,
       Z.EXTENTS,
       Z.STATSTIME
FROM SYSIBM.SYSTABLES X,
     SYSIBM.SYSTABLEPART Z
WHERE X.TSNAME = Z.TSNAME
  AND X.TSNAME LIKE  BBOMS% ;
__________________
You are done when all the desired size statistics are displayed.

Note: If your tables turn out to be larger than expected, see
"Steps for managing large DB2 tables" on page 221 to reduce
their size and protect them from reaching their maximum. If,
however, the tables are already at their maximum, see "Steps for
managing DB2 tables at their maximum" on page 222.

________________________________________________________________

Chapter 3, pg. 221 (added section)

Steps for managing large DB2 tables

If you notice that your DB2 tables are getting too big, there
are two main things that you can do to ensure they don t reach
the maximum:

1. Delete any conversations you don t need, because that will
remove information from the DB2 tables and free up space.
__________________
2. Increase the secondary extent size (SECQTY) for any tables
that have expanded to more than 10 extents and which you expect
will continue to grow. Doing this will mean it takes longer to
reach the maximum number of extents because each newly allocated
extent is larger, it will hold more and you won t need to
allocate more extents as often. This won t change the existing
allocations, but will make any future added extents larger, so
the number of extents won t grow as quickly.

Note: Make sure you first follow the steps in "Steps for
determining the DB2 space currently occupied by the SM tables"
on page 219.

Example: SQL statement to alter secondary extent size for SM
tables or "BLOB" tables
ALTER TABLESPACE BBOMDB01.tsname SECQTY SizeInK
  - "tsname" is the table space name shown in the TSNAME column
of the display output.
  - "SizeInK" is the desired new secondary extent size in K
    (kilobytes).

Note: The display output PRIQTY and SECQTY values are the number
of 4K blocks allocated, but when doing the ALTER command shown,
you must specify the value in K. So, for example, if the current
SECQTY shown in the display output is 100, that means there are
100 4K blocks or 400K. To make the extent larger, you must
specify a number larger than 400 on the ALTER command (for
example, 800 to request 200 4K blocks).
__________________
You are done when the size of your DB2 table diminishes.

________________________________________________________________

Chapter 3, pg. 222 (added section)

Steps for managing DB2 tables at their maximum

If your DB2 table is at its maximum and reducing its size
doesn t work, try the following:

1. Do a "prepare for cold start." This makes a copy of
everything necessary to restore the conversations. See "Cold
start" on page 344 for more information.
__________________
2. Redefine the DB2 tables with larger primary/secondary extent
sizes.
__________________
3. Do a "cold start" to reload the DB2 tables. See "Cold start"
on page 344 for more information.
__________________
You are done when your system is back up and the DB2 tables are
no longer at their maximum.

Note: A coldstart costs you a fairly significant outage, so it
is not a desirable option for most customers. The best thing to
do is make sure your DB2 tables never reach their maximum in the
first place.

...
________________________________________________________________
Temporary fix Comments
APAR information
APAR number PQ59440
Reported component name WASKBASE
Reported component ID 5655A9801
Reported release 401
Status CLOSED DOC
PE NoPE
HIPER NoHIPER
Submitted date 2002-03-26
Closed date 2002-07-15
Last modified date 2002-09-24

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros

Fix information

Applicable component levels


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server for z/OS
Operating system(s):
Software version: 401
Software edition:
Reference #: PQ59440
IBM Group: Software Group
Modified date: Sep 24, 2002