SBL-SMI-00077: Component error, see the trace file for more information

Applies to:

Siebel Remote - Version 8.0 [20405] and later
Information in this document applies to any platform.

Symptoms

Database Extract (DbXtract) tasks fail with errors. Reviewing
detailed DbXtract*.log file following errors/messages can be noticed:





GenericLog GenericError 1 000000084b553068:0 2010-01-20 10:00:34 Unable to find node in database

...

GenericLog GenericError 1 000000084b553068:0 2010-01-20 10:00:35
Message: Internal error occurred in a procedure., Additional Message:
Updated 0 rows

Trace TracingInfo 3 000000084b553068:0 2010-01-20 10:00:35 UTLNodeSetRouteActive

Trace TracingInfo 3 000000084b553068:0 2010-01-20 10:00:35 Error while processing client "SADMIN". Results may be incomplete.

...

Trace TracingInfo 3 000000084b553068:0 2010-01-20 10:00:35 Unable to find node in database

Trace TracingInfo 3 000000084b553068:0 2010-01-20 10:00:37 ERROR: 1 client(s) failed with errors, 0 client(s) successful

GenericLog GenericError 1 000000084b553068:0 2010-01-20 10:00:37
(smisched.cpp (894) err=1376333 sys=0) SBL-SMI-00077: Component error,
see the trace file for more information

Cause

SBL-SMI-00077 is just a generic message that suggests the real cause of problem should be searched elsewhere in log .



"Unable to find node in database" error can be explained by fact that 
Mobile Web Client user attempted to be extracted (SADMIN in this
example) was not defined properly.


This can be checked by inspecting Administration - Siebel Remote >
Mobile Clients screen. Or alternately, by querying table S_NODE for the
list of existing / active mobile clients:



select * from SIEBEL.S_NODE where NODE_TYPE_CD = 'REMOTE' and NAME='[user_name]' and EFF_END_DT is NULL;

Solution

In case there are no records there, as per details in Siebel Bookshelf
- Remote and Replication Manager Administration Guide > Setting Up
Mobile Web Clients > "Registering a Mobile Web Client" - these steps
should be applied before attempting to extract the Mobile user.

Applies to:

Siebel Remote - Version: 7.5.2 [15051] to 8.1.1 [21112] - Release: V7 to V8
Information in this document applies to any platform.

Symptoms

When trying to extract a mobile users' database, DbXtract task failed with error message:


"SBL-SMI-00077: Component error, see the trace file for more information"

This
is only a generic error message - as it indicates, the real cause for
the failure should be searched somewhere else in the corresponding task
log file (DbXtract_*.log) on server.


In this case, even if some time ago extracting databases for users
worked fine in same environment, now this error appears for any mobile
client attempted.

Changes

To gather more details, event log levels for DbXtract component
should increased by using srvrmgr command line utility, running these
commands (in this order, one by one):

srvrmgr> change evtloglvl %=5 for comp dbxtract
srvrmgr> change evtloglvl sql%=1 for comp dbxtract
srvrmgr> change evtloglvl sqlparse%=4 for comp dbxtract
(Please
remember to revert to previous or default logging levels - i.e. "...
evtloglvl %=1 ..." once troubleshooting DbXtract is no longer required
to avoid log files growing excessively).

Cause

>>From detailed DBXtract log the root cause for these errors was:

DBXTRACT: File "/siebel/xxxxxxxx/siebsrvr/sqltempl/dbxlogin.sql" not found.
…
>>



Script file dbxlogin.sql (along with some others from same location -
sqltempl directory) is a required file that is used as "template" for
database extracts and other server tasks.

Solution

One should check for the file/directory presence. That proved indeed file was missing in this case.


To avoid re-installation of whole server environment, if only one
file might be found missing,  this directory contents from this
environment can be compared with the same on another machine with EXACT
same Siebel product version installed (!) where DbXtract works fine and
copy that file from here.


In case such a "working" environment is not available, the only solution would be to re-install the Siebel server.

Please
note is advisable to only copy the file(s) that are proved to
be missing; do not overwrite the complete directory contents - there
might be cases of customers who have been provided in past  with
modified comdb*.sql file from Oracle | Siebel Technical Support or
Expert Services for various other purposes; if that may be the
case, these files should not be overwritten.

DbXtract task should complete fine afterwards.

References

 

 

 

Applies to:

Siebel Anywhere - Version: 7.5.3.5 [16183] and later   [Release: V7 and later ]
Siebel Remote - Version: 7.5.3.5 [16183] and later    [Release: V7 and later]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.5.3.5 [16183]

Database: Oracle 9.2.0.4

Application Server OS: Microsoft Windows 2000 Server SP 4

Database Server OS: HP-UX 11.0



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

Symptoms

We are extracting everyone. We used a notepad file to export everyone.
Now Database extract says exited with error. The reason being there were
three client names that were not valid mobile users. Did all of our 150
valid mobile user go through okay? How can I check? Please see the
urgency of this because our production system is now shut down.

Cause

Enhancement Request 12-TBTZAV

Solution

Message 1

For the benefit of others:



Valid nodes were extracted successfully. DbXtract log reported errors on
failed clients, but did not provide information on valid users. We
verified that .UAF, .DAT and .TOC files were created under the users'
outboxes and the mobile clients were initialized successfully.



Technical Support reproduces this behavior inhouse. When running
dbxtract for multiple users, if there is an invalid node name in the
list of mobile users, the task status on the UI will show
'SBL-SMI-00077: Component error, see the trace file for more
information' eventhough valid nodes were actually extracted
successfully.



Enhancement Request 12-TBTZAV was raised to have a more meaningful
message on the UI. For example, in this case it would be better if the
task status reads "147 users extracted successfully, 3 users not
extracted".



As always, please note that all Change Requests are reviewed, prioritized and possibly fixed in future releases.



Regards,

Applies to:

Siebel Remote - Version: 8.0.0.11 SIA[20440] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Product Release: V8

Database: Oracle Server

Application Server OS: All Supported

Database Server OS: All Supported

Symptoms

Siebel Remote: Database Extract (DbXtract) task fails with generic
SBL-SMI-00077 error (that indicates relevant error is somewhere else in
the log file) and the relevant error being Oracle RDBMS one:

[DataDirect][ODBC Oracle driver][Oracle]ORA-29275: partial multibyte character

Detailed logging level DbXtract_*.log files would look like:
(note that base table involved or variables' values may vary - could be other than S_CONTACT or those listed in this example)

SQLError Statement 0 000000074f561360:0 2012-03-07 10:34:15 SQL Statement:
select mtx.*
from SIEBEL.S_DOCK_INITM_01 di
,SIEBEL.S_CONTACT mtx
where di.NODE_ID = '1-7LIVG'
and di.DOCK_NAME = 'PTY-C'
and di.PR_TBL_ROW_ID = mtx.PAR_ROW_ID
and di.VIS_STRENGTH >= 25
DBCLog
DBCLogError 1 000000074f561360:0 2012-03-07 10:34:15 [DataDirect][ODBC
Oracle driver][Oracle]ORA-29275: partial multibyte character

Trace TracingInfo 3 000000074f561360:0 2012-03-07 10:34:15 DBXTRACT: Database returned error.
Trace
TracingInfo 3 000000074f561360:0 2012-03-07 10:34:15 S1000:
[DataDirect][ODBC Oracle driver][Oracle]ORA-29275: partial multibyte
character

Cause

"ORA-29275: partial multibyte character"

It seems there may be some char data in table that are not AL32UTF8 encoded - or respecting DB's characterset parameters.

Solution

Problem was identified as only occurring when using Oracle Client 11g
version; it would not occur with 10g client installed on same Siebel
Remote server.

Based on current Siebel System Requirements and Supported Platforms
(SR&SP) documentation, for Siebel 8.0 version the supported client
Connectivity Software is "Oracle 10g client and Data Direct ODBC Driver
5.0".

It it important to ensure that Oracle Client installed on
Siebel Servers comply with most recent SR&SP document for respective
Siebel product version.

In case despite running on a supported platform same error would occur, following these steps may help troubleshooting that:



1- Check and confirm the exact versions of Oracle RDBMS server and
client versions used - for instance from Siebel server, start a SQL*Plus
session from cmd prompt and connect to DB (as SADMIN, Siebel table
owner or any other valid DB account).
Upon successful connection that should show exact version details of both Oracle client and server DB.



2- Check and ensure following entries are correctly set in the ODBC DSN used for Siebel Server:
ColumnsAsChar=1
ColumnSizeAsCharacter=1

These should be defined in:

- for Windows systems: in registry under [HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\($EnterpriseName)_DSN]
- for Unix systems: in file $SIEBEL_HOME/sys/.odbc.ini - under section [($EnterpriseName)_DSN].


3- Finally, by running previously identified query from DbXtract log
may not return any results or ORA-29275 error if after hitting that,
the "Part 4: Deleting from temporary tables" of extract - cleanup still
happens, so S_DOCK_INITM_nn table would be empty.



So following approach should be used to determine if there is data in S_CONTACT table that would have wrong multibyte encoding:



3.a) Check first how many records there are in that base table:



SELECT COUNT(*) FROM S_CONTACT;



3.b) Based on actual size, one can determine how to break up the
selects. For example, if above count returns 100K, two queries could be
run: one for 1 to 50K rows and the other for the second half. Once
found the half that returns the ORA-29275 error, then start breaking
that in half and so on...



i.e.

SELECT * FROM S_CONTACT WHERE rownum > 1 AND rownum < 1000;

SELECT * FROM S_CONTACT WHERE rownum > 999 AND rownum < 2000;

...


This should help determining where the problem record(s) may be. Above
generic approach could be automated by writing a small PL/SQL program
especially for high cardinality tables.
Alternately a separate SR may be logged with Oracle RDBMS team to assist in identifying that(those) record(s) .
And
once identified those rows could be updated (from UI or using EIM,
scripting) to eliminate any suspect character(s) causing the error
followed by retrying the DbXtract task.

