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:

1. Synchronize enterprise and restarted server
2. Full uninstall and install of the whole enterprise
3. Truncate s_srm_request
4. Apply workaround described on Oracle Bug 6066116 (Doc ID: 435458.1 - On Oracle Database support site)
5. Recreate diccache.dat
6. Reassign "System" Component Group to the server
7. 'Run task" instead of "start task" in the server manager command line utility.
8. Review of data on s_srm_request and s_srm_data didn't show anything wrong.
9. 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

1. The solution of the issue is switch off the HP WBEM utility.
   
   -- or --
   
2. 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.