Fixing date field Jumbing in Siebel open UI

There might be some issue with date input field. We need to edit the css files to fix this problem.
I got the same problem in vanila SRF also.

Above image is before selecting/clicking calender Icon

After clicking calender icon. You can see its length is increased.


To solve this probelm, go to
theme-base.css file in your "files" folder.

.mceGridField input.siebui-input-popup {
        max-width: 119px;
    }

Here   max-width: 119px is given as our input filed. If you need more than this width, you can alter this.

GetProfileAttr/SetProfileAttr not Working in Siebel 8.1.1.10

In 8.1.1.10 version, SetProfileAttr() has been disabled for HTTP calls as a security fix.
That means if you have a browser scripts uses SetProfileAttr(), it won't work. No change to GetProfileAttr() access.
Oracle disable this "SetProfileAttr()" as a security fix. So enabling this is not recommended.

SetProfileAttr() access can be turned on by setting the server parameter “EditProfileAttr” value to TRUE

Siebel Mobile Connected Apps - Side effects of custom toggle applets.

We've been doing some development on the very new Siebel mobile connected apps. The Siebel Mobile app is a huge and exciting addition to Siebel CRM. However, Just like all new products, you can expect some product defects in the initial version of the software.

We will be updating this blog with all the bugs we come accross and their workarounds untill we have a permanent solution from Oracle.

Issue: Side effects of custom toggle applet in Siebel Mobile connected apps.

Here is how you can reproduce the Issue -

Create a toggle applet on a Form Applet to toggle on a particular LOV value. Lets say the LOV toggle Value is 'Retailer'

Issue 1 - (New Record renders the applet in Base Mode)

The applet opens in Base mode when the record context is the value (Retailer) used for the toggle in the list applet. However when you create a new record from other types record, this does not happen.

Issue 2 - (Toggling back from the toggle applet, renders the applet in Base Mode)

After you have selected the Toggle, and the toggle applet is active switch back to another LOV so the original applet loads. The applet switches to Base mode instead of staying on Edit mode.

Issue 3 - (Applet switches to List Applet on New record instead of opening the entry form applet) - Happens only in iPhone Mode
 
Upon creating a new record the applet switches to List mode (without loosing context, which is Ok). You then have to tap on the record again to go to Detail mode to edit/ enter data

Workaround:

The workaround to the above three issues would be to do away with the base mode completely, and have the applet render in Edit Mode at all times. You can do this by simply selecting the Applet Mode to Edit in the View web template items property.

Although, this is not the best approach to have a record editable at all times, especially when using a touch phone/pad. Its the only way that can keep the toggle from not breaking.

Any other workarounds are very welcome!

Cheers!

SBL-SVR-01074

Applies to:

Siebel Assignment Manager - Version: 7.5.3 [16157] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.5.3 [16157]

Database: Oracle 9i

Application Server OS: Microsoft Windows 2000 Server SP 2

Database Server OS: Redhat Linux Advanced Server 2.1



This document was previously published as Siebel SR 38-1464958381.

Symptoms

Customer getting the following messages in the Assignment Manager Log

021
2004-07-28 22:41:53 2004-08-20 18:44:08 -0700 00000005 001 001f 0001 09
AsgnSrvr 31802 4964 792 C:\sea752\siebsrvr\log\AsgnSrvr_31802.log 7.5.3
[16157] ENU ServerLog    LstnObjInherit    3   
2004-07-28 22:41:53    Inherited listening object for port 49159 ServerLog    LstnObjPrivCreate    3   
2004-07-28
22:41:53    Created port 49177 for Assignment Manager
GenericLog    GenericError    1    2004-08-20 18:43:36    (scirkey.cpp
13(819) err=2001074 sys=0) SBL-SVR-01074: Routing key All AM Rule Set
was not found GenericLog    GenericError    1    2004-08-20
18:43:36    (scirkey.cpp 13(285) err=2001074 sys=0) SBL-SVR-01074:
Routing key (null) was not found
GenericLog    GenericError    1    2004-08-20 18:43:36    (scirkey.cpp
13(1020) err=2001074 sys=0) SBL-SVR-01074: Routing key (null) was not
found

Changes

some assignment rules were changed when the error started

Cause

This is a benign error in the log file and can be ignored.

Solution

To avoid this error message in the log file, Please set the logging level to minimal for the assignment manager component.

There is an existing change request 12-M7NBG9 logged for this error messages in the log file.

Applies to:

Siebel Test Automation Interfaces - Version 8.0 SIA [20405] to 8.2.2.2 SIA[23016] [Release V8]
Information in this document applies to any platform.

Checked for relevance 28-02-2012

Goal

How to change advanced component parameter using srvrmgr, e.g. set MaxSkillsAge to 60 for comp AsgnSrvr?

Fix

Please note that you will need to specify the "advanced" keyword
when listing the parameter but not when changing or modifying the
parameter setting. The command should be used as below.

srvrmgr> list advanced param MaxSkillsAge for comp AsgnSrvr

srvrmgr> change param MaxSkillsAge=60 for comp AsgnSrvr








Note:



Running the following command will give error:


srvrmgr>change advanced param MaxSkillsAge=60 for comp AsgnSrvr
SBL-GEN-00001: (svradml.cpp: 222) error code = 1, system error = 0, msg1 = (null), msg2 = (null), msg3 = (null), msg4 = (null)


There were following Generic Error in AsgnSrvr logs::

GenericLog
GenericError 1 0 2010-08-30 22:17:19 (scirkey.cpp (286) err=2001074
sys=0) SBL-SVR-01074: Routing key All AM Rule Set was n
ot found.
GenericLog
GenericError 1 0 2010-08-30 22:17:19 (scirkey.cpp (1021) err=2001074
sys=0) SBL-SVR-01074: Routing key All AM Rule Set was
not found.
Generic Error 1 0 2010-08-30 22:17:19 Could not deregister default key "All AM Rule Set"

SBL-SVR-01069

Applies to:

Siebel Scheduling - Version: 7.8.2.2 SIA [19219] and later   [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.8.2.2 [19219] NLD Pub Sect

Database: Oracle 10g

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-3035897353.

Symptoms

The customer had created a new Siebel environment and copied the
database from another existing environment to this new environment.
-
The initial server key mappings for the Appointment Booking Service
(ABS) were in the database when it was copied to the new environment.
This means that the new environment had server key mappings which
pointed to a non-existing server.
- When it was first started, ABS errored out due to the fact that the server key mappings were invalid.
-
The server key mappings were updated with the new Siebel server name,
and the Siebel service was restarted after changing the server key
mappings.
- When the Siebel server is restarted, the ABS tries to start but fails with SIGABRT.

The Siebel server log says:
..
ServerLog
ProcessCreate 1 0 2006-05-10 16:03:18 Serverproces met
meerdere threads aangemaakt (PID besturingssysteem = 376842) voor
Appointment Booking Engine met taak-ID 6306
ServerLog ProcessExit
1 0 2006-05-10 16:04:02 ApptBook 6306
SBL-OSD-02006 Process exited with error - Proces beëindigd vanwege
ontvangen van signaal SIGABRT.
..
After 10 retries it gives up.

In the ApptBook log it says:
..
GenericLog
GenericError 1 0 2006-05-09 18:21:30 (scirkey.cpp (215)
err=2001069 sys=0) SBL-SVR-01069: Deze component, die gebruikmaakt van
unieke sleutels, probeert een bestaande sleutel vast te leggen (1-URXGL)
GenericLog
GenericError 1 0 2006-05-09 18:21:30 (scirkey.cpp (987)
err=2001069 sys=0) SBL-SVR-01069: Deze component, die gebruikmaakt van
unieke sleutels, probeert een bestaande sleutel vast te leggen (1-URXGL)
Execution
Warning 2 0 2006-05-09 18:21:30 De engine kan
serviceregio 1-URXGL (1) niet registreren bij Siebel Server SRCWIT102.
Execution
Warning 2 0 2006-05-09 18:21:30 De engine kan geen
serviceregio registreren bij Siebel Server SRCWIT102.
..
This behavior happens when executing the BusSvcMgrInit and ReloadServiceRegion methods.

Translation of error messages:
* SBL-OSD-02006 - Process exited because it received signal SIGABRT.
* SBL-SVR-01069 - This component is using unique keys and it is trying to register an existing key (1-URXGL)
* SBL-ABS-00109 - The engine failed to register any service region with Siebel server 'SRCWIT102'

Cause

The behavior was caused by the previously existing server key mappings pointing to a different environment.
It
seems that somewhere the server key mapping is stored and even after
updating it and restarting the Siebel server, it still has not
deregistered the previous server key.

Solution

Just changing the server key mappings to the correct Siebel server did not resolve the behavior.
It was necessary to recreate the mappings by deleting and adding the correct lines.



Keywords: SBL-ABS-00109, SBL-ABS-00110, Server Key Mappings, Register,
Service Region, BusSvcMgrInit, ReloadServiceRegion, ApptBook, ABS,
Optimizer

Applies to:

Siebel Scheduling - Version: 8.0.0.8 SIA[20430] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

ABS is not loading the service regions on all Siebel Servers upon Siebel Server service or ApptBook component restart.



Specific Error Message:



GenericLog GenericError 1 000000054ca3f0fe:0 2010-09-29 17:39:06
(scirkey.cpp (232) err=1311789 sys=0) SBL-SVR-01069: This component is
using unique keys and it is trying to register an existing key
(1-8E7-113)

GenericLog GenericError 1 000000054ca3f0fe:0 2010-09-29 17:39:06
(scirkey.cpp (1047) err=1311789 sys=0) SBL-SVR-01069: This component is
using unique keys and it is trying to register an existing key
(1-8E7-113)

Execution Warning 2 000000054ca3f0fe:0 2010-09-29 17:39:06 The
engine failed to register service region '1-8E7-113 (1)' with Siebel
Server 'aixprd10'.

GenericLog GenericError 1 000000054ca3f0fe:0 2010-09-29 17:39:06
(scirkey.cpp (232) err=1311789 sys=0) SBL-SVR-01069: This component is
using unique keys and it is trying to register an existing key
(1-8E7-100)

GenericLog GenericError 1 000000054ca3f0fe:0 2010-09-29 17:39:06
(scirkey.cpp (1047) err=1311789 sys=0) SBL-SVR-01069: This component is
using unique keys and it is trying to register an existing key
(1-8E7-100)

Execution Warning 2 000000054ca3f0fe:0 2010-09-29 17:39:06 The
engine failed to register service region '1-8E7-100 (2)' with Siebel
Server 'aixprd10'.



Sequence of Event:



1. Restart Siebel Server service or ApptBook component.

The ApptBook component is enabled and online.

2. Service Regions are loaded in ABS cache with error SBL-SVR-01069.



What is working:



Click on Load ABS on each Service Region to reload all the service
regions, and all are loaded and registered successfully without error
SBL-SVR-01069.





Environment:



Affecting Assignment Booking in both UAT and Production environments.

Siebel version: 8.0.0.8 SIA [20430] QF0858 , Siebel Server: IBM AIX on POWER Systems (32-bit), Database: Oracle 10.2.0.4

UAT has one Siebel Server 'aixuat06', it is a multi-processor machine.

Production has two Siebel Servers 'aixprd10' and 'aixprd14', both are multi-processor machines.

Cause

On multiprocessor machine, Service Regions can be mapped to ApptBook
component on multiple processess, and each process is represented by a
process#. It is accomplished by setting MinMTServers = MaxMTServers >
1for ApptBook component, e.g., MinMTServers = MaxMTServers = 4 for
ApptBook component. And the error SBL-SVR-01069 in loading Service
Regions only happens to Service Regions mapped to multiple processes,
i.e., more than one process#. If Service Regions are mapped to ApptBook
component on one process only which is accomplished by setting
MinMTServers = MaxMTServers = 1, then the error SBL-SVR-01069 doesn't
happen when loading Service Regions.





The service regions loaded in the very 1st process don't have the error,
and in ApptBook log for Process 1 doesn't have any error, this can be
seen in ApptBook_0025_26214403.log from Logs_101310.zip:



Execution Trace 3 000000054cb670ee:0 2010-10-13 16:11:27 The engine
registered service region '1-EEUQWC (1)' with siebel server 'aixuat06'.

Execution Trace 3 000000054cb670ee:0 2010-10-13 16:11:27 The engine
registered service region '1-EEUQWO (1)' with siebel server 'aixuat06'.



The service regions loaded after 1st process have the error, because for
each process ApptBook always starts with all service regions with
Service Region's ROW_ID and Process# in ascending order, we can see from
ApptBook_0027_28311555.log from Logs_101310.zip the SQL being executed
in the log that select all service regions with Service Region's ROW_ID
in ascending order, and the error:



ObjMgrSqlLog Detail 4 000000054cb6901c:0 2010-10-13 16:11:26 SELECT statement with ID: 3056F2F8

SELECT /*+ ALL_ROWS */

T2.CONFLICT_ID,

T2.LAST_UPD,

T2.CREATED,

T2.LAST_UPD_BY,

T2.CREATED_BY,

T2.MODIFICATION_NUM,

T2.ROW_ID,

T2.COMPONENT_ID,

T1.NAME,

T2.PROCESS_NUM,

T2.SERVER_NAME,

T2.SRV_REGN_ID

FROM

SIEBEL.S_SRM_ACTION T1,

SIEBEL.S_SCH_SRV_MAP T2

WHERE

T2.COMPONENT_ID = T1.ROW_ID AND

(UPPER(T2.SERVER_NAME) LIKE UPPER(:1) AND T1.NAME = :2)

ORDER BY

T2.PROCESS_NUM, T2.SRV_REGN_ID

ObjMgrSqlLog Detail 4 000000054cb6901c:0 2010-10-13 16:11:26 Bind variable 1: aixuat06

ObjMgrSqlLog Detail 4 000000054cb6901c:0 2010-10-13 16:11:26 Bind variable 2: ApptBook



GenericLog GenericError 1 000000054cb6901c:0 2010-10-13 16:11:27
(scirkey.cpp (232) err=1311789 sys=0) SBL-SVR-01069: This component is
using unique keys and it is trying to register an existing key
(1-EEUQWC)

GenericLog GenericError 1 000000054cb6901c:0 2010-10-13 16:11:27
(scirkey.cpp (1047) err=1311789 sys=0) SBL-SVR-01069: This component is
using unique keys and it is trying to register an existing key
(1-EEUQWC)

Execution Warning 2 000000054cb6901c:0 2010-10-13 16:11:27 The engine
failed to register service region '1-EEUQWC (1)' with Siebel Server
'aixuat06'.



The ones already loaded will get the error, as shown as above error,
until it gets to the ones to be loaded on the designated process#, and
then load them successfully in the designated process#:



Execution Trace 3 000000054cb6901c:0 2010-10-13 16:11:27 The engine
registered service region '1-EEUQVX (2)' with siebel server 'aixuat06'.

Execution Trace 3 000000054cb6901c:0 2010-10-13 16:11:27 The engine
registered service region '1-EEUQWX (2)' with siebel server 'aixuat06'.



And it goes like this until all Service Regions in all processes are loaded.

Solution

1. Use the existing Service Region configuration in place which is multiple server processor mappings, no changes needed:



- MinMTServers = MaxMTServers = 4 for ApptBook component on each Siebel Server.

- Map Service Regions to one of the 4 process#: 1, 2, 3, 4 for ApptBook
component on Siebel Servers in Server Key Mappings In client application
> Site Map > Administration - Scheduling:



PROCESS_NUM SERVER_NAME SRV_REGN_ID COMPONENT_ID

4 aixuat06 1-EEUQVL 1-35D5

4 aixuat06 1-EEUQVO 1-35D5

3 aixuat06 1-EEUQVR 1-35D5

3 aixuat06 1-EEUQVU 1-35D5

2 aixuat06 1-EEUQVX 1-35D5

3 aixuat06 1-EEUQW0 1-35D5

3 aixuat06 1-EEUQW3 1-35D5

3 aixuat06 1-EEUQW6 1-35D5

4 aixuat06 1-EEUQW9 1-35D5

1 aixuat06 1-EEUQWC 1-35D5

4 aixuat06 1-EEUQWF 1-35D5

3 aixuat06 1-EEUQWI 1-35D5

3 aixuat06 1-EEUQWL 1-35D5

4 aixuat06 1-EEUQX0 1-35D5

1 aixuat06 1-EEUQWO 1-35D5

3 aixuat06 1-EEUQWR 1-35D5

4 aixuat06 1-EEUQWU 1-35D5

2 aixuat06 1-EEUQWX 1-35D5





2. The error SBL-SVR-01069 in loading Service Regions in the multiple
processor mappings should be benign and can be ingored. The Service
Region's Server Key Mappings should be correct. The Documentation
Enhancement CR 10602873 has been created to document the following in
Siebel Field Services Guide:



=====

Multiple Processor Support documentation needs to include the following:



Restarting Siebel Server which restarts ApptBook component, you get
error SBL-SVR-01069 in Process 2 trying to load the Service Region
already loaded on Process 1:



SBL-SVR-01069: This component is using unique keys and it is trying to register an existing key (1-CSIQ)

The engine failed to register service region '1-CSIQ (1)' with Siebel Server 'siebsrvr1'.



Book an appointment with service region 1-CSIQ right after without
reloading by executing Load ABS on 1-CSIQ, and it is successful.



Explanation is as long as Service Regions are mapped to multiple
processes, you will get SBL-SVR-01069 for higher process# > 1 because
Service Regions are loaded sequentially starting with lowest process#
during ApptBook component starts up, the error SBL-SVR-01069 is
informational, it is benign.

=====

Applies to:

Siebel Scheduling - Version: 7.5.3.4 SIA [16180] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.5.3.4 SIA [16180] and above

Database: Any Database

Application Server OS: Any Application Server OS

Database Server OS: Any Database Server OS





This document was previously published as Siebel SR 38-2743675661.

Symptoms

Customer created a workflow process which uses the "Server Request"
business service to submit a request to the Appointment Booking Service
(ABS) to run the ReloadServiceRegion method. This workflow process is
scheduled to run every day at 5:00 AM.

When the Siebel Server
services first come up, the Appointment Booking Engine is also online
and the ApptBook component is able to register each service region and
load each service region into cache. Users are then able to book
appointments throughout the day. However, once the workflow process to
reload service region is executed the following happens:

a. The resulting ApptBook task that attempts to reload service regions fails with error message:
GenericLog
GenericError 1 2005-12-16 05:02:33 (scirkey.cpp 13(986)
err=2001069 sys=0) SBL-SVR-01069: This component is using unique keys
and it is trying to register an existing key ((null))
Execution
Warning 2 2005-12-16 05:02:33 The engine failed to register
service region '1-1J6MMA (1)' with Siebel server 'V04751S846'.

b.
The ApptBook component stopped returning appointments to the users.
Rather, the ApptBook component returned an error message to the user as
follows:
ApptBook with key [1-1J6MMA] is not available

Cause

Upon checking the customer's log files, they revealed the following:

----------------------------------------

[1] The ApptBook component came up when Siebel Server started:

ServerLog
ProcessCreate 1 2005-12-15 16:49:30 Created multithreaded
server process (OS pid = 3032) for Appointment Booking Engine with task
id 51265
....
ServerLog ProcessCreate 1 2005-12-16
05:02:18 Created server process (OS pid = 2836) for Siebel Server
Scheduler with task id 51499
; A new ApptBook process started here,
before the original one even completed. It is unclear at this time why a
new ApptBook process was started.
....
ServerLog ProcessExit 1 2005-12-16 05:17:05 ApptBook 51265 SUCCESS Process completed Successfully
; After 15 minutes the original ApptBook process was shutdown.

----------------------------------------

[2]
In the ApptBook_51265.log component log file for the above old process,
we can see all 4 service regions registered and loaded:

2021
2005-12-15 16:49:31 2005-12-16 05:17:05 -0500 00003f99 001 001f 0001 09
ApptBook 51265 3032 3028 C:\sea752\siebsrvr\log\ApptBook_51265.log
7.5.3.12 [16272] ENU
....
Execution Trace 3 2005-12-15
16:50:06 The engine registered service region '1-1J6MMA (1)' with
siebel server 'V04751S846'.
Execution Trace 3 2005-12-15
16:50:06 The engine registered service region '1-1J6MMB (1)' with
siebel server 'V04751S846'.
Execution Trace 3 2005-12-15
16:50:06 The engine registered service region '1-1LFGZZ (1)' with
siebel server 'V04751S846'.
Execution Trace 3 2005-12-15
16:50:06 The engine registered service region '1-1LFH00 (1)' with
siebel server 'V04751S846'.
....

----------------------------------------

[3] For the new ApptBook process, the component tried to register a service region with the Server Request Broker but failed:

2021
2005-12-16 05:02:18 0000-00-00 00:00:00 -0500 00000000 001 001f 0001 09
ApptBook 51499 2836 2812 C:\sea752\siebsrvr\log\ApptBook_51499.log
7.5.3.12 [16272] ENU
....
GenericLog GenericError 1
2005-12-16 05:02:33 (scirkey.cpp 13(214) err=2001069 sys=0)
SBL-SVR-01069: This component is using unique keys and it is trying to
register an existing key (1-1J6MMA)
GenericLog GenericError 1
2005-12-16 05:02:33 (scirkey.cpp 13(986) err=2001069 sys=0)
SBL-SVR-01069: This component is using unique keys and it is trying to
register an existing key ((null))
Execution Warning 2
2005-12-16 05:02:33 The engine failed to register service region
'1-1J6MMA (1)' with Siebel server 'V04751S846'.
ObjMgrBusCompLog Delete 4 2005-12-16 05:02:33 BusComp was deleted d8bd578 "Scheduler Server Keys"
SQL SQL 4 2005-12-16 05:02:33 4 row(s) retrieved by ID: D9DDB20
Execution
Warning 2 2005-12-16 05:02:33 The engine failed to register
any service region with Siebel server 'V04751S846'.
ObjMgrBusServiceLog
InvokeMethod 4 2005-12-16 05:02:33 Business Service
'Appointment Booking Service' invoke method 'BusSvcMgrInit' Execute
Time: 0.178 seconds.
....

It seems that the original ApptBook
process/pid was up along with the Siebel Server services and it was
working fine. However, somehow another ApptBook process got started and
caused the original one to shutdown. The new pid was not able to
register with SRBroker as SRBroker already saw the same key from the
earlier ApptBook task, and it cannot register an existing key.

----------------------------------------

[4] When checking one of the ApptBook log files that had some parameter information, this information was found:

TaskConfig TaskCfgParamInit 4 2005-12-16 05:02:18 Maximum MT Servers : 5
TaskConfig TaskCfgParamInit 4 2005-12-16 05:02:18 Memory-based multithread component recycling : FALSE
TaskConfig TaskCfgParamInit 4 2005-12-16 05:02:18 Process memory usage limit : 1500
TaskConfig TaskCfgParamInit 4 2005-12-16 05:02:18 Minimum MT Servers : 1
TaskConfig TaskCfgParamInit 4 2005-12-16 05:02:18 Maximum Tasks : 20

Note how Max MT = 5, meaning that if needed, there can be 5 ApptBook concurrent processes running.
Min MT = 1, meaning that when ApptBook component first comes online, only one ApptBook process is running.

Maximum
Tasks = 20, meaning that 1 process can only handle 20 concurrent tasks.
If the 21st request comes into ApptBook, then a new ApptBook process is
started up to handle the 21st - 40th concurrent tasks. This is the
reason why the new ApptBook process was automatically started while the
original ApptBook process was still running.

However, the new
ApptBook process could not register itself nor the service regions with
SRBroker because the Server Key Mappings says that all service regions
are running on ApptBook process # 1 (Process # 1 being the 1st ABS
process that was started from the Siebel server services startup).

