[Preliminary Note: Please do not try it on PRODUCTION Instance until you have applied it on TEST]
During working on 12.0.6 running on Linux environment I received a complain from the user that:
“Their XML reports (.rtf) are taking too much time in running and ending in Warning status”.
Following is the message I saw in all the XML requests’ log files:
“Beginning post-processing of request 334042 on node ****** at 09-JUL-2009 13:
11:26. Post-processing of request 334042 failed at 09-JUL-2009 13:47:26 with
the error message: The Output Post-processor is running but has not picked up
this request. No further attempts will be made to post-process this request,
and the request will be marked with Warning status. Setting the profile option
Concurrent: OPP Response Timeout to a higher value may be necessary “
And following is the message I found in the OPP Manager Log Files:
“…7/8/09 6:27:40 PM] [EXCEPTION] [OPPAQMON:33664] ORA-01089: immediate shutdown in progress – no operations are permitted
[7/8/09 6:27:40 PM] [UNEXPECTED] [GSMServiceController:33664] oracle.apps.fnd.cp.gsm
.GenCartSetStatusException: ORA-01089: immediate shutdown in progress – no opera
tions are permitted …“
Following are the two Steps I did perform:
I set the following profile options to the value 300000:
1. Concurrent: OPP Response Timeout
2. Concurrent: OPP Process Timeout
By the way there is a metalink note 352518.1, which gives you the formula of setting the values for these profile options. I did as per the support I got.
Shutdown the concurrent manager with the command:
adcmctl.sh stop apps_username/apps_pwd wait=Y
Ensure that no FNDLIBR processes are running. For this confirmation use the following command:
ps –fu appl11i | grep FNDLIBR.
[where “appl11i” is the owner of the oracle applications file system at OS level]
You will get a single line message like as below if no FNDLIBR service is running:
appl11i 18195 8173 0 13:48 pts/3 00:00:00 grep FNDLIBR.
Take the backup of the application tables “FND_CONCURRENT_REQUEST” and “FND_CONCURRENT_QEUES”
Run the non-destructive script cmclean.sql.
Restart Concurrent manager with command:
adcmctl.sh start apps_user/apps_pwd
Retest the Issue.
[NOTE: If the issue resolves, make the following changes:
In the application context_file in the parameter s_concctrl_params change the value wait=N(i.e default) to wait=Y.Run autoconfig.Shutdown the whole application and observe that the shutdown script hangs on the point where it runs the script adcmctl.sh to stop the CCM services.Restart the applications.
If the change1 doesn’t takes affect then do this:In the script adcmctl.sh script make this changing [CONTEXT_PARAMS=”diag=N wait=N” ] to [CONTEXT_PARAMS=”diag=N wait=Y”].Run autoconfig.Shutdown the whole application and observe that the shutdown script hangs on the point where it runs the script adcmctl.sh to stop the CCM services.Restart the applications.]