Tuesday, September 25, 2012

SBL-GEN-00231 Process exited with error



Applies to:


Siebel CRM - Version: 8.1.1 [21112] and later   [Release: V8 and later ]

z*OBSOLETE: IBM AIX5L Based Systems (32-bit)

***Checked for relevance on 28-FEB-2011***





Symptoms


Started JMS Receiver Component remains with the "running" state, but does not connect to JMS Server and does not start to pick up messages from the Queue.



1. Detailed  task log indicates no errors, but also does not show JMS works.



2.
Siebel Server log file gets the "BL-GEN-00231 Process 2453540 exited
with error" message for the JMS Receiver Component. The component self
remains available.


Changes


Following setting were applied in Siebel Enterprise following information, given in the Siebel Bookshelf document: Transports
and Interfaces: Siebel Enterprise Application Integration (EAI Volume
2): Java Business Service > Prerequisites for Implementing a Java
Business Service
.

1. The DLL parameter of the “JAVA” named subsystem (used by the JMS Receiver

Component)
has been set to load the “libjvm.a” static library from the “classic”
Java Virtual Machine of the IBM JDK Java 1.5 (jdk150_20070725):





2. The LIBPATH environment variable in the Siebel Server startup script was set to include following JDK folders:

/…/java/jdk/aix/ jdk150_20070725/jre/bin:

/…/java/jdk/aix/ jdk150_20070725/jre/bin/classic:

/…/java/jdk/aix/ jdk150_20070725/jre/lib

/…/java/jdk/aix/ jdk150_20070725/lib


/…/java/jdk/aix/ jdk150_20070725/jre/bin/classic/libjvm.a



3. The /…/java/jdk/aix/ jdk150_20070725/jre/bin/classic/libjvm.so file did not exist


Cause


Use of static JVM dll library: classic/../libjvm.a, while the dynamic one was required j9vm/.../libjvm.so



"Truss"
traces, indicated that a dynamic JVM library: "libjvm.so" was not found
in the "classic" JVM folder. It was present in the  "j9vm" JVM
directory.



Solution


Following settings change was performed in Siebel Enterprise following information, given in the Siebel Bookshelf document: Siebel
Application Deployment Manager Guide: Configuring and Administering the
ADM Framework > Process of Configuring the ADM
Framework after Installing Siebel Management Server and Siebel Management Agent > Configuring the Siebel Server for ADM
.



1. The DLL parameter of the “JAVA” named subsystem (used by the JMS Receiver

Component)
has been changed to load the “libjvm.so” dynamic library from of “j9vm”
Java Virtual Machine of the IBM JDK Java 1.5 (jdk150_20070725):


/…/java/jdk/aix/ jdk150_20070725/jre/bin/j9vm/libjvm.so





2. The LIBPATH environment variable in the Siebel Server startup script was amended to include only followig JDK folders:

/…/java/jdk/aix/ jdk150_20070725/jre/bin:

/…/java/jdk/aix/ jdk150_20070725/jre/bin/j9vm:

/…/java/jdk/aix/ jdk150_20070725/lib

The Change Request BUG 10559560 has been logged to ask for accordant documentation update in the EAI Book.

It has been fixed in Bookshelf 8.1


References


