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,

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.


SBL-GEN-03008: Error calling SQLExecute

Applies to:

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

Goal


Hi,

Thank you for submitting your question on Oracle Metalink3 portal. I have taken ownership for the Service Request generated (3-948299761).

I understand you are seeing issues with the Transaction Merger trying to process a problematic dx file for user XXXXXXX  and you wish to have the dx file "fxed" if possible in order to save the rest of the probably good Transactions.

I will examine the log files and see what the issue might be. We may be able to perhaps "fix" the dx file to save some of the information.



Thank you

Siebel Technical Support

Solution

An1:
Hi ,

Thank you for your patience, I have reviewed your Txn Merger log file.
""UPDATE dbo.S_ORG_PROD
SET MODIFICATION_NUM = MODIFICATION_NUM + 1, DB_LAST_UPD = {fn now()}, DB_LAST_UPD_SRC = 'REMOTE',
LAST_UPD = ?,
LAST_UPD_BY = ?,
DB_LAST_UPD = ?,
DB_LAST_UPD_SRC = ?
WHERE ROW_ID = ?
DBCLog DBCLogError 1 000000024a3e0c88:0 2009-06-21 14:45:03 [Microsoft][SQL Native Client][SQL Server]Column name 'DB_LAST_UPD' appears more than once in the result column list.
"

:
:

"03007: SQL error: native=264, state=37000, message=[Microsoft][SQL Native Client][SQL Server]Column name 'DB_LAST_UPD_SRC' appears more than once in the result column list.
GenericLog GenericError 1 000000024a3e0c88:0 2009-06-21 14:45:03 (mrgsupd.cpp (1231228) err=0 sys=1) SBL-GEN-00000: (mrgsupd.cpp: 1231228) error code = 0, system error = 1, msg1 = (null), msg2 = (null), msg3 = (null), msg4 = (null)
GenericLog GenericError 1 000000024a3e0c88:0 2009-06-21 14:45:03 (mrgsupd.cpp (700) err=3008 sys=0) SBL-GEN-03008: Error calling SQLExecDirect for UPDATE dbo.S_ORG_PROD
"

:
:

"GenericLog GenericError 1 000000024a3e0c88:0 2009-06-21 14:45:04 Message: GEN-03,
Additional Message: File: C:\sba80\siebsrvr\docking\XXXXXX\inbox\00000035.dx. Last successfully read txn id: 14411. Last committed txn id: 14411."

As you can see 'DB_LAST_UPD' AND 'DB_LAST_UPD_SRC' get two values...

This is a known Siebel Product Defect in Siebel 8.0.x when running against SQL Server database.

The Defect 12-1L0YDDK "apply_thrd failing as columns DB_LAST_UPD, DB_LAST_UPD_SRC listed twice in update statement"

is fixed in Siebel 8.0.0.7 Fix Pack which was released on 25th May 2009.

I have associated your Service Request to this Defect.

For the moment the workarounds are

1). Re-extract affected mobile clients
2). Provide the corrupted dx file along with the corresponding Merger log file OR applythtrd_xxx_xxx.log for an affected mobile client and Technical Support will fix this for you by removing the problematic transaction. (This is what I have done for you here... see my next update)

3). Replace the corrupted dx file with a Blank dx file.

For Options 2 and 3 from above, we will require you to replace the problem dx file with the new fixed or dummy dx file.


Thank You

Siebel Technical Support


An2:
Hi,

Thank you for your patience. As promised, I have identified the corrupt transactions in the dx file, They are


Txn Type : S
Txn Id : 14412
Src Node : 47N
Created By : 1-ER-17
DLog Row Id: 47N-D6U

OperType : Insert
TableName: S_ORG_PROD
Txn RowId : 47N-D6T
Txn LastUpdBy : 1-ER-17
Txn LastUpd : 2009-06-19 18:38:20.000000
Txn ModNum : 0
Txn ConflictId: 0
Txn Id: 14412
File Table : Unknown
Col 0 (C): AMT_CURCY_CD
Col 1 (C): DSTRBN_ACTV_FLG
Col 2 (C): ORDER_FLG
Col 3 (C): OU_ID
Col 4 (C): PROD_ID
Col 5 (C): SALES_FLG
Col 6 (C): STATUS_CD
Col 7 (C): X_BIC_NODELETE_FLG
Col 8 (C): X_BIC_PROM_ADJ_AMT_VALUE
New 0 : EUR
New 1 : Y
New 2 : Y
New 3 : 1-OX-1483
New 4 : 1-12HUZL
New 5 : Y
New 6 : Present
New 7 : N
New 8 : 0
Audit Hints:

