‏הצגת רשומות עם תוויות SBL-GEN-*****. הצג את כל הרשומות
‏הצגת רשומות עם תוויות SBL-GEN-*****. הצג את כל הרשומות

יום רביעי, 3 באוקטובר 2012

SBL-GEN-09603: Unable to connect to named pipe





Applies to:


Siebel Remote - Version 8.0.0.6 SIA [20423] to 8.1 [21039] [Release V8]
Information in this document applies to any platform.

***Checked for relevance on 30-Aug-2012***


Symptoms


We are trying to run the Database Extract for our developers. It
worked for two users but is not working for other users.  It looks like
it uses a lot of I/O on the DB server and finally crashed.


The following error messages are found:



GenericLog GenericError 1 000000054a0405f4:0 2009-05-08 14:35

:32 (scfmsgfac.cpp (805) err=9603 sys=0) SBL-GEN-09603: Unable to connect to

named pipe.



ScfMsgFacLog SCFMsgFacError 1 000000054a0405f4:0 2009-05-08 14:35

:32 SBL-GEN-09603: Unable to connect to named pipe.





Cause


The cause of this issue is due to problems with Server Database.



Solution



The following are the steps to fix the issue:

1. Run the Db statistics to keep the stats up-to-date.

2. Remove “dicdata.dat” from the Siebel server

3. Start the application and login as ‘SADMIN’ user

4. Run new database (GenNewDB)

5. Perform the extract for the developers













Applies to:


Siebel System Software - Version: 8.0.0.2 [20412] and later   [Release: V8 and later ]
HP-UX Itanium



Symptoms



Crash of Server task persistence component is observed.  If it is
reaching more than 1 GB and crashed the component, you may see the
following lines logged:



ScfMsgFacLog SCFMsgFacError 1 00000003492d0a5c:0 2008-11-26 17:22:50 SBL-GEN-09603: Unable to connect to named pipe.

GenericLog
GenericError 1 00000003492b6e7e:0 2008-12-01 18:29:00 (ipc.cpp (597)
err=1181399 sys=0) SBL-NET-01751: The system was unable to allocate
sufficient memory for the specified operation.
IPCLog IPCError 1
00000003492b6e7e:0 2008-12-01 18:29:00 [6] Error occured while
reading/decoding a message from the pipe, rc2 = 1181399, sysError = 0,
msgBuf = "SBL-NET-01751: The system was unable to allocate sufficient
memory for the specified operation."


This is causing crash
of server task persistence component on the Siebel server and requires
restart of Siebel service to restart this background component.



Cause


Cause is due to missing OS patches required for the server platform to run Siebel.


Solution



1. Perform a Siebel EVT output on the server. Refer to Environment Verification Tool (EVT) Overview (Doc ID 477105.1).


2. Ensure that all server requirements are met.


In this case, the HP server is missing the following OS patches as
mentioned in the Siebel System Requirements and Supported Platforms
Guide. Once applied, the crash no longer happen.
PHSS_31853
PHSS_31851
PHSS_32765
PHSS_31855



References


NOTE:477105.1 - Environment Verification Tool (EVT) Overview

NOTE:567662.1 - Error message in Siebel Server component log files: SBL-GEN-09603: Unable to connect to named pipe










Applies to:


Siebel CRM - Version: 8.0 [20405] to 8.0.0.10 SIA [20436] - Release: V8 to V8
Information in this document applies to any platform.



Goal



What is the reason for the following error message in many of the Siebel 8.0 SIEBEL_ROOT/siebsrvr/log files?

"SBL-GEN-09603: Unable to connect to named pipe".



Solution



This is a known defect in Siebel 8.0 where SBL-GEN-09603 occurs in the component log files.

The error is benign and can be ignored.










SBL-GEN-09103: Parameter value was never set (i.e. is null)





Applies to:


Error Message Area:Generic - GEN

Version:Siebel 8.1


Purpose


This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-GEN-09103: Parameter value
was never set (i.e. is null)


Scope


This document is informational and intended for any user.


SBL-GEN-09103: Parameter value was never set (i.e. is null)



Explanation


This is informational only and is not an error.


Corrective Action


This is informational and does not require an action.










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:





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










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.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.7.2.4 [18365] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (MidMarket)

Version: 7.7.2.4 [18365] MME

Database: Microsoft SQL Server 2000 SP3

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



Symptoms


SBL-SWP-00121, SBL-OMS-00102, SBL-SVR-01014, SBL-GEN-09103, SBL-NET-01023Hello Siebel Support,

We are trying to set up a new development environment to be used
during
the Upgrade from Siebel 2000 to Siebel 7.7.2.4

We have followed the suggested
Road map in the Upgrade Guide but have
made some changes. Up until the Upgrep step, the road
map has been followed.
However, the client wants to reapply all functionality from scratch.
After the Upgrade Siebel Database Schema (upgrep) we renamed the repository created during the
upgrep named New Siebel Repository to Siebel Repository under the assumption that this is the
Vanilla 7.7 repository. We then DLL-synchronized and created a new srf from the synchronized
repository. Thus we have not yet performed a repository merge as this is was deemed unnecessary
as we are applying a Vanilla repository.

However we now are unable to login using the thin
client. I have saved
all log files I could find and also the configuration file for the Siebel
Server and the siebns.dat file.

In the SWSE log files I keep getting the following
error:
3912: [SWSE] Failed to obtain a session ID. Business component '%1' is not
defined.
(Please see the rest of the log files for a complete log.)

I have noticed that
there is no Enterprise directory under the siebserver. Usually
there is one that contains log
files for the particular Enterprise. Is this created
at runtime when the siebel server is able
to log in or is this an error by the setup?

** Continued **






Cause


Configuration/ Setup


Solution



Message 1


For the benefit of other users:



Original Issue:

After an upgrade from Siebel version 2000 to Siebel version 7.7.2.4, customer was no able to connect using the Web Client:



The SWSE log file included the following error message:



3912: [SWSE] Failed to obtain a session ID. Business component '%1' is not defined.



Solution:

Investigating the Object Manager log file revealed that the following
SQL Statement could not build correctly during the login process:



SELECT....

      T1.PH_COUNTRY_CD,

      T1.TM_AMPM_PSTN_CD,

      T1.TXT_WRTNG_DRCTN_CD

   FROM

       dbo.S_LOCALE T1

          LEFT OUTER JOIN dbo.S_LOCALE_LANG T2 ON T1.ROW_ID = T2.PAR_ROW_ID AND T2.LANG_ID = ?

   WHERE

      (T1.LOCALE_CODE Import file is not a valid Siebel object export file.



The file being imported is missing the field '%1' in BusComp '%2' which is part of the user key. ?)

   ORDER BY

      T1.LOCALE_CODE

This statement has been identified in all OM log files that have failed connecting to the Web Client.



Such behavior is most likely caused by a wrong installation of the
Siebel Software or different Siebel Components that are installed with
different MR levels. After further investigation it has been determined
that the behavior has been caused by a wrong installation of a language
pack.



Reinstalling the environment solved the above described behavior



Keywords:

SQL Statement, Login failure, “Import file is not a valid Siebel object export file”








Applies to:


Siebel Anywhere - Version: 7.5.3.11 [16199] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (MidMarket)

Version: 7.5.2.100 [15252] MME

Database: Microsoft SQL Server 7.0 SP 3

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



Symptoms


SBL-SMI-00077, SBL-GEN-09103Hi,
My developers in India have been trying to extract remote clients in vein after an
upgrade of the development env from 6.0.1 MME to 7.5.2 MME.

