Create New Timesheet shows blank screen

Samir mailed today. After enabling Oracle Time and Labor in OAM as a newly licensed product, when they access the responsibility Timesheets > Create New Timesheet, the screen goes blank.

Apache logs looked fine. Finally I did a view source on the page and found this at the end:

top.fInitUnexpectedError("The system profile option setup indicates that your system is not licensed to run Self-Service Time. Please contact your system administrator and verify the profile option settings.")

I spoke to Vivek who suggested that we set these profile options to Yes:

PA: Licensed to use Project Time and Expenses
PA: Licensed to use Self-Service Time

After setting these to Yes, it proceeded ahead and showed a page with this message:

Some of your employee information is missing or invalid. Please notify your system administrator.

This was coming because there is no HR record for SYSADMIN account.

The Create Timesheet functionality works fine from Self Service Time responsibility.

I'll update this post, once I learn more.

Windows Command Line shortcuts

If you go to c:\windows\system32 and execute dir *.msc you'll find quite a few:

certmgr.msc        Certificates
ciadv.msc          Indexing Service
compmgmt.msc       Computer Management
devmgmt.msc        Device Management
dfrg.msc           Defragmenter
diskmgmt.msc       Disk Manager
eventvwr.msc       Event Viewer
fsmgmt.msc         File share management
gpedit.msc         Group Policy Editor
lusrmgr.msc        Local Users and Groups
ntmsmgr.msc        Removable Storage
ntmsoprq.msc       Removable Storage Operator Requests
perfmon.msc        Performance Monitor
rsop.msc           Resultant Set of Policy
secpol.msc         Security Policy
services.msc       Services
wmimgmt.msc        Windows Management Infrastructure

If you give a dir *.cpl you'll find more shortcuts for Control Panel applets:

access.cpl         Accessibility
appwiz.cpl         Add Remove Programs
bthprops.cpl       Bluetooth Properties 
desk.cpl           Display properties
firewall.cpl       Firewall
hdwwiz.cpl         Add new hardware wizard
inetcpl.cpl        Internet Properties
infocardcpl.cpl    Windows Cardspace
intl.cpl           Regional and Language options
irprops.cpl        Wireless Link properties
javacpl.cpl        Sun Java Control Panel
joy.cpl            Game Controllers
main.cpl           Mouse Properties
mmsys.cpl          Sound and audio device properties
ncpa.cpl           Network Connections Properties
netsetup.cpl       Network Setup Wizard
nusrmgr.cpl        User Accounts
nwc.cpl            Gateway Services for Netware properties
odbccp32.cpl       ODBC Administrator
plugincpl13125.cpl Oracle Jinitiator 1.3.1.25 control panel
plugincpl13128.cpl Oracle Jinitiator 1.3.1.28 control panel
plugincpl13129.cpl Oracle Jinitiator 1.3.1.29 control panel
powercfg.cpl       Power Options properties
sapi.cpl           Speech properties

sysdm.cpl          System Properties
telephon.cpl       Phone and Modem Options
timedate.cpl       Date and Time properties
wscui.cpl          Windows Security Center
wuaucpl.cpl        Windows Automatic Updates

You can call any of the above *.cpl or *.msc files from command prompt or Start > Run.

ORA-07445: exception encountered: core dump [drumcmf()+184] [SIGSEGV]

We got this error in one of our Production instances whenever we ran Gather Schema Statistics program:

Errors in Database alert log:
$ORACLE_HOME/admin/$CONTEXT_NAME/udump/$TWO_TASK_ora_13052.trc:
ORA-07445: exception encountered: core dump [drumcmf()+184] [SIGSEGV] [Address
not mapped to object] [0x000000000] [] []

