[ICS]Unable to find version "* .*.*" of business object definition XXXX

[Mesg: Data handler com.ibm.bcg.DataHandlers.AttachmentDataHandler failed to convert message (ID:414d51206263672e71756575652e6d61b5afea4620010103) to business object (any). It reported the following error: com.ibm.bcg.DataHandlers.AttachmentDataHandlerException:CxCommon.Exceptions.BusObjSpecNameNotFoundException: Unable to find version "*
.*.*" of business object definition "SBX_".. ]

I tried 3 different BO's and with all of them I get the same error. I had a problem before with the collaboration object that didn't want to start so the connector wasn't even starting. I fixed that but now I'm hitting the wall with this one. I recreated already the connector from scratch and nothing.

Two weeks ago the ICS server didn't want to start, and we had to pull a db backup from last month to make it work. I don't know if there are still hidden issues of the previous problem or a new one because we did that.

Anyone with an idea of the best approach to solve this issue?

一、
This error occurs when the structure of the XML request put into the request queue does not match the BO definition in the repository of the connector.

Please check the following -

1. A BO XSD by name ASBOPip3C3_Pip3C3InvoiceNotification.xsd is present in the repository directory of the connector
2. The BO ASBOPip3C3_Pip3C3InvoiceNotification is listed in the Supported Business Objects tab of the connector configuration file
3. The XML message put into the request queue has an RFH header with the following attributes set under the mcd directory - (Msd='xml', Type='ASBOPip3C3_Pip3C3InvoiceNotification', Fmt='CwXML')
4. The XML body is valid and contains proper namespace prefixes


二、
check DataHandler\CwXMLDataHanlder.jar
check have any OverWrite method

oracle的instr

INSTR方法的格式為
INSTR(來源源字串, 目地字串, 起始位置, 匹配序號)

例如：INSTR('CORPORATE FLOOR','OR', 3, 2)中，源字符串為'CORPORATE FLOOR', 目標字符串為'OR'，起始位置為3，取第2個匹配項的位置。

默認查找順序為從左到右。當起始位置為負數的時候，從右邊開始查找。

所以SELECT INSTR('CORPORATE FLOOR', 'OR', -1, 1) "Instring" FROM DUAL的顯示結果是

Instring
——————
14

FROM <http://www-1.ibm.com/support/docview.wss?rs=693&context=SSBTEG&dc=DA490&dc=DA4A10&dc=DB520&dc=DA4A30&dc=DB530&dc=DA480&dc=D700&dc=DA4A20&dc=DB560&dc=DA440&dc=DA460&dc=DA430&dc=DA470&dc=DB550&dc=D600&dc=DB600&dc=DA420&dc=DA500&dc=DA410&dc=DB540&dc=DB700&dc=DA400&dc=DB510&uid=swg21239674&loc=en_US&cs=utf-8&lang=en>

Problem

Garbage Collection (GC) logs are huge and cannot be contained in a single file or takes up too much space.

Cause

Space and file size constraints, especially in production environments can be a good reason to start using circular logging.

Solution

The format is as follows: -Xverbosegclog:[DIR_PATH][FILE_NAME]#,X,Y For example: -Xverbosegclog:/usr/eai/IBM/orb#.log,5,2 The above example generates 5 files in /usr/eai/IBM path under the names orbtrc1.log, orbtrc2.log, etc up to orbtrc5.log, each containing 2 GC occurrences.

Diagnosing out of memory problems in ICS on AIX&windows

from <http://www-1.ibm.com/support/docview.wss?rs=693&context=SSBTEG&dc=DA490&dc=DA4A10&dc=DB520&dc=DA4A30&dc=DB530&dc=DA480&dc=D700&dc=DA4A20&dc=DB560&dc=DA440&dc=DA460&dc=DA430&dc=DA470&dc=DB550&dc=D600&dc=DB600&dc=DA420&dc=DA500&dc=DA410&dc=DB540&dc=DA400&dc=DB700&dc=DB510&uid=swg21250293&loc=en_US&cs=utf-8&lang=en>

Problem

This document is designed to help you collect data for problems related to running out of memory. Gathering specific information before calling IBM Support will help you communicate the problem and save time analyzing the data.

Solution

Garbage collector output (verbose:gc), javacore files, and heapdumps may all be helpful in diagnosing out of memory issues with WebSphere® InterChange Server. If you have already contacted IBM Support, continue reading to begin collecting WebSphere InterChange Server MustGather data. Otherwise, please consult WebSphere Interchange Server MustGather: read first. Collecting JVM specific information Enabling and collecting verbose:gc Verbose:gc logs provide statistics on the state of memory during every garbage collection. To enable verbose:gc, add the verbose:gc flag to the Java™ executable file in the startup script. Then restart InterChange Server to activate verbose:gc logging. To enable verbose:gc logging, refer to the instructions that follow for your platform. . AIX Modify the ics_manager file so that the Java executable command line reads as follows: exec $JAVA_ICS -verbose:gc -classpath "${CWCLASSES}"... Verify that verbose:gc messages are being logged to the ics_manager.log file. Windows Modify the start_server.bat file so that the Java executable command line reads as follows: NaV -verbose:gc -Djava.....%2 %3 %4 %5 2>verbosegc.log Garbage collector output in the previous example is redirected to the verbosegc.log file written to in NaV\jre\ directory. Collecting heapdumps and javacore files Heapdumps contain a list of objects in the Java heap. They are usually created when an out of memory situation occurs in WebSphere InterChange Server. A heapdump can also be forced when a user sends a particular signal to the Java process. The heapdump file can be very large, so ensure that adequate disk space is available. To enable heapdumps, refer to the instructions that follow for your platform. AIX Enable heapdumps by adding the following environment variables. export IBM_HEAP_DUMP=true export IBM_HEAPDUMP=true export IBM_HEAPDUMP_OUTOFMEMORY=true export IBM_JAVADUMP_OUTOFMEMORY=true export IBM_JAVA_HEAPDUMP_TEXT=true optional: export IBM_HEAPDUMPDIR=alternate_directory/ export IBM_JAVADUMPDIR=alternate_directory You can add the variables to the ics_manager script or to the profile. Restart InterChange Server to activate heapdumps. Check that heapdumps has been activated by sending a kill -3 while InterChange Server is running. The WebSphere InterChange Server process will be momentarily interrupted to write the heapdump, but will not be killed. A message will be logged to the ics_manager.log file indicating the exact location of the heapdump file. Windows Enable heapdumps by adding the following environment variables. set IBM_HEAP_DUMP=true set IBM_HEAPDUMP=true set IBM_HEAPDUMP_OUTOFMEMORY=true set IBM_JAVADUMP_OUTOFMEMORY=true set IBM_JAVA_HEAPDUMP_TEXT=true optional: set IBM_HEAPDUMPDIR=alternate_directory set IBM_JAVADUMPDIR=alternate_directory You can add the variables to the start_server.bat script or to the Windows environment. Restart InterChange Server to activate heapdumps. Check that heapdumps have been activated by sending a Ctrl-Break signal in the InterChange Server console window. The InterChange Server process will be momentarily interrupted to write the heapdump, but will not be killed. A message will be logged indicating the exact location of the heapdump file. Sending diagnostic information to IBM Technical Support To send diagnostic information to IBM Technical Support, follow the instructions in the document Exchanging information with IBM Technical Support for problem determination. For a list of all technotes, downloads, and educational materials specific to WebSphere Interchange Server, search the WebSphere Interchange Server support site.

ICS OutofMemory exception in AIX or latter

FROM <http://www-1.ibm.com/support/docview.wss?rs=693&context=SSBTEG&dc=DA490&dc=DA4A10&dc=DB520&dc=DA4A30&dc=DB530&dc=DA480&dc=D700&dc=DA4A20&dc=DB560&dc=DA440&dc=DA460&dc=DA430&dc=DA470&dc=DB550&dc=D600&dc=DB600&dc=DA420&dc=DA500&dc=DA410&dc=DB540&dc=DA400&dc=DB700&dc=DB510&uid=swg21246680&loc=en_US&cs=utf-8&lang=en>

Problem(Abstract) WebSphere® InterChange Server 4.3.0.x runs out of memory frequently on AIX® 5.2 or 5.3.

Cause

The java.lang.OutofMemory exception in the InterchangeSystem.log or ics_manager.log can caused by several things. This technote addresses situations where the WebSphere InterChange Server JVM might require some tuning on AIX, which in turn might require to move to a higher AIX memory model. To understand more about using higher AIX memory models, please see the link in the Related URL section of this technote.

Resolving the problem

Follow these steps to tune AIX: 1. Change the value for Xmx to either 756 Mb or 1024 Mb, or higher if the application you are using requires it. To change the Xmx value, change the CW_MEMORY_MAX value in the /bin/CWSharedEnv.sh file. The excerpt of the CWSharedEnv.sh file is as shown below: # For ICS server the "maximum Java heap size" is defined by this variable CW_MEMORY_MAX=756 2. In the ics_manager script, located in the /bin/ directory, comment out the following section: os_seg_size=256 num_segs=`expr 9 - $CW_MEMORY_MAX / $os_seg_size` ldr_var=0x"$num_segs"0000000 export LDR_CNTRL=MAXDATA=$ldr_var Add the following section: export IBM_JAVA_MMAP_JAVA_HEAP=true export LDR_CNTRL=MAXDATA=0xA0000000@DSA The script file should look like this after you have made the changes: -------------------- ### OS is being setup in CWSharedEnv.sh ### On AIX we have to setup this variable for the JVM to use if [ "${OS}" = "AIX" ] then # os_seg_size=256 #num_segs=`expr 9 - $CW_MEMORY_MAX / $os_seg_size` #ldr_var=0x"$num_segs"0000000 #export LDR_CNTRL=MAXDATA=$ldr_var export IBM_JAVA_MMAP_JAVA_HEAP=true export LDR_CNTRL=MAXDATA=0xA0000000@DSA fi exec $JAVA_ICS -classpath "${CWCLASSES}" ServerWrapper -s${SERVERNAME} ${var_options} -design ) >${var_outputlog} 2>&1 & PROCESSID=$! echo "Logging output to ${var_outputlog}" -------------------------------------------------------------------------------------------------------------- Things to be aware of when using this memory model on AIX: 1. Ensure that your system is not paging after you make the preceding changes. Your applications can run more slowly if the system starts paging. 2. Use large heap values (Xmx) around 2 GB with caution and only if necessary. For higher values of Xmx ( over 1.75 GB), 0xB0000000@DSA is recommended to provide the highest possible native heap space (the number 1.75 GB is just an approximation, because there can be several threads used in the process). Ensure that your system is not paging after you make the change. 3. The OutofMemory exception can be caused due to fragmentation as well. If that is the case, increasing the Xmx value might not help. You will need to take other steps to address that issue. Refer to the following link for a description of the steps you can take: http://www-128.ibm.com/developerworks/java/jdk/diagnosis/142.html 4. As the Xmx is increased to higher values, the garbage collection cycles can take longer.

Related information

Getting more memory for java applications on AIX

oracle的ora-12514錯誤

轉載自：連接Oracle 10g時ORA-12514: TNS: 監聽進程不能解析在連接描述符中給出的 SERVICE_NAME 錯誤的解決

最近在Oracle網站上下載一個Oracle 10g安裝了一下，只有一張盤，而且安裝時還有一個便捷的選項，非常方便。
可以安裝完畢後，使用的時候卻遇到了麻煩：如果只是本機的訪問 sqlplus system/manager這樣是沒有問題的。
但是如果使用 sqlplus system/manager@orcl的時候卻會報ora-12514的錯誤。

解決方法：
1. 打開/network/admin/listener.ora文件，找到：

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = D:\oracle\product\10.2.0\db_1)
(PROGRAM = extproc)
)
)
2. 添加：
(SID_DESC =
(GLOBAL_DBNAME = ORACLE)
(ORACLE_HOME = D:\oracle\product\10.2.0\db_1)
(SID_NAME = ORACLE)
)
3. 最後變成：
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = D:\oracle\product\10.2.0\db_1)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = ORACLE)
(ORACLE_HOME = D:\oracle\product\10.2.0\db_1)
(SID_NAME = orcl)
)
)
4. 保存文件，重啟服務中的TNSListener，OK！

PS: Oracle10g有一個好處：不再與Tomcat的端口衝突了。原來的Oracle9i安裝完成後，8080端口就會被佔用，一般都需要改tomcat的端口。現在終於輕鬆了。