References

NOTE:788156.1 - AL32UTF8 / UTF8 (Unicode) Database Character Set Implications

NOTE:477174.1 - Database Extract 7.x and 8.x Performance Troubleshooting

NOTE:781927.1 - Performance Tuning Guidelines for Siebel CRM Application on Oracle Database

 

Applies to:

Siebel Remote - Version: 7.7.2.12[18393] to 8.1 [21039] - Release: V7 to V8
Information in this document applies to any platform.

Symptoms

Database Extract (DbXtract) task may fail while extracting a mobile user with following errors:

[DataDirect][ODBC Oracle driver][Oracle]ORA-00904: "PRIMARY_TABLE"."X_custom_column": invalid identifier
Error while writing to file "" for target client "USERNAME".
SBL-SMI-00077: Component error, see the trace file for more information


With detailed logging levels in place for DbXtract component (as per details in Note 477125.1):


srvrmgr> change evtloglvl %=5 for comp DbXtract
srvrmgr> change evtloglvl sql%=1 for comp DbXtract
srvrmgr> change evtloglvl sqlparse%=4 for comp DbXtract


resulted logs will include information helping determine exact
table name that caused this error ("PRIMARY_TABLE" - above is only its
alias)



Note that for other RDBMS platforms used (MS SQL
Server or IBM DB2), database error code and ODBC details would be of
course different, but the other error lines would be identical:

- for instance in case of SQL Server:

[Microsoft][ODBC SQL Server Driver][SQL Server]Invalid column name 'X_custom_column'.
Error while writing to file "" for target client "USERNAME".
SBL-SMI-00077: Component error, see the trace file for more information

Changes

Recent configuration changes in Siebel Tools on Table object(s)
identified in detailed log - custom extension tables (CX_*), custom
extention columns for standard base tables (X_*).

Cause

Relevant error in this case ("ORA-00904: [table].[column] : invalid identifier") is caused by:


1- Invalid definition(s) for these object(s) - Table custom Extension Column(s) in Siebel Repository


OR


2- Discrepancy between server's dictionary file (diccache.dat) and Repository information.

Solution

Existence of custom extension column ("X_custom_column" in this
example) should be checked for that Siebel base table. Then should
be verified same column was created at physical database level by
using DBA specific commands appropriate for each RDBMS used (i.e. for
Oracle's case: "DESC [table_name]" command from a sqlplus, SQLDeveloper
or other similar tool).

After ensuring those exists, following steps should be applied:

1- Apply/Activate changes made in Tools on table objects,
2- stop Siebel Server service;
3- find and delete/move any dic*.dat file found under [Siebel_server_root] directory - please refer to Related Note: "Why is there a dicdata.dat and a diccache.dat file? (Doc ID 475633.1)" for additional details on these files;
4- restart Siebel service - diccache.dat file should be re-created in [Siebel_server_root]\bin\;
5-
run again a "Generate New Database Template" (GenNewDb) task on server
(this is mandatory if schema changes were applied since the database
Schema Version would be increased!);
6- re-extract (DbXtract) mobile users' database and check this completes fine.

References

NOTE:475633.1 - Why is there a dicdata.dat and a diccache.dat file?

NOTE:477125.1 - How can users enable component tracing for the Database Extract component and read the log files in Siebel versions 7.x?

Applies to:

Siebel Remote Server - Version: 7.5.3.5 [16183] to 8.1 [21039] - Release: V7 to V8
IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3 [16157] FIN

Database: IBM DB2 7.2 FixPack 3SA

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-1182262661.

Symptoms

SBL-SMI-00077We are receiving the below error when running the Database Extract component, for creating local
databases for our developers. The database connect parameters for the component seem to be ok
(user, pwd, ODBC name, table owner, table owner pwd). Please let us know what further information
we can provide.

SBL-DCK-00164: Error connecting to datasource (null) ((null))

Thank
you.

Cause

This behavior occurred when the mobile client extracted did not have a
corresponding employee record. This was because the employee record has
been deleted.

Solution

Message 1

For the benefits of other customers, the Database Extract component was erroring out with



Target client "SYDGCML" does not have any valid employees.

SBL-SMI-00077: Component error, see the trace file for more information



This behavior occurred when the mobile client extracted did not have a
corresponding employee record. This was because the employee record has
been deleted.



This behavior is resolved by clearing out the mobile client records
manually. The steps for this are provided by Siebel Technical Support.



Change Request 12-JNNQK7 has been raised to request for a check when an
employee record is being deleted such that it would deactivate and
delete the corresponding mobile client when the employee record is
deleted.



If you encounter this behavior, please raise a Service Request with Siebel Technical Support quoting this Service Request.



Thank you.
 

Applies to:

Siebel Remote Server - Version: 7.5.3.11 [16199] to 8.1 [21039] - Release: V7 to V8
Oracle Solaris on SPARC (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.2.216 [16084]

Database: IBM DB2/UDB 7.2

Application Server OS: Sun Solaris 2.8

Database Server OS: Sun Solaris 2.8



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

Symptoms

SBL-SMI-00077We had installed our pre-production environment without problems, but when we tried a Database
Extract we have the following error:

Final code = 2100077
Finish information =
SMI-00077: Error del componente; consulte el archivo de seguimiento para obtener más
información.

I ran the Generate New Database process with no problems.
I am attaching
the "DbXtract_16461.log" file; in this file I found the following message:

[IBM][CLI
Driver][DB2/SUN] SQL0440N No function by the name "NEXTSEQ" having compatible arguments was found
in the function path. SQLSTATE=42884

This message occurs when the user is doing an upgrade
process, but I am installing a new environment.

Do you have any idea how can I solve this
issue?

Thanks in advance.

Cause

Database specific issue

Solution

Message 1

For the benefit of other users:



Customer installed their pre-production environment without problems,
but when they tried to perform a Database Extract, they received
following error:



“Finish information = SMI-00077: Error del componente; consulte el archivo de seguimiento para obtener más información.”



The main error message found in the DbXtract*.log file is as follows:



‘SQL0440N No function by the name "NEXTSEQ" having compatible arguments was found in the function path. SQLSTATE=42884’



This ‘SQL0440N - No function by the name "<function-name>" having
compatible arguments was found in the function path’ error message
usually occurs in a reference to function "<function-name>" (i.e.
NEXTSEQ), when the database manager cannot find a function it can use to
implement the reference. There are several reasons why this could
occur:



(a). "<function-name>" was either incorrectly specified or does not exist in the database.



(b). A qualified reference was made, and the qualifier was incorrectly specified.



(c).The user's function path does not contain the schema to which the
desired function belongs, and an unqualified reference was used.



(d).The wrong number of arguments was included.



(e).The right number of arguments was included, but the data types of one or more of the arguments are incorrect.



<Ctd..>

Message 2

<Ctd...>



(f).The function does not exist in the database with a create timestamp
earlier than the time the package was bound (applies to static
statements).



Following SQL statement was run against the database to check if the NEXTSEQ function exists in the database.



Select * from sysibm.sysfunctions where name = 'NEXTSEQ';



According to the query results, we found that the NEXTSEQ function does not exist in the database.



In order to have NEXTSEQ function in the database you need to install
the stored procedures and user-defined functions on your Siebel Database
Server. First you must transfer them to the Siebel Database Server and
install the Siebel Database Server components.



The behaviour resolved after customer ran NEXTSEQ.SQL script from the
‘siebproc.sql’ file to create the missing function ‘NEXTSEQ’ in the
database. After that they performed a new Database Extract and it worked
perfectly.



Please refer to Bookshelf, Siebel Server Installation Guide for UNIX
> Chapter 7 Installing the Siebel Database Server for DB2 Universal
Database > Siebel Database Server Software Installation >
“Installing the Stored Procedures and User-Defined Functions" for
information about installing Stored Procedures and User-Defined
Functions.



<Ctd...>

Message 3

<Ctd...>



We recommend obtaining the assistance of a Database Administrator (DBA) to perform this.



Thank you.

Best Regards

Siebel Technical Support



Key words: Database Extract, SMI-00077, SQL0440N, NEXTSEQ, NEXTSEQ.SQL, siebproc.sql, Stored Procedures, User-Defined Functions

SBL-SMI-00064: Internal: Multi-threaded server for component %1 got a request for component %2

Applies to:

Siebel Workflow - Version: 7.7.2.6 SIA [18372] and later   [Release: V7 and later ]
Information in this document applies to any platform.

Symptoms

When more number of request are routed to the WFProc Batch Manager ,
then it might not able to process the request and logs error in the
S_SRM_REQUEST.

Cause

WfProc Manager comp not able process more number of request coming and hence the error
SBL-SMI-00064: Internal: Multi-threaded server for component WfProcBatchMgr  in the S_SRM _REQUEST Table

Solution

Set the MaxMT and MinMT param to 2 for WFProc Batch Manager comp

References

NOTE:476018.1 - How to set Max Tasks and Max MT Server parameters for the Siebel Object Manager?

NOTE:477818.1 - How Synchronous and Asynchronous Server Requests Work, and How To Tune These Requests for Performance and Availability

NOTE:729037.1 - Asynchronous tasks get error out:

Applies to:

Siebel Workflow - Version: 7.7.2.6 SIA [18372] and later   [Release: V7 and later ]
Information in this document applies to any platform.

Symptoms

When more number of request are routed to the WFProc Batch Manager ,
then it might not able to process the request and logs error in the
S_SRM_REQUEST.

Cause

WfProc Manager comp not able process more number of request coming and hence the error
SBL-SMI-00064: Internal: Multi-threaded server for component WfProcBatchMgr  in the S_SRM _REQUEST Table

Solution

Set the MaxMT and MinMT param to 2 for WFProc Batch Manager comp

References

NOTE:476018.1 - How to set Max Tasks and Max MT Server parameters for the Siebel Object Manager?

NOTE:477818.1 - How Synchronous and Asynchronous Server Requests Work, and How To Tune These Requests for Performance and Availability

NOTE:729037.1 - Asynchronous tasks get error out:

Applies to:

Siebel Workflow - Version: 7.5.3 [16157] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.5.3 [16157]

Database: Oracle 8.1.7.4

Application Server OS: Microsoft Windows 2000 Server SP 3

Database Server OS: Sun Solaris 8



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

Symptoms

SBL-DAT-00171, SBL-SMI-00064   We are currently receiving the following error message in the Workflow Process
Batch Manager logs,SBL-SMI-00064: Internal: Multi-threaded server for component (null) got a
request for component (null). We have had this problem before and submitted SR #38-1178344271 to
try to get it resolved. At that time the impact was much greater than it is today so we would
like to catch this problem early before it begins to seriously impact our production environment.
We are not aware of any harmful effects of these errors but suspect that something is not
happening that should
   To resolve the previous issue we modified the number
of MT servers and tasks. The current parameters for the Workflow Process Batch Manager and the
Workflow Process Manager are:

Minumum MT Servers: 5
Maximum MT Servers: 10

Maximum Tasks: 200

   We usually have about 125 concurrent users all of
whom run workflows at some point during the day. Do we have enough tasks to handle the load? What
is the best way to determine if we have enough? Does something have to be done to turn on
statistics for the component so we can monitor the process more closely? Thank you.

Bob
Rabold

Cause

For the benefit of other user, customer observed the following error in the Workflow Process Batch Manager log file:

SBL-SMI-00064: Internal: Multi-threaded server for component (null) got a request for component (null).

Customer
determined that there is a repeating component request that calls a
Workflow Process Batch Manager component. This workflow process has a
step that uses ‘“Synchronous Assignment Manager Requests”. There are
also numerous AsgnSrvr log files in the server log directory.

Based
on the above scenario, there error message is likely to be caused by
not having sufficient task to handle the Assignment Manager request by
the Workflow Process Batch Manager component.

Based on the
information documented in Siebel Server Administration Guide v7.5.3 >
Chapter 6: Siebel Server Infrastructure Administration >
Administering Server Request Broker


The Server Request
Processor (SRProc) and the Server Request Broker (SRBroker) are jointly
responsible for the processing of both synchronous and asynchronous
request.

“Synchronous Assignment Manager Requests” is a synchronous request and therefore, it involves SRProc and SRBroker.

Solution

The error was resolved after tuning the following components with the
value set for parameters: Minumum MT Servers/ Maximum MT Servers/Maximum
Tasks:



Server Request Broker    : 2/2/200

Server Request Processor    : 10/10/200

Workflow Process Manager    : 10/10/200


Keywords

SBL-SMI-00062: Internal: No more process (multithreaded server) slots available

Applies to:

Siebel System Software - Version: 7.8.2.3 SIA [19221] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.8.2.3 [19221] Com/Med

Database: Oracle 9.2.0.6

Application Server OS: Microsoft Windows 2003 Server

Database Server OS: IBM AIX 5L 5.2



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

Symptoms

SBL-CSR-00102, SBL-SMI-00062, SBL-GEN-28758, SBL-SCB-00005- CALL STACK -
siebmtshmw +0xffc00000
sssasos +0x489e = CompCleanup()
+0x1f1e
siebmtshmw +0x527e
siebmtshmw +0x20347 = SmiInProcMsgHandler() +0xad7
siebmtshmw
+0x22d16 = SmiInProcMsgHandler() +0x34a6
siebmtshmw +0x15a13 = SmiCleanupDetTask()
+0xddd3
siebmtshmw +0x16fd7 = GetSmiWorkQObj() +0x1497
siebmtshmw +0xca33 =
SmiCleanupDetTask() +0x4df3
sslcosd +0x20f2 = OSDThreadPrivIsInit() +0x1d0
sslcosd +0x217e
= OSDThreadPrivIsInit() +0x25c
MSVCR70 +0x412f = beginthreadex() +0xba
kernel32 +0x2608b =
GetModuleFileNameA() +0xeb

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers.



The crash with call stack above happened very frequently in the customer.



In the OM logs right before the crash there was this error that
suggested the communication between Siebel Web Server and Siebel App
Server was terminated:



SisnTcpIp    SisnSockError    1    0    2007-10-22 12:50:25     11712:
[TCPIP-server] send() failed for sd=3768 (err=10054 | An existing
connection was forcibly closed by the remote host (peer).)



Because of the crash other subsequent messages were seen in SCBroker log. But they are just a consequence of the crash:



SBL-SCB-00005: Connection timeout waiting for message.

SBL-SCB-00011: Failed to connect to pipe (SEBL_3_5608) on process 5608.



Further, this was last actions captured by *.fdr file. But again this
was just a consequence and it was not related to the root cause of the
crash:



Communications Client Business Service    PushToolbarMessage   

Communications Client Business Service    PushToolbarMessage   

Fire Service Event    Communications Client    WaitForCmd



Solution:



After disabled SNMP protocol to diminish the retransmission of the TCP packages, this crash was no longer seen.

Applies to:

Siebel Workflow - Version: 7.7.2.10 [18385] to 8.0 [20405] - Release: V7 to V8
Information in this document applies to any platform.

** Checked for relevance on 27 February 2012**

Symptoms

Customer is facing recent and intermittent unavailability of WfProcMgr
component installed in one server. Customer has noticed one occurrence
this Sunday 02/15 at 10:30 AM and  02/16 3:20 AM. When it occurred they
were able to restart the server. Customer is not able to always restart
the siebel server because the application does not respond in a timely
manner.

Since WfProcMgr seems unavailable for some reason
SISNAPI errors in SRBroker logs were found also as a consequence of this
component being unavailable it seems that records in S_ESCL_REC are
increasing.

The records in S_ESCL_REC seems to be associated to
triggers created for assignment of campaigns. No recent changes were
made on wf policies or configuration.



In the enterprise log and confirmed that WfProcMgr became unavailable.

From the Enterprise logs the related WfProcMgr logs and this analysis resulted in 3 groups of enterprise +wfprocmgr logs:

In WfProcMgr_58975.3.log  can also find the error SBL-SMI-00140: Internal: The MT Server has been disabled.
Customer
can see from WfProcMgr_80330.log that the same instance'1-6E1YM0' was
still not able to be resumed even after several hours >
SBL-BPR-00124: Cannot resume process instance '1-6E1YM0'. Verify that it
does exist and has a 'Waiting', 'Suspended' or 'In Error' status.

A3,
B3: For the Workflow Process Manager created by the Siebel Server
Scheduler at 2009-02-16 03:19:36 with task id 80973 and exited at
2009-02-16 03:20:37.

Finally here Customer were able to find the
error SBL-SMI-00062: Internal: No more process (multithreaded server)
slots available in WfProcMgr_80973.log.


Customer checked the
memory limits and found that memory limits are not being reached (or
reached only 20% below the limit) which indicate that the cause does not
seem memory related.

Cause

There were 2 problems associated to this workflow component crash;hang:

1.
Associated to the jobs executed by workflow process SMCC - List Import
is consuming too many threads. At some point max tasks limit is reached
and as a consequence no more threads can be created to continue trying
to process these records. This would explain why we saw the error
SBL-BPR-00124: Cannot resume process instance '1-6E1YM0'.




2. After this problem was solved it seems that a crash was found.
This crash was associated to the workflow process "SMCC Sync PEM Status
- Contact Phone Status" fails.

The error seems to happen
when the method "'SyncPEMStatus" updates a business component field with
a picklist with a value that is not available in this picklist. The
pick lists name is "Response Outcome PickList".

Solution

1. By stopping the instances in loop from the workflow instance view
have helped to free up some threads and avoid the Max Tasks limit to be
reached. This means that this job that is processing List Import
records must be reviewed in order to ensure that it will not keep in
loop and allocating a high number of threads until the limit is reached.

2.
The suggestion here is to ensure that the value being used (by workflow
process "SMCC Sync PEM Status - Contact Phone Status") to update the
field (by the method "'SyncPEMStatus") exists in the picklist associated
to this field ("Response Outcome PickList").

Applies to:

Siebel CRM - Version: 8.0.0.5 [20420] - Release: V8
Information in this document applies to any platform.

Goal

If eChannelObjMgr_enu PID crashes the server creates one process for eChannelObjMgr_enu + 1 additional process for SrvrSched.
that's when we hit this error "No more process (multithreaded server) slots available".

Can you please explain the cause of this error?


Below is the log snippet:

ServerLog
ProcessExit 1 00001d5f4b2617ee:0 2009-12-16 11:19:18 eChannelObjMgr_enu
17140 SBL-OSD-02006 Process 17140 exited with error - Process exited
because it received signal SIGABRT.

ServerLog ProcessCreate 1 00001d5d4b2617ee:0 2009-12-16 11:19:18 Created server process (OS pid = 5745 ) for eChannelObjMgr_enu
ServerLog ProcessCreate 1 00001d5d4b2617ee:0 2009-12-16 11:19:18 Created server process (OS pid = 5759 ) for SrvrSched

ServerLog
ProcessExit 1 00001d5f4b2617ee:0 2009-12-16 11:29:21 eChannelObjMgr_enu
5745 SBL-SMI-00062 Process 5745 exited with error - Internal: No more
process (multithreaded server) slots available
ServerLog ProcessExit 1
00001d5f4b2617ee:0 2009-12-16 11:29:21 eChannelObjMgr_enu 5759
SBL-SMI-00062 Process 5759 exited with error - Internal: No more process
(multithreaded server) slots available

ServerLog ProcessCreate 1 00001d5d4b2617ee:0 2009-12-16 11:29:21 Created server process (OS pid = 7246 ) for eChannelObjMgr_enu

Solution

After an OM failure new MT Server PID is started and SrvrSched also starts a PID (as a result some more processes are spawned).

The AOM tuning does recommend you to set MaxMTServer=MinMTServers to avoid overhead time for starting the new process.
However the defect CR# 10642132 causes these error messages appear in the log under following scenario:

When
you have MaxMTServer=MinMTServers and OM crash occurs then component
starts a process as it does not have the requisite MinMTServers running.
The siebsrvr (Scheduler) also starts a process.

If the new process that started sees that it has more than MinMtServers, it will exit.
These message do not imply problem in the above case.

Hence
it would help to set MinMTServers to a lower value than MaxMTServers so
that at any given time you have higher than MinMTServers running but
lower than MaxMTServers.

If the issue persists after thatinvistigate the resource availability aspect of the server and the concurrent OM loads.


















 

Applies to:

Siebel System Software - Version: 7.5.3 [16157] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Professional)