FYI, upgrade process was error
free. The only thing that was done outside Siebel's bookshelf was that they accidentally deleted
old Employee records from S_PARTY & recreated newer ones.

I have attached the log
file of the extraction error. Please advise on how we can overcome this issue.






Cause


Configuration/ Setup


Solution



Message 1


For the benefit of other readers, Database Extract was failing with the following errors:



"GEN-09103: Parameter value was never set (i.e. is null)"

"Warning: Unable to recognize client version(7.5.2)"

"Assuming version is Siebel99"



and then:



"Part 4: Finished deleting from temporary tables."

"Invalid Byte Order."

"DXTOCCommonOpen: open of E:\Siebel753\siebsrvr\docking\DBXTRACT\31041420\58419\entrpse.toc for read failed"

"CDXTOCCopyFile: Could not open HSrcDXTOC"



The reason for this failure was the following parameter:



Parameter Name = Specify the mobile client version

Alias = Clientversion



was set to "7.5.2" instead of "2000."



Once this was changed to "2000" Database Extract completed successfully.



- Siebel Support


























SBL-GEN-05043: The specified user does not have the proper privileges to connect to the name server.





Applies to:


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

Error Message Area:Generic - GEN

Version:Siebel 8.1



Purpose


This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-GEN-05043: The specified user
does not have the proper privileges to connect to the name server.


Scope


This document is informational and intended for any user.


SBL-GEN-05043: The specified user does not have the proper privileges to connect to the name server.



Explanation


Need a Siebel administrator username and password to connect to the Siebel gateway server.
For example, "SADMIN" is an example of administative user account.


Corrective Action


Please provide valid administrator username and password to access the gateway server.










Applies to:


Siebel eClinical - Version 8.1.1.5 SIA [21229] and later
Information in this document applies to any platform.



Symptoms


After server reboot unable to start the siebel service.


Observed the below errors in NameServer.log file:


2009-09-18 16:14:49 select T2.NAME from
SIEBEL.S_PER_RESP T1, SIEBEL.S_RESP T2, SIEBEL.S_USER T3 where
T1.RESP_ID=T2.ROW_ID AND T1.PER_ID=T3.PAR_ROW_ID AND T3.LOGIN='SADMIN'

2009-09-18 16:14:49End 10 Worst Performing Queries ***********

2009-09-18 16:14:49 (SQLFreeEnv) Env Handle: 812926856, Time: 0.004ms

2009-09-18 16:14:49 Invoking SecurityGetRoles for user sadmin.

2009-09-18 16:14:49 user sadmin has 246 responsibilities.

2009-09-18 16:14:49 (client.cpp (325) err=5043 sys=0) SBL-GEN-05043: The
specified user does not have the proper privileges to connect to the
name server.




Cause


SADMIN user got deleted.





Solution


After restoring the SADMIN user and restarting the gateway along with Siebel server resolved the issue.




References


NOTE:944161.1 - RECEIVING ERROR MESSAGE WHEN STARTING THE SIEBEL SERVER OR SRVRMGR












Symptoms



Siebel 8.1.1 new installation was working fine.
After migrate database from previous Siebel version, gateway was starting, but srvrmgr was not working.


Cause


We have verified SADMIN was correctly connecting to database from Gateway machine.


Solution



We checked all DB2 settings and connection were working from Gateway.
But we still had this error message in the gateway log:

2009-09-18
16:14:49 select T2.NAME from SIEBEL.S_PER_RESP T1, SIEBEL.S_RESP T2,
SIEBEL.S_USER T3 where T1.RESP_ID=T2.ROW_ID AND T1.PER_ID=T3.PAR_ROW_ID
AND T3.LOGIN='SADMIN'
2009-09-18 16:14:49End 10 Worst Performing Queries ***********
2009-09-18 16:14:49 (SQLFreeEnv) Env Handle: 812926856, Time: 0.004ms
2009-09-18 16:14:49 Invoking SecurityGetRoles for user sadmin.
2009-09-18 16:14:49 user sadmin has 246 responsibilities.
2009-09-18
16:14:49 (client.cpp (325) err=5043 sys=0) SBL-GEN-05043: The specified
user does not have the proper privileges to connect to the name server.
2009-09-18 16:14:49 515: [TCPIP-server] recv() failed for sd=-1 (err=9 | Bad file number)
2009-09-18 16:14:49 515: [TCPIP-server] send() failed for sd=-1 (err=9 | Bad file number)


Running
the above query against both the custom and vanilla databases showed
that the Siebel Administrator Reponsability was missing. It existed for
other users but was missing for Sadmin user. After adding the Siebel
Administrator to the SADMIN user, the Gateway started correctly and
srvrmgr ran correctly.





 

SBL-GEN-05009: Unable to connect to gateway server



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:Generic - GEN

Version:Siebel 7.7



Purpose


This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-GEN-05009: Unable to connect
to the gateway server.





Scope


This document is informational and intended for any user.





SBL-GEN-05009: Unable to connect to the gateway server.



Explanation


Could not establish a connection to the gateway.



Below is a list of common causes for this error message:



1. The Siebel Gateway Name Server service may not be running.



2. Incorrect entries in the connect string (in the
SWEAPP_ROOT\bin\eapps.cfg file) for the gateway server host name or port
number.



3. The Siebel Server service may not be running.



4. Siebel Web Server Extension reports this error on Solaris 2.8 with
iPlanet as the web server with certain kernel versions and under heavy
load. Please refer to Doc ID 477725.1
for more information about the affected Siebel versions and Solaris
kernel versions. The cause of this error is due to the Solaris hard
limit on the number of file descriptors that can be opened per process
with the fopen function (256).



5. Incorrect values for the DSConnectString and DSGatewayAddress named
subsystem parameters in Siebel versions 7.5.3.x or earlier would cause
this error to appear when users try to access the Server Administration
screens.


Corrective Action


Verify that the gateway is running and restart it if necessary.



Below is a list of corrective actions to try to resolve this error message:



1. Ensure the Siebel Gateway Name Server is running. Refer to the following Siebel Bookshelf reference:
Siebel
System Administration Guide > Administering Server System Services
> Administering the Siebel Gateway Name Server System Server >
Siebel Gateway Name Server System Service on (Windows OR UNIX).



2. Correct the ConnectString parameter In the SWEAPP_ROOT\bin\eapps.cfg
file (on UNIX in the SWEAPP_ROOT/bin/eapps.cfg) which contains the
gateway server host name and port number.



ConnectString = siebel.TCPIP.none.None://dedwards5:2320/Siebel/SalesCEObjMgr_enu/SiebSrvr1



NOTE: In the above example, dedwards5 is the gateway server host name
and 2320 is the port number. SalesCEObjMgr_enu is the name of the
component and SiebSrvr1 is the name of the Siebel Server.



For information about the ConnectString parameter, refer to the following Siebel Bookshelf references:

a. Siebel version 7.5.3 > Siebel Server Installation Guide for (UNIX
or Windows) > Structure of the eapps.cfg File > Editing the Web
Server Extension Configuration File.

b. Siebel version 7.7 > Siebel System Administration Guide > Structure of the eapps.cfg File.
c.
Siebel version 8.x > Siebel Installation Guide > Installing and
Configuring the Siebel Web Server Extension > Postinstallation Tasks
for the SWSE and the Web Server >
Editing the SWSE Configuration File (eapps.cfg)



3. Ensure the Siebel Server is running. Refer to the following Siebel Bookshelf reference:
Siebel
System Administration Guide > Administering Server System Services
> Administering the Siebel Server System Service > Siebel Server
System Service on (Windows OR UNIX).



