How to Find Out Scheduled Concurrent Requests in Oracle Applications 11i

Through this query you will find all the scheduled concurrent program that are running on Oracle Apps.
---------------------------------------------------------------------------------
SELECT cr.request_id,
DECODE (cp.user_concurrent_program_name,
'Report Set', 'Report Set:' cr.description,
cp.user_concurrent_program_name
) NAME,
argument_text, cr.resubmit_interval,
NVL2 (cr.resubmit_interval,
'PERIODICALLY',
NVL2 (cr.release_class_id, 'ON SPECIFIC DAYS', 'ONCE')
) schedule_type,
DECODE (NVL2 (cr.resubmit_interval,
'PERIODICALLY',
NVL2 (cr.release_class_id, 'ON SPECIFIC DAYS', 'ONCE')
),
'PERIODICALLY', 'EVERY '
cr.resubmit_interval
' '
cr.resubmit_interval_unit_code
' FROM '
cr.resubmit_interval_type_code
' OF PREV RUN',
'ONCE', 'AT :'
TO_CHAR (cr.requested_start_date, 'DD-MON-RR HH24:MI'),
'EVERY: ' fcr.class_info
) schedule,
fu.user_name, requested_start_date
FROM apps.fnd_concurrent_programs_tl cp,
apps.fnd_concurrent_requests cr,
apps.fnd_user fu,
apps.fnd_conc_release_classes fcr
WHERE cp.application_id = cr.program_application_id
AND cp.concurrent_program_id = cr.concurrent_program_id
AND cr.requested_by = fu.user_id
AND cr.phase_code = 'P'
AND cr.requested_start_date > SYSDATE
AND cp.LANGUAGE = 'US'
AND fcr.release_class_id(+) = cr.release_class_id
AND fcr.application_id(+) = cr.release_class_app_id;

Concurrent Programs Fail To Submit The Next Schedule Run Even After Completing Successfully

Currently, we are facing similar problem in Production instance. Oracle has shared a good document with detail explanation.
You can also login into metalink.oracle.com and search for document: 1061218.1
I have copied document detailed from metalink.
Symptoms
Concurrent request will not be re-scheduled. The reason the jobs stop rescheduling themselves is because the schedule is removed from the fnd_conc_release_classes table.
Cause
What happens is this:
1. Purge process is scheduled to purge the request each 7 day (as example)
2. We submit a scheduled requets (X1). (A record is created in table fnd_conc_release_classes with field OWNER_REQ_ID populated with X1)
3. The request X1 is executed a reschedule a new request (X2.) the record in fnd_conc_release_classes get update the field OWNER_REQ_ID as X2.
4. The request X2 is executed, when the system schedule the new request X3 and the request finish in warning with the error message, but at the end of the process the update of table fnd_conc_release_classes fail, then the request X3 is scheduled but the table fnd_conc_release_classes has value X2 in field OWNER_REQ_ID.
The request continue scheduling (X4,X5,Xn) but at the 7 days the FNDCPPUR purge request X2 and the record in table fnd_conc_release_classes. The last scheduled (Xn) request executed has not any error message and we can not get any error, because the requested that origin the issue was purged, we can only check that does not exists a record in table fnd_conc_release_classes with the RELEASE_CLASS_ID that have the record of request Xn in fnd_concurrent_requests.
Solution
This issue is described in Bug 7329963 FAILING CONCURRENT SCHEDULES. This bug is still open and Development works on it.Until now there is no fix for the error handling. The fix is expected for 11.5.10.8RUPBut as a workaround you may find out why a scheduled request fails with warning.If non of the scheduled requests fail, then the re-scheduling will work correctly.

When One Function Attached to Responsibility it doesn't default Organization ID.

Problem: If you start off in the apps using a different responsibility (e.g. AU Master Scheduler)and open any org specific form and then you change responsibilities to the new one (Test Oracle Functionality) which has only one function attached to it, it just assumes the same inventory org assignment that was used in the previous resp (e.g. AU). It is not automatically resetting the inv org to the only valid inv org for the resp Test Oracle Functionality (i.e. MST org).