Txn Type : S
Txn Id : 14413
Src Node : 47N
Created By : 1-ER-17
DLog Row Id: 47N-D6W

OperType : Insert
TableName: S_ORG_PROD
Txn RowId : 47N-D6V
Txn LastUpdBy : 1-ER-17
Txn LastUpd : 2009-06-19 18:38:41.000000
Txn ModNum : 0
Txn ConflictId: 0
Txn Id: 14413
File Table : Unknown
Col 0 (C): AMT_CURCY_CD
Col 1 (C): DSTRBN_ACTV_FLG
Col 2 (C): ORDER_FLG
Col 3 (C): OU_ID
Col 4 (C): PROD_ID
Col 5 (C): SALES_FLG
Col 6 (C): STATUS_CD
Col 7 (C): X_BIC_NODELETE_FLG
Col 8 (C): X_BIC_PROM_ADJ_AMT_VALUE
New 0 : EUR
New 1 : Y
New 2 : Y
New 3 : 1-OX-1483
New 4 : 1-12IERT
New 5 : Y
New 6 : Present
New 7 : N
New 8 : 0
Audit Hints:
:
:
“
Lets fix the Dx file and see if the issue ever re-turns.

To "Fix" the dx file, I have removed these two transactions TxnId : 14412, 14413 (which contain 1 sub-operation each) from the dx file "00000035.dx".

I have called the new dx file "fixed_35.dx. Please re-name this to the name of the original (00000035.dx) and use it to replace the original in

C:\sba80\siebsrvr\docking\XXXXXX\inbox\00000035.dx

Please re-name the "inbox" directory also back to it original name, ( if necessary?)

Please let me know if the Transaction Merger processes this new "fixed" Dx file.

Thank you

Siebel Technical Support



Applies to:

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

Symptoms


=== ODM Issue Clarification ===

Transaction Router and Database Extract exhibit  the following errors


ORA-00600 internal error code [qertbFetchByRowID], [], [], [], [], [], [], []

SBL-GEN-03007: (dberror2.cpp: 0) error code = 3007

SBL-GEN-03008: (utlvis.cpp: 2688) error code = 3008, system error = 0, msg1 = SQLFetch, msg2 = VISIBILITY GET ID Party(1), msg3 = (null), msg4 = (null)

Changes

none.

Cause


=== ODM Cause Determination ===

Number of records on certain tables changed dramatically

We also found that simple queries run directly against the Database caused the same Error.

ORA-00600: internal error code, arguments: [qertbFetchByRowID], [], [], [], [], [], [], []

Solution


=== ODM Solution / Action Plan ===

Rebuild Database Indexes on tables that are exhibiting the error.

The exact steps for re-building indexes will vary slightly depending on the Database.

Please review database documentation or involved Database Administrator





Applies to:

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

Description

Customers using Siebel Remote may encounter various errors. These errors have been addressed in Fix Packs, Quick fixes or may have temporary workarounds available. Below is a list of the known defects, a clear description to help you identify if you have hit this defect and a table that lists in what fix pack (FP) or quick fix (QF) the defect has been fixed. This alert will be updated as required to keep customers informed of defects as well as fixed versions. FP's and QF's can be downloaded from My Oracle Support from the "Patches & Updates" tab

The below list is not exhaustive but includes the most critical defects that have been identified.

* Note that after installing the fix for CR #  12-1T2IN2L (Bug:10565949) some customer then experienced another behavior CR # 12-1U0AX75 (Bug:10570714) brought about by applying the fix.

As a result of this situation a new CR was created CR #12-1VNIMYR (Bug:10582025) to provide a thorough, redesigned and complete solution for these two behaviors. Therefore the fix for CR #12-1VNIMYR (Bug:10582025) is a complete solution for both CR # 12-1T2IN2L (Bug:10565949) and CR # 12-1U0AX75 (Bug:10570714)

Every customer that is running Siebel in version 8.0.x and 8.1.x should apply the complete solution. Please see the below table for details.


