[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:
Step 1:
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.
Step 2:
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:
Change1:
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.
Change2(conditional):
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.]
Comments are closed.