SBL-GEN-03005: No data found

Applies to:

Siebel Anywhere - Version: 7.5.3.2 SIA [16168] and later   [Release: V7 and later ]
Siebel Remote - Version: 7.5.3.2 SIA [16168] to 8.0.0.5 [20420]   [Release: to V8]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.5.3.2 [16168] Life Sci

Database: Oracle 9.2.0.2

Application Server OS: Microsoft Windows 2000 Server SP 2

Database Server OS: HP-UX 11i



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

Symptoms

We have applied QF 0239 on our production on 10/01. We have also enabled
UpgradeKitBuilder and Siebel Anywhere to distribute the QF to our
Remote Users. In the time synchronization we are getting the error
“Unable to find Upgrade kit path”. Please check the attached error
screen shot.



We have followed the exact steps as mentioned in ‘Service Request #:
38-1265040051’, which was recommended on SR#38-1516696757. This works
fine on all our testing Environments.

Cause

Wrong setup

Solution

Message 1

For the benefit of the reader:



Customer created self extracting kit for QF. It was to be applied by Mobile Web Client version 7.5.3.2.



During testing when user connected directly to server he was apply the
upgrade kit. Attempt to apply kit on mobile client machine failed with
following error:



   

“Unable to download the upgrade kit”<NameofKit>” required to
upgrade your syteme. Please check your File System setting as available
disk space”SBL-CMD-00220”. This error message is misleading.





Synchronization Manager Log file has error

            

GenericLog    GenericError    1    2004-10-02 17:00:50    (syncsrvr.cpp
6(2418) err=3005 sys=0) SBL-GEN-03005: No data found for
UTLMiscFetchKitInfoCols

            

Real issue was Mobile Client who was trying to download the kit was on
Siebel Application Version 7.5.3 and Upgrade kit was built for Siebel
application Version 7.5.3.2 .. Error became apparent only from
syncthrd_*.log file. This log files had errors

Message 2

Trace    Trace    3    2004-10-02 14:54:16    Skipping kit (LFS_QF0239
1). Curr Component Version (7.5.3.0 sia [16157] ) is out of range, Min
Old Version (7.5.3.2), Max Old Version ()

Trace    Trace    3    2004-10-02 14:54:16    Skipping kit (LFS_QF0239
1) for component (Siebel Client Executables). Curr Version (7.5.3.0 sia
[16157] ) below Min Old Version (7.5.3.2) or above Max Old Version ()

GenericLog    GenericError    1    2004-10-02 14:54:16    (dockupgw.cpp
5(448) err=1700203 sys=0) SBL-DCK-00203: Unable to find upgrade kit path
to upgrade component LFS_QF0239. Please contact your Siebel
Administrator or try again.

SBL-GEN-03002: Required parameter %1 is NULL

Applies to:

Siebel Assignment Manager - Version: 7.8.2 [19213] to 8.1.1 [21112] - Release: V7 to V8
Information in this document applies to any platform.

Symptoms

When the SQL for the Dynamic Candidate was generated, then the component crashes with SBL-GEN-03002



SBL-GEN-03002: Required parameter %1 is NULL

Cause

Technical Support was unable to duplicate the issue.  When creating
an identically configured dynamic candidate, with criteria stored in the
same tables as the customer candidate, the candidate runs successfully
in the Siebel lab environment.


Eventually, through testing the candidate successfully on multiple
versions of the application in the lab environment, it was suspected
that the dictionary cache file diccache.dat or the assignment cache file
rulecache.dat in the customer's installation did not contain the proper
database information required to successfully perform the assignment
process. 


This was suspected because the customer's dynamic candidate |
candidate id column was an extension column.  Specifically, the
diccache.dat file acts as a data dictionary in the assignment process.

Solution

Diccache.dat and Rulecache.dat are located in the siebsrvr\bin
directory.  The customer was asked to perform the following steps:





1.  Stop the Siebel server service


2.  Browse the siebsrvr\bin directory and rename diccache.dat and
rulecache.dat to backup_diccache.dat and backup_rulecache.dat (it is
important to retain a backup copy of these files until you are certain
all components are running successfully after the process).


3.  Restart the Siebel Server Service.  As part of the restart
files, the 2 files will be regenerated to reflect the repository
database settings.





After completing these steps, the issue was resolved for this customer

SBL-GEN-03001: Error allocating %1

Applies to:

Error Message Area:Generic - GEN

Version:Siebel 8.1

Purpose

This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-GEN-03001: Error allocating
%1

Scope

This document is informational and intended for any user.

SBL-GEN-03001: Error allocating %1

Explanation

Unable to allocate memory for the specified entity. Most likely, memory resources on the machine are exhausted.

Corrective Action

Check available memory on the machine.

Applies to:

Siebel Assignment Manager - Version: 8.0.0.5 [20420] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

Customer recently added some organizational skills to their skill tables
by migrating the data from their development. Upon this change, the
assignment manager component is crashing when restarted. This means no
objects can be assigned and it is holding up their business.



Customer is receiving a SBL-GEN-03001 error upon restart at the point of the organizational skill load.