Technical Issue found: for standard FNDSQF.pll. we have choose_org procedure.Case when start off with diffrent responsibility and navigate to Test Oracle Functionality. Since it has single function attached so it directly open the form.First it check for name_in('PARAMETER.ORG_ID') is not null. If this check it null so it skip. It then look for ('GLOBAL.FND_ORG_ID') is not null. In this case it HOLD the value of previous inv org in my case 'AU'. Then it copy the 'GLOBAL.FND_ORG_ID') to 'PARAMETER.ORG_ID'. Which is wrong.It is not flushing the value when single function is attached to responsibility. but When we add extra function to responsibility "Test Oracle Functionality" it is defaulting the inv org.

Currently, i am working with oracle. Here is the update from oracle.
Tried it in our local instances and able to reproduce the same issue . And based upon the result raising a iBug with our BDE .

I will keep posting the update.

Thanks,
Ajay

XML Publisher - HEADER IS NOT VISIBLE FROM ORACLE APPS

This was very interesting.
Issue: When Uploading the XML file and ran the template then the Header was visible as a output when run through my desktop but while running the template through Apps no header is visible in the output.
STEPS to re-produce:
The issue can be reproduced at will with the following steps:
1. Copy template from backup
2. Open in Word (XML Publisher Desktop).
3. Make a change.
4. Save.
5. Preview output.
6. The header/footers are gone.
BUSINESS IMPACT
The issue has the following business impact:Due to this issue, users cannot make desired changes to Templates.

Solution: for this issue we raise an oracle SR.
Oracle provided a note: 388494.1 Templates in XML Publisher Desktop 5.6.2 Lose Header and Footer Information


TIP:
Click help for a detailed explanation of this page.
Bookmark
Go to End
Subject:
Templates in XML Publisher Desktop 5.6.2 Lose Header and Footer Information

Doc ID:
388494.1
Type:
PROBLEM

Modified Date :
07-NOV-2008
Status:
PUBLISHED
In this Document Symptoms Changes Cause Solution References
Applies to: Oracle XML Publisher - Version: 11.5.10This problem can occur on any platform.
SymptomsUsing XML Publisher Desktop 5.6.2 in Development:Find the tool seems to be loosing data. The Templates being modified have headers andfooters. If an update is made to the document and preview run the headers andfooters no longer appear.EXPECTED BEHAVIORExpect to be able to make modifications to the templates without loosing the Header and footer.STEPSThe issue can be reproduced at will with the following steps:1. Copy template from backup2. Open in Word (XML Publisher Desktop).3. Make a change.4. Save.5. Preview output.6. The header/footers are gone.BUSINESS IMPACTThe issue has the following business impact:Due to this issue, users cannot make desired changes to Templates.
ChangesInstalled Product: Microsoft Office XP Professional - Update 'Security Update for Word 2002 (KB917335)'.
Cause
This security update prevents the generation of XSL-FO from headers and footers, so the resultant output is missing these sections.
1. If you are on a version of XML Publisher lower than 5.6.2, use the following workaround, until you are able to upgrade:
Open the template in Notepad and manually change: \headerr to \header
\footerr to \footer

XML Publisher report and RDF errored out

Problem: XML publisher and RDF report are erroring out.

Solution: This is something problem related with processes. Please contact your DBA Team and check following.
Xvfb and twm processes running on the server were not stable. And were getting killed interminently.
Probably that was causing the error.

Incompatibility not set between concurrent programs in Control Env.

Problem: In development Env, I set the Incompability between concurrent program with itself. but when this changes was move to control env then incompability didn't set.

Solution: In development env when i set the incompability then in background a concurrent pgm "Verify Concurrent Managers" is launched.

Use of FND_REQUEST.SET_MODE inside a DB Trigger

Syntax:
FND_REQUEST.SET_MODE(TRUE);
-------------------------------------------------------------------
Normally when a database session is setup, to submit a concurrent request to run concurrent program 'XXXXXXXXXX'.
Note that normally a COMMIT is required following the FND_REQUEST.SUBMIT_REQUEST, otherwise the request will not actually be submitted, however a COMMIT cannot be issued within a trigger. Because the Mode was set to TRUE (i.e. trigger) earlier in this trigger, a COMMIT is not needed.