1) Change Request  12-1T2IN2L  Bug:10565949Transaction Processor may encounter slow performance. Customer may notice this performance issue soon after moving to Siebel 8.x or 8.1. This behavior has been detailed in the following Alert: Transaction Processor can exhibit slow performance Note 841888.1
2) Change Request 12-1TUWRGV Bug:10569597
3) Change Request 12-1QVMO57  Bug:10555407

In certain situations .dx files can be malformed and missing the table name value.   There are 2 Change Requests created to address this behavior. Though the end result is the same the behavior can occur in two distinct scenarios. The .dx file created looks similar and in both cases the TableName is missing.
Example:
Txn Type : S
Txn Id : 1176656580
Src Node : 1-2PPG-2
Created By : 1-2I2UD
DLog Row Id: 1-R231-1

OperType : Cascade / Merge
TableName:
Txn Id: 1176656580
File Table : Unknown
Col 0 (C): CON_PER_ID
Col 1 (C): ROW_ID
Old 0 : 2IPQ-IAI
Old 1 :
Operation 0 (Cascade Delete ): S_CALL_LST_CON.CON_PER_ID


Customer will find the following errors in the Transaction Merger log file or the client applythrd_xxx_yyy.log file

GenericLog pTableName is NULL or empty
GenericLog SBL-GEN-03006: Error calling function: DICFindTable

4) Change Request 12-1L0YDDK  Bug:10529443
Under certain conditions Transaction Merger or the client applythrd may fail when processing an update within a .dx file.The .dx file itself is not malformed but during the update process two system columns are listed twice in the update statement causing an error condition.DB_LAST_UPD and DB_LAST_UPS_SRCNote 848264.1

Set clause for column 'DB_LAST_UPD' used incorrectly for the client applythrd.log file
Column name 'DB_LAST_UPD' appears more than once in the result column list. for the Transaction Merger log file
or
[DataDirect][ODBC Oracle driver][Oracle]ORA-00957: duplicate column name
5) Change Request 12-1RPD2ML  Bug:10559246
Customers have experienced visdata corruption while running Transaction Router and Transaction Processor in a Siebel 8 environment. This behavior has been detailed in the following Alert: Transaction Router and Transaction Processor may encounter visdata.dbf file corruption in Siebel 8 remote environment Note 763195.1


6) Change Request 12-1U0AX75  Bug:10570714
After applying the fix for the Transaction Processor performance condition identified in 1) above it is possible another error can occur. After Transaction Processor restarts it will begin to read transactions from the Low Scan Mark (an internal marker).  These transactions have already been routed by the Transaction Processor and the Transaction Router. The processor places these already routed transactions in the next sequential .dx file - example 101.dx file. Since the transactions within the dx file have already been routed the Transaction Processor will delete this dx file(s) once it starts the Clean File routine. The Transaction Router will start and will be looking for the next sequential dx file in the TXNPROC folder (101.dx). If Transaction Router cannot find the dx file (101.dx) it will fail with:

Read error - system error code 2
Message: Unable to open User Txn Log file for reading or writing.,
SBL-DCK-00142: Error opening transaction file (...) for read
7) Change Request 12-1UP4EOX  Bug:10574894
Running the Database Extract task with certain parameter settings can cause the Transaction Router to fail. Using both the List method and the Optimal Mode=TRUE setting will cause this error condition.This behavior has been detailed in the following Alert:  Running Database Extract with specific settings causes Transaction Router to fail Note 948203.1

Likelihood of Occurrence

Customers using Siebel Remote and Replication on version 8 are likely to encounter these error conditions. Some of these Change Requests have been addressed in Fix Packs. In other cases a Quick Fix may be required on top of  the current version.


Possible Symptoms

Here are the error messages you may find in each scenario.

The error message for Change Request 12-1TUWRGV Bug:10569597 and Change Request 12-1QVMO57 Bug:10555407

GenericLog pTableName is NULL or empty
GenericLog SBL-GEN-03006: Error calling function: DICFindTable

The error message for Change Request 12-1L0YDDK Bug:10529443

Set clause for column 'DB_LAST_UPD' used incorrectly.

Found in the client applythrd.log file

Column name 'DB_LAST_UPD' appears more than once in the result column list.
[DataDirect][ODBC Oracle driver][Oracle]ORA-00957: duplicate column name 
Found in the Transaction Merger log file

The error message for Change Request 12-1U0AX75 Bug:10570714:

Read error - system error code 2
Message: Unable to open User Txn Log file for reading or writing.,
SBL-DCK-00142: Error opening transaction file (...) for read.


The error message for Change Request 12-1RPD2ML Bug:10559246:

Unable to open visibility database in 10 of 10 tries....
SBL-CSC-00213: Invalid visibility database.
SBL-CSC-00200: Cannot acquire spinlock createLatch

The error message for Change Request 12-1UP4EOX Bug:10574894:

SBL-GEN-03006: Error calling function: GetNodeProcessPref

Workaround or Resolution

  • Bug:10574894:
In order to workaround this issue do not use both the list method of extracting users and the Optimal Mode setting together.

srvrmgr:app1> start task for comp dbxtract with client=@c:\clients.txt
srvrmgr:app1> start task for comp dbxtract with client=CLIENT1, optmode=TRUE
The default setting for Optimal Mode for the Database Extract component is FALSE

  • Bug:10559246:
Stop all running Routers and Processors. Uncheck ( set to FALSE) the Optimized Visibility Check preference. By default this Remote System Preference is TRUE. You can find this preference in Administration-Siebel Remote> Remote System Preferences > checkbox bottom left of this applet. Unchecking does not require service restart. In addition there is no negative impact of unchecking this preference. Start Processor and Router.
  • Bug:10570714:
         **(This is a manual workaround the complete and best solution for this behavior is to apply the fix
         for Bug:10582025)
Increase the TP parameter Clean .dx files iterations to a large value so it will not delete .dx files until the Transaction Router has had an opportunity to process them. Be sure to increase the parameter on each Transaction Processor in the environment. Increasing the value from 1 to a value between 100-200 for Clean .dx files iterations should prove effective. Do not run the Transaction processor without running the Transaction Router as well. There is no negative impact on processing. The TXNPROC directory will grow large until the Transaction processor purges the .dx files. For Example if setting the Clean.dx file iteration to 150


Patches