Cause

SBL-GEN-03001 indicates that there are not enough memory resouces to
perform the requested action. In this case, Assignment Manager is
attempting to load the organizational skills into the skill cache at the
time the crash occur. So, this would indicate that there are
inadequate memory resources available for the number of skills.



Prior to this issue there were 25.7 million skill items, now there are over 26 million.



Customer discloses that not all skill items in the table are active.





Part of the Assignment Manager process when starting is to create a
skill cache in memory. This allows assignment manager to perform at a
higher level when assigning records. If there are inadequate memory
resources available for the skills, then assignment manager cannot
create the cache.

Solution

It was discovered that when the skill item is deleted, the
corresponding skill item detail is not also deleted.  This was causing a
large number of orphaned records in the skill table.  CR 12-1XZBSYJ has been opened to address these orphaned records.

 Customer is going to prepare SQL or PL/SQL to clean the orphaned data from the table.



it is recommended that a backup of the table be taken prior to these actions executing.

References

BUG:10592003 - SBL-GEN-03001: ERROR ALLOCATING DYNARRCREATE ORGANIZATION SKILL ITEMS

Applies to:

Siebel Assignment Manager - Version: 7.8.2.5 SIA [19227] and later   [Release: V7 and later ]
Information in this document applies to any platform.

Symptoms

 We started the Batch Assignment task to assign one contact:



TaskConfig TaskCfgParamInit 4 0 2010-04-02 12:17:08 Assignment Object Name                        : Contact



TaskConfig TaskCfgParamInit 4 0 2010-04-02 12:17:08 Object Where Clause                           : where row_id='BBL-6YZ'



The task failed to start up while loading the assignment rules with the error:



GenericLog GenericError 1 0 2010-04-02 12:24:28 (asgnsrvr.cpp (1035)
err=3001 sys=0) SBL-GEN-03001: (asgnrule.cpp: 4269) error code = 3001,
system error = 2, msg1 = DynArrCreate pRuleApi->ruleItemArr, msg2 =
(null), msg3 = (null), msg4 = (null)



There were 3840 new assignment rules imported via EIM in the environment.

Cause

Large number of assignment rules with criteria and values exhausting
Batch Assignment component memory while loading them at task start-up. 
It hits the 2 GB heap memory limit is at machine/OS level.


Look up in Assignment Rules UI in Site Map > Administration -
Assignment > Assignment Rules List, very few are expired. And select
count(*) SQL right before the error from AsgnBatch log:



SELECT COUNT(*)



    FROM SIEBEL.S_ASGN_RULE CR, SIEBEL.S_ASGN_RULE_ITEM VAL, SIEBEL.S_ASGN_GRP R,



    SIEBEL.S_ASGN_RULE_GRP RG, SIEBEL.S_ASGN_RULE_GRP RG1,



    SIEBEL.S_ASGN_ITEM_TYPE ACR



  WHERE



 CR.ASGN_GRP_ID = R.ROW_ID



  AND VAL.ASGN_RULE_ID= CR.ROW_ID



  AND RG.ROW_ID=R.ASGN_RULE_GRP_ID



  AND RG.ROOT_RULE_GRP_ID=RG1.ROW_ID



 AND RG1.KEY_BASED_FLG = 'N'



  AND ACR.NAME = CR.ITEM_TYPE_NAME



  AND ACR.REPOSITORY_ID = ?



 AND ACR.INACTIVE_FLG='N'



 AND CR.TEMPLATE_FLG='N'



  AND (R.EFF_END_DT   >= {fn now()} OR R.EFF_END_DT IS NULL)



SQLSlowQuery Bind Variables 4 0 2010-04-02 12:24:05 01:1-PT64-1



returns 2740281 rows which is a high number.

Solution

Immediate solution is to reduce the number of assignment rules by
deleting assignment rules.  Customer worked with their Assignment Admin
person to delete assignment rules.  After that Batch Assignment worked.

For
the long term, you may look at engaging Oracle Consulting/Expert
Services to review the rules and optimize them to a lesser number.

Additional information:

Siebel
Server is a 32 bit application.  For each process, the memory limit is 4
GB.  In Windows, the heap limit is 2 GB. Batch Assignment (AsgnBatch)
is a Siebel component.  It's a process at runtime.  In  order to improve
the runtime performance ASAP, AsgnBatch loads all
rule/criteria/employee/position/org/skill/skill items into heap memory
at starting up.  We never set any limit on this.  2 GB is a 32 bit
machine and OS limit.  We have no way to overcome this.

By the
way 2 GB is not only for rules, all other stuff likes skill reside in
heap also.  We can't use the number of rules to determine how much
memory is needed since 1 rule may has a lot of criteria while the other 1
only has a few.



AsgnBatch support loading all rules or some rules within one rule group.

Set the AsgnKey to a rule group Id while submitting server request to AsgnBatch.

Then AsgnBatch will just load the rules with the rule group Id.