BUG:10559560 - [CR#12-1RRC6R1][FR#12-1RRC6RN] JMS RECEIVER DOES NOT READ FROM JMS QUEUE












Applies to:


Siebel Financial Services CRM - Version: 8.1 SIA [21039] to 8.1 SIA [21039] - Release: V8 to V8

IBM AIX on POWER Systems (32-bit)


Description


An error occurs while running of 'EAI JMS Transport' or 'Java Business Service' on Siebel version 8.1.1.x on AIX platform.


Likelihood of Occurrence


This affects EAI JMS Transport and Java Business Service running on AIX platform, when using :-

Sun JDK (instead of
IBM Java SDK), or
IBM Java SDK
but incorrect Java library being referenced in the Java (JVMSubsys) profile, or

LIBPATH and LD_LIBRARY_PATH does not reference the expected shared libraries.


Possible Symptoms


The following error will be encountered.



Error:






JVM Exception:java.lang.UnsatisfiedLinkError: net (No such file or directory)
JVM Exception:java.lang.NoClassDefFoundError: java.net.InetAddress (initialization failure)


Workaround or Resolution


1. Update the DLL parameter of the 'JVMSubsys' profile to reference the '/usr/java6/jre/lib/ppc/j9vm/libjvm.so' as per documentation on IBM JRE 1.6 on the IBM website for JNI calls from C/C++ code :-



http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/topic/com.ibm.java.doc.user.aix32.60/user/migrating_60.html



2. Update the environment variables LIBPATH and LD_LIBRARY_PATH  to include the directories containing the :



  • JMS provider specific jar files and

  • jre/lib/ppc and /jre/lib/ppc/j9vm (from IBM Java SDK install directory).


For example :

/u01/siebel/weblogic:/usr/java6/jre/lib/ppc:/usr/java6/jre/lib/ppc/j9vm



where : /u01/siebel/weblogic - is the directory containing JMS Provider specific (e.g Weblogic) jar files




NOTE :- When you build a C or
C++ program that uses the invocation API, your LIBPATH must include the
directories containing the JVM's shared libraries,
/usr/java6/jre/lib/ppc/ and /usr/java6/jre/lib/ppc/j9vm, as well as the
directories that contain the application's shared libraries.



Documentation Enhancement Request <Bug:13646352>
has been filed, to request correction of the LIBPATH expression example
for AIX, to have its JRE-related essential part look as:



...:/usr/java6/jre/lib/ppc:/usr/java6/jre/lib/ppc/j9vm:....



References


NOTE:1285062.1 - JRE version 1.6 required for all Siebel versions from Fix Pack 8.1.1.4 onward

SBL-EAI-05000

SBL-EAI-05102

NOTE:762463.1 - JMS receiver on AIX SBL-GEN-00231 Process exited with error

BUG:10559560 - [CR#12-1RRC6R1][FR#12-1RRC6RN] JMS RECEIVER DOES NOT READ FROM JMS QUEUE

BUG:13646352 - JBS: CORRECT LIBPATH VALUE FOR AIX

SBL-GEN-00230 Process exited with error





Applies to:


Siebel Reports - Version: 8.1.1.1 [21211] and later   [Release: V8 and later ]
Information in this document applies to any platform.



Symptoms


When attempting to upload a report after initial installation the following error may appear in a dialog box :


Process XMLPReportServer on Siebel Server siebsrvr1 terminated


Log file Entries:


<enterprise_name>.<server_name>.log:

ServerLog ProcessExit 1 0000a8d64beb0070:0 2010-05-13 08:54:55
XMLPReportServer 696474 SBL-GEN-00230 Process 696474 exited with
error -



XMLPReportServer_xxx.log:

XMLPReportLog XMLPReportInfo 3 000080c04bca7024:0 2010-05-13 08:54:54 BIP's using Security Model

XMLPReportLog XMLPReportDetail 4 000080c04bca7024:0 2010-05-13 08:54:54 ReportName : Account List

XMLPReportLog XMLPReportDetail 4 000080c04bca7024:0 2010-05-13 08:54:54 TemplateFileName : aclist.rtf

XMLPReportLog XMLPReportDetail 4 000080c04bca7024:0 2010-05-13 08:54:54
TemplateFilePath : /appl/siebel/siebsrvr/xmlp/templates/aclist.rtf

XMLPReportLog XMLPReportDetail 4 000080c04bca7024:0 2010-05-13 08:54:54
Xliff File : /appl/siebel/siebsrvr/xmlp/xliff/enu/aclist.xlf

XMLPReportLog XMLPReportDebug 5 000080c04bca7024:0 2010-05-13 08:54:54 Getting XMLP Java Business Service

XMLPReportLog XMLPReportDebug 5 000080c04bca7024:0 2010-05-13 08:54:54
Invoke UploadReport method of XMLPJavaBusvc java wrapper class



Whilst
the XMLPReportServer process was reporting as having crashed there was
no evidence of an FDR or crash file on the Siebel Server.





Cause


The behavior is caused by running with an incorrect version of Java
Installed. In addition the JAVA_HOME and LIBPATH settings were
incorrectly specified.


Solution


In order to resolve this behavior, it is necessary to install 32-bit
Java and setting the JAVA_HOME and LIBPATH correctly to Java5 32-bit.

For more information on the setting of the environment variables, refer to the following link :

http://download.oracle.com/docs/cd/E14004_01/books/EAI3/EAI3_EAIJBS3.html

This
link can also be viewed from Bookshelf V8.1 Transports and Interfaces:
Siebel Enterprise Application Integration > Java Business Service
> Prerequisites for Implementing a Java Business Service.






SBL-GEN-00255 Process exited with error - Internal: Error during exec



Applies to:


Siebel System Software - Version: 7.5.2.100 [15252] to 8.1.1.1 SIA [21211] - Release: V7 to V8
Generic UNIX
Generic Linux

Product Release: V7 (Enterprise)

Version: 7.5.2.100 [15252]

Database: IBM DB2 8.1 FixPack 6b

Application Server OS: IBM AIX 5L 5.1

Database Server OS: IBM AIX 5L 5.1



This document was previously published as Siebel SR 38-3078571521.



Symptoms


SBL-GEN-00255, SBL-OSD-00220, SBL-OSD-02006, SBL-OSD-02011, SBL-OSD-00204, SBL-ADM-02049, SBL-GEN-00001, OSDmprotect

The Siebel Server was running fine until a few weeks ago. Now
we are unable to start the Siebel Server. The Siebel Gateway Name Server
is running fine.


When we start the Siebel Server by using start_server all command,
the main thread starts (siebsrvr) but when it spawns the child threads
(siebmtsh), they are not staying alive.


No Siebel multithreaded server processes are started after running
start_server all and no Application Object Manager log files are being
generated.


The SiebSrvr.log under siebsrvr/log directory may contain the following error:

    SBL-OSD-00220: Internal: pthread_mutex_trylock () failed with error. (22)


In some situations the following error may also be seen:


   OSDmprotect: mprotect(0xf7400000, 0, 0x00000001) failed with error 22



In addition to SBL-OSD-00220 error messages in SiebSrvr.log log
file, error messages like the following are being logged in the
Enterprise Server log file
(<enterprise_name>.<server_name>.log) under
$SIEBEL_ROOT/enterprises/<enterprise_name>/<server_name>/log
directory:

<NoCompName> 64527 SBL-GEN-00002 Process exited with error - Error code SBL-GEN-00002




Changes


 


Cause


A) This situation has been reported when the Unix machine has been
shutdown without having run the stop_server script. The stop_server
script should remove the
osdf.<enterprise_name>.<server_name> file that resides in
the $SIEBEL_ROOT/siebsrvr/sys directory.

B) This situation has
also been reported when the
svc.siebsrvr.<enterprise_name>:<server_name> was duplicated
under $SIEBEL_ROOT/siebsrvr/sys directory.

When you specify the
ALL argument, the start_server script searches for all files under
$SIEBEL_ROOT/siebsrvr/sys in the format svc.siebsrvr.* and parses it to
identify the Enterprise name and the Server name.
The first string after svc.siebsrvr. is the Enterprise name and the second one is the Server name.
The start_server script skips all filenames ended with the .bak extension, because they are considered backup files.
Then it starts the service and creates the OSDF file based on these parsed names.