Version: 7.7.2.1 [18353]

Database: Oracle 9.2.0.5

Application Server OS: Microsoft Windows 2003 Server

Database Server OS: Sun Solaris 8



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

Symptoms

SBL-SVR-00028, SBL-SMI-00062

We did a reconfigure on our Call Center Object Manager and see that afterwards we get errors in the log

SCCObjMgr_enu   8213      SBL-SMI-00062   Process
exited with error - Internal: No more process (multithreaded server)
slots available

I suspect that we may not have something set correctly to effectively use the reconfigure option.

Solution

In reviewing the log filles the error "SBL-SVR-00028: No more tasks
available for this component" was also found. Both errors are usually
related to the MaxTasks and MaxMTServers values on the server. The
customer was advised to view the document "Tuning AOM Components for CPU
and Memory Utilization" and Technical Note 388 on SupportWeb, these
give details on how to best calculate the values.

The customer
updated the values of MaxTasks and MaxMTServers, as well as
MemoryBasedRecycle and MemoryLimit, and this resolved the issue.

SBL-SMI-00049: Internal: There is no connection to the gateway server

Applies to:

Siebel Insurance CRM Service, SPE - Version: 7.8.2.4 [19224] and later   [Release: V7 and later ]

Information in this document applies to any platform.

Symptoms

When stopping Siebel Server, many error happened as follows,

SBL-SMI-00049 Gateway connection error when shutting down the Siebel Server.

Cause

When stopping Siebel Server, siebctl directs the components to be
shutdown and waits for the end for 2 min(default). But some components
don't stop in time. Then, siebctl kills them.

At this time, the
connection to the Gateway Server from the component is closed, and as
the result the error SBL-SMI-00049 situation is happened and is written
in the enterprise log.

Solution

This error is harmless, you can ignore this error.

Or before stopping the Siebel Server, stop the components via
srvrmgr and check the component status if they are changed into
"Shutdown".

This symptom is registered as CR# 10643122.

References

BUG:10643122 - [CR#12-1RUP03P][FR#12-1RUP04C] SBL-SMI-00049 GATEWAY CONNECTION ERROR WHEN SHUTT

Applies to:

Siebel System Software - Version: 7.7.1 [18306] and later   [Release: V7 and later ]

Information in this document applies to any platform.

Error Message Area:Server Management Infrastructure - SMI

Version:Siebel 7.7

Purpose

This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-SMI-00049: Internal: There is
no connection to the gateway server

Scope

This document is informational and intended for any user.

SBL-SMI-00049: Internal: There is no connection to the gateway server

Explanation

The connection to Siebel Gateway Server has been lost. This can be
caused by the Siebel Gateway Server process being stopped, the machine
hosting the Siebel Gateway Server being shutdown, or a network problem
between the Siebel Gateway Server machine and the machine that hosts the
component that throws this error message.

Corrective Action

Verify that the machine where the error appears can connect to the
Siebel Gateway Server machine over the network by pinging it. Also
verify that the Siebel Gateway Server process is running and that each
part of the infrastructure is using the same build and version of the
application software. This error may be expected if the Siebel Server
and Siebel Gateway Server are stopped in rapid succession where some
components on the Siebel Server are not stopped before the Siebel
Gateway Server is stopped. In this case, no action is required.

Applies to:

Siebel System Software - Version: 7.8.2 [19213] and later   [Release: V7 and later ]

Information in this document applies to any platform.

Error Message Area:Server Management Infrastructure - SMI

Version:Siebel 7.8

Purpose

This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-SMI-00049: Internal: There is
no connection to the gateway server

Scope

This document is informational and intended for any user.

SBL-SMI-00049: Internal: There is no connection to the gateway server

Explanation

Connection to Siebel Gateway is lost.

Corrective Action

Check to see if the Siebel Gateway is running and configured properly.

Applies to:

Siebel System Software - Version: 7.5.3 [16157] and later   [Release: V7 and later ]

Information in this document applies to any platform.

Error Message Area:Server Management Infrastructure - SMI

Version:Siebel 7.5.3

Purpose

This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-SMI-00049: Internal: There is
no connection to the gateway server

Scope

This document is informational and intended for any user.

SBL-SMI-00049: Internal: There is no connection to the gateway server

Explanation

The connection to Siebel Gateway Server has been lost. This can be
caused by the Siebel Gateway Server process being stopped, the machine
hosting the Siebel Gateway Server being shutdown, or a network problem
between the Siebel Gateway Server machine and the machine that hosts the
component that throws this error message.

Corrective Action

Verify that the machine where the error appears can connect to the
Siebel Gateway Server machine over the network by pinging it. Also
verify that the Siebel Gateway Server process is running and that each
part of the infrastructure is using the same build and version of the
application software. This error may be expected if the Siebel Server
and Siebel Gateway Server are stopped in rapid succession where some
components on the Siebel Server are not stopped before the Siebel
Gateway Server is stopped. In this case, no action is required.

Applies to:

Siebel System Software - Version: 7.5.3 [16157] and later   [Release: V7 and later ]

Information in this document applies to any platform.

Error Message Area:Server Management Infrastructure - SMI

Version:Siebel 7.5.3

Purpose

This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-SMI-00046: The port %1 is
already in use

Scope

This document is informational and intended for any user.

SBL-SMI-00046: The port %1 is already in use

Explanation

The Siebel Server is unable to create the configured listening port.
This can happen when multiple server components have the same value
specified for the Static Port Number parameter.

Corrective Action

If there is a specific server component that encounters this error
message, check the value for the Static Port Number parameter and make
sure that it is not the same value specified by any other component.
Also, validate that the port is not in use by another application.

Applies to:

Product Release: V7 (Enterprise)

Version: 7.5.2.217 [16085]

Database: Oracle 9i

Application Server OS: Microsoft Windows 2000 Advanced Server SP 4

Database Server OS: IBM AIX 5L 5.1



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

Symptoms

SBL-SVR-01004, SBL-SMI-00049But we do notice whenever we stop the Siebel service, the service took a long time (1~2 minutes)
to stop and most of cases we got the following message

“Could not stop the Siebel Server from
local Computer, Error 1053: The service did not respond to the start or control request in a
timely fashion.”

We have FINSOBJMGR_ENU and FINSOBJMGR_FRA running on each OM server. The min
and max MT server for ENU are 7 and for FRA are 3. Each server has 8GB physical memory and 16GB
paging size.

Is that possible the Siebel service cannot stop in certain time and then fail to
remove the component rules from Resonate?

Solution

Message 1

For the benefit of other users:



If the object managers are busy at shutdown they cannot gracefully
terminate and remove their corresponding rules from Resonate (e.g. under
UNIX if you force the shutdown this will almost always be the case).
Here are some guidelines to reduce the time necessary to stop the Siebel
servers



1) Before shutting down the Siebel application server shutdown web
servers first. If the seb servers are shutdown there will be no further
traffic to the object managers during shutdown.



2) Define a process that deletes all rules from Resonate each time you
bring down your environment (fail safe procedure). This is done
automatically at startup by the Siebel server, but you will not run into
issues with having this in place (e.g. import an empty rules file, see
below).



Probably the easiest way to remove all rules from Resonate during
restart is importing an empty rule file from command line e.g.:



CDAction -p 2101 localhost <PASSWORD> load_rules empty.dat



CDAction is located in the Resonate bin folder and this should be
performed on the primary scheduler. Please keep in mind that this will
delete all rules and should not be done on a site that is in use.



The empty rules (empty.dat) file will look like this:

-----

VERSION(3.2)

COMMENT(DATE 12/08/2003 02:30:06 PM)

-----



[..]

Message 2

You can create such a file by starting Central Dispatch (GUI) >
Scheduling Rules > Management > Save Scheduling Rules. Then
deletes everything apart from the first two lines so that the file looks
like the above sample.



Thanks

SBL-SME-00038: No contacts were required for any cells, No records moved from Olap.

Applies to:

Siebel System Software - Version: 7.7.1 SIA [18306] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)

Product Release: V7 (Enterprise)

Version: 7.7.1 [18306] Auto

Database: Oracle 9.2.0.6

Application Server OS: Sun Solaris 9

Database Server OS: Sun Solaris 9



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

Symptoms

SBL-SMI-00038Hi,
I am setting up our QA system:
Gateway server is on soa020 (unix).
Siebel server is
on soa016 and soa017 (all unix)
Document server is on snt055 (win 2003 server)
Siebel
remote server is on soa020 also.

The problem is sometime one or both of the siebel servers
state show "Handshake failed" from the dedicated client --> Administration - Server -->
Enterprise view, and the web client would work. sometimes I restart those two siebel servers they
come up fine, sometime I need to restart them several times. Also even I enabled and start
components eAutomotive Object Manager (ENU) and eDealer Object Manager (ENU), after restart
siebel server, their state show "Shutdown".