Solution

In order to address this behaviour, customer was suggested to do the following:

1.
Customer currently has all service regions registered to Process # 1 of
ABS. Thus, they should only have Minimum MT Server = 1. If it is
expected that there would be more than 20 concurrent tasks for ABS, the
Maximum Tasks parameter value on on ABS can be increased to 100 tasks.

2.
Then, change the Maximum MT Server on ABS to 1, so that there is only
one ABS process running on the system since all the service regions in
this case are registered to only 1 process anyway.

3. After applying above changes, restart the Siebel servers.

If
having Min and Max MTS = 1 and Maximum Tasks = 100 is not able to
support the number of concurrent requests for ABS, another alternative
is to do the following:

Set Min and Max MTS = 4
Update the Service Region's Server Key Mapping to have 1 Service Region per ApptBook Process #:

Service Region 1 -> Process # 1
....
Service Region 4 -> Process # 4

This way, the load can be distributed across multiple ApptBook processes according to service regions.

This
customer applied the approach to set Min MT = 1, Max MT = 1, Max Tasks =
100, all 4 service regions mapped to Process # 1 of ApptBook component,
and this setting helped resolve the behaviour they were seeing. When
their workflow runs to reload service regions, each service region was
reloaded successfully. In addition, the ApptBook component continued to
work properly to return appointments to the users after the service
region cache was updated.


Search keywords: ABS, apptbook,
book appointment, reload service region, workflow, submit, request,
error, failure, component, restart, shutdown, recycle, startup, This
component is using unique keys and it is trying to register an existing
key , The engine failed to register service region, ApptBook with key,
is not available, process, multiple, MTS, MT, minimum, maximum, tasks

Applies to:

Siebel System Software - Version: 7.7.2 [18325] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Professional)

Version: 7.7.2 [18325] FRA

Database: Microsoft SQL Server 2000 SP3

Application Server OS: Microsoft Windows 2003 Server

Database Server OS: Microsoft Windows 2003 Server



This document was previously published as Siebel SR 38-1889334041.

Symptoms

SBL-SVR-01069

Dear support,

For your general understanding:
LoyEngineBatch is configured with following parameters:
LOY - Engine Queue Objects: Transaction:500,Tier:15
LOY - Engine Number of Runs: - 1
We have defined 50 server Keys and assigned them to 2 processes

we need to find the way to submit component request, which would:
1. process transactions (in order to update member field attributes)
2.
process tiers (the search spec takes into account member field
attributes which are updated by the processing of transactions)

Would it be possible that only one object type would get processed with the dos cmd below ?

a) We have processed transactions and tiers with following dos cmd:

start task for component LoyEngineBatch
start task for component LoyEngineBatch
sleep 60
start task for component LoyEngineBatch
start task for component LoyEngineBatch
start task for component LoyEngineBatch
start task for component LoyEngineBatch

b)
We have queried in the database and realised that for members which
were assigned to process 2, transactions were processed but not the
tiers.

c) we have shutdowned the component and resumed our test: tiers were all processed.

How can we avoid this from happening ?

Solution

Message 1

For the benefit of the readers,

Question: During the
implementation of the Loyalty environment, some questions were raised
about the starting of tasks from the command line. The reproduction of
this behavior and the troubleshooting of this lead to the following
information raised/clarified.

Resolution:
    *You need to set
the MinMTServer=MaxMTServer=<Number of Loyalty Process on your
Siebel server>=2 for the sake of the example. This is independent on
the number of Server Key you will associate to each pair server/process.
    *In
