Zero Bytes

First of all the following value has to be unique to each install of Sterling Integrator. If you accidentally used shared location for cluster installation your second node installation not going to work. So here is how we can fix this. 1. Go to user home and move $USERHOME$/IBM/IBMSHARED to new local location. 2. Update the reference in  /home/user/var/ibm/InstallationManager/installRegistry.xml           That's it. This will fix First node IBMSHARED location and we can proceed with second node installation. How to verify? 1. Go to InstallManager tools     cd /InstallationManager/IM_Linux/tools  2. ./imcl listInstalledPackages -verbose Validate the output something like below, [Shared] Shared resources directory: /opt/ibm/IBMIMShared [Package group] Name: Sterling Integrator Installation directory: /opt/ibm/sfg Translations: Architecture: 64-bit [Package] Name: IBM Sterling B2B Integrator (com.ibm.sterling.in...

If we want to install external JARs (3rdParty JARs) on Sterling Integrator here are the steps, 1. Stop B2BI Cluster (All Nodes) by running hardStop.sh/cmd. 2. install3rdParty.sh -j          -j = JAR          -l = Library File 3. Run setupfile.sh 4. Repeat Step 2 and 3 on all Nodes. 5. Restart B2BI Cluster. Validation Procedure: If installation was successful then you will see an entry for your new JAR file in dynamicclasspath.cfg file.  

Here is how IBM Sterling B2B Integrator map editor translator controller parse and executes the Rules. Pre-Session (Variable Declarations & Hard Coded Values) Root On Begin    Root Exedend Rules Record On Begin Standard Rule & Exedend Rule Record On End Root On Begin Post-Session (Executes before end of map)

Unveiling the java.lang.Out OfMemoryError — When we encounter a java.lang.OutOfMemoryError, we often find that Java heap dumps, along with other artifacts, are generated by the Java Virtual Machine. If you feel like jumping right into a Java heap dump when you get a java.lang.OutOfMemoryError, don’t worry, it’s a normal thought. You may be able to discover something serendipitously, but it’s not always the best idea to analyze Java heap dumps, depending on the situation you are facing. We first need to investigate the root cause of the java.lang.OutOfMemoryError. http://java.sys-con.com/node/1229281