SBL-SVR-01014: Internal: Could not send the HELLO message
Applies to:
Siebel System Software - Version 7.8.2 [19213] and later
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.8.2 [19213]
Database: Oracle 9.2.0.5
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: Sun Solaris 2.8
This document was previously published as Siebel SR 38-2701371851.
Symptoms
SBL-SVR-01014, SBL-NET-01023, SBL-NET-01553, SBL-NET-01205, SBL-NET-00000, SBL-NET-01931, SBL-NET-01924
We are trying to enable SSL in one of our environments. We have
run the SSL configuration utilities for both SWE and the
Enterprise/Server (only one Server in the Enterprise).
SWE and Server are co-located on the same server.
We are using an internal CA that is based on an Entrust.net certificate.
The
SSL works fine from a raw IIS web server perspective. We are using the
.PEM file from the CA for the IIS server as the "Certification File
Name" and an exported and converted .PEM file for the "Certificate
Authority file". The private key has been exported from IIS and
converted to PEM as well.
We get the following error:
MainThread DetachedExit 3 0 2005-11-30
11:07:37 Detached thread (tid 5748) exited with error: Internal:
Error %1 reading a message from the client
SisnapiLayerLog Info 4 0 2005-11-30
11:07:37 8152: [SISNAPI] changing translation mode for
connection(NOT_SET)/global(UCS2) to UCS2
SisnTcpIp SisnSockError 1 0 2005-11-30 11:07:37 8152: [SISNAPI SSL] SSL initialization failed
Thank you for your assistance.
Cause
Configuration/ Setup
Solution
Message 1
For the benefit of other readers:
The Object Manager log file shows the following messages as well:
recv() failed for sd=1880 (err=10054 | An existing connection was forcibly closed by the remote host (peer).)
SBL-NET-01023: Peer disconnected
releasing connection (0xccdbd0), refCount = 0
SBL-SVR-01014: Internal: Could not send the HELLO message: (null)
Certificate files in ASN (DER) format have binary contents, while
certificate files in PEM (Base-64 encoded) format have ASCII contents.
In order to use the PEM format, all three file names must have “.PEM” extension, and their contents should look like this:
- Certificate file: “-----BEGIN CERTIFICATE-----...”
- CA Certificate file: “-----BEGIN CERTIFICATE-----...”
- Private Key file: “Bag Attributes...”
Checking the files customer was using, we realized that the CA Certificate file was actually in ASN format.
In order to download a new version of the CA Certificate file in the
PEM format, if the CA server runs Microsoft Windows 2000 Certificate
Services, this can be easily done by going to
http://<hostname>/certsrv/, clicking “Retrieve the CA certificate
or certificate revocation list”, choosing “Base 64 encoded“, and
clicking “Download CA certificate”.
If this is not possible, the CA Certificate file needs to be
converted to the correct format by using a third-party utility, such as
OpenSSL.
It can be downloaded from http://gnuwin32.sourceforge.net/packages/openssl.htm.
This tool is useful for the private key file, since IIS only exports private keys to the PKCS # 12 format.
The Certificate and Private Key files must have been created for the specific machine where Siebel Server and SWSE are running.
If they are running on different machines, different Certificate and Private Key files will be needed for each machine.
If they are running on the same machine, only one Certificate file and
one Private Key file should be used for both, although there is no need
to use SSL Encryption in this case.
The CA Certificate file is the one used by the CA Root Server that created the server Certificate file.
By reviewing customer’s files again, we noticed that the CA Certificate
file has not been issued to the same CA that issued the server
Certificate file.
After renaming the server Certificate file to
“*.CER” and double-clicking it on Windows, the following information
could be seen:
- Subject (issued to): Server Host Name
- Issuer (issued by): Subordinate Certification Authority Y
- Certification Path:
[.] Root Certification Authority
|__[.] Subordinate Certification Authority X
|__[.] Subordinate Certification Authority Y
|__[.] Server Host Name
Doing the same with the CA Certificate file, we found the following:
- Subject (issued to): Subordinate Certification Authority X
- Issuer (issued by): Root Certification Authority
- Certification Path:
[.] Root Certification Authority
|__[.] Subordinate Certification Authority X
Note that the server Certificate file has been issued by “Subordinate
Certification Authority Y”, and not “Subordinate Certification Authority
X”.
We have also tested replacing Subordinate Certification
Authority X’s CA Certificate file by Root Certification Authority’s CA
Certificate file, but the same behavior was reproduced.
We concluded that customer needs the CA Certificate file from the CA which issued his server Certificate file.
He must use the one from “Subordinate Certification Authority Y”.
The CA file from “Subordinate Certification Authority X” is not the one
customer should be using, since his server Certificate file has not
been issued by “Subordinate Certification Authority X”, although it is
in the trusted certification chain.
The details of the correct CA Certificate file should look like this:
- Subject (issued to): Subordinate Certification Authority Y
- Issuer (issued by): Subordinate Certification Authority X
- Certification Path:
[.] Root Certification Authority
|__[.] Subordinate Certification Authority X
|__[.] Subordinate Certification Authority Y
Applies to:
Siebel Automotive Sales - Version 8.0.0.11 SIA[20440] and later
Information in this document applies to any platform.
Siebel 8.0.0.11 SIA[20440] and Later
***Checked for relevance on 31-01-2013***
Symptoms
Environment:
-------------------
Siebel 8.0.0.11 SIA[20440], Microsoft Windows (32-bit) 2003 R2
Statement of Issue:
-----------------------------
Getting the below errors in almost all component log files :-
-----------------------------------------------------------------------
err=10054 | An existing connection was forcibly closed by the remote host (peer)
SBL-NET-01023: Peer disconnected
SBL-SVR-01014: Internal: Could not send the HELLO message: (null)
SBL-GEN-05009: Unable to connect to the gateway server.
Steps:
---------
not applicable
Error:
-------
SBL-NET-01023: Peer disconnected
SBL-SVR-01014: Internal: Could not send the HELLO message: (null)
SBL-GEN-05009: Unable to connect to the gateway server.
Business Impact:
-------------------------
system testing is blocked due to this
Changes
Setting up of incorrect values for component parameters
Cause
Changing Max Tasks = 300, Max MT Servers=20 & Min MT Servers=5
for all components, including System components caused this issue
Solution
1) Stop the server [both Siebel application & gateway]
2) Replace the current siebns.dat file with old/original siebns.dat file
3) Start the gateway and Siebel app servers
4) Tune the required parameters for required components [ONLY!!] as per below 2 documents
5) Restart the servers
[1]How to Configure Siebel Object Manager (AOM / SOM) in Siebel 7.x and 8.0 (Doc ID 476830.1)
[2]How Synchronous and Asynchronous Server Requests Work, and How To
Tune These Requests for Performance and Availability (Doc ID 477818.1)
--> In this document it is mentioned that --> In general, do not
change the default values of the Server Request Broker component
parameters MaxTasks (100) and MinMTServers (1) and MaxMTServers (1), as
these values will work fine for most deployments.
Applies to:
Siebel System Software - Version: 7.8.2.3 [19221] and later [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.8.2.3 [19221]
Database: Oracle 9.2.0.6
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: IBM AIX 5L 5.2
This document was previously published as Siebel SR 38-3196279459.
Symptoms
SBL-MBL-02087, SBL-MBL-00211, SBL-OMS-00203, SBL-SVR-01014, SBL-NET-01023We have installed SSSE in our acceptance environment, by following exactly the same process, we
try to install it into our production environment but it fails because the PIMSI Engine component
remains unavailable.
I join the log file to the SR
Cause
Configuration/ Setup
Solution
Message 1
For the benefit of other users:
Customer installed SSSE in their acceptance environment without any
problems but when they tried to install it into their production
environment, by following exactly the same process, it failed because
the PIMSI Engine component remained unavailable.
We found following errors in PIMSIEng*.log.
“An existing connection was forcibly closed by the remote host (peer)”.
SBL-NET-01023: Peer disconnected
SBL-SVR-01014: Internal: Could not send the HELLO message: (null)
SBL-MBL-51024: Opened compound file: \\MSAPP024P\WINSHARE\pimsimon.exc.
SBL-MBL-00211: Method GetRunningApps (), Error = 0x8000401A.
SBL-MBL-00211: Method RefreshAppMap (), Error = 0x8000401A.
SBL-MBL-02087: Exchange 2000 connector failed to initialize. Error = 0x8000401A.
DataMgr: Connector Manager Failed to load the connectors ErrCode: 0x7d3
SBL-OMS-00203: Error 2008 invoking method "BusSvcMgrInit" for Business Service "PIMSI Engine Service"
“Terminate process due to unrecoverable error: 4300203. (Main Thread)”
According to the Error messages knowledge base, following are the causes and corrective actions for these errors:
==================================================================
SBL-NET-01023
Cause: The server has closed the connection.
Corrective actions: Restart the server process if necessary and check the network configuration.
SBL-SVR-01014
Cause: SISNAPI hello failed. %1 in the error message is replaced by the ...
Cause: SISNAPI hello failed. %1 in the error message is replaced by the error code from the SISNAPI layer.
Corrective actions: The error is meant for internal diagnostic and
debugging by Siebel Engineering. If you encounter it, please contact
Siebel Technical Support.
=====================================================================
We got customer to check whether they have experienced any Network
problems in their environment before encountering these errors and also
whether they have any major differences between their acceptance
environment and the production environment.
Customer checked and confirmed that in the security setting for the dcom
object, the domain was missing into the user name and by adding this
domain to the user the PIMSI Engine component started correctly and
stayed in available status and the behaviour is resolved with this.
Applies to:
Siebel Email Response - Version 7.7.2.6 [18372] and later
Siebel eCommunications eMail Response - Version 7.7.2.6 SIA [18372] and later
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.7.2.6 [18372]
Database: Oracle 9.2.0.1
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: HP 9000 Series HP-UX
This document was previously published as Siebel SR 38-3212718611.
Symptoms
Our SR broker is going around the same time our workflow policy is
being initiated. We have a work policy called EES PI Sales Rep Email.
This policy sends a email using the ‘Send email’ workflow policy
program. This problem seems to happen periodically because some of our
emails do go thru
Changes
Mail Profile name was updated on the Communications Drivers and Profiles, but not in the Email Manager.
Cause
Mail Profile name
Solution
Message 1
For the benefits of others:
The errors received in enterprise server log:
ServerLog ProcessExit 1 0 2006-11-26
05:02:37 MailMgr 14369 SBL-SVR-01014 Process exited with
error - Internal: Could not send the HELLO message: %1
ServerLog ProcessCreate 1 0 2006-11-26 05:02:37 Created
server process (OS pid = 4676) for Email Manager with task id 14395
ServerLog ProcessExit 1 0 2006-11-26
05:02:38 MailMgr 14395 SBL-SVR-01014 Process exited with
error - Internal: Could not send the HELLO message: %1
ServerLog ProcessCreate 1 0 2006-11-26 05:02:38 Created
server process (OS pid = 5084) for Email Manager with task id 14402
ServerLog ProcessExit 1 0 2006-11-26
14:55:08 CommOutboundMgr 14366 SBL-OSD-01000 Process exited
with error - Internal: The process attempted to read from or write to a
virtual address for which it does not have the appropriate access.
ServerLog ProcessCreate 1 0 2006-11-26 14:55:08 Created
multithreaded server process (OS pid = 712) for Communications Outbound
Manager with task id 14450
Customer resolved the issue. It was discovered that the Mail Profile
name was updated on the Communications Drivers and Profiles, but not in
the Email Manager. After synchronizing the names everythinng started to
work.
Customer followed verifying their configuration of the Email Manager component and this particular document was used :
How can Users Set Up Email Manager for Siebel Version 7.5 and Above? (Doc ID 551903.1)
Applies to:
Siebel System Software - Version 7.7.2.3 SIA [18361] to 8.1.1 SIA [21111] [Release V7 to V8]
z*OBSOLETE: Microsoft Windows Server 2003
Version: 7.7.2.3 [18361] Com/Med
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-2474562941.
***Checked for relevance on 24-SEP-2012***
Symptoms
SBL-SVR-01014
Dear Support,
we have already installed application server as described in Bookshelf
and then we wanted to start jobs for "eLoyalty Processing Engine -
Batch" component manually (1 sever, 1 process, 2 threads) however the
tasks finished in error - see attached logs. Please can you provide us
some suggestions how to solve the error?
NOTE: based on Siebel atert 1193 I check the values on Server Key Map
field Server name. I have filled there values "SBLLPD01_SS" (it is
Siebel server, but not physical server name. What is really required ?)
No localhost string has been used during installation.
Thank you.
Regards,
Cause
Filed case sensitive.
Solution
Message 1
For benefit of other readers, customer received following errors in the log file
“SBL-SVR-01014: Internal: Could not send the HELLO message: (null)” when starting the task manually.
Solution
Further research showed that although Siebel Server Name under
Administration - Loyalty Programs was specified under Server Key Map
field Server name instead of physical server name, this field is case
sensitive. Customer had specified this in uppercase and restarted the
batch components. After changing it to lower case, the problem was
resolved.
Please refer to Siebel Bookshelf version 7.7 > Siebel Loyalty
Administration Guide > Getting Started with Siebel Loyalty >
Setting Up Server Keys for Siebel Loyalty for further information.
Applies to:
Siebel Remote - Version: 7.8.2 SIA [19213] and later [Release: V7 and later ]
HP-UX PA-RISC (64-bit)
Oracle Database 9.2.0.8
Symptoms
After Upgrade from 7.5.3.15 to 7.8.2, Dbxtract, GenTrig and GenNewDb
components are not working. Log aren't even getting created.
Srvrmgr log file shows the following errors:
SBL-NET-01023: Peer disconnected
SBL-SVR-01014: Internal: Could not send the HELLO message: (null)SRBroker log file shows the following errors:
SBL-NET-01023: Peer disconnected
SBL-SVR-01014: Internal: Could not send the HELLO message: (null)
SBL-SRB-00027: invalid routing information Note that SBL-SRB-00027 is not a very common error at all.
The following actions were taken but didn't solve the issue:
- Synchronize enterprise and restarted server
- Full uninstall and install of the whole enterprise
- Truncate s_srm_request
- Apply workaround described on Oracle Bug 6066116 (Doc ID: 435458.1 - On Oracle Database support site)
- Recreate diccache.dat
- Reassign "System" Component Group to the server
- 'Run task" instead of "start task" in the server manager command line utility.
- Review of data on s_srm_request and s_srm_data didn't show anything wrong.
- Apply patch 7.8.2.9
Solution
The issue got resolved by applying patch 7.8.2.11.
Applies to:
Siebel System Software - Version 7.7.2.7 [18376] to 8.1.1.3 SIA[21219] [Release V7 to V8]
Siebel CRM - Version 7.7.2.7 [18376] to 8.1.1.3 SIA[21219] [Release V7 to V8]
HP-UX PA-RISC (32-bit)
HP-UX Itanium
Symptoms
On Siebel release 8.1.1.3 [21219] version and HP-UX environment:
In this particular case:
- When attempting to execute a batch job through server manager commands, the following errors were displayed:.
SBL-ADM-60070: Error reported on server 'server1' follows:
SBL-SVR-01014: Internal: Could not send the HELLO message: (null)
SBL-NET-01023: Peer disconnected
- The submitted job just stayed on 'Queued' status.
- The behavior also occured on GUI.
Another case:
- A Repeating Component Job (RCR) was submitted.
- The jobs were executed successfully and suddenly new jobs just stayed on 'Active' status.
-
The Siebel services were restarted and the pending jobs were executed
successfully until the new jobs stayed again on 'Active' status.
Cause
"HP-UX Web-Based Enterprise Management" (WBEM), available along with
HP-UX OS, was running on the same box where Siebel services were running
too.
HP WBEM Services is a management utility that allocates
ports in the same range as the Siebel processes, starting at port 49152.
However, WBEM binds these daemons named "cimprovagt" only to the
loopback adapter.
Therefore, the ports used by WBEM are not recognized as busy and Siebel binds to the same ports on all interfaces.
This
causes disruption when a component is bounced or some SISNAPI
communication between the batch components is interfering with WBEM
traffic.
"netstat -an" output showing duplicate port allocation can look like:
tcp 0 0 127.0.0.1.49153 *.* LISTEN
tcp 0 0 *.49153 *.* LISTEN
tcp 0 0 127.0.0.1.49153 *.* ESTABLISHED
tcp 0 0 *.49153 *.* ESTABLISHED
or
tcp 0 0 localhost.49153 *.* LISTEN
tcp 0 0 server1.49153 *.* LISTEN tcp 0 0 localhost.49153 *.* ESTABLISHED
tcp 0 0 server1.49153 *.* ESTABLISED
Where:
italic: corresponds to WBEM:cimprovagt binding to localhost (127.0.0.1)
bold: corresponds to Siebel binding to * or <SiebelServer>
Port
49153 was assigned to a localhost of WBEM. But, Siebel server is also
listening to the same port for one of the batch components.
Siebel does not check for all busy ports which are held by the WBEM
loopback method. If any of the ports (above 49152) are associated by the
loopback method, then these ports will be taken as free and used by
Siebel.
The below bugs were raised to report the behavior:
Bug 10642972 Make Siebel Server Bind Using SO_REUSEADDR Configurable - It Does Not Detect Port Bound To Loopback.
Bug 10642973 Make The First Port That Siebel Server Scans For An Available Port Configurable - Currently 49152.
Solution
- The solution of the issue is switch off the HP WBEM utility.
-- or -- - Configure HP WBEM to use a port range that does not conflict with the Siebel Server.
NOTE: An available workaround is also described in Port
in Use / Blocked - Cannot access FSMSrvr (or other component) through
SRBroker - SISNAPI Error - HP-UX / HP Open View (Doc ID 875068.1).
While
the method described in this document provides a temporary solution, HP
may be able to provide recommendations to customers to add ndd commands
to the boot script files for HP 11.0 so that these changes are
persistent across reboots.
Applies to:
Siebel Call Center - Version 7.5.3.4 [16180] and later
Information in this document applies to any platform.
Symptoms
The following errors are observed in the Development environment, when starting tasks from the Server Manager command-line:
start task for component WfProcMgr with ProcessName="<process name>"
SBL-NET-01033: The SISNAPI handshake timed out. The Siebel Service may not be running.
SBL-SVR-01014: Internal: Could not send the HELLO message: (null)
The WfProcMgr component is Online in the Development environment.
The same behavior does not reproduce in the Test environment - it is consistently working
Cause
After reviewing the Server Request Broker (SRBroker) log files, it
was decided to obtain information about the Workflow Process Manager
(WFProcMgr) component on both the Development and Test environments. The
customer was asked to run the following from srvrmgr:
spool WfProcMgr_<env>.txt
list servers
list comp WfProcMgr
list params for comp WfProcMgr
list evtloglvl for comp WfProcMgr
list tasks for comp WfProcMgr
spool off
When examining these spools, we found the cause of this problem. The
'Run Mode' for the WfProcMgr component in the Test environment is
correctly set to 'Batch'. However, in Dev, it is 'Background', which is
incorrect. This was verified on the Technical Support lab environment
and it is 'Batch' there also.
Solution
The customer was advised to stop the Siebel Server system service in
Dev and also the Gateway Server system service. When these were fully
shut down - ie. the Siebel environment is not running at all in Dev,
they were advised to provide their siebns.dat file.
Using this "cold" siebns.dat file, we changed the 'Run Mode' for WfProcMgr to 'Batch'.
The
customer was subsequently provided the updated siebns.dat file and
placed this in their Development environment - again with the Siebel
system services shutdown.
This resolved this behavior.
Applies to:
Siebel System Software - Version 7.7.2.2 [18356] 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
***Checked for relevance on 07-Feb-2013***
Symptoms
SBL-SVR-01014, SBL-SMI-00033, SBL-SMI-00049, SBL-CSO-01031, SBL-GEN-09103
In 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.
Keywords: SRBroker, Server, Request, Settings, MT, Task, Parameters, Asynchronous, Monitor, Scheduler, Components
Applies to:
Siebel Remote Server - Version 7.5.3.12 [16272] to 8.1 [21039] [Release V7 to V8]
Siebel Remote - Version 7.5.3.12 [16272] to 8.1.1.4 [21225] [Release V7 to V8]
HP-UX Itanium (32-bit)
Symptoms
Running the
Generate New Database Template job from the GUI
(without any parameters set)
failed,
and running the srvrmgr command
start task for comp gennewdb
resulted in
SBL-ADM-60070: Error reported on server 'siebsrvr1' follows:
SBL-SVR-01014: Internal: Could not send the HELLO message: (null)
SBL-NET-01023: Peer disconnected
GenNewDb_*.log (all event log levels set to 5)
showed the following errors:
GenericLog GenericError 1 00008b84496a5269:0 2009-01-13
08:08:57 SQL Message, 08001: [Siebel Database][ODBC Driver][Adaptive
Server Anywhere]Unable to start database server
DBCLog DBCLogError 1 00008b84496a5269:0 2009-01-13
08:09:07 [Sybase][ODBC Driver][Adaptive Server Anywhere]Unable to start
database server
GenericLog GenericError 1 00008b84496a5269:0 2009-01-13
08:09:07 SQL Message, 08001: [Siebel Database][ODBC Driver][Adaptive
Server Anywhere]Unable to start database server
GenericLog GenericError 1 00008b84496a5269:0 2009-01-13
08:09:17 Error creating SQL Anywhere database template file
(UTLOdbcConnect DBA/siebelmobiledb).
GenericLog GenericError 1 00008b84496a5269:0 2009-01-13 08:09:17 Error in MainFunction (CreateDbTemplateFile)
GenericLog GenericError 1 00008b84496a5269:0 2009-01-13
08:09:17 (gennewdb.cpp (610) err=524292 sys=2) SBL-GDB-00004: Error in
Main function.
RecovTry RecovDBConn 1 00008b84496a5269:0 2009-01-13 08:09:23 Attempting to recover from a DB Connection Loss
Changes
The customer solved the error by
"adding lib server to SHLIB_PATH."
Now the database server can start the [Adaptive Server Anywhere] database
and the gennewdb task completes successfully.
Further details were not provided - the HP-UX environments in Tech
Support already have the following settings in their siebenv.csh:
setenv SQLANY ${SIEBEL_ROOT}/SYBSsa90
and
setenv SHLIB_PATH ${SHLIB_PATH}:${SQLANY}/lib:${SQLANY}/lib_server
on a standard installation,
so these settings MAY earlier have been manually removed.
Cause
not having
setenv SQLANY ${SIEBEL_ROOT}/SYBSsa90
and
setenv SHLIB_PATH ${SHLIB_PATH}:${SQLANY}/lib
in the siebenv.sh
or not sourcing siebenv.sh
may cause the errors above
Solution
make sure
setenv SQLANY ${SIEBEL_ROOT}/SYBSsa90
and
setenv SHLIB_PATH ${SHLIB_PATH}:${SQLANY}/lib
are included in your siebenv.sh
and the Siebel Server is restarted after changes.
Apologies
for having partially duplicate information in the various sections of
this document - the Metalink publishing "wizard" requires this
separation, even if it may make published information more confusing
than one combined solution text.
תגובות
הוסף רשומת תגובה