Customer has three svc* files on his system:

- $SIEBEL_ROOT/siebsrvr/sys/svc.siebsrvr.<enterprise_name>:<server_name>
- $SIEBEL_ROOT/siebsrvr/sys/svc.siebsrvr.<enterprise_name>:<server_name>.bak
- $SIEBEL_ROOT/siebsrvr/sys/svc.siebsrvr.<enterprise_name>:<server_name>.OLD1

The second file is considered as a backup file by start_server script.
However,
the other two files are used by start_server to start up the Siebel
Server, and both point to the same Enterprise and Server names.
Therefore, the start_server script is starting the same Siebel Server twice.

The
problem is that, when the second instance is started, the OSDF file is
overwritten, and the information used by Siebel about the memory
structures used by the first instance is lost. The second instance will
conflict with the first one, and the processes end up failing.


Solution


In order to fix this behavior and guarantee you have a clean environment, please do the following:

1. Shutdown the Siebel Server and run the following commands to clean all structures that may remain:

    % stop_server ALL
    % reset_server -e <enterprise_name> <server_name>
    % siebclean -f $SIEBEL_ROOT/siebsrvr/admin/<enterprise_name>.<server_name>.shm -q
    % cleansync -f $SIEBEL_ROOT/siebsrvr/sys/osdf.<enterprise_name>.<server_name> -d
    % siebctl -r $SIEBEL_ROOT -S siebsrvr -i <enterprise_name>:<server_name> -k -q
    % mwcleanup -silent 2>/dev/null

2. If using AIX, log into UNIX as root and run the following command:

    % /usr/sbin/slibclean

3.
Ensure no Siebel processes are running and check that there are no
semaphores or shared memory segments allocated for the UNIX user who
owns the Siebel Server installation:

    % ps -ef | grep <username>
    % ipcs -b

4.
If there are any processes, shared memory segments or semaphores stuck
in memory, they can be killed by using the following commands,
respectively:

    % kill -9 <process_ID>
    % ipcrm -m <shared_memory_segment_ID>
    % ipcrm -s <semaphore_ID>

5. Remove the following files if they still exist:

    $SIEBEL_ROOT/siebsrvr/sys/osdf.<enterprise_name>.<server_name>
    $SIEBEL_ROOT/siebsrvr/admin/<enterprise_name>.<server_name>.shm

6. Remove all svc* files or move all of them out from $SIEBEL_ROOT/siebsrvr/sys directory.

7. Recreate the correct svc* file:

 


For Siebel 8.0.x and earlier please use the comand: 



%
siebctl -S siebsrvr -i "<enterprise_name>:<server_name>" -a
-g "-g <gateway_name> -e <enterprise_name> -s
<server_name>"



For Siebel 8.1.x and later please use the comand: 



%
siebctl -S siebsrvr -i "<enterprise_name>:<server_name>" -a
-g "-g <gateway_name> -e <enterprise_name> -s
<server_name> -u <sadmin_user>" -e <sadmin_password>


please note that the siebel server service needs user and password for gateway authentication starting with Siebel version 8.1



8. Restart the Siebel Server:

    % start_server all

Customers
should note that if there are still any processes, semaphores or shared
memory segments stuck in memory, the machine will need to be rebooted
before recreating the svc* file (between steps 6 and 7).


Customers should also note that recreating the svc* file (steps 6
and 7) is not necessary in all situations, and in most cases step 1 only
is sufficient to guarantee a clean startup.

KEYWORDS:
start_server all, failure to start Siebel on Unix server,  OSDmprotect,
err=1300220 sys=22 sys=0 SBL-GEN-00001 SBL-GEN-00002 SBL-GEN-00003
SBL-GEN-00004 SBL-GEN-00005 SBL-GEN-00006 SBL-GEN-00007
pthread_mutex_trylock AIX slibclean ipcrm








Applies to:


Siebel System Software - Version: 7.5.3 SIA [16157] and later   [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3 [16157] Cons Sec

Database: IBM DB2/UDB 7.2

Application Server OS: IBM AIX 5L 5.1

Database Server OS: IBM AIX 5L 5.1



This document was previously published as Siebel SR 38-1095528661.



Symptoms


SBL-GEN-00255, SBL-OSD-02006The object manager and several important server components are unavailable or partially online -
this is holding up Production load!!!

The following is appearing in the Enterprise server
log:
ServerLog    ProcessExit    1    2003-11-03
22:41:58    <NoCompName>    17427     SBL-GEN-00255   Process
exited with error - Internal: Error during exec()






Cause


Enhancement request 12-IYEB5W


Solution



Message 1


For the benefit of others:



The following components are showing as UNAVAILABLE via srvrmgr and SIGBART in the enterprise log.



Business Integration Batch Manager

Business Integration Manager

Workflow Process Batch Manager

Workflow Process Manager

eConsumerSectorObjMgr_enu



Multiple occurrences of the following error was seen in the enterprise server log:



ServerLog    ProcessExit    1    2003-11-03
22:41:58    <NoCompName>    17427     SBL-GEN-00255   Process
exited with error - Internal: Error during exec()



As part of the troubleshooting:

Reset some parameter values for one of the components which is
unavailable, stop and restart the Siebel server via the UNIX command
line and see what error messages may be displayed after the start up.



Tried the following for eConsumerObjMgr_enu on server, siebdvsrvr



1. Use srvrmgr to set the following:

change param foreground=true for comp eConsumerObjMgr_enu server siebdvsrvr

change evtloglvl %=5 for comp eConsumerObjMgr_enu server siebdvsrvr

change param errorflags=-1 for server siebdvsrvr

change param traceflags=-1 for server siebdvsrvr



2. Stop the Siebel server.



3. As root login, run the AIX command slibclean



4. Start the Siebel server using the following command (do not use the
start_server script and ensure siebenv.sh has already been invoked):

siebsrvr /g <gateway_host> /e <enterprise> /s <server>



eg. siebsrvr /g gateway_host_name /e siebdvent /s siebdvsrvr



(cont)


Message 2


(cont)

5. Do you see any error messages on the screen following the siebsrvr startup?



You can control C out of that screen and then revert back to restarting the Siebel server via start_server script.

To revert back with the parameters you can reset:

change param foreground=FALSE for comp eConsumerObjMgr_enu server siebdvsrvr

change evtloglvl %=1 for comp eConsumerObjMgr_enu server siebdvsrvr



From Step 5 when running the siebsrvr command, the following message displayed:



Fatal Error: The file /siebapp/sieb75/siebsrvr/mw/system/registry.bin is not a valid registry file

Fatal Error: Could not load the HKLM hive (/siebapp/sieb75/siebsrvr/mw/system/registry.bin).



Resolution:



Checked the date and file size of $SIEBEL_ROOT/mw/system/registry.bin.*

registry.bin is 245760 dated 9/29

registry.bin.old is 819200 dated 9/25



The backup copy of registry.bin.old is the correct size. Shutdown the
Gateway and Siebel Servers and copied in this backup copy to be the
current registry.bin via:

mv $SIEBEL_ROOT/mw/system/registry.bin $SIEBEL_ROOT/mw/system/registry.bin.current



mv $SIEBEL_ROOT/mw/system/registry.bin.old $SIEBEL_ROOT/mw/system/registry.bin



Restarted the servers and all components are now coming online available.



Enhancement request 12-IYEB5W was logged to provide a more descriptive error message to identify a corrupt registry.bin










Applies to:


Siebel eCommunications Call Center - Version: 8.0 [20405] and later   [Release: V8 and later ]
Information in this document applies to any platform.



Symptoms


Customer tried to install and configure the swse with Oracle Application Server but always failed with below error:



GenericLog GenericError 1 0000000249a74757:0 2009-02-27 16:13:33 Executing step: ApplyValuescfg
GenericLog GenericError 1 0000000249a74757:0 2009-02-27 16:13:33 Executing step: RestartWebServer
GenericLog GenericError 1 0000000249a74757:0 2009-02-27 16:13:33 Executing step: ShutdownApacheServer
GenericLog
GenericError 1 0000000249a74757:0 2009-02-27 16:13:35 (ossystem.cpp
(96) err=255 sys=0) SBL-GEN-00255: Internal: Error during exec()
GenericLog
GenericError 1 0000000249a74757:0 2009-02-27 16:13:35 Step
ShutdownApacheServer: failed to run program
%%WebServerInstance%%%%OSDirSeparator%%bin%%OSDirSeparator%%apachectl
with cmdline stop
GenericLog GenericError 1 0000000249a74757:0 2009-02-27 16:13:35 Failed during Execution, err: 255




Cause



There are 2 possible causes:


- Initially they installed the complete Oracle Application Server, not the one from companion CD.


- They then reinstalled using Oracle HTTP Server 10.1.3/Apache
v2.x, from the Oracle Application Server 10.1.3 companion CD, but the
"Web Server Instance Location" was not entered correctly.

The "Web Server Instance Location" should be the directory where the Oracle Application Server is installed.

The customer supplied it with:
Web Server Instance Location : /data1/siebel_sweapp/https-one5all

while
the Oracle Application Server was installed in 
/data1/oracle/app10gR3/ohs (httpd.conf exists in conf directory of the
Web Server, /data1/oracle/app10gR3/ohs/conf/httpd.conf)



After correcting the above parameter, customer was able to proceed and complete the swse installation

Oracle Application Server 10.1.3 companion CD can be downloaded from:


http://www.oracle.com/technology/software/products/ias/htdocs/101310.html



Solution



It was suggested to customer to rerun the configuration with the correct location.

The ”Web Server Instance Location” should be: /data1/oracle/app10gR3/ohs.



The installation/configuration of the swse was then completed successfully.

 




Applies to:


Siebel System Software - Version: 8.0.0.8[20430] and later   [Release: V8 and later ]
Information in this document applies to any platform.



Symptoms



Customer had installed 8.0.0.9 patchset to production enviroment.
Previously customer had Siebel 8.0.0.8 version and was installed on the
IBM AIX 5.3 (64-bit). After installation of 8.0.0.9 patchset siebel
server was not coming up.



Error:

-------
Siebel server Logs:
--------------------

GenericLog GenericError 1 000069d14e0b30c0:0 2011-06-29 18:15:09
(sccnmsys.cpp (1305) err=2883609 sys=0) SBL-SCC-00025: No value found in
the Gateway. Default value in the repository is used.

GenericLog GenericError 1 000069e04e0b30c0:0 2011-06-29 18:15:09
(sccnmsys.cpp (1305) err=2883609 sys=0) SBL-SCC-00025: No value found in
the Gateway. Default value in the repository is used.


Enterprise Logs:
------------------
GenericLog
GenericError 1 000076ee4deb1046:0 2011-06-05 13:31:39 (scirkey.cpp
(1142) err=1310772 sys=0) SBL-SVR-00052: Internal: Invalid proc handle
ServerLog
ProcessExit 1 000076ee4deb1046:0 2011-06-05 13:31:39 SRBroker 594106
SBL-GEN-00255 Process 594106 exited with error - Internal: Error
during exec()



Changes


Applies patchset 8.0.0.9 on top of 8.0.0.8.


Cause


After Verification it was found installable library files from previous
installation 8.0.0.8 got corrupted and hence installation of 8.0.0.9 is
not getting through.


Further verification showed, release timestamp for some library
files from 'siebsrvr/lib' were not set to patch release date but patch
install date.

In Ideal case the timestamp should correspond to patch release date,
thing is that the release time stamp is only set at the very end. If
something breaks before then files remain on disk with install date.



In case of customers environment, some library files has timestamp of
April2011 which is patch installation date, in correct scenario it
should have been patch 8.0.0.8 release date (Oct2009).

Which shows incorrect deployment of 8.0.0.8 patchset.


Solution


Below are some prominent steps for re-installation of gateway and Siebel Servers:



Reinstalling the Gateway Server:

-----------------------------------------------------------

1) Stop the Gateway service

