addbctl.sh: exiting with status 127

Solution steps:

1.Check Base_dir Permission.
2. Disable SELinux.

The sestatus command returns the SELinux status and the SELinux policy being used:

root$ sestatus

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted 

On systems with SELinux disabled, the SELINUX=disabled option is configured in 

root$ vi /etc/selinux/config

edit this file

  SELINUX=disabled

save it. 

# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=disabled # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection.

SELINUXTYPE=targeted

Also, the getenforce command returns Disabled:

root$ getenforce 

 Disabled

Bigfile Tablespaces

Bigfile Table-spaces

A bigfile table-space is a table-space with a single, but very large (up to 4G blocks) data-file. Traditional smallfile tablespaces, in contrast, can contain multiple data-files, but the files cannot be as large. The benefits of bigfile tablespaces are the following:

• A bigfile tablespace with 8K blocks can contain a 32 terabyte datafile. A bigfile tablespace with 32K blocks can contain a 128 terabyte datafile. The maximum number of datafiles in an Oracle Database is limited (usually to 64K files). Therefore, bigfile tablespaces can significantly enhance the storage capacity of an Oracle Database.
• Bigfile tablespaces can reduce the number of datafiles needed for a database. An additional benefit is that the DB_FILES initialization parameter and MAXDATAFILES parameter of the CREATE DATABASE and CREATE CONTROLFILE statements can be adjusted to reduce the amount of SGA space required for datafile information and the size of the control file.
• Bigfile tablespaces simplify database management by providing datafile transparency. SQL syntax for the ALTER TABLESPACE statement lets you perform operations on tablespaces, rather than the underlying individual datafiles.

Bigfile tablespaces are supported only for locally managed tablespaces with automatic segment-space management, with three exceptions: locally managed undo tablespaces, temporary tablespaces, and the SYSTEM tablespace can be bigfile tablespaces even if their segments are manually managed.

Notes:

• Bigfile tablespaces are intended to be used with Automatic Storage Management (ASM) or other logical volume managers that supports striping or RAID, and dynamically extensible logical volumes.
• Avoid creating bigfile tablespaces on a system that does not support striping because of negative implications for parallel query execution and RMAN backup parallelization.
• Using bigfile tablespaces on platforms that do not support large file sizes is not recommended and can limit tablespace capacity. Refer to your operating system specific documentation for information about maximum supported file sizes.
  
  

  Creating a Bigfile Tablespace

  To create a bigfile tablespace, specify the BIGFILE keyword of the CREATE TABLESPACE statement (CREATE BIGFILE TABLESPACE ...). Oracle Database automatically creates a locally managed tablespace with automatic segment-spec management. You can, but need not, specify EXTENT MANAGEMENT LOCAL and SEGMENT SPACE MANAGEMENT AUTO in this statement. However, the database returns an error if you specify EXTENT MANAGEMENT DICTIONARY or SEGMENT SPACE MANAGEMENT MANUAL. The remaining syntax of the statement is the same as for the CREATE TABLESPACE statement, but you can only specify one datafile. For example:
  

  CREATE BIGFILE TABLESPACE bigtbs 
      DATAFILE '/u02/oracle/data/bigtbs01.dbf' SIZE 50G
  ...
  
  

  You can specify SIZE in kilobytes (K), megabytes (M), gigabytes (G), or terabytes (T).
  If the default tablespace type was set to BIGFILE at database creation, you need not specify the keyword BIGFILE in the CREATE TABLESPACE statement. A bigfile tablespace is created by default.
  If the default tablespace type was set to BIGFILE at database creation, but you want to create a traditional (smallfile) tablespace, then specify a CREATE SMALLFILE TABLESPACE statement to override the default tablespace type for the tablespace that you are creating.
  
  

  Altering a Bigfile Tablespace

  Two clauses of the ALTER TABLESPACE statement support datafile transparency when you are using bigfile tablespaces:
  
• RESIZE: The RESIZE clause lets you resize the single datafile in a bigfile tablespace to an absolute size, without referring to the datafile. For example:
  

  ALTER TABLESPACE bigtbs RESIZE 80G;
  
  

• AUTOEXTEND (used outside of the ADD DATAFILE clause):
  With a bigfile tablespace, you can use the AUTOEXTEND clause outside of the ADD DATAFILE clause. For example:
  

  ALTER TABLESPACE bigtbs AUTOEXTEND ON NEXT 20G;
  
  

An error is raised if you specify an ADD DATAFILE clause for a bigfile tablespace.

Identifying a Bigfile Tablespace

The following views contain a BIGFILE column that identifies a tablespace as a bigfile tablespace:

• DBA_TABLESPACES
• USER_TABLESPACES
• V$TABLESPACE

You can also identify a bigfile tablespace by the relative file number of its single datafile. That number is 1024 on most platforms, but 4096 on OS/390.

APP-FND-01238: Cannot Set Value For Field

Applies to:

Oracle General Ledger - Version 11.5.10.0 to 11.5.10.0 [Release 11.5.10]
Information in this document applies to any platform.

Symptoms

On : 11.5.10 version:

You are trying to add new rule in  'Cross Validation Rules' form , this following error occur

ERROR
-----------------------
APP-fnd-01238: Cannot set value for field RULE_LIST.CREATED_BY
APP-fnd-01238: Cannot set value for field RULE_LIST.CREATED_DATE
APP-fnd-01238: Cannot set value for field RULE_LIST.LAST_UPDATE_DATE

STEPS
-----------------------
The issue can be reproduced at will with the following steps:
1. Added a new Rule or updated an existing rule.

Cause

Bug 5936906 (91) ORA-1400 CANNOT INSERT NULL INTO FND_FLEX_VALUE_RULE_LINES.LAST_UPDATE_DATE:

The application of forms patchset 18 (version 6.0.8.27.0) has caused an issue with the call to FND_STANDARD.SET_WHO from Pre-Insert trigger(at block level).

Current Form
----------------------------------------
Form Application : Application Object Library
Form Name : FNDFFMCV
Form Version : 11.5.11
Form Last Modified : $Date: 2002/02/08 17:11 $

Solution

To implement the solution, please execute the following steps:

1. Please download and review the readme and pre-requisites for Patch 5216496 .
2. Please apply Patch 5216496 in a test environment.
3. Please test and verify the problem.
4. If the issue is resolved, please migrate the solution as appropriate to other environments.
or
5. Temporary workaround is to commit on each line as it is entered/updated in Cross Validation Rules.

Application blocked by java security

Application blocked by java security in oracle apps

CAUSE


Java has further enhanced security to make the user system less vulnerable to external exploits. Starting with Java 7 Update 51, Java does not allow users to run applications that are not signed (unsigned), self-signed (not signed by trusted authority) or that are missing permission attributes.

Risks involved in running applications

• Unsigned application
  An application without a certificate (i.e. unsigned apps), or missing application Name and Publisher information are blocked by default. Running this kind of application is potentially unsafe and present higher level of risk.
• Self-signed application (Certificate not from trusted authority)
  An application with self-signed certificate is blocked by default. Applications of this type present the highest level of risk because publisher is not identified and the application may be granted access to personal data on your computer.
• Jar file missing Permission Attribute
  Permissions Attribute verifies that the application requests the permission level that developer specified. If this attribute is not present, it might be possible for an attacker to exploit a user by re-deploying an application that is signed with original certificate and running the application at a different privilege level.

---

SOLUTION

The application that you are running is blocked because the application does not comply with security guidelines implemented in Java 7 Update 51.
Contact the developer or publisher of this application and let them know about the application being blocked. You can refer them to these links that provide information about implementing secure practices in the code for the application.

---

WORKAROUND


It is highly recommended not to run these types of applications. However if you still want to run these apps, run only if you understand the risks and implications.
As a workaround, you can use the Exception Site list feature to run the applications blocked by security settings. Adding the URL of the blocked application to the Exception Site list allows it to run with some warnings.

Steps to Add URLs to the Exception Site list