order to start the Loyalty Batch Engine, you can either run a "Workflow
Process Manager" job for the process "LOY Engine - Start Engine" in
which you will set the number of processes and the number of thread per
process to the value required for your environment. Both are set to 1 by
default. This will start a number of Batch Engine tasks as per the
formula (1 + (1 + Thread/Process #)) * # of Processes which is a minimum
of 3 tasks per process. This makes 6 tasks in our example.
*You can alternatively start these tasks manually as per the customer description.
The
first task will make the MTServer determine to which process it will be
associated. In our example the second task will be associated to the
2nd key. The only way to confirm that is by reading the log in which the
SRMRouting event has been set to 4.

Enhancement Change Request
12-VM0YFD: "Please add a way to read the process associated to a task
via the srvrmgr" has been opened to have an easier way of verification.
Enhancement
Change Request 12-VLY7CK: "Error SBL-SVR-01069 while choosing the
process to work for the LoyEngineBatch tasks" has been opened to remove
this message which is the expected behavior.
*Please note that a the
startup of your server, you will have one log file per MTServer has this
process require to start its listener on a TCP port.
*Please also
note that in the Server Administration task view, you will see the
entries from the S_SRM_REQUEST table which are requests for tasks and
not tasks.
*When you activate a Promotion, this will generate a
request for a task in order to update the Cache in the Batch Engine
MTServer.
*If you do this when the Engine Tasks are not fully
started, this will result in left over request that will need to be
cleaned up with the component SvrTblCleanup.

SBL-SVR-01068

Applies to:

Siebel System Software - Version: 7.8.2.3 SIA [19221] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)

Product Release: V7 (Enterprise)

Version: 7.8.2.3 [19221] Com/Med

Database: Oracle 9.2.0.6

Application Server OS: Sun Solaris 9

Database Server OS: Sun Solaris 9



This document was previously published as Siebel SR 38-3199007053.

Symptoms

SBL-SVR-01068We are getting frequent SIGABRT error for "Workflow Proc Batch Mgr" comp and on checking its
corresponding logs of each of the exited tasks.It is giving the below error:

PS:exited
tasks are the one which is leading to a crash and generating a
core.

GenericLog    GenericError    1    0    2006-11-14
07:56:55    (scirkey.cpp (121) err=2001068 sys=0) SBL-SVR-01068: This
component is not enabled for "Key Based Routing"


I've gone through the Supportweb and
found a solution mentioned bellow : I tried to implement the same,though it gave successful
change message,but it didn't reflect the change on listing the value.

FYI:

change
param KeyBasedEnabled = TRUE for comp WfProcBatchMgr

    *This allowed
the component to run without this error but still the Tier changes were not
changed.


I've even tried to compare this with other test enviornment but could see it
as TRUE or False on some of the instances.Kindly help us in understanding this parameter
further.


Regards

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other users,



The customer was running a Siebel 7.8.2.3 eCommunications environment
and had recently started seeing SIGABRT errors which appeared to result
from Workflow Process Batch Manager instances running on the enterprise.
In addition to the SIGABRT errors the crashing processes also reported
the following error :



GenericLog    GenericError    1    0    2006-11-14
07:56:55    (scirkey.cpp (121) err=2001068 sys=0) SBL-SVR-01068: This
component is not enabled for "Key Based Routing"



The error message suggests that the component should be enabled for
'Key-Based Routing' but this specific form of request routing based on a
generated key for particular instances of a component is restricted in
its use. It was not expected that the WfProcBatchMgr component would
make use of this functionality and the error message appears to be
misleading. For further information on Key-Based Routing please refer to
'Siebel Field Service Guide > Scheduling and Dispatch >
Scheduling Administration > Setting Up Server Processes, Performance,
and Key-Based Routing' and Technical Note 641: How Assignment Manager,
Rule Group, and Server Key Mapping Interact.



Following comparison of the component configuration between this and
other functioning environments it was established that a number of LOV
entries were missing in the problematic Test environment and which were
required by the Workflow Process being run. (continued...)


This appeared to result in the SIGABRT errors in the component and
misleading error messages being seen in the log files. Once the customer
migrated the missing LOV entries the processes functioned correctly.


Keywords : Key, Based, Routing, enabled, Key-Based, SBL-SVR-01068, WfProcBatchMgr, SIGABRT, LOV, List of Values, KeyBasedEnabled

Applies to:

Siebel Loyalty Engine - Version: 7.7.2.2 SIA [18356] and later   [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.7.2.2 [18356] Travel

Database: IBM DB2 8.1 FixPack 5

Application Server OS: IBM AIX 5L 5.2

Database Server OS: IBM AIX 5L 5.2

Symptoms

SBL-LTY-00109, SBL-SVR-01068

Hi siebel support

We have created a custom version of the
eLoyalty Processing Engine with Name = eLoyalty Tier Processing engine.
Purpose of this is to process tier changes nightly.
Creation of this
and how to make it run was discussed in other service request but we
managed to make it run in our Test envinronment. Now that we have
created the exact same component in UAT, it errors when trying to start
it.
The errormessage in the logfile is:
"SBL-LTY-00109: The
process was unable to find an available server routing key to register.
Please check the loyalty server key definition of your system."
And:
"SBL-SVR-01068: This component is not enabled for "Key Based Routing""

These messages comes right after this SQL:
SELECT
      T1.CONFLICT_ID,
      T1.LAST_UPD,
      T1.CREATED,
      T1.LAST_UPD_BY,
      T1.CREATED_BY,
      T1.MODIFICATION_NUM,
      T1.ROW_ID,
      T1.PROCESS_NUM,
      T1.SERVER_NAME
   FROM
       siebel.S_LOY_SRV_MAP T1
   WHERE
      (T1.SERVER_NAME = ?)
   ORDER BY
      T1.PROCESS_NUM
ObjMgrSqlLog    Detail    4    0    2005-09-20 19:29:26    Bind variable 1: uat_loy

Which returns my Server Key map i run directly against the database.

Please see attached logfile.

Cause

The cause was the copied component did not copy all component parameters correctly

Solution

Symptoms: After creating a new Loyalty Batch Engine Component, it does not start and gives the error message :
    "SBL-LTY-00109:
The process was unable to find an available server routing key to
register. Please check the loyalty server key definition of your
system."
    "SBL-SVR-01068: This component is not enabled for "Key Based Routing""

Troubleshooting:
    *The List of Values LOY_ENGINE_COMPONENT_KEYED for the component LoyTierEngineBatch is present in the system.
    *Indirect SupportWeb search lead to find that the SBL-SVR-01068 was caused by the advanced parameter KeyBasedEnabled.


Resolution:
    By using the srvrmgr command line utility :
        list advanced param KeyBasedEnabled for comp LoyEngineBatch
        ->True
        list advanced param KeyBasedEnabled for comp LoyTierEngineBatch
        -> False
        change param KeyBasedEnabled = TRUE for comp LoyTierEngineBatch
    *This allowed the component to run without this error but still the Tier changes were not changed.
    *Copying of component is very sensitive as there are many parameters to review.
    *By using again the srvrmgr command line utility:
        spool <myspool1.out>
        list param for comp LoyEngineBatch
        spool off
        spool <myspool2.out>
        list param for comp LoyTierEngineBatch
        spool off
    *By comparing the 2 spool files, it was found out that the Maximum Tasks had been left to 1 instead of 20.

Applies to:

Siebel Loyalty Engine - Version: 7.8.2.3 SIA [19221] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.8.2.3 [19221] SVE Transp

Database: Microsoft SQL Server 2000 SP3

Application Server OS: Microsoft Windows 2003 Server

Database Server OS: Microsoft Windows 2003 Server



This document was previously published as Siebel SR 38-3073606491.

Symptoms

SBL-SVR-01068, SBL-BPR-00162Customer had an issue with the component ‘eLoyalty Processing Engine -
Realtime’.

On the server, we try to process a transaction with the Realtime component
using the 'Process' button in the GUI. We get the following error:
[1] Error invoking service
'LOY Processing Engine', method 'SubmitObjectForProcessing' at step 'Invoke Submit
Object'.(SBL-BPR-00162)
[2] Could not route message to LoyEngineRealtime with registered key
(null)
[3] no other server

Processing the transaction on the dedicated
client, the transaction is processed successfully.

Cause

The Loyalty component was not assigned and synchronised on the server

Solution

Unassigning and re-assigning the Loyalty Batch Engine component, then
synchronising the componets resolved the issue for this customer

SBL-SVR-01054

Applies to:

Siebel Enterprise Integration Manager - Version 8.0.0.2 [20412] and later
Information in this document applies to any platform.

***Checked for relevance on 04-Dec-2012***

Symptoms

The EIM DELETE task does not complete successfully when deleting
rows from S_CON_ADDR using EIM_ADDR_PER. The following errors are seen
in the Server Manager Command line window when the EIM task is executed
from the same:

SBL-ADM-60070: Error reported one server “SIEBEIM8” follows:
SBL-SVR-01054: The task exited without sending has response.
In attachment, a file log, a print screen and an ifb.

Cause

The following entry in the EIM-Log file is relevant:

"...
* [Del MyDelete] batch 100, step 2, pass 107: locate by user key
* (started at 6/9/08 3:03)
*/

UPDATE dbo.EIM_ADDR_PER
SET T_CON_ADDR__RID =
(SELECT MIN(BT.ROW_ID)
FROM dbo.S_CON_ADDR BT
WHERE (BT.RELATION_TYPE_CD = IT.CONADDR_RELATIONTY AND
(BT.START_DT = IT.CONADDR_START_DT OR
(BT.START_DT IS NULL AND IT.CONADDR_START_DT IS NULL)) AND
BT.ADDR_PER_ID = IT.T_CON_ADDR_ADDRPE AND
(BT.ACCNT_ID = IT.T_CON_ADDR_ACCNTI OR
(BT.ACCNT_ID IS NULL AND IT.T_CON_ADDR_ACCNTI IS NULL)) AND
(BT.CONTACT_ID = IT.T_CON_ADDR_CONTAC OR
(BT.CONTACT_ID IS NULL AND IT.T_CON_ADDR_CONTAC IS NULL)) AND
(BT.ORG_GROUP_ID = IT.T_CON_ADDR_ORGGRO OR
(BT.ORG_GROUP_ID IS NULL AND IT.T_CON_ADDR_ORGGRO IS NULL))))
FROM dbo.EIM_ADDR_PER IT
WHERE (CONADDR_RELATIONTY IS NOT NULL AND
T_CON_ADDR_ADDRPE IS NOT NULL AND
IF_ROW_BATCH_NUM = ? AND
IF_ROW_STAT_NUM = 0 AND
T_CON_ADDR__STA = 0)
?1: 100
go
..."

The problem is that the UPDATE statement from above is also checking for
S_CON_ADDR.ACCNT_ID/EIM_ADDR_PER.T_CON_ADDR_ACCNTI
and
S_CON_ADDR.START_DT/EIM_ADDR_PER.CONADDR_START_DT
respectively.

If
those columns are not considered for the EIM_ADDR_PER load then the
DELETE EXACT operation is failing as seen in the EIM-Log file:

"...Process [Del MyDelete] had 1 row fail
on EIM_ADDR_PER for batch 100 in step 2, pass 107:
Exact specification of rows were not found. (severity 4, row eliminated)

Rows which were specfied using exact deletion were not found by the user keys
specified in the interface table. Check that the key values specified in the IF
table exactly match a row in only one base table.

The rows were eliminated from further processing in this IF table. Processing
will continue for other rows in this interface table..."

Solution

Considering the S_CON_ADDR.ACCNT_ID and S_CON_ADDR.START_DT
columns via their respective EIM_ADDR_PER columns resolves the
behaviour. A sample script and IFB-File is shown below:

INSERT INTO EIM_ADDR_PER
(ROW_ID,
IF_ROW_BATCH_NUM,
IF_ROW_STAT,

AP_ADDR_NAME, -- S_ADDR_PER
AP_ALIGNMENT_FLG,
AP_DISACLEANSE_FLG,
AP_NAME_LOCK_FLG,
AP_PREMISE_FLG,

CONADDR_RELATIONTY, --S_CON_ADDR
CONADDR_START_DT,
CONADDR_ACTIVE_FLG,
CONADDR_BLADDR_FLG,
CONADDR_FRAUD_FLG,
CONADDR_MAINADDRFL,
CONADDR_SHIPADDRFL,

CONADDR_ACCNT_BU, -- S_CON_ADDR.ACCNT_ID
CONADDR_ACCNT_LOC,
CONADDR_ACCNT_NAME
)
VALUES
(1,
100,
'FOR_DELETE',

'MyAccntStreetAddress1, MyAccntCity1', -- S_ADDR_PER
'N',
'N',
'N',
'N',

'ContactPointUsage',
'2008-06-09',
'Y','N','N','N','N',

'Default Organization',
NULL,
'MyAccnt1'
)

-------

[Siebel Interface Manager]
USER NAME="SADMIN"
PASSWORD="SADMIN"
PROCESS = Del MyDelete

[Del MyDelete]
TYPE = DELETE
BATCH = 100
TABLE = EIM_ADDR_PER
DELETE EXACT = TRUE
ONLY BASE TABLES = S_CON_ADDR

Applies to:

Siebel Enterprise Integration Manager - Version: 8.0.0.1 SIA [20408] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Product Release: V8 (Enterprise)

Version: 8.0.0.1 [20408] Life Sci

Database: Microsoft SQL Server 2005

Application Server OS: Microsoft Windows 2003 Server SP2

Database Server OS: Microsoft Windows 2003 Server SP2



This document was previously published as Siebel SR 38-3460398791.

Symptoms

I'm getting the following error when trying to run EIM. This .ifb used to work.



SBL-ADM-60070: Error reported on server 'SblCRMDev01' follows:

SBL-SVR-01054: The task exited without sending a response.



The only difference that I know of is that we have extended EIM_CONTACT
several times. We didn't have a problem for the other ones, though.



I've attached the ifb file I'm using, the log file produced when logging was turned up and the crash file.



Let me know if you have any questions. Thanks.



Ken Ratzlaff

425-478-1951

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of othere readers,



Customer experienced issues with columns created with the 'Case Insensitivity' wizard.



It has been determined that Customer ran the 'EIM Mapping Wizard'
sometime after running the 'Case Insensitivity' wizard. For this reason
the EIM mapper created eim columns and mappings for the case insensitive
columns.



In order to avoid the above issue you should always make sure that the EIM Mapping wizard does not take such columns in account.



Additional Keywords: Case Insensitivity, EIM Mapping

Applies to:

Siebel CRM - Version 8.0.0.13 SIA [20448] and later
Information in this document applies to any platform.

Symptoms

On : 8.0.0.13 SIA [20448] version, ADM - App. Deployment Manager

When
attempting to export data using ADM command line using ADMbatchProc
component, the component crashes and the following error occurs:

ERROR
-----------------------
SBL-ADM-60070: Error reported on server 'WFMDEVAPP1' follows:
SBL-SVR-01054: The task exited without sending a response.
SBL-SCL-00131: Either the RC2 or the AES cryptography engine is not initialized.


STEPS
-----------------------
The issue can be reproduced at will with the following steps:
1. login using srvrmgr
2. Execute following command to export LOV records using ADM.

run
task for comp admbatchproc with admpath="C:\ADM\output_xml",
admfilter='[Value] LIKE "SR_AREA*"', admdatatype=LOV,
admeaimethod=upsert, admprefix=ADM_SR_AREA

Cause

Cause of the issue is identified as product defect.

Issue is replicated in-house and a product defect 14460219 - ADM BATCH PROC EXPORT FAILS WITH SBL-SCL-00131 ERROR is raised to address the issue.

Solution

Defect#14460219 is fixed by engineering and a QF is now available in My Oracle Support.Please find the details of the fix below:

Because 800x code line is in extended support, this QF is protected with a password.

Summary:

Patch ID: 14686221

Platform Available: SOLARIS, WINDOWS
Product Certified: SIA
Languages Certified: Language Independent
Base Required: FIX PACK 8.0.0.13[20448]

Patch Abstract:
8.0.0.13 20448 sba QF0D25 sebl_aru

QF Install Doc:

Doc is named README.html and is located under

p14686221_800_SOLARIS64_1of2.zip

p14686221_800_WINNT_1of2.zip

SBL-SVR-01051

Applies to:

Siebel Handheld - Version 7.5.3.9 PDA [16194_2] to 8.2.2.3 SIA [23021] [Release V7 to V8]
Microsoft Windows CE

Product Release: V7 (Enterprise)

Version: 7.7.0.1 [AN307]

Database: Oracle 9i

Application Server OS: Microsoft Windows 2003 Server

Database Server OS: Sun Solaris 9



This document was previously published as Siebel SR 38-1719219591.

***Checked for relevance on 27-Mar-2013***

Symptoms

SBL-SVR-01051, SBL-NET-01218


We are experiencing problems syncronising our Siebel Handheld devices
with the Server using DSS. It has worked in the past, but since the
server went down during a sync, we can't get it to work again.

We continue to get these error, taken from the log on the HH device.

SYSTEM    0xd290894e    01/17/2005 10:00:40    Loading Metadata.
ERROR    0xd290894e    01/17/2005
10:00:40    0x7766: Failed to load configuration. Metadata file is
absent or invalid. Siebel Handheld Sync will be launched now.
SYSTEM    0xB3605DE2    01/17/2005 10:00:41    Initializing SyncClient.
SYSTEM    0xd290894e    01/17/2005 10:00:41    Terminating Siebel application.
ERROR    0xD2BB26E6    01/17/2005 10:01:13    0x65aa: Server returned NOTOK
ERROR    0xD2BB26E6    01/17/2005 10:01:13    Server returned NOTOK
ERROR    0xD2BB26E6    01/17/2005
10:01:13    The server may be busy. Please try again later. Contact
your administrator if the problem persists.
ERROR    0xD2BB26E6    01/17/2005 10:01:13    Fatal Error, Shutting Down Session
SYSTEM    0xB3605DE2    01/17/2005 10:01:26    Exiting SyncClient.

Any
ideas what may be causing this. We thought that it may still have an
active sync task running, but we have started and stopped the server and
it still conitnues to error out.

Many Thanks

Andy

Cause

As cause was identified the entry for the handheld application in
eapps_sia.cfg file. All sections for handheld applications require the
additional line 'EnableExtServiceOnly = TRUE'. The standard eapps*.cfg
files do contain this line.

Solution

Message 1

For the benefit of other users:

The object manager log file showed following errors a couple of times:
SBL-NET-01218: The connection was refused by server gal-rtw-app-16. No component is listening on port 49160.
SBL-SVR-01051: SISNAPI connection is refused by the Siebel server: (null)

As
cause was identified the entry for the handheld application in
eapps_sia.cfg file. All sections for handheld applications require the
additional line 'EnableExtServiceOnly = TRUE'. The standard eapps*.cfg
files do contain this line. In the case here for some reason this line
was missing. After correcting this the handheld synchronization worked properly.

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:Server Common Layers - SVR

Version:Siebel 7.5.3

Purpose

This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-SVR-01051: SISNAPI connection
refused, the server could be down: %1

Scope

This document is informational and intended for any user.

SBL-SVR-01051: SISNAPI connection refused, the server could be down: %1

Explanation

Cannot connect to the Siebel Server machine to start a process. The
Siebel Server machine might not be available over the network or the
Siebel Server process may not be started. The details of the error from
the SISNAPI layer replaces the %1 in the error message.

Corrective Action

Make sure the Siebel Server machine is up and running and that the Siebel Server process is running.

Applies to:

Product Release: V7 (Enterprise)

Version: 7.7.1 [18306]

Database: Oracle 9.2.0.4

Application Server OS: Microsoft Windows 2000 Server

Database Server OS: Sun Solaris 8



This document was previously published as Siebel SR 38-1557600801.

Symptoms

SBL-SVR-01051, SBL-SMI-00049, SBL-NET-01218Hi Support,

We have created new Object Managers for PRM Portal (for 8 different
languages). As part of this, we have created new virtual directories, new components, new entries
in the eapps.cfg. And finally, we synchronized the components.

But, when we try to access
the new OM, it says 'Page can not be displayed'.

For example, we created new OM:
echannelObjMgr_enu_eidm and when we access it through:

http://hostname/prmportal_enu_eidm
we get a 'Page can not be displayed' message.

We see that the URL gets re-directed to
homepage like:


http://hostname/prmportal_enu_eidm/start.swe?SWECmd=Start&SWEHo=hostname

I
think the OM is not responding to the request that has passed through SWSE.

Please let us
know your ideas on this.

Thanks,
Jagadeesh

Solution

Message 1

For the benefit of other user:



The customer has created new Object Managers for PRM Portal (for 8
different languages). As part of this, he has created new virtual
directories, new components, and new entries in the eapps.cfg. And
finally, he synchronized the batch server components.



But, when he tried to access the new Object Manager, it says "Page can not be displayed".



The problem has been resolved after the customer modified the web server (IIS) parameters as follows:

1. Open IIS (Start menu --> Program Files--> Administrative Tools--> Internet Services Manager)

2. Expand default web site

3. Choose Virtual directory created (for the custom component) and right click and go to Properties

4. In Virtual directory tab, choose Configuration button. Click that

5. You get another pop up- choose tab - App mappings. Highlight .swe and click on edit

6. Another pop up opens - At the bottom, there is a check box - "Check that file exists"

7. Uncheck the check box

8. Repeat this for .swef



Documentation Enhancement request 12-QAWCBM (Update the "Creating a New
Virtual Directory" section from Siebel Installation Guide for MS
Windows) was logged to address this matter.

Applies to:

Siebel CRM - Version: 7.5.3 [100] to 8.1.1.7 [21238] - Release: V7 to V8
Information in this document applies to any platform.

Product Release: V7 (Professional)



Application Server OS: Microsoft Windows 2000 Server SP 4

Database Server OS: Microsoft Windows 2000 Server SP 4

Symptoms

It was reported that there were problems using drag drop
functionality in the Siebel application. When the user was trying
to save an attached document, the system was displaying the following
error message:

Session
Warning: The server you are trying to access is either busy or
experiencing difficulties. Please close the Web browser, open a new
browser window, and try logging in again.

After this error, the user is usually logged out of the application.

The issue was only present in the thin client and could not be reproduced in the dedicated client.


The same error was observed in the thin client using both DB authentication and ADSI authentication.

The following messages were displayed in the SWE logs:

ProcessPluginRequest    ProcessPluginRequestError    1    0    2006-04-18
17:15:22     5116: [SWSE] RPC coming in without a user session

ProcessPluginRequest    ProcessPluginRequestError    1    0    2006-04-18
17:15:22     5116: [SWSE] Failed to obtain a session ID. NOT OK

ProcessPluginRequest    ProcessPluginRequestError    1    0    2006-04-18
17:15:22     5116: [SWSE] Set Error Response (Session: Error: 00065535
Message: NOT OK)

The following error messages may also be seen for the end user or in the logs related to this issue:
SBL-UIF-00401,
SBL-SCR-00141, SBL-DAT-00215, SBL-DAT-00712, SBL-SVR-01051,
SBL-SCM-00022, SBL-SMI-00033, SBL-NET-01023, SBL-BPR-00125,
SBL-BPR-00151

Cause

The cause of this issue was determined to be an underscore "_" character in the naming of the servers.

Solution

The workaround for this issue is to use the IP address of the server instead of the server name.

Document 477993.1  has additional information regarding problems using a dash/hyphen in the Siebel Server Name.



Document 477993.1 was previously referred to as Alert 1067.

Applies to:

Siebel Financial Services Call Center - Version: 7.7.2.10 SIA [18385] and later   [Release: V7 and later ]
Information in this document applies to any platform.

Symptoms

Web client not working after migration with CUSTOM srf. It works fine with STANDARD srf.





 OM logs were misleading indicating following errors:


2010-02-01 13:58:57 4848: [TCPIP-client] connect() to drlmrsie07p:49164 failed (err=10061 | Connection refused.)

2010-02-01
13:58:57 (srmconn.cpp (905) err=1801218 sys=49164) SBL-NET-01218: The
connection was refused by server drlmrsie07p. No component is listening
on port 49164.


2010-02-01 13:58:57 (srmconn.cpp (905)
err=2001051 sys=126) SBL-SVR-01051: SISNAPI connection is refused by the
Siebel server: (null)

Changes

Customer was  in the process of building a Siebel disaster recovery (DR)
environment, which mimics their production environment.  They built the
environment from a fresh installation of Siebel. The vanilla Siebel web
client worked perfect, however, after doing a database refresh from
production, as well as repository migration (including repository
import, copying over SRF, bscript, image and CSS files from production),
the web client stopped working.

Cause

Custom srf was failing because Firstlogic was not installed

Solution

Installed Firstlogic and web client started working with custom srf. 



 

SBL-SVR-01045: No components are configured

Applies to:

Siebel Life Sciences CRM - Version: 8.1 [21039] to 8.1.1 [21112] - Release: V8 to V8
Microsoft Windows (32-bit)

Symptoms

Customer changed the sadmin's password following the Siebel
Security Guide > Changing or Adding Passwords > Changing Passwords
> Changing System Administrator Passwords on Microsoft Windows, but
after changing the password the Siebel Server did not come up .


In the Siebsrvr.log file it was found the following error message:


GenericLog GenericError 1 00000002499b0e08:0 2009-02-17 16:41:28
(scmnsclnt.cpp (135) err=2555922 sys=0) SBL-SCM-00018: Could not open
connection to Siebel Gateway configuration store (siebel03:2320).


The following errors were just a symptom of the failure to connect to the Siebel Gateway:


GenericLog GenericError 1 00000002499b0e08:0 2009-02-17 16:41:28
(scisvc.cpp (1391) err=1311765 sys=0) SBL-SVR-01045: No components are
configured.

GenericLog GenericError 1 00000002499b0e08:0
2009-02-17 16:41:28 (scfsis.cpp (274) err=1310725 sys=0) SBL-SVR-00005:
Stale or invalid Task handle

ScfEventLog SubEvtFacFatal 0
00000002499b0e08:0 2009-02-17 16:41:28 scfEventFac::s_pEvtFacLock is
NULL and hence SCF event facility cannot be initialised

GenericLog
GenericError 1 00000002499b0e08:0 2009-02-17 16:41:28 (scfeventfac.cpp
(3790) err=1319869 sys=0) SBL-SVR-09149: Could not initialize the event
facility.

ScfMsgFacLog SCFMsgFacFatalError 0 00000002499b0e08:0
2009-02-17 16:41:28 SCFMessageFacility::s_pSCFMsgFacLock is null and
hence the SCFMessageFacility cannot be initialized
IPCLog IPCFatal 0 00000002499b0e08:0 2009-02-17 16:41:28 ipcFacility GetInstance called before initialization - object is null


GenericLog GenericError 1 00000002499b0e08:0 2009-02-17 16:41:28
(scfsis.cpp (64) err=1310749 sys=0) SBL-SVR-00029: Internal: Shared
memory has not been initialized.

Cause

The issue was due to the new security feature that was introduced
on Siebel 8.1.1 to avoid access to the Gateway Server without being
properly authenticated.


There are now in Siebel 8.1.1 user and password information in the
Windows registry for the Siebel Server service. This can be verified by
on "Path to executable:" field on General tab for the respective Siebel
Server service in Administrative Tools > Services.  See the example
below:


C:\sia81\siebsrvr\bin\siebsvc -s siebsrvr -i Siebel_app01 -a "-g
localhost:2320 -e Siebel -s app01 -l ENU -u SADMIN -ep 9ntkUOUf" -t 120
-h C:\sia81\siebsrvr

Solution

Follow the instructions below to reflect the sadmin's password to all
Siebel Serves in the Enterprise, i.e. repeat the process on all Siebel
Servers in the Enterprise.



a) Delete the Siebel Server service

syntax:
siebctl -d -S siebsrvr -i "<enterprise name>_<siebel server name>"

example:
C:\sia81\siebsrvr\bin\siebctl -d -S siebsrvr -i "sia81_app01"

b) Restart the machine

