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 is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
|
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
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.