4. Ensure the Solaris 2.8 with iPlanet as the web server is running
kernel patch 108528-24 or later. If you are unable to apply this kernel
patch, make sure the nscd daemon is running which seems to temporarily
work around this behavior. For more information refer to Doc ID 477725.1 .



5. Check the values for the DSConnectString and DSGatewayAddress named
subsystem parameters. Try to ping the machine using these values. In
some cases, try the fully qualified name for the Siebel Gateway host
name like 'abc.xyz.us'.








Applies to:


Siebel System Software - Version: 7.0.4 [14068] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)
Oracle Solaris on SPARC (32-bit)

Solaris Operating System (SPARC 64-bit)Solaris Operating System (SPARC 32-bit)

Area(s):System Administration

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

Database(s):All Supported Databases

App Server OS(s):Solaris

Latest release tested against:V7 (Enterprise)

Keywords:SBL-GEN-05009, Unable to connect to gateway server, Solaris, iplanet, kernel, SBL-UIF-00272



This document was previously published as Siebel Alert 996.



Description


When running Siebel version 7.0.x and 7.5.x on Solaris 2.8 with
iPlanet as the web server, iPlanet's httpd process makes calls to
gethostbyname function, which is implemented using the fopen function in
Solaris kernel patches prior to 108528-24.

Solaris has a hard
limitation on the number of file descriptors that can be opened per
process with the fopen function (256). When the httpd process runs out
of available file descriptors, users will be unable to log in to the
Siebel application and errors will be reported in the SWE log file.



Solaris has a name service cache daemon called nscd that runs by
default. When the nscd daemon is running, it caches the hostname
details. When gethostbyname is called, it gets this data from this
cache. Having the nscd daemon running will prevent the above behavior.
Please note that the above behavior does not occur when Resonate is
being used in the environment.



Likelihood of Occurrence


This specific behavior has been seen under the following conditions:



  • Using Siebel version 7.0.x or 7.5.x on Solaris with an iPlanet web server

  • The iPlanet web server is running kernel patch 108528-23 or lower.

  • The nscd daemon is not running.

  • Resonate is not being used.

  • The servers are under heavy load.





Possible Symptoms


Siebel Web Clients will be able to log in and work normally until all
file descriptors are exhausted. After this, all new login attempts will
receive the following error, even though the correct username and
password have been supplied:


SBL-UIF-00272: The user ID or password that you entered is incorrect.
Please check the spelling and try again.

Analysis of the SWE log files named swenesPID.log (where PID is the
UNIX process ID of the web server) found in the SIEBEL_ROOT/swe/log
directory will show the following error:



GenericLog GenericError 1 2003-11-26 21:28:16 NSC -
ErrCode 5009 SysErr 0
GenericLog GenericError 1 2003-11-26 21:28:16
(scbconn.cpp 5(107) err=5009 sys=0) SBL-GEN-05009 Unable to
connect to gateway server





Please note that if some users log out of the application, which
frees up some file descriptors, the behavior will rectify itself for a
short time. However, it will reoccur if the file descriptors become
exhausted again.



Workaround or Resolution


One possible workaround for this behavior is to make sure that the nscd daemon is running on the iPlanet web server machine.


With Solaris kernel patch 108528-24 and above, the implementation
of gethostbyname has been changed by Sun Microsystems, so the 255 file
descriptor limit is no longer applicable. To resolve this behavior apply
the Solaris kernel patch 108528-24 or above, which can be downloaded
from the following link, to all web server machines running the iPlanet
web server.


SunOS 5.8: kernel update patch 108529

At the page accessed from the above link, search for the description below:


4353836 if more than 255 file descriptors are already open then gethostbyname fails










Applies to:


Error Message Area:Generic - GEN

Version:Siebel 7.5.3


Purpose


This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-GEN-05009: Unable to connect
to gateway server




Scope


This document is informational and intended for any user.




SBL-GEN-05009: Unable to connect to gateway server



Explanation


Could not establish a connection to the gateway.



Below is a list of common causes for this error message:



1. The Siebel Gateway Name Server service may not be running.



2. Incorrect entries in the connect string (in the
SWEAPP_ROOT\bin\eapps.cfg file) for the gateway server host name or port
number.



3. The Siebel Server service may not be running.



4. Siebel Web Server Extension reports this error on Solaris 2.8 with
iPlanet as the web server with certain kernel versions and under heavy
load. Please refer to Alert 996 for more information about the affected
Siebel versions and Solaris kernel versions. The cause of this error is
due to the Solaris hard limit on the number of file descriptors that can
be opened per process with the fopen function (256).



5. Incorrect values for the DSConnectString and DSGatewayAddress named
subsystem parameters in Siebel versions 7.5.3.x or earlier would cause
this error to appear when users try to access the Server Administration
screens.


Corrective Action


Verify that the gateway is running and restart it if necessary.



Below is a list of corrective actions to try to resolve this error message:



1. Ensure the Siebel Gateway Name Server is running. Refer to the following Siebel Bookshelf references:

a. Siebel version 7.7 > Siebel System Administration Guide >
Administering Server System Services > Administering the Siebel
Gateway Name Server System Server > Siebel Gateway Name Server System
Service on (Windows OR UNIX).

b. Siebel version 7.5.3 > Siebel Server Administration Guide >
Server System Services > Administering the Siebel Gateway System
Service > Siebel Gateway System Service on (Windows OR UNIX).



2. Correct the ConnectString parameter In the SWEAPP_ROOT\bin\eapps.cfg
file (on UNIX in the SWEAPP_ROOT/bin/eapps.cfg) which contains the
gateway server host name and port number.



ConnectString = siebel.TCPIP.none.None://dedwards5:2320/Siebel/SalesCEObjMgr_enu/SiebSrvr1



NOTE: In the above example, dedwards5 is the gateway server host name
and 2320 is the port number. SalesCEObjMgr_enu is the name of the
component and SiebSrvr1 is the name of the Siebel Server.



For information about the ConnectString parameter, refer to the following Siebel Bookshelf references:

a. Siebel version 7.5.3 > Siebel Server Installation Guide for (UNIX
or Windows) > Structure of the eapps.cfg File > Editing the Web
Server Extension Configuration File.

b. Siebel version 7.7 > Siebel System Administration Guide > Structure of the eapps.cfg File.



3. Ensure the Siebel Server is running. Refer to the following Siebel Bookshelf references:

a. Siebel version 7.7 > Siebel System Administration Guide >
Administering Server System Services > Administering the Siebel
Server System Service > Siebel Server System Service on (Windows OR
UNIX).

b. Siebel version 7.5.3 > Siebel Server Administration Guide >
Server System Services > Administering the Siebel Server System
Service > Siebel Server System Service on (Windows OR UNIX).



4. Ensure the Solaris 2.8 with iPlanet as the web server is running
kernel patch 108528-24 or later. If you are unable to apply this kernel
patch, make sure the nscd daemon is running which seems to temporarily
work around this behavior. For more information refer to Alert 996.



5. Check the values for the DSConnectString and DSGatewayAddress named
subsystem parameters. Try to ping the machine using these values. In
some cases, try the fully qualified name for the Siebel Gateway host
name like 'abc.xyz.us'.






Applies to:


Siebel System Software - Version: 7.7.2 [18325] and later   [Release: V7 and later ]
HP-UX Itanium

Product Release: V7 (Enterprise)

Version: 7.7.2 [18325]

Database: Oracle 9.2

Application Server OS: HP-UX 11.11

Database Server OS: HP-UX 11.11



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



Symptoms


SBL-GEN-05004, SBL-ICF-00018

