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
תגובות
הוסף רשומת תגובה