c) Recreate the Siebel Server service providing the new password, it will be encrypted by siebctl.

syntax:
siebctl
-h %SIEBEL_ROOT% -S siebsrvr -i "<enterprise name>_<siebel
server name>" -a -g "-g <gateway hostname>:<port#> -e
<enterprise name -s <siebel server name> -u sadmin" -e <new
password> -u <NT Account> -p <NT password>

example:
C:\sia81\siebsrvr\BIN>siebctl
-h "d:\sia81\siebsrvr" -S siebsrvr -i "sia81_app01" -a -g "-g
localhost:2320 -e sia81 -s app01 -u sadmin" -e sadmin -u .\SADMIN -p
SADMIN

d) Restart the machine

NOTE: If no local user account is used, i.e. Local System is used instead, don't use -u and -p options
NOTE 2:
After recreating the service using siebctl and restarting the machine,
you may receive a failed logon message when starting the service. If
this happens navigate to Windows Control Panel, Services list, locate
the Siebel Server service and click on Properties. Under the "Log On"
tab re-enter the password for the service owner account.

Below is the updated documentation as a result of the document bug 10561582:

http://download.oracle.com/docs/cd/E14004_01/books/Secur/Secur_ChangePwd3.html

Applies to:

Siebel CRM - Version: 8.0 [20405] to 8.1 [21039] - Release: V8 to V8
Information in this document applies to any platform.

