Search This Blog

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












No comments:

Post a Comment