Our database file was filled up around 1:07AM last night possibly
causing our Siebel Server to fail. While troubleshooting this morning,
we’ve shutdown the Siebel Server and Gateway Server and received (hand
translated from Chinese) “Not Started: Unable to copy service item files
into memory” when attempting to restart Gateway server.

The database size has since been extended, however, we still continue to receive this error.

We have tried the following:
- Delete and rebuild svc* file
- Verify all files are owned by Siebel user (and have read write permission to siebns.dat)
- Tried using an older version of siebns.dat
- Verify port 2320 is available

I have uploaded:
- screen shot of the error (in Chinese)
- Gateway logs
- enterprise server log

Any suggestions would be much appreciated



Cause


Configuration/ Setup


Solution


For the benefit of other users, the customer received the following
error message when attempting to restart their Siebel Gateway Server
“Not Started: Unable to copy service item files into memory”

Following
the failed restart, they recreated the *.svc files by running a siebctl
command but still could not start the Siebel Gateway Server and
received “NameSrvr - [5018] (No message)” errors in the NameSrvr.log.

Summary:

Siebel
does not recommend that customers should re-create the Siebel Gateway
or Server services if there are problems starting any service. The
reason Siebel does not recommend re-creating the Siebel Services is
because they could be created incorrectly which then cause other issues.
Customers are advised to raise a Service Request with Siebel Technical
Support if assistance is required diagnosing why a Siebel service failed
to start.

Further research found the siebctl syntax the customer
used to create the Gateway Server service is the one specified in
Service Request #38-1960105998 to create the Siebel Server service. The
steps used to resolve this Service Request was:



1)    Ensure the Siebel Server Service and Web Server services are offline
2)    Run gtwysrvr\siebenv.sh
3)    Stop the Gateway Server service (stop_ns)
4)    Copy svc.gtwyns. in $SIEBEL_ROOT/gtwysrvr/sys to backup.svc.gtwyns.old
5)    Delete the svc.gtwyns. file
6)    Run
the command siebctl -S gtwyns -a -g "/f $SIEBEL_ROOT/sys/siebns.dat /t
2320" substituting the port number for the Gateway Server service in
place of 2320.
7)    Start the Siebel Gateway service (start_ns)
8)    Type list_ns












Applies to:


Siebel CRM - Version: 8.1.1 SIA [21111] - Release: V8
Information in this document applies to any platform.



Symptoms


Unattended Siebel Server configuration fails.
o Gateway has already been installed/configured and is up and running
o Database has also been installed
o Same error was encountered during a subsequent attempt to run the installation manually


Cause


It was established that the Siebel Server had been installed on an unsupported Operating System.

o Using the Strace debugging tool to track system calls, it was established that an incorrect OS platform was in use:
sysname="Linux",
nodename="apn0.ccbs6a.net", release="2.6.9-67.ELsmp", version="#1 SMP
Wed Nov 7 13:56:44 EST 2007", machine="x86_64"


[siebel@apn0
bin]$ strace -f -v -o /tmp/server.confignew.log ./ssincfgw
-is:javaconsole -console -args LANG=enu MODE=LIVE
MODEL_FILE=/opt/siebel/siebsrvr/admin
n/siebel_server_sia.scm

Initializing InstallShield Wizard........


Extracting Bundled JRE.[ Process PID=24822 runs in 32 bit mode. ]
[ Process PID=24705 runs in 64 bit mode. ]
[ Process PID=24824 runs in 32 bit mode. ]
[ Process PID=24826 runs in 64 bit mode. ]
[ Process PID=24824 runs in 32 bit mode. ]
[ Process PID=24826 runs in 64 bit mode. ]
[ Process PID=24824 runs in 32 bit mode. ]

and then,

21156
execve("/bin/awk", ["awk"..., "END { i=index(a, \"-is:in\"); prin"...,
"a=-args"...], ["SYSTEM_ARCHIVE=/mnt/global_backu"...,
"EV_AGENTID_DIRECTORY=/etc/Navisp"...,
"ORACLE_INSTALL=/opt/cbuPlatform_"..., "HOSTNAME=apn0.ccbs6a.net"...,
"ASM_HOME=/opt/oracle/product/10."..., "SHELL=/bin/bash"...,
"TERM=xterm"..., "HISTSIZE=1000"..., "SYSTEM_HOME=/home/ccbs"...,
"SSH_CLIENT=131.207.209.109 4846 "...,
"BPEL_HOME=/opt/oracle/jdevstudio"..., "ORACLE_CLUSTERWARE_NODES=dbn-0
d"..., "SYSTEM_PROVIDER=nokiasiemensnetw"...,
"SYSTEM_VAR=/var/opt/nokiasiemens"..., "SSH_TTY=/dev/pts/2"...,
"SYSTEM_DATA=/var/opt/nokiasiemen"...,
"ANT_HOME=/opt/oracle/jdevstudiob"..., "USER=siebel"...,
"SIEBEL_WEB_SERVER_EXTENSION_NODE"...,
"JRE_HOME=/usr/java/jdk1.6.0_06/j"...,
"LS_COLORS=no=00:fi=00:di=00;34:l"...,
"LD_LIBRARY_PATH=/opt/siebel/sieb"..., "ORACLE_SID=CRM"...,
"ORACLE_CLIENT_NODES=apn0 apn1 ap"..., "SIEBEL_SERVER_NODES=apn0"...,
"ORACLE_BASE=/opt/oracle"..., "ORACLE_EBS_NODES=apn2 apn3"...,
"SYSTEM_RUN=/var/opt/nokiasiemens"...,
"PATH=/usr/local/bin:/bin:/usr/bi"..., "MAIL=/var/spool/mail/siebel"...,
"TNS_ADMIN=/etc/opt/nokiasiemensn"..., "SYSTEM_TYPE=CCBS"...,
"ORACLE_AIA_NODES=apn4"..., "PWD=/opt/siebel/siebsrvr/bin"...,
"INPUTRC=/etc/inputrc"..., "DBN_NODES=dbn-0 dbn-1"...,
"JAVA_HOME=/usr/java/jdk1.6.0_06"...,
"SYSTEM_STORAGE_MULTIPATHING_SW=D"..., "SYSTEM_CLASSPATH="...,
"LANG=en_US.UTF-8"..., "ORACLE_WEB_SERVER_NODES=apn0"...,
"SYSTEM_USERGROUP=ccbs"..., "HOME=/home/siebel"..., "SHLVL=2"...,
"SYSTEM_SW_BUILD_LOCATION=local"...,
"SYSTEM_STORAGE_ARRAY=emc-via-fc"..., "SYSTEM_USER=ccbs"...,
"SYSTEM_LOG=/var/opt/nokiasiemens"..., "LOGNAME=siebel"...,
"SIEBEL_GATEWAY_NODES=apn0"..., "SSH_CONNECTION=131.207.209.109 4"...,
"CLASSPATH=/opt/siebel/siebsrvr/b"..., "ORACLE_SOA_NODES=apn4"...,
"LESSOPEN=|/usr/bin/lesspipe.sh %"...,
"SYSTEM_ETC=/etc/opt/nokiasiemens"..., "APN_NODES=apn0 apn1 apn2 apn3
ap"..., "SYSTEM_OPT=/opt/nokiasiemensnetw"...,
"DISPLAY=localhost:10.0"..., "ORACLE_DATABASE_NODES=dbn-0 dbn-"...,
"ORACLE_HOME=/opt/oracle/product/"..., "G_BROKEN_FILENAMES=1"...,
"HISTTIMEFORMAT=%F %T "..., "_=/bin/awk"...]) = 0
21156
uname({sysname="Linux", nodename="apn0.ccbs6a.net",
release="2.6.9-67.ELsmp", version="#1 SMP Wed Nov 7 13:56:44 EST 2007",
machine="x86_64"}) = 0