2) Uninstall the Gateway server.

3) Delete the Gateway server directory structure.

4) Reboot the machine.

5) Install the Gateway server.



Reinstalling the Siebel Server:

-----------------------------------------------------------

1) Make backups of all the .cfg files present in \siebsrvr\bin and the siebns.dat file present in \gtwysrvr\ADMIN.

2) Make backup of the .srf file present in \siebsrvr\OBJECTS.

3) Make backups of the following folders present in the \siebsrvr directory to take care of any customizations:

IDCENTRIC, MSGTEMPL, REPORTS, WEBTEMPL.

4) I am not sure if you have remote users in your environment, If there
are remote users working off this application server, backup the
following folders to avoid reextracting them:

DOCKING, DBTEMPL

5) Stop the Siebel server service

6) Uninstall the Siebel server

7) Delete the Siebel server directory structure.

8) Remove Siebel Server from the Gateway by removing configuration from wizard.

9) Reboot the machine.

10) Start the Gateway server service if not running already.

11) Install the Siebel server using same installation parameters as before.

12) Copy the backed up folders, .cfg files and the .srf file to the corresponding directory where it belongs.

13) Stop and restart the Gateway and Siebel server services.

14) From the Server Administration screen enable the needed component groups.



There is a note out there on MOS with the correct steps. It refers to Windows but same steps apply to AIX as well:

Reinstalling the Siebel Servers (Doc ID 476317.1)

Note: This
solution was specific to one environment/scenario, there is possibility
that same solution may not work for other environments.



References


NOTE:476145.1 - Failure When Installing Siebel Patches on the AIX Operating System

NOTE:971849.1 - Error "SBL-SVR-01031: Invalid Parameter" is generated in the SRProc log files








Applies to:


Siebel Server Extns for Solaris Operating Envrmnt - Version: 8.1.1.5 [21229] and later   [Release: V8 and later ]
Information in this document applies to any platform.



Symptoms



SWSE configuration fails with error on step SetMimeTypes




2011-08-19 14:22:34 Looking for executable
/usr3/siebiut/siebel/siebsrvr/bin//usr3/siebiut/siebel/siebsrvr/install_script/install/UpdateMimeTypes
2011-08-19
14:22:34
/usr3/siebiut/siebel/siebsrvr/bin//usr3/siebiut/siebel/siebsrvr/install_script/install/UpdateMimeTypes
not found
2011-08-19 14:22:36 (ossystem.cpp (96) err=255 sys=0) SBL-GEN-00255: Internal: Error during exec()
2011-08-19 14:22:36 OSSystem returned 255
2011-08-19
14:22:36 Step SetMimeTypes: failed to run program
%%SiebelRoot%%%%OSDirSeparator%%install_script%%OSDirSeparator%%install%%OSDirSeparator%%UpdateMimeTypes
with cmdline %%SiebelRoot%% %%WebServerInstance%%
2011-08-19 14:22:36 Failed during Execution, err: 255
2011-08-19 14:39:31 Exiting configuration.




Cause



SWSERoot was incorrectly defined prior to launching the configuration wizard

Verbose log file contains the following entries:

Value key SiebelRoot resolves to /usr3/siebiut/siebel/siebsrvr

Value key SWSERoot resolves to /usr3/siebiut/siebel/siebsrvr






Solution



Verify the directory containing your SWEApp installation and then
source the correct environment variables using cfgenv.sh from it, before
running the configuration wizard once more.




References


NOTE:955972.1 - Issues with SWSE Configuration task - Siebel Release 8.1.1 Version




SBL-GEN-00171:





Applies to:


Siebel Workflow - Version: 8.1.1 [21112] and later   [Release: V8 and later ]

Information in this document applies to any platform.


Symptoms


Validation rules that work when called from the UI are not correctly
displaying the error when called from a workflow business service step,
even though the workflow is correctly set up to execute as a runtime
event.






Instead the end user sees the error message "Field 'Error Code' is empty, and is required for Abort step SBL-GEN-00171"





Logging the process via client side logging shows an SBL-GEN-00000
error immediately follwed by errors (SBL-BPR-00162)--(SBL-GEN-65535)


Cause


There was no business object set on the Workflow



Solution


Setting a business object on the workflow resolved the issue.  

SBL-GEN-00143 Process 8408 exited with error



Applies to:


Siebel Public Sector Service - Version: 8.1.1.3[21219] and later   [Release: V8 and later ]
Information in this document applies to any platform.



Symptoms



Statement of issue:

------------------------

intermittent failures and timeouts when sending out JMS messages.



Error:

--------

JMSReceiver 8408 SBL-GEN-00143 Process 8408 exited with error



Expected behaivor:

-----------------------

the messages should be processed in a consistence way with no timeouts