Too many rules is not a good thing for Assignment Manager.  You can try
to divide the existing rules into several different rule groups. But
this may fail again if the customer has a large number of rules within
one rule group. We don't have limit on number of assignment rules, the 2
GB memory limit is at machine/OS level.



Actually 1 Siebel Server is enough.  For example, we have rule group 1
and 2.  When you submit request to AsgnBatch, if you specify the AsgnKey
= group 1, only the rules under rule group 1 will be loaded.

Of course you can submit another request to AsgnBatch with AsgnKey =
group 2. This is different with the server key mapping for Assignment
Manager (AsgnSrvr) component.

Applies to:

Siebel Assignment Manager - Version: 8.1.1.2 SIA[21215] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

On : 8.1.1.2 SIA[21215] version, Assignment Manager



When attempting to Start Assignment Manager

the following error occurs.GenericLog GenericError 1 000053d84dd91268:0
2011-05-22 12:45:41 (asgnrule.cpp (6963) err=3001 sys=2) SBL-GEN-03001:
Error allocating DynArrCreate pRuleApi->EmpArr



ERROR

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

SBL-GEN-03001





STEPS

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

The issue can be reproduced at will with the following steps:

1. Start Assignment Manager

2. Wait

3. component crashes




Due to this issue, users cannot have records assigned as expected.

Cause

Upon restart, Assignment Manager will build a cache of candidates for
assignment that is held in memory. A Significant change in the number
of employees is pushing this memory cache beyond its limits.





SBL-GEN-03001 is indicative of a memory problem per <>.
Additionally customer has indicated that they recently added over
900,000 employees to the database, many of which are terminated

Solution

The solution is to use the Active Employee Where Clause parameter on the
Assignment Manager component to limit the number of employees loaded
into cache on component restart.

1. In Server Configuration > Server >Components locate the Assignment Manager Component, Parameters

2. Locate the Employee Where Clause Paramenter

3. Enter the where clause, in SQL formatting, not Siebel formatting, to
select only the employees to be considered for assignment. In this
case, customer chose the where clause WHERE emp.EMPLOYEE_STATUS_CD =
'HR'

References

NOTE:1103948.1

SBL-GEN-01000: System was unable to allocate sufficient memory

Applies to:

Siebel eCommunications eMail Response - Version: 7.7.2 SIA [18325] and later   [Release: V7 and later ]
Siebel Email Response - Version: 7.7.2 SIA [18325] and later    [Release: V7 and later]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.7.2 [18325] Pub Sect

Database: Oracle 9.2.0.6

Application Server OS: Microsoft Windows 2003 Server

Database Server OS: Microsoft Windows 2003 Server



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

Symptoms

We have an Comm Inbound Receiver on our Test machine that worked fine up
until a certain day 2 months ago and then we have not been able to get
it to work again since then. I have attached the log file. I have
followed all recommendations on SRs regarding POP3, but I have not been
able to find a solution. I can login to the pop3 server fine from the
telnet command line and lock the mailbox, but Siebel never gets to the
point of trying to login based on the log files. I have also attached
the script of the telnet session.

Although this is not a
production issue, it is preventing us from testing critical fixes to the
production system. Thank you for your prompt attention to this matter.

Cause

Incorrect settings for the Comm Inbound Processor component.

Solution

Message 1

For the benefit of other users,

When the Siebel Services are started, the Comm inbound processor was exiting with the task status
SBL-GEN-01000: System was unable to allocate sufficient memory for the specified operation.

Upon
further investigation it was found out that the reason was the
tableowner pass and password parameters for the comm Inbound receiver
and Comm Inbound processor components were changed at the enterprise
component definition level making them visible in clear text. Once these
parameters were removed, the components started normally and the emails
were properly processed.

SBL-GEN-00231 Process exited with error

Applies to:

Siebel CRM - Version: 8.1.1 [21112] and later   [Release: V8 and later ]

z*OBSOLETE: IBM AIX5L Based Systems (32-bit)

***Checked for relevance on 28-FEB-2011***

Symptoms

Started JMS Receiver Component remains with the "running" state, but does not connect to JMS Server and does not start to pick up messages from the Queue.



1. Detailed  task log indicates no errors, but also does not show JMS works.



2.
Siebel Server log file gets the "BL-GEN-00231 Process 2453540 exited
with error" message for the JMS Receiver Component. The component self
remains available.

Changes

Following setting were applied in Siebel Enterprise following information, given in the Siebel Bookshelf document: Transports
and Interfaces: Siebel Enterprise Application Integration (EAI Volume
2): Java Business Service > Prerequisites for Implementing a Java
Business Service.

1. The DLL parameter of the “JAVA” named subsystem (used by the JMS Receiver

Component)
has been set to load the “libjvm.a” static library from the “classic”
Java Virtual Machine of the IBM JDK Java 1.5 (jdk150_20070725):





2. The LIBPATH environment variable in the Siebel Server startup script was set to include following JDK folders:

/…/java/jdk/aix/ jdk150_20070725/jre/bin:

/…/java/jdk/aix/ jdk150_20070725/jre/bin/classic:

/…/java/jdk/aix/ jdk150_20070725/jre/lib