Change RequestDescriptionFixed version
12-1VNIMYR Bug:10582025
(CR #'s 12-1T2IN2L Bug:10565949 and 12-1U0AX75 Bug:10570714 are addressed by applying this fix)
Provides the complete solution for
"Slow Transaction Processor performance"
and
"dx file deleted before Router can read them."
Fix Pack:
8.0.0.10
8.1.1.3 

Quick Fix
8.0.0.9[20433] QF0901
8.0.0.8 [20430]QF0809
8.0.0.7[20426] QF0754
8.0.0.6[20423] QF06AA
8.0.0.5 [20420]QF05CB
8.0.0.2 [20412]QF02E4
8.1.1.2 [21215] QF0238
8.1.1 SIA [21111] or HOR[21112] QF00AO



12-1TUWRGV
Bug:10569597
pTable Name errorFix Pack
8.0.0.9
8.1.1.2
Quick Fix
8.0.0.2 [20412]QF02C8
8.0.0.5 [20420]QF05BC
8.0.0.6 [20423]QF0661
8.0.0.8 [20430]QF0809
8.1.1 [21112] QF00AO
12-1QVMO57
Bug:10555407
Frequent dbxtract, dbinit and synchronization leads to TxnMerger failingFix Pack
8.1.1 HOR [21112]
8.0.0.9
8.1.1.4
Quick Fix
8.0.0.2 [20412]QF02C8
8.0.0.3 [20416]QF0368
8.0.0.5 [20420]QF05BO
8.0.0.6 [20423]QF06AJ
8.0.0.8 [20430]QF0809
8.1.1 SIA [21111] or HOR[21112] QF00AO
12-1L0YDDK
Bug:10529443
DB_LAST_UPD listed twiceFix Pack
8.0.0.7
8.0.0.8
8.1.1.2
Quick Fix
8.0.0.4 [20417]QF0420
8.0.0.5 [20420]QF0591
8.0.0.6 [20423]QF0669
8.1.1.1 [21211] QF01BN
12-1RPD2ML
Bug:10559246
Visdata.dbf corruptionFix Pack
8.0.0.8
8.1.1.2
Quick Fix
8.0.0.5 [20420]QF0571
8.0.0.6 [20423]QF0611
8.1.1 [21112] QF0076
12-1UP4EOX Bug:10574894Router fails if Database Extract is run with specific settingsFix Pack
8.0.0.13
8.1.1.7

References

NOTE:763195.1 - Transaction Router and Transaction Processor may encounter visdata.dbf file corruption in Siebel 8 remote environment
NOTE:790117.1 - The Txnskip functionality is not working as expected.
NOTE:841888.1 - Transaction Processor 8.x can exhibit slow performance
NOTE:848264.1 - Transaction Merger crashes on a DX File error SBL-GEN-03008
NOTE:948203.1 - Running Database Extract 8.x with specific settings causes Transaction Router to fail Error calling function: GetNodeProcessPref





Applies to:

Siebel Assignment Manager - Version 7.8.2.6 [19230] to 8.1 [21039] [Release V7 to V8]
Information in this document applies to any platform.

Symptoms

We have Repeating Component Request for Batch Assignment.  Our Batch Assignment task is erring out in Production with following error:

GenericLog GenericError 1 0 2008-08-25 13:43:11 Message: Internal error occurred in a procedure.,
Additional Message: rule-ERR-1109: Unable to read value from export file (Data length (4) > Column definition (3)).

GenericLog GenericError 1 0 2008-08-25 13:43:11 Message: Internal error occurred in a procedure.,
Additional Message: rule-ERR-1107: Unable to read row 0 from export file (UTLDataValReadUTLDataValRead pBuf, col 3 ).
GenericLog GenericError 1 0 2008-08-25 13:43:11 (asgnrule.cpp (2561) err=3008 sys=486992) SBL-GEN-03008: (asgnrule.cpp: 2561) error code = 3008, system error = 486992, msg1 = UTLDataFetch, msg2 =

SELECT R.ROW_ID, R.ASGN_TYPE_CD, R.SCORE_VAL, R.EXCLUSIVE_FLG, R.ASGN_CHILD_FLG, R.CREATE_ACT_FLG,
R.CAL_ADDTL_TIME, R.MIN_SCORE_VAL, R.ALL_POSTN_FLG, R.ALL_POSTN_FLG, R.PR_EMP_ID, R.PR_POSTN_ID, R.ALL_EMP_SKILL_FLG,
R.NAME, R.EFF_START_DT, R.EFF_END_DT, R.ALL_BU_FLG, R.PR_BU_ID, R.CHECK_CAL_FLG, RG.ROOT_RULE_GRP_ID,R.PER_CAND_SRC_CD, R.BU_CAND_SRC_CD
FROM SIEBEL

GenericLog GenericError 1 0 2008-08-25 13:43:11 Message: Internal error occurred in a procedure.,
Additional Message: rule-ERR-1109: Unable to read value from export file (UTLCompressFReadUTLCompressFRead (fseek)).

GenericLog GenericError 1 0 2008-08-25 13:43:11 Message: Internal error occurred in a procedure.,
Additional Message: rule-ERR-1107: Unable to read row 0 from export file (UTLDataValReadUTLDataValRead pBuf, col 0 ).


The S_SRM_REQUEST has over 1000 such requests still 'queued'.

COUNT(*) TRUNC(CREATED) TRUNC(LAST_UPD) SUBSTR(PARAM_VAL,2,INSTR(PARAM_VAL,'|')-2)
---------- ----------------- ----------------- --------------------------------------------------
1 09/27/2004 00:00:00 08/14/2007 00:00:00 AsgnKey=1-7OAG9
1232 02/26/2008 00:00:00 08/28/2008 00:00:00 AsgnKey=1-7OAG9

Can you please suggest the recommended steps to delete these stale requests by our DBA?

Thanks.

Cause

Customer discovered that the repeat errors are for an Assignment rule processing which is no longer active.

Solution

1. Cancel existing 1000 QUEUED tasks.
You can cancel 1000 QUEUED tasks so they won't get executed. One way is by manually updating the status to 'CANCELLED' in database, this should stop the tasks from starting. First execute this SQL in database to get component requests related to the inactive assignment rule in S_SRM_REQUEST and look them through.  The Asgnkey holds the assignment rule group's ROW_ID, S_SRM_REQUEST.ACTION_ID is the component ID.

SELECT a.STATUS, a.ACTION_ID, b.NAME, a.PARAM_VAL
FROM S_SRM_REQUEST a, S_SRM_ACTION b
WHERE a.ACTION_ID = b.ROW_ID
AND a.PARAM_VAL LIKE '%AsgnKey=1-7OAG9%'

Then use the following SQL to update the status:

UPDATE S_SRM_REQUEST
SET STATUS = 'CANCELLED'
WHERE STATUS = 'QUEUED'
AND ACTION_ID in (SELECT a.ACTION_ID
FROM S_SRM_REQUEST a, S_SRM_ACTION b
WHERE a.ACTION_ID = b.ROW_ID
AND a.PARAM_VAL LIKE '%AsgnKey=1-7OAG9%' )
AND PARAM_VAL like '%AsgnKey=1-L6G9%'

2. New RCR tasks for Batch Assignment are queued.
Customer set existing QUEUED tasks to CANCELLED.  Customer tried to re-schedule Batch Assignment tasks. But all the requests were getting queued sitting in QUEUED status. Customer restarted the Siebel Server having Assignment Management server component group.  After restart the status of "Assignment Manager" and "Batch Assignment" components were in "Shutdown" state. Customer restarted the component from the GUI, after that the components showed "Online" state.  But the requests were still queued.   Customer manually started a Batch Assignment task in UI, the task was QUEUED.  Customer found Batch Assignment tasks with the same input parameters submitted in srvrmgr command line were executed successfully:  Troubleshooting by following "Component Requests remain in a Queued status (Doc ID 476707.1)", no faults found.
Customer has 7 Siebel Servers in enterprise, and only one Siebel Server BEOVPVSS2 has Assignment Management server component group enabled.  In siebns.dat, the group showed enabled and online. But the 2 components were shown enabled and offline as the following:
enable state = enabled
status = offline
Applying solution from "Component becomes offline on rebooting Siebel server (Doc ID 543893.1)": online compgrp AsgnMgmt and restart Siebel Server, did not work.
This problemt got resolved after customer moved Assignment Management component group to another Siebel Server by doing the following:
- Disable the Assignment Management component group, Synchronize the batch components, and restart on 1st Siebel Servere;
- Enable the Assignment Management component group, Synchronize the batch components, and restart on 2nd Siebel Server. 
- Then customer moved Assignment Management component group back to original server, by doing the same steps. 
It looks like the component status got refreshed in the gateway configuration, by doing this 2 step process between 2 Siebel Servers.   It took time to confirm the solution worked because being in Production customer cannot restart servers during weekdays hence wait for the weekend

References

NOTE:476707.1 - Component Requests remain in a Queued status
@NOTE:543893.1 - Component becomes offline on rebooting Siebel server





Applies to:

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

Symptoms


Transactions are not getting processed. Even though it says copying transactions.
Transaction Router fails with
SBL-CSC-00213: Invalid visibility database. Shut down and restart *all* remote components using it (txnproc and txnroute) to rebuild.

Cause


TxN Router wasn't working fine. It was failing with the following errors:

[DataDirect][ODBC Oracle driver][Oracle]ORA-00904: "SIEBEL"."VIS_DB_MAX_TXN_ID": invalid identifier

SBL-GEN-03007: SQL error: native=904, state=S0022, message=
[DataDirect][ODBC Oracle driver][Oracle]ORA-00904: "SIEBEL"."VIS_DB_MAX_TXN_ID": invalid identifier

SBL-GEN-03008: Error calling SQLExecute for VIS NODE INFO (1)


and finally with:

SBL-CSC-00213: Invalid visibility database. Shut down and restart *all* remote components using it (txnproc and txnroute) to rebuild.


All the Remote components must be working correctly. If one fails, it affects the others.

Solution


VIS_DB_MAX_TXN_ID is a function and it was suspected that it was not valid. It's been also seen in previous cases that after granting sse_role to SADMIN again and then granting execute on VIS_DB_MAX_TXN_ID to SADMIN, Transaction Router runs successfully.

So please:

1. Make sure sse_role has been properly granted to the user running Transaction Router

select * from dba_role_privs where grantee = '<>’;
2. Make sure the function VIS_DB_MAX_TXN_ID is valid

select object_name, object_type, status
from all_objects
where object_name = 'VIS_DB_MAX_TXN_ID'
and owner = 'SIEBEL';

If the function is invalid, this function can be recreated by executing the pkgvis.sql script in the \dbsrvr folder. When the function VIS_DB_MAX_TXN_ID is created, it also issues a grant execute to sse_role. This may very well be the missing privilege causing the ORA-00904 failure.
The above action plan resolved the issue.