Trace file:
ORA-07445: exception encountered: core dump [drumcmf()+184] [SIGSEGV] [Address not mapped to object]
[0x000000000] [] []
Current SQL statement for this session:
begin :retval := "CTXSYS"."TEXTOPTSTATS".ODCIStatsCollect(:idx_info,:stat_opt,:stats,:env);
end;
----- PL/SQL Call Stack -----
object line object
handle number name
3b1247878 6 CTXSYS.TEXTOPTSTATS
3b1688f20 1 anonymous block
3b144c860 3379 package body SYS.DBMS_STATS
3b144c860 3639 package body SYS.DBMS_STATS
3b144c860 10584 package body SYS.DBMS_STATS
3b144c860 13153 package body SYS.DBMS_STATS
3b144c860 13202 package body SYS.DBMS_STATS
3a7244100 1 anonymous block
3b11b3e38 676 package body APPS.FND_STATS
3b11b3e38 1487 package body APPS.FND_STATS
3b11b3e38 1004 package body APPS.FND_STATS
3b11b3e38 782 package body APPS.FND_STATS
3c197dab0 1 anonymous block

We had an SR logged with Oracle for this. They noticed that we were not passing estimate percent which defaults to 10%. They asked us to explicitly give estimate percent as 30% and run GSS. The issue was resolved after this. From the SR:

ISSUE CLARIFICATION
====================

Gather Schema Statistics concurrent program issue for ' All ' schemas : it completes with error.


ISSUE VERIFICATION
===================
Verified the issue by the alert log file and trace file , which displays :

ORA-07445: exception encountered: core dump [drumcmf()+184] [SIGSEGV] [Address not mapped to object] [0x000000000]" errors are encountered with core dumps.


CAUSE DETERMINATION
====================
Parameters to run Gather Shema Statistics are incorrect.

CAUSE JUSTIFICATION
====================
The following parameters are set as fillow :

GATHER OPTIONS: GATHER AUTO
Estimate Percent: 10


.
PROPOSED SOLUTION(S)
======================
GATHER OPTIONS: GATHER
Estimate Percent: 30


PROPOSED SOLUTION JUSTIFICATION(S)
====================================
GATHER AUTO : If underlying tables are not in monitoring mode , then "Gather Auto" option will try to change it. Since this is a DDL statement, it requires an exclusive lock on the table. If
table is under heavy load and frequently accessed , then this might take a while.
Note : 331017.1


Estimate Percent : Note.141532.1

Percentage of rows to estimate. If left empty it will default to 10%. The valid range is 0-99. A higher percentage will be more accurate, but take longer to run. If the object(s) that you
are gathering statistics for do not change often or the object(s) has data entered that is very similiar you may choose a lower number. However, if the data changes frequently a larger number entered for this parameter would be recommended to provide a more accurate representation of your data.

SOLUTION / ACTION PLAN
=======================
To implement the solution, please execute the following steps:

1. Schema Name: ALL
Estimate Percent: 30
Backup Flag : NOBACKUP
HISTORY MODE: LAST RUN
GATHER OPTIONS: GATHER
Invalidate Dependent Cursors: Y (Yes)


2. References :
Note. 141532.1 ' How To Gather Schema Statistics for Oracle Applications 11i '
Note. 331017.1 ' Gather Schema Statistics program hangs or fails with ORA-54 error '

LsInventorySession failed: Unable to create patchObject

Srinivas reported this error today:

opatch lsinventory showed this error at the end:

Inventory load failed... OPatch cannot load inventory for the given Oracle Home.

LsInventorySession failed: Unable to create patchObject

OPatch failed with error code 73

Metalink note 751152.1 suggested a few things but we didn't want to reclone the Oracle home. So we enabled debug mode:

export OPATCH_DEBUG=TRUE

And found that:

PatchObject::PatchObject looks for the actions file $ORACLE_HOME/inventory/oneoffs/5587976/etc/config/actions.xml
PatchObject::PatchObject looks for the inventory file $ORACLE_HOME/inventory/oneoffs/5587976/etc/config/inventory.xml
parserXMLFile : start
parserXMLFile : start
PatchObject(oracleHomePath,patchID)
PatchObject::PatchObject looks for the actions file $ORACLE_HOME/inventory/oneoffs/5648872/etc/config/actions.xml
PatchObject::PatchObject looks for the inventory file $ORACLE_HOME/inventory/oneoffs/5648872/etc/config/inventory.xml
PatchObject::PatchObject now looks for the actions file $ORACLE_HOME/inventory/oneoffs/5648872/etc/config/actions
PatchObject::PatchObject now looks for the inventory file $ORACLE_HOME/inventory/oneoffs/5648872/etc/config/inventory
Loading the information from inventory/filemap.