I am attaching the screenshot, logfiles and
siebelns.dat for your review.

Thank you so much.

Cause

Configuration/ Setup

Solution

Message 1

For the benefits of other users:



When login to the dedicated client and go to SiteMap> Administration -
Server > Enterprise view, customer observed that siebel servers
state show "Handshake failed".



Resolution:



According to Troubleshooting Steps 8 “Siebel Server Installation
Troubleshooting Guide”, one of the cause of “handshake failed” error is
insufficient memory.



In addition, review of the Enterprise Server log show the following error,



GenericLog    GenericError    1    0    2005-06-05
17:27:31    (schedule.cpp (452) err=2100038 sys=12) SBL-SMI-00038:
Internal: Cannot create process for siebsess



The “sys=12” in the error message above means ENOMEM which is out of memory error.



The customer increases the RAM size and did not encounter the “handshake failed” error again.



According to the System Requirement and Supported Platform document for
7.7, the RAM size recommendation is 1GB. Please note that this is only
the minimum memory requirement. For more precise memory sizing, please
engage Expert Service.



Many Thanks,

Applies to:

Siebel System Software - Version: 7.7.1 [18306] to 8.1.1.4 [21225] - Release: V7 to V8
Oracle Solaris on SPARC (64-bit)

Product Release: V7 (Professional)

Version: 7.8.2 [19213]

Database: Oracle 10g

Application Server OS: Sun Solaris 9

Database Server OS: None - Not Implementing Web Server OS



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

Symptoms

SBL-SMI-00038, SBL-ADM-02049Hi

Sometimes when we log into Siebel and navigate to the Administration - Server
Managment - Servers and Sessions screen to check on the status of ther server we cannot access
the screen and we get the following error.
"We detected an Error which may have occurred for
one or more of the following reasons:
Operation failed, possibly because of "SBL-ADM-02049:
There is no connected server targeted for that command."(SBL-SDM-00112) ".

When we
navigate to Administration - Server Managment - Tasks we get the following error"
"We detected
an Error which may have occurred for one or more of the following reasons:
SBL-NET-01023: Peer
disconnected"

I think we also have a related issue with above as we can not log into
srvrmgr from the command prompt. We were able to log in using the following commands, however it
is not working now: Here are the steps we are taking to log
in
*********************************************************************************************
Log
into the box
Change directory to root where Siebel is installed
$ cd /var/adm/Siebel
Get
a subshell
$ ksh
Navigate to siebsrvr folder
$ cd siebsrvr
Run the environment
variable
$ . ./siebenv.sh
Navigate to Bin folder
$ cd bin
Run the Srvrmgr
command
$ srvrmgr -g dmncvmdev2 -e SiebDev –s dmncvmdev2 -u sadmin -p
sadmin
srvrmgr:dmncvmdev2>

***********************************************************************************************
We
have been having this issue for some time. The workaround has been to restart the services and it
used to get corrected. How ever off late this has been happening more often and with start of
development this is getting
critical.
=================================================================
We are also
unable to run any EIM task. It errors out with the following error:
"SBL-EIM-00204: Invalid
configuration file (ifb) name." Please see the attached EIM log file.

Any help will be
highly appreciated

Regards

Solution

Message 1

For benefit of other readers:



They are able to startup the gateway and siebel server successfully. But
after sometime, they are no more able to access Server Admin screen and
connect via srvrmgr.



Below error was found in the log:

SBL-SMI-00038: Internal: Cannot create process for siebsess



The behavior was resolved after they increase the swap space to twice of the RAM, 4.5 GB.


 
Thanks

SBL-SMI-00034: Internal: Error %1 reading a message from the client

Applies to:

Siebel System Software - Version: 7.5.3.13 SIA [16275] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3.13 [16275] Auto

Database: Oracle 9.2.0.6

Application Server OS: Sun Solaris 2.8

Database Server OS: Sun Solaris 2.8



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

Symptoms

SBL-DAT-00144, SBL-EXL-00145, SBL-DAT-00306, SBL-DAT-00315,
SBL-DAT-00322, SBL-DAT-00501, SBL-OSD-00204, SBL-SVR-04000,
SBL-SVR-01004, SBL-SMI-00034, SBL-SMI-00126, SBL-GEN-09103,
SBL-NET-01023, SBL-NET-01201, SBL-NET-01204Our thin clients are presenting error "page can not be displayed” after loggin and doing
some
navigation.

We first thought this is because of the SRF, so we have changed the SRF also.
But still the same error persists.

I am attaching the log files of the Web server and
Siebel eAutomotive object manager.
Some of the errors from the log files
are:
----------------------------------------------------------------------------------------------------
SBL-NET-01204:
Internal: recv() failed: Connection timed out
SBL-SMI-00034: Internal: Error (null) reading a
message from the client
[SWSE] New anon session open failed
SWSE] Could not get an anon
session...PROBLEM
[SWSE] after the timeout/broken anonymous connection impersonate failed.
Could not open repository file '%1'.\n\nFile does not exist or may be in use by another
process?
-----------------------------------------------------------------------------------------------------

We
already tried by recycling the whole environment also.

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers:



After extensive troubleshooting with Resonate environment variables,
Resonate password variables in Unix OS and comparing errors in the web
server and OM logs, customer was able to identify the server which was
presenting the behavior.



Customer had three load balancers in the environment (A, B, C). Due to
some activities they were not using the C load balancer. When shutting
down the A LB, where only B LB was running, the thin client worked
properly without any issue.

When we shut down B and put only A LB up. At that time started getting same error for the thin client.



Customer resolved the issue by removing the defecting node from Resonate and added it back.

It also found that CFGClientRootDir for the defective node was set to
%SIEBEL_ROOT% while searching Siebns.dat. This value was also changed.



Thank you and best reagrds,

Applies to:

Siebel System Software - Version: 7.5.3.1 [16161] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Professional)

Version: 7.5.3.15 [16279]

Database: IBM DB2 8.1

Application Server OS: Microsoft Windows 2000 Advanced Server SP 4

Database Server OS: IBM AIX 5L 5.1



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

Symptoms

SBL-SMI-00034Recently, we began to notice that Siebel Server Scheduler was starting up and failing every
minute. Since this time it has never gone away and the Siebel Server Scheduler component appears
to start/fail every minute indefinitely. We are unsure of the impact of this component
failing.

BEFORE 3:52PM, 10/26/2006 we would receive only this message and only when we had
just restarted the
environment:
ServerLog    ProcessCreate    1    2006-10-25
09:26:01    Created server process (OS pid = 5124) for Siebel Server
Scheduler with task id 77975

AFTER 3:52PM, 10/26/2006 we began getting the above message
but with an error directly after it and it would occur every
minute:
ServerLog    ProcessCreate    1    2006-11-11
04:30:53    Created server process (OS pid = 4776) for Siebel Server
Scheduler with task id
50426ServerLog
ProcessExit    1    2006-11-11
04:30:53    <NoCompName>    50426    

SBL-SMI-00034   Process
exited with error - Internal: Error %1 reading a message from the client

Note: These
errors are coming from the Enteprise log on one of our Siebel servers.

To help
trouble-shooting, I have attatched the following files: 1) A before and after Enterprise log. 2)
A before and after siebns.dat file. 3) A few samples of the SiebSrvr.logs that get created when
the Siebel Server Schedule is failing.

Questions: 1) Could you provide more background on
what the Siebel Server Scheduler does? Note: we looked at various documentation and only got a
very short explaination. 2) What is the impact of this component failing? 3) Do you have any
ideas what would have caused this behaivor?

Please let me know what other information I
can provide. Thanks for your help and cooperation.

--Ken/Holly

Cause

Configuration/ Setup

Solution

Message 1

**For the benefit of others***



A number of questions were posed in relation to the Siebel Server Scheduler:

(1) Could you provide more background [information] on what the Siebel Server Scheduler does?

(2) What is the impact of this component failing?

(3) Do you have any ideas what would have caused this behaviour?



The Siebel Enterprise log also contained a number of errors relating to this component:

ServerLog    ProcessCreate    1    2006-11-11 05:01:31    Created server
process (OS pid = 3276) for Siebel Server Scheduler with task id 50901

ServerLog    ProcessExit    1    2006-11-11
05:01:31    <NoCompName> 50901     SBL-SMI-00034   Process exited
with error - Internal: Error %1 reading a message from the client





***Resolution****



In response to the questions posed...

The “Siebel Server Scheduler” is a background component responsible for Server job execution.

This pre-configured component does not appear as a job that can be
configured under the ‘System Administration’ views even though it forms
part of the ‘System Management’ component group.

Note, the Siebel Server Scheduler process runs (only becomes “active”)
every time a Server needs to fork one of the following processes:
siebproc, siebprocmw, siebmtsh, and siebmtshmw processes.

Message 2

Important to note, still, is that the type of process/shell that gets
started depends on the mode of an associated component (interactive,
background, batch) and whether or not an Objected Manager is involved
and Multi-threaded.

(You may already be aware that the siebproc is used for server mode
components, while siebmtsh is used for forking off multi-threaded batch
mode components as well as multi threaded sessions, for instance).



On a further note, before spawning a new process, the scheduler only
knows the process type has to come from this list (siebproc, siebprocmw,
siebmtsh or siebmtshmw) and nothing more.

That, the component running, at this point in time, only has the
identity of the Siebel Server Scheduler should thus account for the
error sometimes seen in a Siebel Server enterprise log.

It is only after the Scheduler actually reads the message sent on by a
Siebel Server that it acquires ‘knowledge’ about the component it needs
to startup, and subsequently loads the same.



With respect to last question, although it is difficult to determine the
breakpoint, in this instance, without the benefit of additional logs,
please note that the Siebel Server Scheduler could just have easily been
called into action, given the following scenarios:

(a) asynchronous requests are processed - repeating component(s), say;