/…/java/jdk/aix/ jdk150_20070725/lib

/…/java/jdk/aix/ jdk150_20070725/jre/bin/classic/libjvm.a

3. The /…/java/jdk/aix/ jdk150_20070725/jre/bin/classic/libjvm.so file did not exist

Cause

Use of static JVM dll library: classic/../libjvm.a, while the dynamic one was required j9vm/.../libjvm.so



"Truss"
traces, indicated that a dynamic JVM library: "libjvm.so" was not found
in the "classic" JVM folder. It was present in the  "j9vm" JVM
directory.

Solution

Following settings change was performed in Siebel Enterprise following information, given in the Siebel Bookshelf document: Siebel
Application Deployment Manager Guide: Configuring and Administering the
ADM Framework > Process of Configuring the ADM
Framework after Installing Siebel Management Server and Siebel Management Agent > Configuring the Siebel Server for ADM.



1. The DLL parameter of the “JAVA” named subsystem (used by the JMS Receiver

Component)
has been changed to load the “libjvm.so” dynamic library from of “j9vm”
Java Virtual Machine of the IBM JDK Java 1.5 (jdk150_20070725):

/…/java/jdk/aix/ jdk150_20070725/jre/bin/j9vm/libjvm.so

2. The LIBPATH environment variable in the Siebel Server startup script was amended to include only followig JDK folders:

/…/java/jdk/aix/ jdk150_20070725/jre/bin:

/…/java/jdk/aix/ jdk150_20070725/jre/bin/j9vm:

/…/java/jdk/aix/ jdk150_20070725/lib

The Change Request BUG 10559560 has been logged to ask for accordant documentation update in the EAI Book.

It has been fixed in Bookshelf 8.1

References