Inventory load failed... OPatch cannot load inventory for the given Oracle Home.

Locker::release()
OUISessionManager::unRegister()
Un-Registering the caller : OPatch
LsInventory::getInstance() returns
LsInventorySession failed: Unable to create patchObject
Cleaning up the directory : "$ORACLE_HOME/.patch_storage/patch_unzip"...

OPatch failed with error code 73

From the above output, it was clear that opatch was unable to find patch 5648872 in $ORACLE_HOME/inventory/oneoffs directory. So I compared the contents of $ORACLE_HOME/inventory/ContentsXML/comps.xml file in this instance and production:

In this instance:
$ cd $ORACLE_HOME/inventory/ContentsXML
$ grep 5648872 *
$ grep 5648872 comps.xml

5648872

In Production:
$ cd $ORACLE_HOME/inventory/ContentsXML
$ grep 5648872 *
comps.xml: 5648872

The lines



were extra in this instance.

Instead of manually editing the lines, I ftped the $ORACLE_HOME/inventory/ContentsXML/comps.xml file from Production and globally replaced the instance name in the file. Replacing the comps.xml file with this changed file from Production, resolved the issue.

We got this issue again after two months in a different instance. We checked metalink note 793600.1 which references Bug 7624037 A ROLLING PATCH UPGRADE ON TOP OF 10.2.0.4 CORRUPTS INVENTORY ON REMOTE NODES.

Even though our instance is not a RAC instance, we followed the advice and copied the $ORACLE_HOME/inventory/oneoffs directory from Production instance along with $ORACLE_HOME/inventory/ContentsXML/comps.xml file.

In comps.xml, we did a global replace of ORACLE_HOME path to point to development path instead of production path.

After this opatch succeeded.

Hope they fix the bug soon. Currently the patch suggested for the bug 7364519 (86 MB size) is password protected which means Oracle hasn't regression tested it yet.

Will update this post as I learn more.

Applications File Server could not Create a Temporary File

During migration to shared APPL_TOP, we changed the APPLTMP and APPLPTMP and mount point to a dedicated mount for temporary files. The DBAs not wanting to run autoconfig, just changed the environment variable and bounced the services. While viewing the log or output file of any concurrent request this error occurred:

“The Applications File Server could not create a temporary file.”

Metalink Note 433104.1 describes this issue:

Cause

Incorrect setup of the apps.conf configuration file

As per the customer's last update, "we found there were some source instance entries in the $IAS_ORACLE_HOME/Apache/Apache/conf/apps.conf with some customization for temp files."

As per Note 276695.1, "FNDWRR does use APPLTMP as its temp directory, but remember FNDWRR is a CGI program so you must set APPLTMP in your WEBSERVER environment."
Solution

To implement the solution, please execute the following steps:

1. Ensure the “apps.conf” file is configured correctly, particularly temporary directory paths like "SetEnv APPLTMP"

2. Relink Applications programs and Generate product JAR files via adadmin.

There was no need to relink programs or generate JAR files. We just changed the SetEnv APPLTMP line to point to the correct directory. This resolved the issue.

FRM-92500 Failed to connect to the server

After migrating to shared appl_top on new servers, we got the following error while accessing forms:

ERROR
FRM-92500 Failed to connect to the server: myhost.oracle.com:9000

Details:
Java Exception:
Java.security.accessControlException: access denied (java.net.socketPermission myhost.oracle.com resolve)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkConnect(Unknown Source)
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getByName(Unknown Source)
at java.net.InetSocketAddress.(Unknown Source)

Metalink Note 753152.1, describes this problem.

We had already run Regenerate jar files, so we ran Regenerate jar files with force option this time.

The problem was resolved after the jar files were regenerated with force option.