(b) when additional object manager processes to service Client-requests



Thank you,

Applies to:

Product Release: V7 (Enterprise)

Version: 7.5.2.217 [16085]

Database: Oracle 9i

Application Server OS: Sun Solaris 8

Database Server OS: Sun Solaris 8



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

Symptoms

SBL-SMI-00034, SBL-SSM-00003Hi,

We have installed the eService across the Firewall and it is not working.

The
ports are opened bi-directionally i.e 2320 and 48090 for object manager eService and other 47000
- 48000 ports are opened on the firewall.

We have installed the Iplanet ws 6sp2 and Siebel
7.5.2.217 eappweb software and all the virtual directories are created properly.

The
application server is inside the firewall and the application is running and can be invoked from
inside the firewall as it is running from another web server.

So please help. I wil
lattach some log files found on the DMZ server install under SWSE/bin and SWSE/log
locations.


- Sathya

Solution

Message 1

Issue : Unable to connect to eservice across a firewall even when all ports above 49000 are open



Resolution :

NOTE: If a firewall is used then Siebel STRONGLY recommends using Resonate. This is documented in Bookshelf.

In this scenario, Resonate was not used, so all ports above 49000 need
to be open for the Siebel Object Managers, along with port 2320. Even
after doing this eservice was not able to connect across the firewall.

The name of the HOST inside the firewall which had the Siebel
Application Server was engit28.central and the same was used in the
ConnectString for eservice_enu in eapps.cfg.



Following tests were done to ensure that the ports were indeed open.

From the web server machine outside the firewall we issued the following command

telnet <engit28.central>:2320 and it connected.

telnet <engit28.centra>:<port for esrevice OM determined by looking at the enterprise log> and it was successful.



After further investigation, we ran the following command from srvrmgr connected to the siebel server



change paramter host="engit28.central"



After this we re started the processes and it worked. The reason is that
the host name of the sun box which was inside the firewall and had the
siebel server, was engit28.central but the siebel server parameter
called HOST had the value of engit28. This was verified by looking at
the siebns.dat.

SBL-SMI-00033: The client exited without closing the SISNAPI connection

Applies to:

Siebel Finance Call Center - Version: 7.8.2.7 [19234] to 8.1.1 SIA [21111] - Release: V7 to V8
Information in this document applies to any platform.

Symptoms

After a server restart, it can happen that the  SRProc dispatcher task  is terminating itself after 60 seconds.


The following error message can be seen in the SRProc log file:


SBL-SMI-00033: The client exited without closing the SISNAPI connection.


The main  SRProc process however continues to run and in srvrmgr status shows as 'running'.


Tasks will remain in queued status and you need to restart the SRProc component to get pending tasks processed.

Cause

Bug 10643087 has been created to address this behavior. There has
been a race condition detected that can cause shutdown of SRProc
process.

Solution

For the benefit of other readers:


Quickfix QF 0765 has been built for the Siebel CRM version 7.8.2.7 Fixpack.


The fix for this issue has been included on the following Siebel CRM maintenance releases and later:

Siebel CRM version 7.8.2.12
Siebel CRM version 8.0.0.7
Siebel CRM version 8.1.1.1

References