Solution


In line with recommended guidelines ('Siebel System Requirements and Supported Platforms Version 8.1', p31), the only Linux-based Operating Systems that are currently supported are:


o Red Hat Enterprise Linux 4 (32-bit)


o Novell SUSE Linux Enterprise Server 9 (32-bit)


o Oracle Enterprise Linux 4 Kernel level 2.6.9-42.0.0.0.1 (32-bit)
and Oracle Enterprise Linux 5 kernel level 2.6.18-53el5 (32-bit) .












Applies to:


Siebel CRM Call Center - Version 8.2.2 SIA[22320] to 8.2.2 SIA[22320] [Release V8]
Linux x86-64



Symptoms


The issue occurs when installing Siebel 8.2.2 on Linux version 6 update 0 or above (64bit).

After running the Siebel configuration wizard -> Configured a new Gateway name server, the following error shows:

"Unable to connect to Siebel Gateway Name Server".



Siebel Gateway log shows:



Location: siebel_root/gtwysrvr/log/siebel.log





[TCPIP-client]
failed to resolve hostname: SDCR710I006E (err=852198 | Internal:
gethostbyname_r ()failed with error. (%sysError))

NameServerLayerLog Error 1 000000024f4c19ce:0 2012-02-28 09:36:10 Unable to connect to the gateway server.

GenericLog GenericError 1 000000024f4c19ce:0 2012-02-28 09:36:10 NSC -
ErrCode 5009 SysErr 0GenericLog GenericError 1 000000024f4c19ce:0
2012-02-28 09:36:10 (srvredit2.cpp (302) err=5009 sys=1) SBL-GEN-05009:
Unable to connect to the gateway server.


Cause


The cause of the problem could be associated to the hostname indeed not been resolved.



By default the file host.conf, located in /etc/host.conf, has the "multi on" option set.



As an example the host.conf should look like:



multi on

order hosts,bind





Note: "The multi option determines whether a host
in the /etc/hosts file can have multiple IP addresses i.e.multiple
interface ethN. Hosts that have more than one IP address are said to be
multiomed, because the presence of multiple IP addresses implies that
host has several network interfaces. As an example, a Gateway Server
will always have multiple IP address and must have this option set to
ON."


Solution


The workaround solution is to set the following environment variable
to override the "multi on" option on the host.conf file. This has to be
disabled in the session that starts the Wizard.



1. export RESOLV_MULTI=off



Note: Make sure to use a port # lower than 32767.



2. Remove any previous installations from directory siebel_root/gtwysrvr/sys.



Run commands:



cd /home/siebel/gtwysrvr/sys

rm siebns*

rm svc.gtwyns*



3. Run the Siebel configuration Wizard.



Note: Detail logs from the Siebel installation can be generated using the parameter "-verbose"



BUG:13784383 has been created.












Applies to:


Siebel Call Center - Version: 8.1.1.2 SIA[21215] and later   [Release: V8 and later ]
Information in this document applies to any platform.



Symptoms


Siebel Servers suddenly did not start any more, even though there was no change in the Siebel environment.

SiebSrvr_28.log

immediately after benign errors like

SBL-SCC-00025: No value found in the Gateway. Default value in the repository is used.

(which means the Gateway Server can be contacted successfully, but the parameter requested is not set, so its default is used)

there were

SBL-GEN-05009: Unable to connect to the gateway server.

like

NameServerLayerLog Error 1 000024ec4c494b91:0 2010-07-23 08:26:43 Unable to connect to the gateway server.
GenericLog GenericError 1 000024ec4c494b91:0 2010-07-23 08:26:43 NSC - ErrCode 5009 SysErr 0
GenericLog
GenericError 1 000024ec4c494b91:0 2010-07-23 08:26:43 (listener.cpp
(184) err=5009 sys=0) SBL-GEN-05009: Unable to connect to the gateway
server.
GenericLog GenericError 1 000024ec4c494b91:0 2010-07-23
08:26:43 (lstnsvc.cpp (150) err=5009 sys=0) SBL-GEN-05009: Unable to
connect to the gateway server.

while the Gateway was still running,
and netstat output confirmed it was listening on its configured port (default: 2320)


Cause


Setting the Unix environment variable

SIEBEL_LOG_EVENTS=5; export SIEBEL_LOG_EVENTS
in the siebenv.sh
prior to starting the Gateway Server

(in Windows, you would set the SYSTEM environment variable SIEBEL_LOG_EVENTS=5 prior to starting the Gateway Server instead)

showed the problem in the NameSrvr.log (NameSrvr_01.log here)

in

<Gateway Root>

there were about 500 entries like

SecAdptLog Debug 5 00001d2b4c495cb8:0 2010-07-23 09:49:05 username=oemxyz : authentication succeeded.
SecAdptLog Debug 5 00001d2b4c495cb8:0 2010-07-23 09:49:05 username=oemxyz : retrieving responsibilities...

per
minute (the user name would reflect the username your monitoring script
uses to invoke srvrmgr behind the /u (user) command line switch)


Temporarily disabling access for
DB user
oemxyz
made the logins error out, but the Siebel Servers could be started correctly again,
so this was considered the root cause.

The monitoring tool used causes about 8 ODBC connections to be opened (and closed) every second,
which seems to max out the Gateway's connections to the database

SiebSrvr_28.log
first shows 160
SBL-SCC-00025

GenericLog
GenericError 1 00027c704c497cd9:0 2010-07-23 08:26:43 (sccnmsys.cpp
(1305) err=2883609 sys=0) SBL-SCC-00025: No value found in the Gateway.
Default value in the repository is used.

which means the gateway has been contacted and keys could be search (just no value found)
before this starts failing and a new connection cannot be made any more either