• Go to the Java Control Panel (On Windows Click Start and then Configure Java)
• Click on the Security tab
• Click on the Edit Site List button
• Click Add in the Exception Site List window
  
  
• Click in the empty field under the Location field to enter the URL
  
  Example: http://www.example.com
  (URL should begin with http:// or https://)
  
  If the URL where the applet is hosted is different from the URL of the web page from which the applet is launched, then you will need to add both the URL for the applet as well as the URL for the web page.
  
  Example with different URLs for the applet and the web page
    you would enter both URLs (The urls listed can be different depending on which host is serving the ERP Apps)
  
  1. http://192.32.33.20:8004
     This is the url for the EBS Apps
  2. http://sujeet.oracle.com:8004
  
  
• Click OK to save the URL that you entered
• Click Continue on the Security Warning dialog

Debug in Oracle appsR12

You can configure whether end users can run the application in debug mode by using the Debugging attribute on the Edit Application Definition page. A developer who is logged into the application's workspace can always run the application in debug mode.

To enable or disable debugging:

1. On the Workspace home page, click the Application Builder icon.
2. Select an application.
3. Click the Edit Application Properties button to the right of the application name.
   The Edit Application page appears.
4. Scroll down to Properties.
5. For Debugging:
   • Yes. Enables the application debug mode using the browser at run time.
   • No. Disables the application debug mode using the browser at run time.
     
     
     
     
     VIEW DEBUG Reports
     
     
   • On the Workspace home page, click the Application Builder icon.
   • Select the desired application.
     You can view debug reports when the application is running or in development mode.
   • To view a debug reports in development mode:
     • Click the Find icon and then the Debug tab. 
     • On the Application home page, click Utilities, and then Debug Messages.
   • To view debug reports when the application is running, click View Debug on the Developer Toolbar.
     A list of Debug reports displays.
   • Click the View Identifier to the left of the session you want to view.
     The following illustration shows debug reports viewed in the Item Finder.
     
     
     
      
   • Description of the illustration debug_report.gif
     
   • To view steps that took the longest, hover over that step on the graph above the report.
     The step details display.
   • To go to that step in the report, click the bar.
     Note:

     Debug sessions listed in the report live for at least 2 weeks and age out along with the activity log. This is usually more than adequate for debugging purposes.

A fatal error related to codelines or codelevels has occurred

AutoPatch error:
--------
This patch is not compatible with your current codelines.

This patch is compatible with: entity 'pjt' - codeline 'R12.PJT.A'.
Your current on-site codeline for the entity 'pjt' is: 'R12.PJT.B'.

You should not apply this patch.
Apply an equivalent patch that is compatible with your
current codelines instead.
--------
AutoPatch error:
--------
A fatal error related to codelines or codelevels has occurred.

Solution:-

SQL script to check product patchlevel or codelevel

SELECT app_short_name, MAX(patch_level)
FROM apps.ad_patch_driver_minipks
GROUP BY app_short_name ;

APP_SHORT_NAME
--------------------------------------------------
MAX(PATCH_LEVEL)
------------------------------
PSP
R12.PSP.B.3

AS
R12.AS.B.3

FTE
R12.FTE.B


APP_SHORT_NAME
--------------------------------------------------
MAX(PATCH_LEVEL)
------------------------------
AK
R12.AK.B.3

CHV
R12.CHV.B.3

IEC
R12.IEC.B.3

how to find applied patches in r12

There are some tables in oracle apps (AD tables especially) involved when applying patches.
Some of them are very useful when we need specific information about patch already applied.
 

Adpatch Base Table:-

AD_APPLIED_PATCHES – The main table when we are talking about patches that applied in Oracle Apps.
This table holds information about the "distinct" Oracle Applications patches that have been applied.
If 2 patches happen to have the same name but are different in content (e.g. "merged" patches), then they are considered distinct and this table will therefore hold 2 records (eTRM).
I also found that if the applications tier node is separate from the concurrent manager node, and the patch applied on both nodes, this table will hold 2 records, one for each node.

AD_PATCH_DRIVERS – This table holds information about all patch drivers included in specific patch.
For example if patch contain only one unified driver like u[patch_name].drv then ad_patch_drivers will hold 1 record.
On the other hand, if patch contain more than 1 driver, for example d[patch_name].drv and c[patch_name].drv, this table will hold 2 records.

AD_PATCH_RUNS – holds information about each execution of adpatch for a specific patch driver.
In case a patch contains more than one driver, this table will hold a record for each driver.
This table also holds one record for each node the patch driver has been applied on (column APPL_TOP_ID).

AD_PATCH_RUN_BUGS – holds information about all the bugs fixed as a part of specific run of adpatch.

AD_BUGS – this table holds information about all bug fixes that have been applied.

 Two Way to view applied patch information in Oracle EBS R12:-

1) OAM – Oracle Applications Manager
2) SQL queries


With OAM it’s easy and very intuitive, from OAM site map -> “Maintenance” tab -> “Applied Patches” under Patching and Utilities.

Search by Patch ID will get all information about this patch; In addition, drill down by clicking on details will show the driver details.


For each driver we can use the buttons (Timing Details, Files Copied, etc.) to get more detailed information.

With SQL we can retrieve all the above information, sometimes more easily.

For example: How to know which modules affected by specific patch?

With OAM:
1) search patch by Patch ID
2) click on Details
3) For each driver click on “Bug Fixes” and look on product column.

With SQL:
Run the following query, it will show you all modules affected by specific patch in one click…

select distinct aprb.application_short_name as "Affected Modules"
from ad_applied_patches aap,
ad_patch_drivers apd,
ad_patch_runs apr,
ad_patch_run_bugs aprb
where aap.applied_patch_id = apd.applied_patch_id
and apd.patch_driver_id = apr.patch_driver_id
and apr.patch_run_id = aprb.patch_run_id
and aprb.applied_flag = 'Y'
and aap.patch_name = '&PatchName';
Another SQL will retrieve basic information regarding patch applied, useful when you need to know when and where (node) you applied specific patch:

select aap.patch_name, aat.name, apr.end_date
from ad_applied_patches aap,
ad_patch_drivers apd,
ad_patch_runs apr,
ad_appl_tops aat
where aap.applied_patch_id = apd.applied_patch_id
and apd.patch_driver_id = apr.patch_driver_id
and aat.appl_top_id = apr.appl_top_id
and aap.patch_name = '&PatchName';
To check if specific bug fix is applied, you need to query the AD_BUGS table only.
This table contains all patches and all superseded patches ever applied:

select ab.bug_number, ab.creation_date
from ad_bugs ab
where ab.bug_number = '&BugNumber';