*** Checked for Relevance 15 Feb 2012 ***

Symptoms

Siebel Server failed to start.

• No new enterprise log was created


• Siebel Server log contained the following errors:

(SiebSrvr.log)
2010-07-13 15:03:33 1: [TCPIP-client] socket() closed descriptor = 8 from 10.1.1.51:49976 to 10.1.1.51:2320
2010-07-13 15:03:33 (scfsis.cpp (80) err=2555932 sys=0) SBL-SCM-00028: Key not found
2010-07-13 15:03:33 (listener.cpp (172) err=2555932 sys=0) SBL-SCM-00028: Key not found
2010-07-13 15:03:33 (lstnsvc.cpp (150) err=2555932 sys=0) SBL-SCM-00028: Key not found
2010-07-13 15:03:33 (scisvc.cpp (1391) err=1311765 sys=0) SBL-SVR-01045: No components are configured.
2010-07-13 15:03:33 (scfsis.cpp (274) err=1310725 sys=0) SBL-SVR-00005: Stale or invalid Task handle
2010-07-13 15:03:33 scfEventFac::s_pEvtFacLock is NULL and hence SCF event facility cannot be initialised
2010-07-13 15:03:33 (scfeventfac.cpp (3790) err=1319869 sys=0) SBL-SVR-09149: Could not initialize the event facility.
2010-07-13 15:03:33 SCFMessageFacility::s_pSCFMsgFacLock is null and hence the SCFMessageFacility cannot be initialized
2010-07-13 15:03:33 ipcFacility GetInstance called before initialization - object is null
2010-07-13 15:03:33 (scfsis.cpp (64) err=1310749 sys=0) SBL-SVR-00029: Internal: Shared memory has not been initialized.

