e*Gate 4.5.x Edit
Control Broker Issues Edit
- Problem:The Control Broker won't start and you get errors like the one below in the control broker log file.
cbMySchema (Error): unable to create temporary monk file: /usr/egate/client/tmp/A588727A-4BB3-11DA-9B80-D4F6A70C8982.monk - retrying
- Cause: The Control Broker cannot find it's
$HOMEdirectory and therefore it's
.egate.storefile. Most likely you have overridden the
$HOMEenvironment variable on this machine.
- Solution: Find and fix the
$HOMEenvironment variable so that it points to where your .egate.store file is located.
- Problem: When you are trying to get a Schema up and running but the Participating Host is labeled (inactive) for some reason. This prevents you from starting the Schema or managing it effectively.
- Cause: Sometimes importing a new Schema fails to set the PH as active.
- Solution: There are two solutions.
- First, the official SeeBeyond solution is to use stcinstd command to cause the PH to be activated. The downside to this is that it takes the machines name (i.e. unixmachine) instead of the name that you want to use for this PH (i.e. parthost01).
- The second way to make this change is to export the
.expfile and modify the
!REGISTRY_HOSTsection. Select the proper PH, change the second field to TRUE, and reimport the .exp file.
To export the Schema, use the following command:
stcregutil -rh <reg host> -rs <schema name> -un Administrator -up <admin password> -ef <schema name>
To import the .exp file, use the following command:
stcregutil -rh <reg host> -rs <schema name> -un Administrator -up <admin password> -i <schema name>.exp
- Problem: Trying to start a component, you get the message below in the control broker log file and nothing in the component log file:
Unable to find a file matching the Target Location configuration settings. ewSDEBOHSchedulerEvents (Error (0x20000020  item not found)): HostFindFailed ewSDEBOHSchedulerEvents (Fatal): Unable to load module host configuration
- Cause: According to SeeBeyond this is caused by Schema corruption and/or forcefully stopping a component.
- Solution: The
Process Host LNentry for this component is missing in the export (.exp) file. To correct this issue you must export the component, open it's
.expfile, insert the hostname (i.e. parthost01) into the 3rd stansa, and then import it back into the original Schema.
ewSDEBOHSchedulerEvents,MODTYPE_EWAY,,cbSDE,20,SYSCONTROL_BAD,-:,bin,stcewscheduler.exe, FILETYPE_EXE,0,,-rh %_HOST% -rs %_SCHEMA% -ln %_LOGICALNAME% -un %_USERNAME% -up %_PASSWORD% -rp %_REGPORT%,configs\stcewscheduler,ewSDEBOHSchedulerEvents.cfg,FILETYPE_ASCIITEXT,0, TRUE,TRUE,10,TIMEUNIT_MINUTES,10,ewSDEBOHSchedulerEvents,,,Administrator,TIMEUNIT_NONE,0,0,0,0,0
ewSDEBOHSchedulerEvents,MODTYPE_EWAY,hctunx53,cbSDE,20,SYSCONTROL_BAD,-:,bin,stcewscheduler.exe, FILETYPE_EXE,0,,-rh %_HOST% -rs %_SCHEMA% -ln %_LOGICALNAME% -un %_USERNAME% -up %_PASSWORD% -rp %_REGPORT%,configs\stcewscheduler,ewSDEBOHSchedulerEvents.cfg,FILETYPE_ASCIITEXT,0, TRUE,TRUE,10,TIMEUNIT_MINUTES,10,ewSDEBOHSchedulerEvents,,,Administrator,TIMEUNIT_NONE,0,0,0,0,0
Database Issues Edit
- Problem: The DB2 JDBC driver spits out this message when trying to connect to a database:
14:50:14.106 COL I 1800 (java_extensions.cxx:1442): 14:50:14.108 COL I 1800 (java_extensions.cxx:1442): StackTrace: java.sql.SQLException: No suitable driver at java.sql.DriverManager.getConnection(DriverManager.java:563) at java.sql.DriverManager.getConnection(DriverManager.java:194) at com.stc.eways.jdbcx.Session.connect(Session.java:323) at com.stc.eways.jdbcx.Session._open(Session.java:415) at com.stc.eways.jdbcx.DbConnector.open(DbConnector.java:120) at com.stc.common.collabService.JConnectionManagerImpl.openConnectorConnection (JConnectionManagerImpl.java(Compiled Code)) at com.stc.common.collabService.JConnectionManagerImpl.manageAutomatic (JConnectionManagerImpl.java(Compiled Code)) at com.stc.common.collabService.JConnectionManagerImpl.registerConnector (JConnectionManagerImpl.java:269) at com.stc.eways.jdbcx.SqlObjectGroupExt.initialize(SqlObjectGroupExt.java:87) at com.stc.jcsre.JCollaboration.newInstance(JCollaboration.java:79) at crMySchemaProcessEventsBase.createInstances(crMySchemaProcessEvents.java:139) at com.stc.jcsre.JCollaboration.initialize(JCollaboration.java:46) at com.stc.common.collabService.JCCollabControllerImpl.initializeJCollaboratorExt (JCCollabControllerImpl.java:1232) at com.stc.common.collabService.JCCollabControllerImpl.firstTimeInTranslate (JCCollabControllerImpl.java:1217) at com.stc.common.collabService.JCCollabControllerImpl.translate (JCCollabControllerImpl.java:433)
- Cause: Your DB2 JDBC environment variables are not set up properly.
- Solution: The three magic environment variables that must be set are
- Add the path to your DB2 binary files (i.e.
/usr/lpp/db2_07_01/bin) to the end of the
- Add the path to your DB2 library files (i.e.
/usr/lpp/db2_07_01/lib) to the beginning of the
- Set DB2INSTANCE variable to the proper instance name (i.e.
db2as). You may have to contact your DB2 admin if you don't know this information.
- Add the path to your DB2 binary files (i.e.
- Problem: While installing an ESR you get the following message when trying to register a dll with the regsvr32 program.
Load Library SBYNxxx.dll failed. Specified procedure could not be found.
- Cause: Usually this occurs because a DLL didn't get properly updated in some previous ESR, or some program is using this particular DLL and it can't be replaced until that program is shut down.
- Solution: Shut down the offending program or service (most likely the JINTEGRA service) and try to install the ESR again.
e*Gate 5.x Edit
JMS Issues Edit
- Problem: Trying to insert too large of a message into a JMS queue/topic gives you the following error:
PrepareForWrite() failed : Total bytes to write(=17321384) cannot fit in ../jmsDevelopment/stcms4f398f.dbs(size=8388608), Check STCMS.DB.SegmentSize parameter. CommitAction::Execute() - commit failed txnid=506915753
- Cause: JMS managers are configured by default with 16MB segments and a single message cannot occupy more than 1 segment at a time. Trying to stuff a message that is larger that 16MB into a single segment will cause the segment to fill up and the operation to error out.
- Solution: Increase the SegmentSize (using the properties of the JMS manager in the Environment tab) to something larger than what you'll need to account for multiple messages & overhead. On Windows, the segment size is base on 512 byte pages and on Unix the pages are 1024 bytes. So, for a 15MB message with only 1 receiver you'll need a SegmentSize of approximately 40,960 bytes (on Windows).
NOTE: You have to stop the JMS server and remove the .dbs files before this change will take effect!