Actual behaivor:

-------------------

the EAI Object Manager doesnt release the running task until 25 minutes.
This causes a stack of running tasks stating 'Waiting for command'
which seems to make the component unstable





Siebel / OS version:

--------------------------

8.1.1.3, Windows 2003


Cause



Wrong "SessionType" being used in the HTTP Header as 'Stateless'
while the external system was not using the session tokens provided in
the the Siebel HTTP Response. Changing the SessionType to 'None' ensures
the EAI Tasks are completing successfully and



The customer has used "SessionType" Stateless according to his confirmation


Solution



In this particular case where the external application did not use
the token from soap header, ensure the SOAP header of the message
contains a section with sessiontype = None like following:


Example:


 <soap:Header>

<UsernameToken xmlns="http://siebel.com/webservices">user</UsernameToken>

<PasswordText xmlns="http://siebel.com/webservices">hello123</PasswordText>

<SessionType xmlns="http://siebel.com/webservices">None</SessionType>

</soap:Header>

SBL-GEN-00127 Process 1865 exited with error





Applies to:


Siebel CRM - Version 8.1.1.4 [21225] and later
Linux x86-64



Symptoms


 You are running a Siebel version 8.1.1.4 or above on a Linux 64-bit (x86_64) system.





During server startup you will see lots of errors like this in the enterprise log file:





ServerLog    ProcessExit    1    0000fa204f977fee:0    2012-04-24
16:13:00    WfProcMgr     1865     SBL-GEN-00127   Process 1865 exited
with error -





This occurs for almost all components and they are shown as unavailable in the srvrmgr.





Core dumps are generated with the following file information:





$ file core.4681

core.4681: ELF 64-bit LSB core file AMD x86-64, version 1 (SYSV), SVR4-style, from 'siebmtshw'





Note the ELF 64-bit signature. Since all siebel binaries are 32-bit,
it is clear that this core is caused by the operating system shell,
which runs as 64-bit on a 64-bit platform.



Cause


 This error message is caused by a core dump of the siebmtshw or
siebprocmw shell script. This script is crashing when it is sourcing the
setmwruntime sub script. The setmwruntime script sets a few environment
variables for the Mainwin subsystem.






Solution


 This crash has been observed for some version of Red Hat Linux
64-bit. At the moment it is not clear which particular Linux setup is
responsible for this crash. Customers experiencing this crash should
send the core dump of the shell script to Red Hat support.





The following workaround will enable the startup on such systems:






Edit the file $SIEBEL_ROOT/mw/setmwruntime:



Comment out the following lines:



Line 131:



#PATH=`echo :$PATH | sed "s,:${MWHOME},:@${MWHOME},g" | sed "s,:\([^@]\),:${new_path}:\1,"|sed -e 's,:@,:,g' -e 's,^:,,'`





Lines 148-150:



#if [ "${MWOS}" = "aix4" -o "${MWOS}" = "linux" ]; then

#    LIBPATH=`echo $LIBPATH |tr ":" "\012"|grep -v '^/usr/lib$'|tr "\012" ":"`

#fi




The modification done in these lines is not really necessary in Siebel context.





Then the next startup of the siebel service is successful and no more core dumps are observed.


SBL-GEN-00015 'versions of installed components do not match'



Applies to:


Siebel System Software - Version: 7.5.2.211 SIA [16061] and later   [Release: V7 and later ]

z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.5.2.211 [16061] DEU Cons Sec

Database: Oracle 8.1.7.4

Application Server OS: Microsoft Windows 2000 Server SP 3

Database Server OS: Microsoft Windows 2000 Server SP 3



This document was previously published as Siebel SR 38-946524365.





Symptoms


SBL-GEN-00015The customer has after applied the Siebel 7.5.2.211 Maintenance Release to the Siebel Tools
client ( previous version was 7.5.2.210), and the customer is not able to start Siebel Tools. The
following error message is encountered :



Error: versions of installed components do not
match

(wanted version: 7.5.2.211, actual version: 7.5.2.210 SIA)



From the Siebel.log
file in the Log directory :

2021 2003-03-04 15:50:44 2003-03-04 15:58:33 +0100 00000001 001
001f 0001 09 siebdev 504 500 C:\sea752\tools\log\siebdev(001).log 7.5.2.211 [16061]
ENUENU



GenericLog    GenericError    1    2003-03-04
15:50:44    Error: versions of installed components do not match (wanted
version: 7.5.2.211, actual version: 7.5.2.210 SIA)



After further examining the
<tools>\bin\sia directory, the customer found that the srlcver.dll file had not been
updated to the .211 Maintenance Release version ( the version of the file was still 7.5.2.210 ).





Cause


Configuration/ Setup



Solution



Message 1


For the benefit of other readers :



Investigation :

The customer was advised to run the following MS-DOS command from the
hard drive where Siebel 7.5.2.211 is installed, and send in the
all_enu.txt and all_base.txt, in order to work out what Siebel versions
had been installed.

( For example if Siebel 7.5.2.211 is installed in d:\s752, then run the MS-DOS commands from the D: drive )



d:

cd\

findstr /s /i 7 enu.txt > d:\all_enu.txt

findstr /s /i 7 base.txt > d:\all_base.txt



Reviewing the customers all_base.txt file, except for the PATCH_BACK
directories, there are 30 occurrences of 7.5.2.210 in the all_base.txt
file, for example :



sea752\tools\ACTUATE\AFC\base.txt:        7.5.2.210 SIA [16060] LANG_INDEPENDENT patch applied.

sea752\tools\ACTUATE\BIN\base.txt:        7.5.2.210 SIA [16060] LANG_INDEPENDENT patch applied.