Cause

Siebel Server definition is missing from Siebel Gateway Name Server Data file (siebns.dat).


At startup, the Siebel Server obtains its configuration information
from the Siebel Gateway Name Server's siebns.dat file.  Refer to the
following 8.x Siebel System Administration Guide bookshelf document for
more information:

• About Siebel Gateway Name Server

Solution

Either of the following actions should resolve the issue:

A. Restore a copy of the Gateway Name Server backup file (siebns.dat).
B. Configure a "new" Siebel Server, by running the configuration wizard.

Applies to:

Siebel CRM - Version 8.1.1 SIA [21111] and later
Generic Linux
Generic UNIX

Affected Database: Oracle



""Checked for Relevance on 11-09-2012""

Symptoms

start_server script (for staring Siebel Server) or srvrmgr command
may fail and the error message in NameSrvr.log file indicates "
SBL-SEC-10007: The password you have entered is not correct. Please
enter your password again." while the same user/password combination
works on SQLPlus.

Cause

In Siebel 8.1.x, Siebel Gateway Server (GtwySrvr) authenticates the
user who attempts to connect to GtwySrvr. In standard setting, GtwySrvr
performs database authentication against the user. Using Oracle
database, $ORACLE_HOME/lib (or $ORACLE_HOME/lib32 when Oracle Database
Server is 64 bit) must be part of the shared libraries for GtwySrvr
process (siebsvc). If it is not set correctly, starting Siebel Server
(start_server script) or launching srvrmgr will fail with following
errors..



1) start_server

- On terminal window, it does not show any error but list_server scripts reveals it is stopped in a few seconds.



- SiebSrvr.log under siebsrvr/log directory shows following error.

SBL-SCC-00005: Internal:No more items found.

SBL-SVR-01045: No components are configured.

SBL-SVR-00005: Stale or invalid Task handle

scfEventFac::s_pEvtFacLock is NULL and hence SCF event facility cannot be initialised

SBL-SVR-09149: Could not initialize the event facility.

SCFMessageFacility::s_pSCFMsgFacLock is null and hence the SCFMessageFacility cannot be initialized

ipcFacility GetInstance called before initialization - object is null

SBL-SVR-00029: Internal: Shared memory has not been initialized.



- NameSrvr.log under gtwysrvr/log directory shows following error.

SBL-SEC-10018: 523 80

SBL-SEC-10007: The password you have entered is not correct. Please enter your password again.





2) srvrmgr command

- On terminal windows, error message "Fatal error (2555922): Could not
open connection to Siebel Gateway configuration store" is shown.



- srvrmgr.log under siebsrvr/log directory shows following error.

NSS - ErrCode 4597527 SysErr 0

SBL-SCM-00018: Could not open connection to Siebel Gateway configuration store (GATEWAY SERVER HOST:GATEWAY SERVER PORT).

GATEWAY SERVER HOST = Host name for Siebel Gateway Server

GATEWAY SERVER PORT = Port number to connect to Siebel gateway Server



- NameSrvr.log under gtwysrvr/log directory shows following error.

SBL-SEC-10018: 523 80

SBL-SEC-10007: The password you have entered is not correct. Please enter your password again.



** Please note key messages is "SBL-SEC-10018: 523 80" in NameSrvr.log.
If this error is NOT recorded, this is really password problem.

Solution

Please make sure to set $ORACLE_HOME/lib in LIBPATH (AIX), SHLIB_PATH
(HP-UX), or LD_LIBRARY_PATH (Linux, Solaris) variables before start_ns
is run.

Applies to:

Siebel CRM - Version 8.1.1 SIA [21111] and later
Information in this document applies to any platform.

***Checked for relevance on 02-JAN-2013***

Symptoms

The Siebel Server is not starting on Windows platform.





Contents of the Siebel Server log file ...

2021
2011-05-12 11:49:47 2011-05-12 11:49:47 +0100 00000011 001 ffff 0001 09
SiebSrvr 3216 4768 C:\Siebel_Preprod\siebsrvr\log\SiebSrvr.log 8.1.1 SIA
[21111] ENU

GenericLog GenericError 1 000203864dca311f:0 2011-05-12 11:49:47 NSS - ErrCode 4597527 SysErr 0

GenericLog
GenericError 1 000203864dca311f:0 2011-05-12 11:49:47 (scmnsclnt.cpp
(135) err=2555922 sys=0) SBL-SCM-00018: Could not open connection to
Siebel Gateway configuration store (ojcrmppgw01:2320).

GenericLog
GenericError 1 000203864dca311f:0 2011-05-12 11:49:47 (scmobj.cpp (211)
err=2555922 sys=0) SBL-SCM-00018: Could not open connection to Siebel
Gateway configuration store (ojcrmppgw01:2320).

GenericLog
GenericError 1 000203864dca311f:0 2011-05-12 11:49:47 (scfutil.cpp (112)
err=2555922 sys=0) SBL-SCM-00018: Could not open connection to Siebel
Gateway configuration store (ojcrmppgw01:2320).

GenericLog
GenericError 1 000203864dca311f:0 2011-05-12 11:49:47 (sissrvr.cpp
(3112) err=2555922 sys=0) SBL-SCM-00018: Could not open connection to
Siebel Gateway configuration store (ojcrmppgw01:2320).

GenericLog
GenericError 1 000203864dca311f:0 2011-05-12 11:49:47 (scfsis.cpp (80)
err=2555922 sys=0) SBL-SCM-00018: Could not open connection to Siebel
Gateway configuration store (ojcrmppgw01:2320).

GenericLog
GenericError 1 000203864dca311f:0 2011-05-12 11:49:47 (listener.cpp
(172) err=2555922 sys=0) SBL-SCM-00018: Could not open connection to
Siebel Gateway configuration store (ojcrmppgw01:2320).

GenericLog
GenericError 1 000203864dca311f:0 2011-05-12 11:49:47 (lstnsvc.cpp
(150) err=2555922 sys=0) SBL-SCM-00018: Could not open connection to
Siebel Gateway configuration store (ojcrmppgw01:2320).

GenericLog
GenericError 1 000203864dca311f:0 2011-05-12 11:49:47 (scisvc.cpp
(1391) err=1311765 sys=0) SBL-SVR-01045: No components are configured.

GenericLog
GenericError 1 000203864dca311f:0 2011-05-12 11:49:47 (scfsis.cpp (274)
err=1310725 sys=0) SBL-SVR-00005: Stale or invalid Task handle

ScfEventLog
SubEvtFacFatal 0 000203864dca311f:0 2011-05-12 11:49:47
scfEventFac::s_pEvtFacLock is NULL and hence SCF event facility cannot
be initialised

GenericLog GenericError 1 000203864dca311f:0
2011-05-12 11:49:47 (scfeventfac.cpp (3790) err=1319869 sys=0)
SBL-SVR-09149: Could not initialize the event facility.

ScfMsgFacLog
SCFMsgFacFatalError 0 000203864dca311f:0 2011-05-12 11:49:47
SCFMessageFacility::s_pSCFMsgFacLock is null and hence the
SCFMessageFacility cannot be initialized

IPCLog IPCFatal 0 000203864dca311f:0 2011-05-12 11:49:47 ipcFacility GetInstance called before initialization - object is null

GenericLog
GenericError 1 000203864dca311f:0 2011-05-12 11:49:47 (scfsis.cpp (64)
err=1310749 sys=0) SBL-SVR-00029: Internal: Shared memory has not been
initialized.

GenericLog GenericError 1 000203864dca311f:0
2011-05-12 11:49:47 (siebsvc.cpp (329) err=2555922 sys=0) SBL-SCM-00018:
Could not open connection to Siebel Gateway configuration store
((null):(null)).

Cause

The customer confirmed that TCP connection could be established from the Siebel Server host to the Siebel Gateway Server host.

The following document was consulted and the customer re-registered the Siebel Server several times:


784524.1 - Siebel Server does not start after changing the SADMIN password on Siebel 8.1.1

The same behavior was persistent after this.

We
trussed the Gateway Server process (running on a Unix platform) for the
time period where the Siebel Server was attempting to start, and
connect to the Gateway Server. This was showing no connection attempt in
the truss, which was not logical, as we had determined that the Gateway
Server was listening on port 2320. The connection to port 2320 should
have generated some output in the truss. It was as though the connection
was not being properly established

After further trace routes
(tracert) were run to check the TCP connection to the Gateway Server
host machine, the customer determined that the attempted connection to
the Gateway Server was showing an incorrect IP address.

Solution

Technical Support directed the customer to the following resources / testing:

(i) Check your network interface configuration on the Windows server:

ipconfig /all

Check
that the Subnet Mask, Default Gateway and DNS Servers are configured
correctly. I suggest you compare with another Windows server that you
know to be "correct".