GenericLog
GenericError 1 00027ea84c497cd9:0 2010-07-23 08:26:43 (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
00027ea94c497cd9:0 2010-07-23 08:26:43 (sccitems.cpp (310) err=2555932
sys=0) SBL-SCM-00028: Key not found
GenericLog GenericError 1
00027ea94c497cd9:0 2010-07-23 08:26:43 (sccconfg.cpp (2149) err=2555932
sys=0) SBL-SCM-00028: Key not found
NameServerLayerLog Error 1 000024ec4c494b91:0 2010-07-23 08:26:43 Unable to connect to the gateway server.
GenericLog GenericError 1 000024ec4c494b91:0 2010-07-23 08:26:43 NSC - ErrCode 5009 SysErr 0
GenericLog
GenericError 1 000024ec4c494b91:0 2010-07-23 08:26:43 (listener.cpp
(184) err=5009 sys=0) SBL-GEN-05009: Unable to connect to the gateway
server.
GenericLog GenericError 1 000024ec4c494b91:0 2010-07-23
08:26:43 (lstnsvc.cpp (150) err=5009 sys=0) SBL-GEN-05009: Unable to
connect to the gateway server.
GenericLog GenericError 1
000024ec4c494b91:0 2010-07-23 08:26:43 (scfsis.cpp (274) err=1310725
sys=0) SBL-SVR-00005: Stale or invalid Task handle
ScfEventLog
SubEvtFacFatal 0 000024ec4c494b91:0 2010-07-23 08:26:43
scfEventFac::s_pEvtFacLock is NULL and hence SCF event facility cannot
be initialised
GenericLog GenericError 1 000024ec4c494b91:0
2010-07-23 08:26:43 (scfeventfac.cpp (3790) err=1319869 sys=0)
SBL-SVR-09149: Could not initialize the event facility.
ScfMsgFacLog
SCFMsgFacFatalError 0 000024ec4c494b91:0 2010-07-23 08:26:43
SCFMessageFacility::s_pSCFMsgFacLock is null and hence the
SCFMessageFacility cannot be initialized
IPCLog IPCFatal 0 000024ec4c494b91:0 2010-07-23 08:26:43 ipcFacility GetInstance called before initialization - object is null
GenericLog
GenericError 1 000024ec4c494b91:0 2010-07-23 08:26:53 (siebsvc.cpp
(221) err=5009 sys=0) SBL-GEN-05009: Unable to connect to the gateway
server.


Solution


If you are using monitoring scripts that connect to srvrmgr,
reduce the number of srvrmgr invocations of the monitoring tool
to for example once per minute per Siebel Server

also, don't forget to reduce the logging by removing

SIEBEL_LOG_EVENTS=5; export SIEBEL_LOG_EVENTS

from the Gateway Server's siebenv.sh file

(or changing the Windows SYSTEM environment variable SIEBEL_LOG_EVENTS to 1)

to reduce the logging again.


PS: If without any changes you suddenly see the error

SBL-GEN-05009: Unable to connect to the gateway server.

in 8.1.1. and above

(all of a sudden without using monitoring tools as described here)

and this happens to be 14 days after the installation, you may want to take a look at

Siebel CRM 8.1.1 DataDirect License file IVSE.LIC is missing from Gateway Name Server

instead - this was ruled out as a root cause in the beginning of this service request


References


NOTE:751784.1 - Siebel CRM 8.1.1.x: Two weeks after installation, Siebel server cannot start and srvrmgr returns: Fatal error (2555922)








Applies to:


Siebel CRM - Version: 8.1.1 SIA [21111] and later   [Release: V8 and later ]
Information in this document applies to any platform.

***Checked for relevance on 17-Feb-2012***



Symptoms


The Gateway daemon for Siebel Industry Applications version 8.1.1
running on IBM AIX 5.3 against Oracle 11g shows high CPU. This can be
observed after starting a Siebel server, which has a duration of 2-3
minutes. After the Siebel server has started the CPU of the Gateway
daemon reduces and stabilizes, however the Siebel Workflow components
fail after startup. If these failed components are restarted manually
via Siebel Server Manager then the CPU increases on the Gateway as
before.

ERROR MESSAGES


  1. SBL-DAT-00173: An invalid key was entered.

  2. SBL-NET-01218: The connection was refused by server %1. No component is listening on port %2.

  3. SBL-SRB-00040: Cannot open asynchronous SISNAPI connection.

  4. SBL-GEN-05009: Unable to connect to the gateway server.

  5. SBL-SVR-00052: Internal: Invalid proc handle





Cause


Issue caused by extremely large SIEBNS.DAT which can be seen by the high
CPU in the gateway process originating from the reads performed by the
NSClient.

Bug 10643323 has been logged to address a Product
Enhancement Request so that the size of the SIEBNS.DAT does not grow
excessively and if it does then to provide means to reduce the size - in
particular removing event log level entries.

The large amounts of reads being performed by the NSClient are directly related to the high CPU observed on the gateway


Solution


To reduce the size of the SIEBNS.DAT, the following can be employed to resolve the issue:

1. Restore backup of SIEBNS.DAT after changing event log levels for large amount of server components
2. Remove unnessary component definitions


References


BUG:10643323 - [CR#12-1VM5KED][FR#12-1VM5KEZ] PROVIDE RESTRICTIONS ON THE SIZE OF SIEBNS.DAT












 


SBL-GEN-05004 Key was not found.



Applies to:


Siebel System Software - Version: 7.7.2 [18325] and later   [Release: V7 and later ]

HP-UX Itanium

Product Release: V7 (Enterprise)

Version: 7.7.2 [18325]

Database: Oracle 9.2

Application Server OS: HP-UX 11.11

Database Server OS: HP-UX 11.11



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





Symptoms


SBL-GEN-05004, SBL-ICF-00018

Our database file was filled up around 1:07AM last night possibly
causing our Siebel Server to fail. While troubleshooting this morning,
we’ve shutdown the Siebel Server and Gateway Server and received (hand
translated from Chinese) “Not Started: Unable to copy service item files
into memory” when attempting to restart Gateway server.



The database size has since been extended, however, we still continue to receive this error.



We have tried the following:

- Delete and rebuild svc* file

- Verify all files are owned by Siebel user (and have read write permission to siebns.dat)

- Tried using an older version of siebns.dat

- Verify port 2320 is available



I have uploaded:

- screen shot of the error (in Chinese)

- Gateway logs

- enterprise server log



Any suggestions would be much appreciated


Cause


Configuration/ Setup



Solution


For the benefit of other users, the customer received the following
error message when attempting to restart their Siebel Gateway Server
“Not Started: Unable to copy service item files into memory”



Following
the failed restart, they recreated the *.svc files by running a siebctl
command but still could not start the Siebel Gateway Server and
received “NameSrvr - [5018] (No message)” errors in the NameSrvr.log.



Summary:



Siebel
does not recommend that customers should re-create the Siebel Gateway
or Server services if there are problems starting any service. The
reason Siebel does not recommend re-creating the Siebel Services is
because they could be created incorrectly which then cause other issues.
Customers are advised to raise a Service Request with Siebel Technical
Support if assistance is required diagnosing why a Siebel service failed
to start.



Further research found the siebctl syntax the customer
used to create the Gateway Server service is the one specified in
Service Request #38-1960105998 to create the Siebel Server service. The
steps used to resolve this Service Request was:

1)    Ensure the Siebel Server Service and Web Server services are offline

2)    Run gtwysrvr\siebenv.sh

3)    Stop the Gateway Server service (stop_ns)

4)    Copy svc.gtwyns. in $SIEBEL_ROOT/gtwysrvr/sys to backup.svc.gtwyns.old

5)    Delete the svc.gtwyns. file

6)    Run
the command siebctl -S gtwyns -a -g "/f $SIEBEL_ROOT/sys/siebns.dat /t
2320" substituting the port number for the Gateway Server service in
place of 2320.

7)    Start the Siebel Gateway service (start_ns)

8)    Type list_ns



Regards,






Applies to:


Siebel System Software - Version: 7.7.2.4 [18365] and later   [Release: V7 and later ]

IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.7.2.4 [18365]

Database: IBM DB2 8.2

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





Symptoms


SBL-GEN-05004, SBL-ICF-00018


We are in the process of setting up a disaster recovery
environment. While installing the first server we are running into
issue. I have installed the gateway server without issue. I have
installed the Siebel server 5 times now and get the same error every
time we try to start the server.



bash-2.05b$ start_server all

Siebel Server "rirdrs7gw01" (Enterprise "siebelpro")

OSDmmap: mmap(addr = 0x00000000, len = 3888496, prot = 0x00000003, flags = 0x00000001) failed: Invalid argument



Error 1300003 in OSDInit

bash-2.05b$ start_server all

Siebel Server "rirdrs7gw01" (Enterprise "siebelpro")

OSDmmap: mmap(addr = 0x00000000, len = 3888496, prot = 0x00000003, flags = 0x00000001) failed: Invalid argument