sea752\tools\ACTUATE\CACHE\base.txt:        7.5.2.210 SIA [16060] LANG_INDEPENDENT patch applied.



Resolution :

The customer stated they had not patched Actuate, and during the
investigation of this Service Request, the customer de-installed Siebel
Tools, re-installed Siebel 7.5.2 Tools and then applied the Siebel
7.5.2.211 Maintenance Release afterwards. Siebel Tools now successfully
comes up.










Applies to:


Siebel System Software - Version: 7.5.2.214 [16066] and later   [Release: V7 and later ]

z*OBSOLETE: Microsoft Windows NT Terminal Server

Product Release: V7 (Enterprise)

Version: 7.5.2.214 [16066]

Database: Oracle 8.1.6.3

Application Server OS: Microsoft Windows NT Server 4.0 SP 6a

Database Server OS: IBM AIX 4.3.3



This document was previously published as Siebel SR 38-1015424087.





Symptoms


SBL-GEN-00015, SBL-SMI-00147I installed the patch 7.5.2.214 and can not start the App. Server anymore!

It start and stop
immediately with the following log file info.



2021 2003-05-28 09:08:17 2003-05-28 09:08:17
-0400 00000003 001 001f 0001 09 SiebSrvr 16385 370 389
e:\sea752\siebsrvr\log\Siebel.TNNWAPP06.log 7.5.2.211 [16061]
ENUENU



GenericLog    GenericError    1    2003-05-28
09:08:17    Error: versions of installed components do not match (wanted
version: 7.5.2.214, actual version: 7.5.2.211 ENU
)



GenericLog    GenericError    1    2003-05-28
09:08:17    (lstnsvc.cpp 8(113) err=2100147 sys=0) SMI-00147: (lstnsvc.cpp 8:
113) error code = 2100147, system error = 0, msg1 = Error: versions of installed components do
not match (wanted version: 7.5.2.214, actual version: 7.5.2.211 ENU ), msg2 = (null), msg3 =
(null), msg4 =
(null)



GenericLog    GenericError    1    2003-05-28
09:08:17    (siebsvc.cpp 9(317) err=2100147 sys=0) SMI-00147: (siebsvc.cpp 9:
317) error code = 2100147, system error = 0, msg1 = (null), msg2 = (null), msg3 = (null), msg4 =
(null)



I installed the Windows_Server_ses patch 214 section on the server.

Which
component do not match?





Cause


Configuration/ Setup



Solution





For the benefit of other users, the customer received the following
error in the Siebel Server log files after installing patch 214:

SMI-00147: (lstnsvc.cpp 8: 113) error code = 2100147, system error = 0,
msg1 = Error: versions of installed components do not match (wanted
version: 7.5.2.214, actual version: 7.5.2.211 ENU)



Summary:



This error can occur if the 214 patch installation did not update all
components of the Siebel installation. Results like this are a symptom
of installing the patch when the services were active or not having
proper administrator rights during the install.



To check if this is the case, submit your vpd.properties file to
Technical Support for review. If we see components listed at versions
214 and an earlier version, you will be asked to back-up your current
vpd.properties file and your Siebel Root directory before proceeding
with either of the following options:

1)    Do you have a back-up of the vpd.properties file either from the
base or the 211 install? If so, replace the current vpd.properties file
with the back-up.

2)    If no back-up exists, edit the current vpd.properties file and replace all references of 214 with 211.







If the subsequent install of patch 214 fails, you will have to uninstall
the entire Siebel product, and then install the Siebel base build and
the 214 patch.



Regards,




Applies to:


Siebel System Software - Version: 7.5.3.5 [16183] and later   [Release: V7 and later ]

IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3.5 [16183]

Database: IBM DB2 8.1 FixPack 3

Application Server OS: IBM AIX 5L 5.2

Database Server OS: IBM AIX 5L 5.2



This document was previously published as Siebel SR 38-3015316631.





Symptoms


SBL-OSD-00204Hi, Siebel Support,



    Recently we are having CLOSE_WAIT issue
frequently in our test environment. There was a new release we put on the test environment
several months ago. Now the AIX file system is at 5200-06. DB2 level is at "DB2 v8.1.1.88",
"special_15285", "U800789_15285", and FixPak "9".



    When the
CLose_wait problem happened, we saw 12-200 or more close_waits on the OM servers, most of them
are from resonate vip to web server. Once it happened, user can't log in to the server. If the
problem happens on both our OM servers, no user can log in to the servers(got login page, but
when log in, it hung for long time and finally gave server busy error). Sometimes we can't even
get login page.



    Recently, we found there are exiting processes on
the system, like following:



siebsupp 22350 23026   0 13:50:32 pts/3 0:00
grep exiting

       -
35100     -   -                     -
<exiting>

       -
39082     -   -                     -
<exiting>

       -
44410     -   -                     -
<exiting>



    Right now, those are all for our call center obj
mgr. And when the pid showing exiting status, the tasks for those PID in srvrmgr still showing
running status. Just now two these Pids just disappeared (not in exiting status any more), and I
checked those tasks that were under that pid, they all exited with following error
message:



Internal: Siebel home directory could not be determined




   This is when the pid
exiting:



app224   US_CCOM       
56272      39082   Running            Interactive
2006-04-25
13:45:15                     
Handling
Logon                                          
US_CCOM_CG                     7             CRMP4007     Normal                  



    This
is when the pid is
gone:



app224   US_CCOM       
56272              Exited
with error Interactive 2006-04-25 13:45:15 2006-04-25 13:54:35 Internal: Siebel home directory
could not be determined
US_CCOM_CG                     7             CRMP4...





Cause


Configuration/ Setup



Solution