(ii) Check the 'hosts' file in C:\WINDOWS\system32\drivers\etc for the specification of any static routes

(iii) Perform some trace routes to the Windows server hosting siebsrvr4, to see how the routing is working in reverse.

The
customer determined that the cause was with a static route specified in
the 'hosts' file in C:\WINDOWS\system32\drivers\etc. This contained a
reference to ojcrmppgw01 (the Gateway Server host) pointing to the wrong
IP address. After removing this from the hosts file, the customer was
able to start the Siebel server.

Applies to:

Siebel CRM - Version 8.1.1 [21112] and later
Information in this document applies to any platform.

***Checked for relevance on 10-SEP-2012***

Description

With Siebel CRM version 8.1.1 it can happen that the gateway service
is unresponsive under high load. In such a scenario, no more client
connections from server manager can be established or an entire siebel
server node and additional application object manager (AOM) processes
can not be started.

Occurrence

 You might run into this behavior when you run Siebel CRM version
8.1.1 or above and run an enterprise with more than 10 defined
application servers or when enterprise configuration updates to the
siebns.dat file are made. You are observing slowness in enterprise
startup in general.

Symptoms

Once it has been verified that the gateway service is up and running,
the database can be accessed and the correct passwords are provided, if
you then get one of the below error messages you might be facing the
issue discussed here:

 a)   The srvrmgr command needs a very
long time to connect to a single server using the /s switch or returns
the following error after a while in srvrmgr.log file:

NameServerLayerLog      Error   1    000000024f5f0132:0      2012-03-13 10:12:21     Unable to connect to the gateway server.

GenericLog      GenericError    1       000000024f5f0132:0      2012-03-13 10:12:21     NSC - ErrCode 5009  SysErr 0 

GenericLog      GenericError    1       000000024f5f0132:0     
2012-03-13 10:12:21     (scmnsclnt.cpp (135) err=2555922 sys=2)
SBL-SCM-00018: Could not open connection to Siebel Gateway configuration
store (localhost:2320).

b)   An Object manager process is
terminating during startup. When running the srvrmgr command "list procs
for comp <compname>", processes are stuck in the "Starting" state
and never transition to a state of "Running" or "Online"

c)   The siebsvc server  scheduler process
service is exiting, no processes are started and in the Siebsrvr.log
file the following error can be found:

NameServerLayerLog      Error   1       0000fb2e4f7100de:0      2012-03-27 08:56:09     Unable to connect to the gateway server.

GenericLog      GenericError    1       0000fb2e4f7100de:0      2012-03-27 08:56:09     NSS - ErrCode 5009  SysErr 0

GenericLog      GenericError    1       0000fb2e4f7100de:0     
2012-03-27 08:56:09     (scisvc.cpp (1391) err=1311765 sys=0)
SBL-SVR-01045: No components are configured.

GenericLog      GenericError    1       0000fb2e4f7100de:0     
2012-03-27 08:56:19     (siebsvc.cpp (221) err=2555922 sys=0)
SBL-SCM-00018: Could not open connection to Siebel Gateway configuration
store ((null):(null)).

d) The siebns.dat file is recreated
multiple times per minute. You can observe a temporary file called
siebns.dat.new frequently listed in the folder where siebns.dat is
located.

e) You are also running into this issue if
none of the above errors occur but you notice increased startup times
when adding servers to the enterprise.

   

Workaround

The following three bugs have been created to address this behavior:

• Bug 12561457: GATEWAY SERVER CONSUMING HIGH CPU.

This has been fixed in Fixpack 8.1.1.8

• Bug 13827461: SIEBNS.DAT FILE COMPACTION AND OPTIMISATION

Thas been fixed in Fixpack 8.1.1.6.

• Bug 13827574: EXTRA SRVRMGR CONNECTIONS CAUSING PERFORMANCE ISSUES

This has been fixed in Fixpack 8.1.1.6.

Currently there exist Quick Fixes for the following Fixpacks to address these issues:

• Fixpack 8.1.1.3:  QF03CK patch 13819838


• Fixpack 8.1.1.4:  QF0475 patch 13912174


• Fixpack 8.1.1.5:  QF0591 patch 13910484


• Fixpack 8.1.1.6:  QF0637 patch 14283967


• Fixpack 8.1.1.7:  QF0723 patch 14084625

Customers that are looking to accelerate the enterprise startup
process should apply these Quick Fixes regardless if one of the above
errors is encountered or not. They should benefit from the optimized
siebns.dat write performance in any case.





To mitigate the issue on versions where currently no quickfix does
exist, the following workarounds have helped to reduce the load put on
the gateways siebsvc process:


a) do not start many siebel servers concurrently. Starting each
server with a delay of 3-5 minutes will give gateway sufficient time to
handle all incoming requests.

To monitor when a server has completely
started up, you can either run the srvrmgr "list procs for server
<servername>" command and verify all processes are in running
state or enable auditing by setting the gateway.cfg parameter
EnableAuditTrail = TRUE. Then monitor the file nameserver_audit.log. The
server has started up when no more lines are added to the audit file.

b) try to run as little srvrmgr commands as possible; use /i command
file switch switch rather than to launch multiple srvrmgr in a row.

In case a system monitoring tool is used that makes frequent use of srvrmgr, it should be disabled or poll frequency reduced.

c) if you are starting lots of additional batch component processes after initial enterprise startup:

define a dedicated admin user that only
has the Siebel administrator responsibility assigned and use this new
account to start recurring batch components like Workflow, Assignment,
EIM etc. The standard sadmin account has 228 responsibilities and all
these are retrieved from the database for each gateway login. Reducing
this to 1 makes the database login part of a gateway connection faster.

d) customers running Oracle 11g database might deploy the DRCP protocol to connect the gateways odbc source.

To setup a DRCP connection string see
note How To Setup and Trace Database Resident Connection Pooling (DRCP)
(Doc ID 567854.1). Then the gateways odbc source definition needs to be
changed to use the new drcp tnsnames connection string. Tests have shown
that gateways database login can be accelerated  with this DRCP 
approach by up to 30% compared to the standard dedicated  database mode.

e) Configuration changes to the enterprise should only be done in a maintenance window.





To avoid the risk of frequent siebns.dat rewrites, configuration
changes that require updates to the siebns.dat like for example adding
new servers to the entrprise, assigning or unassigning components,
changes in component definition etc should only be done when the
enterprise is down or there is very little load during low volume
business hours. In 24x7 deployments special care needs to be taken to
find a period of very low activity.

Patches

Fixpack: 8.1.1.3 QF03CK


Fixpack: 8.1.1.4 QF0475


Fixpack: 8.1.1.5 QF0591


Fixpack: 8.1.1.7 QF0723

Applies to:

Siebel System Software - Version 7.7.2.6 SIA [18372] and later
z*OBSOLETE: Microsoft Windows Server 2003

Database: Oracle 9.2.0.6

Application Server OS: Microsoft Windows 2003 Server SP1

Database Server OS: HP-UX 10.0



This document was previously published as Siebel SR 38-3262290961.

Symptoms

We've installed a new server (JANBEBESBL37) for our production server
farm consisting of 6 siebel servers (enterprise ES_VINP). The server
runs Windows 2003 server SP1.
However, when starting the Siebel Server service, the server won't start up displaying following error messages:


GenericLog    GenericError    1    0    2007-01-30
09:34:18    (sissrvr.cpp (2979) err=2000026 sys=12) SBL-SVR-00026:
Unable to allocate shared memory.


GenericLog    GenericError    1    0    2007-01-30
09:34:18    (scisvc.cpp (1225) err=2001045 sys=0) SBL-SVR-01045: No
components configured !


GenericLog    GenericError    1    0    2007-01-30
09:34:18    (scfsis.cpp (166) err=2000005 sys=0) SBL-SVR-00005: Stale or
invalid Task handle


GenericLog    GenericError    1    0    2007-01-30
09:34:18    (scfsis.cpp (41) err=2000029 sys=0) SBL-SVR-00029: Internal:
Shared memory has not been initialized.

Cause

While carrying out tests to monitor the behaviour of the Siebel
Server service at start-up, it was determined that based on a number of
different variables (# of components enable; # of maxtasks per
components...etc), the optimal size of a Shared Memory file is
calculated.

The test Server employed for these tests was built
around the Microsoft Windows 2003 Server platform and configured with
1.8GB of physical memory.
Note, at no more point during the course
of these tests did the Server actually have more than 1107MB (approx
1.1GB) free – due to allocation made to the system itself as well as
other underlying (non-Siebel related) processes.

Observation:
With 5 Call Center Object Managers running with Default settings (Max Tasks = 20), .shm file built in memory was 13MB
With SCCObjMgr_enu (ONLY) re-configured to support 100 Masktasks, .shm file built went up to 22.7MB;

for 500 tasks, 70MB was required; while for 5000 and 10000 tasks, 564MB
of memory and 1.1GB of memory was required respectively.

**With 20000 Maxtasks enabled, the Siebel Server simply could not be starte

Solution

Resolution:

---To begin with no .shm could be created.



---After decreasing the number of max tasks set for one of the
Object Managers enabled, a 650MB shared memory file was created (note:
actual size on disk was 800MB), although the following error was also
recorded:
ServerLog    ProcessExit    1 0 2007-03-05 03:20:21


ServerLog    ProcessExit    1 0 2007-03-05
03:20:21    ePharmaObjMgr_egr60677     SBL-SVR-00027   Process exited
with error - Internal: Unable to attach the shared memory file.
---
By decreasing the number of max tasks set on several other components,
it was possible to reduce the size of the .Shm file created to 640MB and
also start up the Siebel Server.