BUG:10559560 - [CR#12-1RRC6R1][FR#12-1RRC6RN] JMS RECEIVER DOES NOT READ FROM JMS QUEUE

Applies to:

Siebel Financial Services CRM - Version: 8.1 SIA [21039] to 8.1 SIA [21039] - Release: V8 to V8

IBM AIX on POWER Systems (32-bit)

Description

An error occurs while running of 'EAI JMS Transport' or 'Java Business Service' on Siebel version 8.1.1.x on AIX platform.

Likelihood of Occurrence

This affects EAI JMS Transport and Java Business Service running on AIX platform, when using :-

Sun JDK (instead of IBM Java SDK), or
IBM Java SDK but incorrect Java library being referenced in the Java (JVMSubsys) profile, or

LIBPATH and LD_LIBRARY_PATH does not reference the expected shared libraries.

Possible Symptoms

The following error will be encountered.



Error:

JVM Exception:java.lang.UnsatisfiedLinkError: net (No such file or directory)
JVM Exception:java.lang.NoClassDefFoundError: java.net.InetAddress (initialization failure)

Workaround or Resolution

1. Update the DLL parameter of the 'JVMSubsys' profile to reference the '/usr/java6/jre/lib/ppc/j9vm/libjvm.so' as per documentation on IBM JRE 1.6 on the IBM website for JNI calls from C/C++ code :-



http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/topic/com.ibm.java.doc.user.aix32.60/user/migrating_60.html



2. Update the environment variables LIBPATH and LD_LIBRARY_PATH  to include the directories containing the :

• JMS provider specific jar files and


• jre/lib/ppc and /jre/lib/ppc/j9vm (from IBM Java SDK install directory).

For example :

/u01/siebel/weblogic:/usr/java6/jre/lib/ppc:/usr/java6/jre/lib/ppc/j9vm



where : /u01/siebel/weblogic - is the directory containing JMS Provider specific (e.g Weblogic) jar files

NOTE :- When you build a C or
C++ program that uses the invocation API, your LIBPATH must include the
directories containing the JVM's shared libraries,
/usr/java6/jre/lib/ppc/ and /usr/java6/jre/lib/ppc/j9vm, as well as the
directories that contain the application's shared libraries.

Documentation Enhancement Request <Bug:13646352>
has been filed, to request correction of the LIBPATH expression example
for AIX, to have its JRE-related essential part look as:



...:/usr/java6/jre/lib/ppc:/usr/java6/jre/lib/ppc/j9vm:....

References

NOTE:1285062.1 - JRE version 1.6 required for all Siebel versions from Fix Pack 8.1.1.4 onward

SBL-EAI-05000

SBL-EAI-05102

NOTE:762463.1 - JMS receiver on AIX SBL-GEN-00231 Process exited with error

BUG:10559560 - [CR#12-1RRC6R1][FR#12-1RRC6RN] JMS RECEIVER DOES NOT READ FROM JMS QUEUE

BUG:13646352 - JBS: CORRECT LIBPATH VALUE FOR AIX

SBL-GEN-00230 Process exited with error

Applies to:

Siebel Reports - Version: 8.1.1.1 [21211] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

When attempting to upload a report after initial installation the following error may appear in a dialog box :

Process XMLPReportServer on Siebel Server siebsrvr1 terminated

Log file Entries:



<enterprise_name>.<server_name>.log:

ServerLog ProcessExit 1 0000a8d64beb0070:0 2010-05-13 08:54:55
XMLPReportServer 696474 SBL-GEN-00230 Process 696474 exited with
error -



XMLPReportServer_xxx.log:

XMLPReportLog XMLPReportInfo 3 000080c04bca7024:0 2010-05-13 08:54:54 BIP's using Security Model

XMLPReportLog XMLPReportDetail 4 000080c04bca7024:0 2010-05-13 08:54:54 ReportName : Account List

XMLPReportLog XMLPReportDetail 4 000080c04bca7024:0 2010-05-13 08:54:54 TemplateFileName : aclist.rtf

XMLPReportLog XMLPReportDetail 4 000080c04bca7024:0 2010-05-13 08:54:54
TemplateFilePath : /appl/siebel/siebsrvr/xmlp/templates/aclist.rtf

XMLPReportLog XMLPReportDetail 4 000080c04bca7024:0 2010-05-13 08:54:54
Xliff File : /appl/siebel/siebsrvr/xmlp/xliff/enu/aclist.xlf

XMLPReportLog XMLPReportDebug 5 000080c04bca7024:0 2010-05-13 08:54:54 Getting XMLP Java Business Service

XMLPReportLog XMLPReportDebug 5 000080c04bca7024:0 2010-05-13 08:54:54
Invoke UploadReport method of XMLPJavaBusvc java wrapper class

Whilst
the XMLPReportServer process was reporting as having crashed there was
no evidence of an FDR or crash file on the Siebel Server.

Cause

The behavior is caused by running with an incorrect version of Java
Installed. In addition the JAVA_HOME and LIBPATH settings were
incorrectly specified.

Solution

In order to resolve this behavior, it is necessary to install 32-bit
Java and setting the JAVA_HOME and LIBPATH correctly to Java5 32-bit.

For more information on the setting of the environment variables, refer to the following link :

http://download.oracle.com/docs/cd/E14004_01/books/EAI3/EAI3_EAIJBS3.html

This
link can also be viewed from Bookshelf V8.1 Transports and Interfaces:
Siebel Enterprise Application Integration > Java Business Service
> Prerequisites for Implementing a Java Business Service.

SBL-GEN-00255 Process exited with error - Internal: Error during exec

Applies to:

Siebel System Software - Version: 7.5.2.100 [15252] to 8.1.1.1 SIA [21211] - Release: V7 to V8
Generic UNIX
Generic Linux

Product Release: V7 (Enterprise)

Version: 7.5.2.100 [15252]

Database: IBM DB2 8.1 FixPack 6b

Application Server OS: IBM AIX 5L 5.1

Database Server OS: IBM AIX 5L 5.1



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

Symptoms

SBL-GEN-00255, SBL-OSD-00220, SBL-OSD-02006, SBL-OSD-02011, SBL-OSD-00204, SBL-ADM-02049, SBL-GEN-00001, OSDmprotect

The Siebel Server was running fine until a few weeks ago. Now
we are unable to start the Siebel Server. The Siebel Gateway Name Server
is running fine.


When we start the Siebel Server by using start_server all command,
the main thread starts (siebsrvr) but when it spawns the child threads
(siebmtsh), they are not staying alive.


No Siebel multithreaded server processes are started after running
start_server all and no Application Object Manager log files are being
generated.


The SiebSrvr.log under siebsrvr/log directory may contain the following error:

    SBL-OSD-00220: Internal: pthread_mutex_trylock () failed with error. (22)


In some situations the following error may also be seen:


   OSDmprotect: mprotect(0xf7400000, 0, 0x00000001) failed with error 22



In addition to SBL-OSD-00220 error messages in SiebSrvr.log log
file, error messages like the following are being logged in the
Enterprise Server log file
(<enterprise_name>.<server_name>.log) under
$SIEBEL_ROOT/enterprises/<enterprise_name>/<server_name>/log
directory:

<NoCompName> 64527 SBL-GEN-00002 Process exited with error - Error code SBL-GEN-00002

Changes

 

Cause

A) This situation has been reported when the Unix machine has been
shutdown without having run the stop_server script. The stop_server
script should remove the
osdf.<enterprise_name>.<server_name> file that resides in
the $SIEBEL_ROOT/siebsrvr/sys directory.

B) This situation has
also been reported when the
svc.siebsrvr.<enterprise_name>:<server_name> was duplicated
under $SIEBEL_ROOT/siebsrvr/sys directory.

When you specify the
ALL argument, the start_server script searches for all files under
$SIEBEL_ROOT/siebsrvr/sys in the format svc.siebsrvr.* and parses it to
identify the Enterprise name and the Server name.
The first string after svc.siebsrvr. is the Enterprise name and the second one is the Server name.
The start_server script skips all filenames ended with the .bak extension, because they are considered backup files.
Then it starts the service and creates the OSDF file based on these parsed names.

Customer has three svc* files on his system:

- $SIEBEL_ROOT/siebsrvr/sys/svc.siebsrvr.<enterprise_name>:<server_name>
- $SIEBEL_ROOT/siebsrvr/sys/svc.siebsrvr.<enterprise_name>:<server_name>.bak
- $SIEBEL_ROOT/siebsrvr/sys/svc.siebsrvr.<enterprise_name>:<server_name>.OLD1

The second file is considered as a backup file by start_server script.
However,
the other two files are used by start_server to start up the Siebel
Server, and both point to the same Enterprise and Server names.
Therefore, the start_server script is starting the same Siebel Server twice.

The
problem is that, when the second instance is started, the OSDF file is
overwritten, and the information used by Siebel about the memory
structures used by the first instance is lost. The second instance will
conflict with the first one, and the processes end up failing.

Solution

In order to fix this behavior and guarantee you have a clean environment, please do the following:

1. Shutdown the Siebel Server and run the following commands to clean all structures that may remain:

    % stop_server ALL
    % reset_server -e <enterprise_name> <server_name>
    % siebclean -f $SIEBEL_ROOT/siebsrvr/admin/<enterprise_name>.<server_name>.shm -q
    % cleansync -f $SIEBEL_ROOT/siebsrvr/sys/osdf.<enterprise_name>.<server_name> -d
    % siebctl -r $SIEBEL_ROOT -S siebsrvr -i <enterprise_name>:<server_name> -k -q
    % mwcleanup -silent 2>/dev/null

2. If using AIX, log into UNIX as root and run the following command:

    % /usr/sbin/slibclean

3.
Ensure no Siebel processes are running and check that there are no
semaphores or shared memory segments allocated for the UNIX user who
owns the Siebel Server installation:

    % ps -ef | grep <username>
    % ipcs -b

4.
If there are any processes, shared memory segments or semaphores stuck
in memory, they can be killed by using the following commands,
respectively:

    % kill -9 <process_ID>
    % ipcrm -m <shared_memory_segment_ID>
    % ipcrm -s <semaphore_ID>

5. Remove the following files if they still exist:

    $SIEBEL_ROOT/siebsrvr/sys/osdf.<enterprise_name>.<server_name>
    $SIEBEL_ROOT/siebsrvr/admin/<enterprise_name>.<server_name>.shm

6. Remove all svc* files or move all of them out from $SIEBEL_ROOT/siebsrvr/sys directory.

7. Recreate the correct svc* file:

 

For Siebel 8.0.x and earlier please use the comand: 

%
siebctl -S siebsrvr -i "<enterprise_name>:<server_name>" -a
-g "-g <gateway_name> -e <enterprise_name> -s
<server_name>"

For Siebel 8.1.x and later please use the comand: 

%
siebctl -S siebsrvr -i "<enterprise_name>:<server_name>" -a
-g "-g <gateway_name> -e <enterprise_name> -s
<server_name> -u <sadmin_user>" -e <sadmin_password>

please note that the siebel server service needs user and password for gateway authentication starting with Siebel version 8.1

8. Restart the Siebel Server:

    % start_server all

Customers
should note that if there are still any processes, semaphores or shared
memory segments stuck in memory, the machine will need to be rebooted
before recreating the svc* file (between steps 6 and 7).


Customers should also note that recreating the svc* file (steps 6
and 7) is not necessary in all situations, and in most cases step 1 only
is sufficient to guarantee a clean startup.

KEYWORDS:
start_server all, failure to start Siebel on Unix server,  OSDmprotect,
err=1300220 sys=22 sys=0 SBL-GEN-00001 SBL-GEN-00002 SBL-GEN-00003
SBL-GEN-00004 SBL-GEN-00005 SBL-GEN-00006 SBL-GEN-00007
pthread_mutex_trylock AIX slibclean ipcrm

Applies to:

Siebel System Software - Version: 7.5.3 SIA [16157] and later   [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3 [16157] Cons Sec

Database: IBM DB2/UDB 7.2

Application Server OS: IBM AIX 5L 5.1

Database Server OS: IBM AIX 5L 5.1



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

Symptoms

SBL-GEN-00255, SBL-OSD-02006The object manager and several important server components are unavailable or partially online -
this is holding up Production load!!!

The following is appearing in the Enterprise server
log:
ServerLog    ProcessExit    1    2003-11-03
22:41:58    <NoCompName>    17427     SBL-GEN-00255   Process
exited with error - Internal: Error during exec()

Cause

Enhancement request 12-IYEB5W

Solution

Message 1

For the benefit of others:



The following components are showing as UNAVAILABLE via srvrmgr and SIGBART in the enterprise log.



Business Integration Batch Manager

Business Integration Manager

Workflow Process Batch Manager

Workflow Process Manager

eConsumerSectorObjMgr_enu



Multiple occurrences of the following error was seen in the enterprise server log:



ServerLog    ProcessExit    1    2003-11-03
22:41:58    <NoCompName>    17427     SBL-GEN-00255   Process
exited with error - Internal: Error during exec()



As part of the troubleshooting:

Reset some parameter values for one of the components which is
unavailable, stop and restart the Siebel server via the UNIX command
line and see what error messages may be displayed after the start up.



Tried the following for eConsumerObjMgr_enu on server, siebdvsrvr



1. Use srvrmgr to set the following:

change param foreground=true for comp eConsumerObjMgr_enu server siebdvsrvr

change evtloglvl %=5 for comp eConsumerObjMgr_enu server siebdvsrvr

change param errorflags=-1 for server siebdvsrvr

change param traceflags=-1 for server siebdvsrvr



2. Stop the Siebel server.



3. As root login, run the AIX command slibclean



4. Start the Siebel server using the following command (do not use the
start_server script and ensure siebenv.sh has already been invoked):

siebsrvr /g <gateway_host> /e <enterprise> /s <server>



eg. siebsrvr /g gateway_host_name /e siebdvent /s siebdvsrvr



(cont)

Message 2

(cont)

5. Do you see any error messages on the screen following the siebsrvr startup?



You can control C out of that screen and then revert back to restarting the Siebel server via start_server script.

To revert back with the parameters you can reset:

change param foreground=FALSE for comp eConsumerObjMgr_enu server siebdvsrvr

change evtloglvl %=1 for comp eConsumerObjMgr_enu server siebdvsrvr



From Step 5 when running the siebsrvr command, the following message displayed:



Fatal Error: The file /siebapp/sieb75/siebsrvr/mw/system/registry.bin is not a valid registry file

Fatal Error: Could not load the HKLM hive (/siebapp/sieb75/siebsrvr/mw/system/registry.bin).



Resolution:



Checked the date and file size of $SIEBEL_ROOT/mw/system/registry.bin.*

registry.bin is 245760 dated 9/29

registry.bin.old is 819200 dated 9/25



The backup copy of registry.bin.old is the correct size. Shutdown the
Gateway and Siebel Servers and copied in this backup copy to be the
current registry.bin via:

mv $SIEBEL_ROOT/mw/system/registry.bin $SIEBEL_ROOT/mw/system/registry.bin.current



mv $SIEBEL_ROOT/mw/system/registry.bin.old $SIEBEL_ROOT/mw/system/registry.bin



Restarted the servers and all components are now coming online available.



Enhancement request 12-IYEB5W was logged to provide a more descriptive error message to identify a corrupt registry.bin

Applies to:

Siebel eCommunications Call Center - Version: 8.0 [20405] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

Customer tried to install and configure the swse with Oracle Application Server but always failed with below error:



GenericLog GenericError 1 0000000249a74757:0 2009-02-27 16:13:33 Executing step: ApplyValuescfg
GenericLog GenericError 1 0000000249a74757:0 2009-02-27 16:13:33 Executing step: RestartWebServer
GenericLog GenericError 1 0000000249a74757:0 2009-02-27 16:13:33 Executing step: ShutdownApacheServer
GenericLog
GenericError 1 0000000249a74757:0 2009-02-27 16:13:35 (ossystem.cpp
(96) err=255 sys=0) SBL-GEN-00255: Internal: Error during exec()
GenericLog
GenericError 1 0000000249a74757:0 2009-02-27 16:13:35 Step
ShutdownApacheServer: failed to run program
%%WebServerInstance%%%%OSDirSeparator%%bin%%OSDirSeparator%%apachectl
with cmdline stop
GenericLog GenericError 1 0000000249a74757:0 2009-02-27 16:13:35 Failed during Execution, err: 255

Cause

There are 2 possible causes:


- Initially they installed the complete Oracle Application Server, not the one from companion CD.


- They then reinstalled using Oracle HTTP Server 10.1.3/Apache
v2.x, from the Oracle Application Server 10.1.3 companion CD, but the
"Web Server Instance Location" was not entered correctly.

The "Web Server Instance Location" should be the directory where the Oracle Application Server is installed.

The customer supplied it with:
Web Server Instance Location : /data1/siebel_sweapp/https-one5all

while
the Oracle Application Server was installed in 
/data1/oracle/app10gR3/ohs (httpd.conf exists in conf directory of the
Web Server, /data1/oracle/app10gR3/ohs/conf/httpd.conf)



After correcting the above parameter, customer was able to proceed and complete the swse installation

Oracle Application Server 10.1.3 companion CD can be downloaded from:


http://www.oracle.com/technology/software/products/ias/htdocs/101310.html

Solution

It was suggested to customer to rerun the configuration with the correct location.

The ”Web Server Instance Location” should be: /data1/oracle/app10gR3/ohs.



The installation/configuration of the swse was then completed successfully.

 

Applies to:

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

Symptoms

Customer had installed 8.0.0.9 patchset to production enviroment.
Previously customer had Siebel 8.0.0.8 version and was installed on the
IBM AIX 5.3 (64-bit). After installation of 8.0.0.9 patchset siebel
server was not coming up.

Error:

-------
Siebel server Logs:
--------------------

GenericLog GenericError 1 000069d14e0b30c0:0 2011-06-29 18:15:09
(sccnmsys.cpp (1305) err=2883609 sys=0) SBL-SCC-00025: No value found in
the Gateway. Default value in the repository is used.

GenericLog GenericError 1 000069e04e0b30c0:0 2011-06-29 18:15:09
(sccnmsys.cpp (1305) err=2883609 sys=0) SBL-SCC-00025: No value found in
the Gateway. Default value in the repository is used.

Enterprise Logs:
------------------
GenericLog
GenericError 1 000076ee4deb1046:0 2011-06-05 13:31:39 (scirkey.cpp
(1142) err=1310772 sys=0) SBL-SVR-00052: Internal: Invalid proc handle
ServerLog
ProcessExit 1 000076ee4deb1046:0 2011-06-05 13:31:39 SRBroker 594106
SBL-GEN-00255 Process 594106 exited with error - Internal: Error
during exec()

Changes

Applies patchset 8.0.0.9 on top of 8.0.0.8.

Cause

After Verification it was found installable library files from previous
installation 8.0.0.8 got corrupted and hence installation of 8.0.0.9 is
not getting through.


Further verification showed, release timestamp for some library
files from 'siebsrvr/lib' were not set to patch release date but patch
install date.

In Ideal case the timestamp should correspond to patch release date,
thing is that the release time stamp is only set at the very end. If
something breaks before then files remain on disk with install date.



In case of customers environment, some library files has timestamp of
April2011 which is patch installation date, in correct scenario it
should have been patch 8.0.0.8 release date (Oct2009).

Which shows incorrect deployment of 8.0.0.8 patchset.

Solution

Below are some prominent steps for re-installation of gateway and Siebel Servers:



Reinstalling the Gateway Server:

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

1) Stop the Gateway service