Internal:
The parameter values in the header of file
/siebelgw/siebsrvr/sys/osdf.siebelpro.rirdrs7gw01 do not correspond to
the current parameter values:



        nFileSize                          0              3888496

        nSiebNLatch                         0                 5039

        nSiebLatch                         0                 1000

        nSiebRWLock                         0                  503

        nSiebNSema                         0                 1021

        nSiebLatchNameLen                    0                  256

        nSiebSemaNameLen                     0                   64

        nSiebProcExit                      0                  256



Error 1300003 in OSDInit



As
you can see, we start the server, the startup fails but an osdf file is
created. if we try to start again we get the same error as the first
time but with an Internal error as well.






Cause


The filesystems were mounted with CIO option.

CIO is concurrent IO -
it's a mount option for the filesystem. It has some implications about
what can be done with the filesystem, including hindering the ability to
run executables from the filesystem.


Solution



Message 1


For the benefit of other readers, the troubleshooting steps and resolution are summarized below:



1) The customer was advised to run the following:



-    Run siebsrvr\siebenv.sh

-    Make sure that $SIEBEL_ROOT is correctly defined.

-    Stop the Siebel Server service (stop_server ALL)

-    Remove *.osdf in the $SIEBEL_ROOT/sys

-    Remove the svc.* files in the $SIEBEL_ROOT/sys (after backing it up)

-    Run
the siebctl command below but with the actual names of the Siebel
Enterprise, Server and Gateway Server names substituted for the
variables.

siebctl -S siebsrvr -i "$SIEBEL_ENTERPRISE:$SIEBEL_SERVER" -a -g "-g $SIEBEL_GATEWAY -e $SIEBEL_ENTERPRISE -s $SIEBEL_SERVER"

-    Start the Siebel Server service (start_server ALL)



This did not resolve the issue.



2) We checked that the customer’s environment met all the requirements in the following SupportWeb documents:



a) System Requirements and Supported Platforms, Version 7.7;



b)
Siebel 7.7 Bookshelf > Performance Tuning Guide > Tuning UNIX
Operating Systems for Performance > Tuning Siebel eBusiness
Applications for AIX >Tuning Kernel Settings for AIX



3) The test in the following SupportWeb Knowledge Item was successful:

FAQ 1113: How Do You Test Connectivity Through ODBC Data Sources Created by Siebel Systems?



4)
After reviewing the truss output from running start_server, Siebel
Technical Support recommended that the customer contact IBM AIX Support
who identified that the filesystems were mounted with CIO option.



When the filesystems were remounted without CIO option, the Siebel Server started successfully.





Best Regards,

יום שלישי, 25 בספטמבר 2012

SBL-GEN-04031: Internal: Error occurred during base64 decoding



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] ESN

Database: Oracle 9.2.0.4

Application Server OS: Microsoft Windows 2000 Server SP 3

Database Server OS: HP-UX 11i



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



Symptoms


SBL-GEN-04031, SBL-GEN-09103, SBL-ADM-02537Good morning,

A new Siebel developer has arrived to our project, he needs to use Siebel
Tools.
This morning we created a new mobile user for him and after install Siebel Tools in his
PC, we tried to launch task "Generate New Database" , in order to create a local database for
him.

When we run server task "Generate New database" with following parameters:
SQL
Anywhere Database = sse_utf8.dbf

we got the following error:

(gennewdb.cpp 27(462)
err=4031 sys=0) SBL-GEN-04031: Error durante descodificación Base64.
(smisched.cpp 17(821)
err=4031 sys=0) SBL-GEN-04031: Error durante descodificación Base64.

I searched on
supportweb this error, but unfortunately I don't find the cause of it.
I attached task log
file.

I have tried to connect with Tools application in my PC, with the new user, to
development Server database, and I connected succesfully.

Could you help us,
please?

Many thanks and Best regards.






Cause


Configuration/ Setup


Solution



Message 1


For the benefit of other users:



Customer experienced problems when attempting to perform a "Generate New
Database" task. We found following errors in Generate New Database log
(GenNewDb*.log).



SBL-GEN-09103: No se ha definido el valor del parámetro (es decir, es nulo)



SBL-GEN-04031: Error durante descodificación Base64.

[SBL-GEN-04031: Internal: Error occurred during base64 decoding]



During the research we found that above error could encounter as a
result of having an unencrypted Password in the siebns.dat file. As in
version 7 the passwords at Enterprise, Server or Component level are
stored in an encrypted format, having an unencrypted value in the
siebns.dat could corrupt siebns.dat file and cause this error.



We reviewed customer’s siebns.dat file and did find ‘DbaPwd’ parameter
for GenNewDb component is set to unencrypted value “SQL” as follows.



[/enterprises/Ent_CRM_DES/component groups/Remote/components/GenNewDb/parameters/DbaPwd]

    Persistence=full

    Type=string

    Value="SQL"

    Length=3



The encrypted value for “SQL” is “QqKg”. We made the changes to the
siebns.dat file by setting it to the correct value “QqKg” and returned
the file to customer with following instructions.



1. Please replace the current siebns.dat file with fixed siebns.dat file.



2. Stop Siebel servers, then stop Gateway server.



3. Restart Gateway server then start Siebel servers.



3. Now perform a new Generate New Database (GenNewDb) task.



The issue was ...<Ctd>..


Message 2


...<Ctd>



The issue was resolved with the fixed siebns.dat file.



Please note that customers modifying the siebns.dat files themselves is not supported, as it may corrupt the file.



Keywords: Generate New Database, SBL-GEN-04031, password, encrypted, unencrypted, siebns.dat, GenNewDb, DbaPwd, SQL, QqKg.



Thank you.














Applies to:


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

Product Release: V7 (Enterprise)

Version: 7.7.2.4 [18365]

Database: Oracle 9.2.0.6

Application Server OS: Sun Solaris 5.8

Database Server OS: Sun Solaris 5.8



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



Symptoms


SBL-GEN-04031Hi,

For security purpose, we plan to change the default value of Generate Trigger
component so that the technical team wouldn't need to provide the parameters while running this
task.

We were successful in updating all the parameters but when we run the task, it exits
with the following error:

"SBL-GEN-04031: Internal: Error occurred during base64
decoding."

We saw Service Request #: 38-1025380931 on the similar issue.

The steps
we performed were to update the default password in the server configuration - enterprise
component parameter as well as server component parameter (with start configuration & commit
configuration) and then syncronised the components and bounced ther server.

Did we miss
something?
Is it possible to change the default password from the GUI as we did?
Why
doesn't siebel store the default password we provide it in the encrpted form?

Thanks in
advance.

Regards






Cause


Change Request #12-1D2BMPK


Solution



Message 1


For the benefits of other users:



After performing the following password changes steps, error
"SBL-GEN-04031: Internal: Error occurred during base64 decoding."
reported where the password is not being encrypted accordingly in
Gateway Name Server (siebns.dat).



1) Navigate to "Site Map > Administration - Server Configuration >
Enterprise" and on Component Definitions view, select Menu, Start
Reconfiguration

2) Query for component Generate Trigger on Component Definition view

3) On Parameter view at lower panel, query for Privileged User Password and set the password and save it (step off the record)

4) On Component Definitions view, select Menu, Commit Reconfiguration

5) Restart Siebel Server



When checking siebns.dat file, the password set for Privileged User Password is on plain text.



Change Request #12-1D2BMPK (Password changes on enterprise component
definition through UI not being encrypted) being logged to address this
behavior.



Solution:



Change the password using server manager command when Siebel Gateway and Siebel Server are up and running.



srvrmgr /g gateway /e enterprise /u username /p password

srvrmgr> change param PrivUserPass=Siebel for compdef GenTrig



After the above restart Siebel Server and Gateway services and the password should be set in encrypted format accordingly










Applies to:


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