For the benefit of others,



The customer encountered the following behavior in their preproduction environment.



The customer was encountering a CLOSE_WAIT issue frequently in their test environment.



The end result was that once this occurred users were unable to log in
to the server. If the problem happened on both their OM servers, no user
could log in to the servers. They received the login page, but when
they logged in, it hung for a long time and finally gave server busy
error. Sometimes they were not able to get the login page.



The customer was also seeing processes exit with the error "Internal: Siebel home directory could not be determined".



For the processes which were exiting with the above error the customer
was advised that this error had been seen previously and the root cause
in the past indicated a problem with the userpref filesystem or with the
preferences file itself.



The customer was also advised to double check that rpc.lockd and
rpc.statd were enabled on the siebel server and that 511 threads were
assigned to the lockd.

On searching supportweb the following posting describes a past experience with this setting too low.

Service Request 38-1409228471 entitled "Objectmanager exits with error
GEN-00014: Internal: Siebel home directory could not be determined".





The customer was also advised to try the suggestion to set the
environment variable MWLOCK_WITHOUT_TIMER=1 on both servers so that the
Siebel Server will release locks on processes as per instructions on the
following service request on supportweb.

Service Request 38-2294263997 entitled “SIGABART on production”



In this case it was suggested that the SBL-GEN-00014 error message
occurred due to a locking issue typically when accessing user preference
files from the File System.



On making the above change the customer no longer encountered the CLOSE_WAITs on their server.



However, the customer still encountered cases where the PIDs for Object
manager processes were hanging. When this occurred it hung at Handling
Logon status. And after the user put in user name and password in the
login page, it was hanging there and would never start to launch the
Siebel pop up window. If the user kept the hanging session open, it
finally returned to "The page can not be displayed" error.



This occurred for any users connecting to this same PID.



In depth analysis was performed on the customer’s environment including
performing truss traces on the PIDs in question which showed the last
file accessed being the user preference file which had extensions
similar to the following:

CRMAUTO10&Siebel Universal Agent.spf_d98capp221_42440_4899



These seemed to be of zero size in the file system.





Some analysis was completed on the file system user preference area as
the customer had some customizations around this area but these were not
found to be having an influence.



After further investigation it was found that the customer had applied a QuickFix a few months previously.

The customer found that the patch was not showing correctly in enu.txt,
base.txt and fra.txt files in /siebel/siebsrvr/admin directory on both
servers. They uninstalled and reinstalled the Quick Fix and remonitored
the environment.



After doing so no new hangs occurred and the environment behaved correctly.








Applies to:


Siebel Anywhere - Version: 7.0.4 [14068] to 7.8.2.5 [19227] - Release: V7 to V7

Information in this document applies to any platform.

Area(s):Remote/Replication/Anywhere

Release(s):V7 (Enterprise), V7 (Professional)

Database(s):All Supported Databases

App Server OS(s):All Supported Platforms

Latest release tested against:V7 (Enterprise)

Keywords:srlcvder.dll, SBL-GEN-00015, versions of installed components do not match



This document was previously published as Siebel Alert 1246.





Description



When
creating a Delta Client Executables kit, the user creates a BASE and Language Specific Kit,
specifying SIA as the Vertical Code.




The
version information for this kit is held in the srlcver.dll and this file is used to determine if
the kit needs to be downloaded.




In
Siebel Industry Applications (SIA) version 7.7.2.x when the user creates a BASE and language kit
(for example ENU), the delta kit does not contain an update to the srlcver.dll in the SIA and
<LANG>SIA (for example ENUSIA) folders.




The
upgrade kit downloads successfully, but when the application restarts you get the error message
listed under the Possible Symptoms section.




Bug 10505354 has been logged to address this product defect.




For
more information on the Delta Install Client Executables upgrade kit, refer to Siebel Bookshelf
version 7.7 > Siebel Anywhere Administration Guide > Upgrade Planning and Preliminary Tasks
> Process of
Creating a Delta Install Siebel Client Executables Upgrade Kit
.




NOTE: You should review the following Alerts for other related behaviors with
Siebel Anywhere and Siebel version 7.7.2.x:





  • Document 473956.1 which has information about how Siebel Anywhere cannot
    upgrade Siebel clients from versions 7.7.2.x to 7.7.2.4 using Delta Client Executables
    kit.






  • Document 473957.1 which has information about how the Siebel Anywhere Delta
    Client Executables Upgrade kit fails for Siebel Dedicated Web Clients and Siebel Mobile Web
    Clients because of incorrect versioning.






  • Document 473788.1 which has information about how the Delta Repository File
    upgrade kit fails for Siebel Dedicated Web Clients and Siebel Mobile Web Clients installed in a
    path which contains spaces.





Likelihood of Occurrence



This
issue is highly likely if you are using SIA version 7.7.2.x to create a Delta Client Executables
Kit.




Possible Symptoms



After
the Delta Client Executables Kit has been downloaded successfully, the application restarts and
will report the below error:




Error:
versions of installed components do not match (wanted version: %1, actual version: %2)








Workaround or Resolution



Manually
copy the srlcver.dll from the \bin folder to the \<LANG>SIA and SIA folders. For
example:




C:\Siebel\Client\BIN\ENUSIA\srlcver.dll


C:\Siebel\Client\BIN\SIA\srlcver.dll




This
now holds the new 7.7.2.x version information.




A
Siebel Customer Revisions kit can be created to automatically distribute the srlcver.dll with the
correct versions to the mobile client. For more information, refer to the Siebel Bookshelf
version 7.7 > Siebel Anywhere Administration Guide > Defining Upgrade Kits > Defining
a Siebel Customer Revisions Upgrade Kit
.