2) Uninstall the Gateway server.

3) Delete the Gateway server directory structure.

4) Reboot the machine.

5) Install the Gateway server.



Reinstalling the Siebel Server:

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

1) Make backups of all the .cfg files present in \siebsrvr\bin and the siebns.dat file present in \gtwysrvr\ADMIN.

2) Make backup of the .srf file present in \siebsrvr\OBJECTS.

3) Make backups of the following folders present in the \siebsrvr directory to take care of any customizations:

IDCENTRIC, MSGTEMPL, REPORTS, WEBTEMPL.

4) I am not sure if you have remote users in your environment, If there
are remote users working off this application server, backup the
following folders to avoid reextracting them:

DOCKING, DBTEMPL

5) Stop the Siebel server service

6) Uninstall the Siebel server

7) Delete the Siebel server directory structure.

8) Remove Siebel Server from the Gateway by removing configuration from wizard.

9) Reboot the machine.

10) Start the Gateway server service if not running already.

11) Install the Siebel server using same installation parameters as before.

12) Copy the backed up folders, .cfg files and the .srf file to the corresponding directory where it belongs.

13) Stop and restart the Gateway and Siebel server services.

14) From the Server Administration screen enable the needed component groups.



There is a note out there on MOS with the correct steps. It refers to Windows but same steps apply to AIX as well:

Reinstalling the Siebel Servers (Doc ID 476317.1)

Note: This
solution was specific to one environment/scenario, there is possibility
that same solution may not work for other environments.

References

NOTE:476145.1 - Failure When Installing Siebel Patches on the AIX Operating System

NOTE:971849.1 - Error "SBL-SVR-01031: Invalid Parameter" is generated in the SRProc log files

Applies to:

Siebel Server Extns for Solaris Operating Envrmnt - Version: 8.1.1.5 [21229] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

SWSE configuration fails with error on step SetMimeTypes

2011-08-19 14:22:34 Looking for executable
/usr3/siebiut/siebel/siebsrvr/bin//usr3/siebiut/siebel/siebsrvr/install_script/install/UpdateMimeTypes
2011-08-19
14:22:34
/usr3/siebiut/siebel/siebsrvr/bin//usr3/siebiut/siebel/siebsrvr/install_script/install/UpdateMimeTypes
not found
2011-08-19 14:22:36 (ossystem.cpp (96) err=255 sys=0) SBL-GEN-00255: Internal: Error during exec()
2011-08-19 14:22:36 OSSystem returned 255
2011-08-19
14:22:36 Step SetMimeTypes: failed to run program
%%SiebelRoot%%%%OSDirSeparator%%install_script%%OSDirSeparator%%install%%OSDirSeparator%%UpdateMimeTypes
with cmdline %%SiebelRoot%% %%WebServerInstance%%
2011-08-19 14:22:36 Failed during Execution, err: 255
2011-08-19 14:39:31 Exiting configuration.

Cause

SWSERoot was incorrectly defined prior to launching the configuration wizard

Verbose log file contains the following entries:

Value key SiebelRoot resolves to /usr3/siebiut/siebel/siebsrvr

Value key SWSERoot resolves to /usr3/siebiut/siebel/siebsrvr

Solution

Verify the directory containing your SWEApp installation and then
source the correct environment variables using cfgenv.sh from it, before
running the configuration wizard once more.

References

NOTE:955972.1 - Issues with SWSE Configuration task - Siebel Release 8.1.1 Version