BUG:10643087 - [CR#12-1QTP7FD][FR#12-1QTP7FY] SRPROC CRASH/TIMEOUT ON SERVER STARTUP.

Applies to:

Siebel System Software - Version: 7.7.2.3 [18361] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.7.2.3 [18361]

Database: Microsoft SQL Server 2000 SP4

Application Server OS: Microsoft Windows 2003 Server SP1

Database Server OS: Microsoft Windows 2003 Server SP1



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

Symptoms

SBL-DAT-00306, SBL-DAT-00315, SBL-SVR-01014, SBL-SMI-00033, SBL-CSO-01031, SBL-GEN-09103The SRBroker log file often contains the following error message:

SBL-SMI-00033: The client exited without closing the SISNAPI connection.

The eventlog of the server does not show any errors.
The backups of the
database occur at night.
Until now there was no user complaining having lost his
session.

Should we be concerned about this error?

Changes

Cause

Change Request Numbers 10641111 and 10641355.

Solution

For the benefit of other readers:



The Customer had installed and was currently in the process of using the
Siebel Version 7.7.2.3 product release in their Production environment,
when these error messages started to occur with the Server Request
Broker (SRBroker) Server Components:

SisnTcpIp    SisnSockError    1    0    2006-01-04
15:00:19     8300: [TCPIP-server] recv() failed for sd=2904 (err=10054 |
An existing connection was forcibly closed by the remote host (peer).)



GenericLog    GenericError    1    0    2006-01-04
15:00:19    (smimtses.cpp (350) err=2100033 sys=0) SBL-SMI-00033: The
client exited without closing the SISNAPI connection

Through research and investigation, we discovered that these error
messages could be safely ignored.  Product Enhancement Change Request
Numbers 10641771 and 10641272 have been raised to address this SRBroker
error behavior.



We also discovered these error messages occurring here as well :

DBCLog    DBCLogError    1    0    2006-03-03 05:37:23    [Microsoft][ODBC Driver Manager] Invalid cursor state



SRPQueryLogEvt    SRPQueryError    1    0    2006-03-03 05:37:23    SQL
Error Rc:0 SqlState:24000 Message:[Microsoft][ODBC Driver Manager]
Invalid cursor state



SRPQueryLogEvt    SRPQueryError    1    0    2006-03-03 05:37:23    SQL Error Rc:100 SqlState:00000

These messages are related to known product behavior for which Change
Request Numbers 10641111 and 10641355 have already been raised to
address. Refer to the following MOS document for related information:

• Server Request Processor Component May Hang or Report Deadlock Behaviors While Waiting for Resource (Doc ID 477667.1).

Keywords: SBL-SMI-00033, Forcibly Closed, SISNAPI, Connection, 12-O6HYF2, 12-HH6SF4, ALERT 953

Applies to:

Siebel System Software - Version: 7.5.3 [16157] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.5.3 [16157]

Database: Oracle 9i

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

Symptoms

SBL-SMI-00033

SBL-SMI-00033. The client exited without closing the SISNAPI connection.

We have checked Support web for this error, which suggests no specific way to resolve.

We have tried to stop and restart the Services on our main Server, but this has not fixed the issue.

Can you suggest any other way to rectify this issue?

Solution

The customer had a morning batch process on their Siebel Server and
observed many Server Request Broker (SRB) tasks that exited at around
the same time (anywhere up to 200 requests in this batch).

The customer restarted the Siebel services on their main server, but this did not fix the exiting SRB tasks.

The
last time the Siebel Server machines were re-booted was about one month
ago: the machines were re-started which resolved the behavior.

Siebel
Technical Support requested the Windows server's application and system
event logs, in order to review these to obtain a better understading of
the behavior:

The Siebel Servers are shutdown every night for
the database to be backed up. It was noted that 22 seconds after the
database backup at 04:00, a siebmtshmw.exe process (a multi-threaded
server component) raised an exception at 04:00:22 reporting the
following error:

---
10/09/2004    04:00:22    Siebel
Application    Error    Printers     1002    N/A    S7OFS1    "The
description for Event ID ( 1002 ) in Source ( Siebel Application )
cannot be found. The local computer may not have the necessary registry
information or message DLL files to display messages from a remote
computer. The following information is part of the event: Exception
0xc0000005 at 0x00154030
Thread: 0x00000bf4, Process 0x00001238
---

This
means the component crashed. We believed that this was the SRB process.
The call stack was included in the event log (but did not show any
useful information). This was the first occurence of this crash type. It
occured 5 times between this initial occurence and 10:07:59 on the same
date. This type of crash did not occur prior to the 10th of September,
nor did it occur subsequently.

The error code "Event ID 1002"
means that the component experienced a "Disconnect error", which would
make sense in that the database was being backed up. It seemed that the
component had difficulty re-establishing a connection with the database
after the backup. We do not know why the component could not
re-establish a connection.

The customer was satisified with this analysis.

Applies to:

Siebel System Software - Version: 7.7.2.2 SIA [18356] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.7.2.2 [18356] Cons Goods

Database: Oracle 9.2.0.4

Application Server OS: Microsoft Windows 2000 Server

Database Server OS: Compaq Tru64 UNIX



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

Symptoms

SBL-SMI-00033, SBL-ADM-09217Dear Support,

we have problems to set up the Admin Notification on the Enterprise level
via Email.

I already read in the Siebel Bookshelf 7.7 (configuring Siebel Servers, page
76-79) and also in SR# 38-1486557451but I still recieve errors.

We also set up an order
confirmation via Email with the same Servername and Serverport as we used for the Admin Notify
and that is working fine.

Can you please help?


Please see the attached
files.

1 Word Document with 3 Hardcopies showing different Screens/Parameters
2 log
files from our QA system

(AdminNotify_38.log,
POP3SMTP_1B2C_1_1_43FADED2_808E282E.log)

Best Regards

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other users:



Original Issue:

Customer configured the Admin Notification component on the Enterprise
level as documented in the Siebel Bookshelf. While testing the
functionality the following error messages were encountered in the
AdminNotify_xx.log file:



- SBL-ADM-09217: Error occurred in invoking the notification handler in
dll [ssemailntfy] for doing notification configured in named subsystem
[AdminEmailAlert] for component [SiebSrvr]

- Socket error 10053: An established connection was aborted by the software in your host machine.

- Unable to connect socket to port 25 on remote host crw-001.ho.u1403.unilever.com

- Socket error 10053: An established connection was aborted by the software in your host machine.



Solution:

After further investigation and reviewing all configuration steps for
the Admin Notification component, it was found that behavior was not
related to any incorrect configuration of the component.



Further investigation of the error messages logged in the AdminNotify log file revealed the following:



- An established connection was aborted by the software in your host machine.

- Error 10053 means that an established connection has been dropped.



...

Message 2

...



The first part of the error message \'software in your host machine\'
that is referred to is actually \'Winsock\' - the TCP/IP component of
Windows. The \'protocol error\' referred to in the second text is the
TCP protocol, not POP3 or SMTP, etc protocol.

10053 errors are actually quite rare usually, but there are a couple of
cases which can cause them; It could be a problem caused by an
antivirus software. Some virus scanners have been known to cause these
errors.



After excluding the Siebel component from the Antivirus software, Admin
Notification alerts were sent out correctly through Emails on port 25.



Keywords:

Socket error 10053; An established connection was aborted by the
software in your host machine; Admin Notifictaion; System Alert;



Thanks and Regards,

Applies to:

Siebel System Software - Version: 7.7.2.3 SIA [18361] to 8.1.1.4 SIA [21225] - Release: V7 to V8
IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.7.2.3 [18361] NLD Fin Svcs

Database: Oracle 8.1.7.4

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-2424543581.



*** Checked for relevance on 04-May-2011 ***

Symptoms

SBL-SMI-00033We have 2 siebel servers in our enterprise, one running on AIX which hosts the Application OM's,
and one on W2K which host Communication Server for CTI.

Upon start-up of our siebel
server(AIX), the SRProc component raises a SBL-SMI-00033 error message. This occurs consistantly
every time the Siebel server is restarted. If I then manually shutdown and restart just the
SRProc component (via the UI), then this component does not raise this error. I also notice that
upon startup of the 'Server Request Processor' component shows one open task (via server manager
UI). After manual re-start of 'Server Request Processr', there are 2 open tasks.

Please
advise what the casue of SBL-SMI-00033, and how we can correct it

Cause

Environment specific

Solution

We tried to see if this was port conflict issue, it was not. However we
found that the Encryption Type is RSA for the SRPRoc. we requested to
set it to None for SRProc and SRBroker as this typically applies to AOM.
We also ensured that after changing the parameter and starting the
server it was set to None


In customer's environment RSA encryption had been enabled at the
Enterprise level, so they Disabled encryption for SRproc and SRBoker.
This helped customer resolve the behavior.

Applies to:

Siebel System Software - Version: 7.7.2.6 [18372] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.7.2.6 [18372]

Database: Microsoft SQL Server 2000 SP3

Application Server OS: Microsoft Windows 2000 Server SP 4

Database Server OS: Microsoft Windows 2000 Server SP 4



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

Symptoms

SBL-OSD-00098, SBL-SMI-00033We just had the following error in our Production Siebel
Task 12337 of component SRBroker
has ended with error code 2100033 error string SBL-SMI-
00033: The client exited without
closing the SISNAPI connection

This type of error happened frequently when we were 7724
level. Now we are patched up to 7726(11-08-206) and we understand that this would no longer
happen with 7726.

We have crash_xxx.txt created with this error. No FDR log was created.

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers.



Customer had crash in FINSObjMgr_enu with the following information:



1. Error message in enterprise log:

ServerLog    ProcessExit    1    0    2006-11-22
10:09:19    FINSObjMgr_enu 25638     SBL-OSD-00098   Process exited with
error - Internal: The process exited abnormally and the Operating
System could not get the exit code



2. This call stack generated from UserDump, because there was no crash or *.fdr file created:

sscfcmn!CSSLocalStringManager::GetLocalString+0x1e

sscfcmn!CSSObjectBase::GetLocalString+0x1f

sscfcmn!CSSObjectBase::IsLocalString+0x26

sscfdm!CSSQuery::UsesTable+0x493

sscfdm!CSSQuery::UpdateFieldSearchSpec+0x6a1

sscfdm!CSSQuery::Parse+0xf1b

sscfdm!CSSQuery::Parse+0xef4

sscfdm!CSSQuery::ParseFieldExpr+0xd63

sscfdm!CSSQuery::GetPhysText+0x47

sscfdm!CSSSqlObj::AddSqlWhereClause+0x336

sscfdm!CSSSqlObj::AddSqlParts+0x208

sscfdm!CSSSqlObj::Execute+0x78a



3. The corresponding FINSObjMgr_enu.log log file has the following info:

ObjMgrBusServiceLog    InvokeMethod    4    0    2006-12-14
10:04:28    Begin: Business Service 'Data Validation Manager' invoke
method: 'Validate' at 30c19ad0

ObjMgrBusCompLog    Create    4    0    2006-12-14 10:04:28    Begin: construct BusComp "FINS Validation Rule Set" at 31cb33c0

ObjMgrBusCompLog    Debug    5    0    2006-12-14 10:04:28    BusComp
FINS Validation Rule Set has 22 total, 7 NJS, 2 FA, 2 LS, and 0 SeqObj
metadata fields.

ObjMgrBusCompLog    Create    4    0

ObjMgrBusCompLog    Create    4    0    2006-12-14 10:04:28    End: construct BusComp "FINS Validation Rule" at 31cbd070

ObjMgrBusCompLog    Create    4    0    2006-12-14 10:04:28    Begin: construct BusComp "FINS Validation Action" at 31cbe588

ObjMgrBusCompLog    Create    4    0    2006-12-14 10:04:28    End: construct BusComp "FINS Validation Action" at 31cbe588

ObjMgrBusCo



4. Errors seen in SRBroker and in SRProc were just a consequence of the crash in FINSObjMgr_enu.



Resolution.

With the information above, it was found that there was a DVM process
triggered on the PreWriteRecord of the Service Request BC. After
disabling it, the crash did not happen anymore.



Thank you and kind regards,



Siebel Technical Support

Applies to:

Siebel System Software - Version: 7.7.2.2 [18356] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.7.2.2 [18356]

Database: Oracle 9.2.0.6

Application Server OS: Microsoft Windows 2003 Server SP1

Database Server OS: HP-UX 11i



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

Symptoms

SBL-SVR-01014, SBL-SMI-00033, SBL-SMI-00049, SBL-CSO-01031, SBL-GEN-09103In our production environment the SRBroker component is using massive amounts of memory. We have
a maximum of 100 brokers running, and they are currently using up to 15gb of ram.

Is it
normal for the SRBroker to use this much memory? Is there some way we limit this memory
usage?

The server this component is running on has 8gb of physical ram.

I have
exported the configuration parameters for the SRBroker and attached them for your
reference.

Our production environment went live today, so this is a big issue for us. We
have already had to restart the server once, which has a negative impact on our call centre
users.

Thanks,

Cause

Product Enhancement Change Request Number 12-1BYX33J

Solution

Message 1

For the benefit of other readers :



The Customer was currently experiencing some Server Request Broker
(SRBroker) error behavior, whilst running some specialised Workflow
Processes using their Siebel Version 7.7.2.2 product release.
Specifically, the SRBroker Components were consuming a large amount of
available memory (around 15Gb RAM) causing their SRBrokers to become
"maxed out" and the users would then be experiencing some performance
challenging error behavior.



Following on from our examination of the Server Request Broker settings,
we discovered that their Siebel Object Manager parameter settings had
been changed and were different from the ones originally specified by
our Expert Services (ES) Division during their PRR (Production Readiness
Review). For example: their EAI (Enterprise Application Integration)
Object Manager MaxTasks Server parameters were set to 50, whereas
originally they had been set to 20. We were also concerned that the
Customer was running 100 SRBrokers on one Enterprise Application Server
machine, whereby the Siebel recommendation would be to run 1 SRBroker
with 100 Max MT Server Tasks instead.



We also suggested that the Customer run with the Siebel "Recycle" Factor
for their Object Manager Settings - addtional information can be
acquired from reading through Siebel Version 7.7.2.x Bookshelf >
Siebel System Administration Guide > Appendix A: Siebel Server
Components and Parameters > Generic Parameters > Parameters :



<Continued ...>

Message 2

Recycle Factor. This parameter allows an alternate method to managing
resources through the use of a rolling shutdown and restart of component
processes. The Siebel Server components, however, do not require the
recycling of processes. Use this parameter to remedy your application
only if excessive memory usage appears to exist.



The Customer also required some information regarding the use of the
Siebel Server Scheduler ? I discovered this information for them :



The Siebel Server Scheduler (SrvrSched) is a Component Definition, and
therefore runs as a Component on every Siebel Server. It is a
multi-threaded component. However, it is advisable to only run 1 per
Siebel Server. The default settings for a multi-threaded component are:



          MaxTasks=20

          MinMTServers=1

          MaxMTServers=1



As such, you will then see that MaxTasks = 1 defined at the Component
Definition level for "SrvrSched". This will ensure that 1 process, with 1
Server Task is loaded per Siebel Server. Since it exists as a
background component on each Siebel Server which Schedules Siebel Server
job execution, details can be then captured by increasing event Log
Levels.



Under normal and most circumstances, it is advisable to just leave this
alone. As it is internal task that forms part of System Task Management
and one of the first processes loaded when the Siebel Server is actually
started and is used to spawn the other components.



<Continued ...>

Message 3

I raised Product Enhancement Change Request Number 12-1BYX33J to allow
for "monitoring" of these Siebel Server Scheduler (SrvrSched) Component
Task Parameter settings. I also raised Documentation Enhancement Change
Request Number 12-1C06PMF to have this Siebel Version 7.7.2.x Bookshelf
> Siebel System Administration Guide updated with additional
information surrounding the use of this Siebel Server Scheduler.



Keywords: SRBroker, Server, Request, Settings, MT, Task, Parameters, Asynchronous, Monitor, Scheduler, Components

Applies to:

Siebel System Software - Version: 7.5.2.214 SIA [16066] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.5.2.214 [16066] Fin Svcs

Database: Oracle 8.1.7.4

Application Server OS: Microsoft Windows 2000 Server SP 3

Database Server OS: Sun Solaris 2.8



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

Symptoms

SBL-EVT-01012, SBL-SVR-00005, SBL-SVR-00029, SBL-SCC-00025,
SBL-SVR-01045, SBL-SCM-00018, SBL-SMI-00033, SBL-SRB-00061,
SBL-SRB-00041, SBL-GEN-05009, SBL-ADM-02044, SBL-ADM-02049Hello,

I have just finished upgrading from 7.5.2.214 SIA [16066] to 7.5.3 SIA
[16157].

Our configuration is:
- 1 Unix server CLSSS22: OS Solaris 2.8 with the
Entreprise Server et 1 Siebel Server 'CRMR'
- 1 Windows 2000 Service Pack 4 Server
'xxxSA2048'
- Oracle version 9.2.0.2

When I go on the server admin screens, I can see
that the server server 'xxxSA2048' is in status "Echec de la connexion" (connexion failed). If i
click on this server, i receive the following error "SBL-ADM-02044: Aucune connexion trouvée sur
les serveurs actifs.".

By server manager, i have the following
message:
"decibel@clsss22:/appsiebel/siebel/siebsrvr/bin$ srvrmgr /e CRMR /g CLSSS22:2323 /u
SADMIN /p
SADMIN            
Connected
to 1 server(s) out of a total of 2 server(s) in the enterprise
srvrmgr> list
server
SBLSRVR_NAME HOST_NAME
INSTALL_DIR                 SBLMGR_PID
SV_DISP_STATE SBLSRVR_STATE
START_TIME           END_TIME
SBLSRVR_STATUS                 
------------
--------- -------------------------- ---------- ------------- ------------- -------------------
-------- ------------------------------

CRMR          clsss22    /appsiebel/siebel/siebsrvr
15564       Running       
Running        2003-10-07
11:22:27            7.5.3 [16157]
LANG_INDEPENDENT
xxxsa2048     xxxsa2048
E:\sea752\siebsrvr                     
Connect failed"

Thank you for your help

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers, the 'Connect failed' error was caused
by a network problem. The new Windows 2000 Server 'xxxSA2048' (masked)
was not declared in the DNS server. After setting the correct value to
DNS and restarting the machine, the connection to server was
successfully established.



The error messages received were as follows in the Siebel Server Log files.



SBL-SCC-00025; SBL-SVR-00029; SBL-ADM-02049; SBL-ADM-02044;
SBL-EVT-01012; SBL-SVR-00005; SBL-SVR-01045;
SBL-GEN-05009;SBL-SMI-00033; SBL-SRB-00061; SBL-SRB-00041; SBL-SCM-00018



The following Supportweb Knowledge items were also suggested:



FAQ 1323 which discusses how to troubleshoot error ADM-02044.

FAQ 1187 which discusses how to troubleshoot error ADM-02088.

FAQ 1399 which discusses how to troubleshoot error NET-01003.





-Siebel Technical Support



Keywords: DNS Server, Connect Failed, list server, SBL-SCC-00025,
SBL-SVR-00029, SBL-ADM-02049, SBL-ADM-02044, SBL-EVT-01012,
SBL-SVR-00005, SBL-SVR-01045, SBL-GEN-05009, SBL-SMI-00033,
SBL-SRB-00061, SBL-SRB-00041, SBL-SCM-00018

Applies to:

Siebel CRM - Version: 7.5.3 [100] to 8.1.1.7 [21238] - Release: V7 to V8
Information in this document applies to any platform.

Product Release: V7 (Professional)



Application Server OS: Microsoft Windows 2000 Server SP 4

Database Server OS: Microsoft Windows 2000 Server SP 4

Symptoms

It was reported that there were problems using drag drop
functionality in the Siebel application. When the user was trying
to save an attached document, the system was displaying the following
error message:

Session
Warning: The server you are trying to access is either busy or
experiencing difficulties. Please close the Web browser, open a new
browser window, and try logging in again.

After this error, the user is usually logged out of the application.

The issue was only present in the thin client and could not be reproduced in the dedicated client.


The same error was observed in the thin client using both DB authentication and ADSI authentication.

The following messages were displayed in the SWE logs:

ProcessPluginRequest    ProcessPluginRequestError    1    0    2006-04-18
17:15:22     5116: [SWSE] RPC coming in without a user session

ProcessPluginRequest    ProcessPluginRequestError    1    0    2006-04-18
17:15:22     5116: [SWSE] Failed to obtain a session ID. NOT OK

ProcessPluginRequest    ProcessPluginRequestError    1    0    2006-04-18
17:15:22     5116: [SWSE] Set Error Response (Session: Error: 00065535
Message: NOT OK)

The following error messages may also be seen for the end user or in the logs related to this issue:
SBL-UIF-00401,
SBL-SCR-00141, SBL-DAT-00215, SBL-DAT-00712, SBL-SVR-01051,
SBL-SCM-00022, SBL-SMI-00033, SBL-NET-01023, SBL-BPR-00125,
SBL-BPR-00151

Cause

The cause of this issue was determined to be an underscore "_" character in the naming of the servers.

Solution

The workaround for this issue is to use the IP address of the server instead of the server name.

Document 477993.1  has additional information regarding problems using a dash/hyphen in the Siebel Server Name.



Document 477993.1 was previously referred to as Alert 1067.

References

NOTE:477993.1 - Siebel Server Failures Due to Hyphen Character in Machine Hostname and in the Siebel Server Name

Applies to:

Siebel System Software - Version: 7.8.2.2 [19219] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.8.2.2 [19219]

Database: Oracle 9i

Application Server OS: Microsoft Windows 2003 Server SP1

Database Server OS: Sun Solaris 9



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

Symptoms

SBL-SVR-01015, SBL-SVR-01043, SBL-SMI-00033, SBL-NET-01034, SBL-NET-01033, SBL-ADM-01044, SBL-SCB-00015, SBL-SCB-00011Hi,

Each night a cold DB backup is taken on each environment. This is affecting a number
of components on the Siebel server:

Transaction Processor
Transaction
Merger
Transaction Router
Server Tables Cleanup

These components need to be
restarted each morning as the backup is affecting them. I decided to use scripts to shutdown the
siebel server 15 mins before backup is taken and another to restart it in the morning. I have
tested these script on one environment and this works fine. On another environmnet the shutdown
script appears to hang (i.e batch job does not complete). All the parameters are correct as the
command would not run otherwise. I have attached the script and the log files at the time it
executed (01:45). As you can see from the log file at 06:00 created after the startup script is
executed, the server is still shutting down. Can you please inform me what the issue
is?

Kind regards

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers:



The customer's script:



D:\sea78\test\siebsrvr\BIN\srvrmgr /g UKGateway /e siebtest /s SiebTest1 /u sadmin /p password /c "shutdown appserver SiebTest1"



In review of the customer's component log files, we could see that there
was a problem with one or more components shutting down. As stated in
SupportWeb SR 38-1147657941 [Siebel Servers stick in "Shutting down"
state], the "shutdown appserver" command issued from the Server manager
command-line is a synchronous process, thus the command will block until
all tasks in the server have exited. There could be a problem stopping
one or more components, caused either by the components themselves, or
caused by the synchronous nature of the shutdown process (ie. one
component is waiting on a response from another component, or the Siebel
server - that may have already been shutdown).



The customer was recommended to use the Windows command, net stop. The net stop command is used as follows:



net stop <service>



For example:



net stop SiebSrvr



Which would stop the service called SiebSrvr.



Assuming you do not have any problem stopping your Siebel Server service
using the Windows' Services utility, then you should not experience a
problem with using the net stop command to stop the Siebel Server
service. You can schedule the command using the Windows command, at.



This information resolved this for the customer.



Regards,

Applies to:

Product Release: V7 (Enterprise)

Version: 7.5.3 [16157]

Database: Microsoft SQL Server 2000 SP3

Application Server OS: Microsoft Windows 2000 Advanced Server

Database Server OS: Microsoft Windows 2003 Server



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

Symptoms

We have recently applied the 7.5.3.14 patch to our 7.5.3 installation. We have patched both our DEV and TEST instances.



In our TEST environment only, the only environment with Communications
Management enabled, we are seeing new log files for smart answer and
SRBroker being created about every couple seconds. This has only been an
issue since the application of the 7.5.3.14 patch. The smart answer
files show an error of "Smart Response module is not licensed" and the
SRBroker files show an error of " [TCPIP-server] recv() failed for
sd=2088 (err=10054 | A existing connection was forcibly closed by the
remote host (peer).)



GenericLog    GenericError    1    2006-02-03 22:50:53    (smimtses.cpp
18(352) err=2100033 sys=0) SBL-SMI-00033: The client exited without
closing the SISNAPI connection"



Do you have any suggestions to resolving this, other than setting the
smart answer component to disabled? How can I verify our license
contains this module for comm mgmt?



Why are these log files being generated only AFTER applying the patch to
the application? it was running with no issues before the patch.



Thanks

Solution

Message 1

For the benefit of others:



After a recent upgrade, the smart answer functionality of communications
server seemed to have been disabled. It was later discovered that the
customer was not licensed for this functionality. However, the issue
became stopping the logging from occurring, for a disabled component.



To ensure logging is inactive for a component:



There are a couple of areas to check, to make sure that logging is no longer active...



First, ensure that the component is completely inactive:



Administration - Server Management > Components > Smart Answer Manager



Please make sure that the component is both offline and Shutdown



Next: Verify the logging event levels...



Administration - Server Configuration > Components > Smart Answer Manager > Events (Tab)



Please make sure that all of the event levels are 1 or zero. 1 is the
default, and will only produce log entries for component Errors. 0 will
only produce errors for Fatal events. You can also check the other
components, such as SRBroker and CommMgr. Specifically, if there are any
components where you have increase event logging, please return those
to 1.



Best regards,



Siebel Technical Support



Keywords: continuing continuous logging wont stop repeating logs