Customer facing errors when trying to generate new database task from Siebel remote Server



Symptoms


Everytime that customer try to run gennewdb (generate new database task) he received error message bellow:



SBL-GEN-04031: Internal: Error occurred during base64



Changes


No visible changes



Cause



1. Missing DBAPWD parameter into gennewdb parameters screen


2. Customer changed some siebel server folders to a different structure






Solution


A. Add DBAPWD password into gennewdb parameter screen



B. Customer found that the enu*.dbf file which is in the parameters
of the Generate New Database server task, had been moved to different
location. When copied back to correct location the task ran correctly

We
found that the \dbtempl folder had been moved to the \bin subdirectory.
After moving this directory back to \%siebel_root%\srvr DbXtract worked
without problems

 












Applies to:


Siebel System Software - Version: 7.7.2 [18325] to 8.0.0.5 [20420] - Release: V7 to V8
All Platforms

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






Symptoms


We have configured password hashing as described in the Siebel
Security Guide's section "Security Adapter Authentication: Configuring
Password Hashing."  After restarting the server and gateway, we were
able to successfully login using a dedicated client with the clear-text
password.  However we are not able to connect using the web client and
the following components were not running but had passed one or more of
the errors listed below:

PDbXtract/DbXtract
SSEObjMgr_enu
WfProcBatchMgr
WfProcMgr
WfRecvMgr

SBL-DAT-00446, SBL-DCK-00164, SBL-GEN-04031, SBL-OMS-00102, SBL-OMS-00107, SBL-SEC-10018, SBL-SEC-10007, SBL-SVR-00040




Solution


Customer was implementing Password Hashing, and after changing
parameter DSHashUserPwd in Server Data Source named subsystem to “TRUE”
and restarting the Siebel environment, the following components did not
start:

PDbXtract/DbXtract
SSEObjMgr_enu
WfProcBatchMgr
WfProcMgr
WfRecvMgr

WfRecvMgr, WfProcMgr, and WfProcBatchMgr had the following error messages:


SBL-SEC-10007: The password you have entered is not correct. Please enter your password again. (0x5a94))
SBL-SEC-10018: You have entered an invalid set of logon parameters. Please type in your logon parameters again.(SBL-DAT-00446)

SBL-SVR-00040: Internal: Informational, encrypted parameter. (0x5a8f))

SBL-OMS-00107: Object manager error: ([2] SBL-SVR-00040: Internal: Informational, encrypted parameter. (0x5a8f))
SBL-OMS-00107:
Object manager error: ([1] SBL-SEC-10018: You have entered an invalid
set of logon parameters. Please type in your logon parameters
again.(SBL-DAT-00446)
ORA-01017: invalid username/password; logon denied

SBL-OMS-00107:
Object manager error: ([0] SBL-SEC-10007: The password you have entered
is not correct. Please enter your password again. (0x5a94))
SBL-OMS-00102: Error 23188 logging in to the application



SSEObjMgr had the following error messages:

SBL-DAT-00446: You have entered an invalid set of logon parameters. Please type in your logon parameters again.
SBL-SEC-10018: You have entered an invalid set of logon parameters. Please type in your logon parameters again.(SBL-DAT-00446)
ORA-01017: invalid username/password; logon denied


The
above errors were resolved by setting the Password parameter for each
component to the unhashed password for the SADMIN user and restarting
the environment.  Further information is available in the Siebel
Bookshelf > Security Guide > Security Adapter Authentication >
Configuring Password Hashing.


Components PDbXtract (during server startup) and DbXtract (at component task start) had the following error message:

SBL-GEN-04031: Internal: Error occurred during base64 decoding.

Error
message SBL-GEN-04031 in PDbXtract and DbXtract log files occur because
the password length is greater than 21 characters. If SADMIN password
has more than 21 characters, PDbXtract and DbXtract components will fail
with the error message.

The SADMIN password was hashed using the
RSA SHA-1 encryption algorithm. When using SADMIN as password in test
environment, the hashed password contained 28 characters.  Since
"SADMIN" is a fairly simple and short password, we would expect that
most good passwords would result in RSA SHA-1 values that are too long. 



Change Request 12-SQ798U has been opened to address this Product Defect.

The
workaround is to change the Hashing algorithm to use Siebel Hash
instead of RSA SHA-1. Siebel Hash will encrypt passwords with a length
smaller than RSA SHA-1 algorithm.  Please refer to the Security Guide
for more information about how to change encryption algorithm.










Applies to:


Siebel CRM - Version: 7.7.2.8 SIA [18379] and later   [Release: V7 and later ]
Information in this document applies to any platform.



Symptoms



This occurred on a Siebel enterprise deployment version 7.7.2.8 on windows platform.

SCBroker and SRProc that do not start on 1 of 7 application server after
application server startup, instead the components are staying with the
status 'unavailable' .






Cause



The following errors are reported for the 2x components:

File: SRProc_10249.log

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

>>>

...

RPQueryLogEvt SRPQuerySubevt 3 0 2010-09-10 17:22:11 Task waiting is 60

GenericLog GenericError 1 0 2010-09-10 17:22:11 (srpdb.cpp (569)
err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64
decoding.

GenericLog GenericError 1 0 2010-09-10 17:22:11 (srpsmech.cpp (57)
err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64
decoding.

GenericLog GenericError 1 0 2010-09-10 17:22:11 (srpmtsrv.cpp (90)
err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64
decoding.

SRPQueryLogEvt SRPTaskInfo 3 0 2010-09-10 17:22:11 Main Init failed

GenericLog GenericError 1 0 2010-09-10 17:22:11 (smimtsrv.cpp (1063)
err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64
decoding.

SmiLayerLog Error 1 0 2010-09-10 17:22:11 Terminate process due to unrecoverable error: 4031. (Main Thread)

<<<



File: SRBroker_10250.log

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

>>>

...

GenericLog GenericError 1 0 2010-09-10 17:22:12 (srbthrd.cpp (3869)
err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64
decoding.

GenericLog GenericError 1 0 2010-09-10 17:22:12 (srbmtsrv.cpp (71)
err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64
decoding.

SrbLayerLog Error 1 0 2010-09-10 17:22:12 Main Init fails

GenericLog GenericError 1 0 2010-09-10 17:22:12 (smimtsrv.cpp (1063)
err=4031 sys=0) SBL-GEN-04031: Internal: Error occurred during base64
decoding.

SmiLayerLog Error 1 0 2010-09-10 17:22:12 Terminate process due to unrecoverable error: 4031. (Main Thread)

<<<


The above errors indicate the following:

1. A high number of
components being raised while your Siebel server is coming up. This can
lead to a high memory consumption and make the SrBroker and SrProc to go
down. Please review the number of components being used and make
offline the ones that are not being used.



2. A discrepancy on the password parameter for the components SRbroker and SRproc.

I can see that a Parameter Password has been set for SRBroker and SRProc cmponents at compnent definition level.

The password value I can see there is different to the one used for the
password parameter at enterprise level which is equally used for some
components at server level.



This could be confirmed by reviewing the password parameters at different levels.

File: siebns.dat

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

Password value at enterprise level: "xxxxxxxxxxxxxxx". The same password is set for some components at server level.

Password value at component definition level for SRBroker and SRProc: "yyyyyyyyyyyyyy"






Solution



Please try resetting the password a the highest level component
definition or reset the password for server "SVWSIEBP04" only by going
into Server Manager command line, set server SVWSIEBP04 and type:



srvrmgr> change param password=new_password for comp srproc

srvrmgr> change param password=new_password for comp srbroker

After doing the above and restarting the application server, the issue was resolved.