|
APPLIES TO:
Oracle Inventory Management - Version 12.1.3
and later
Oracle Purchasing - Version 12.1.3 and later Oracle iProcurement - Version 12.1.3 and later Information in this document applies to any platform. Executable:POXCON - PO Document Approval Manager Program Executable:RCVOLTM - Receiving Transaction Manager Executable:INCTM - Inventory Remote Procedure Manager
After upgrading to
12.1.3 the PO Document Approval Manager dies immediately after starting it
up. The same behavior is observed with the Receiving Transaction
Manager.
In the Administer Concurrent Manager form, the following is shown:
The following sql can be used to check the managers:
Select CONCURRENT_QUEUE_ID, USER_CONCURRENT_QUEUE_NAME, DESCRIPTION, CONCURRENT_QUEUE_NAME, ENABLED_FLAG, RUNNING_PROCESSES, TARGET_PROCESSES
from FND_CONCURRENT_QUEUES_VL where CONCURRENT_QUEUE_NAME in ('INVMGR','PODAMGR','RCVOLTM'); The issue can be reproduced at will with the following steps: 1. Using a System Administrator responsibility navigate to Concurrent > Manager > Administer. 2. Query up the PO Document Approval Manager and activate it. 3. The PO Document Approval Manager dies immediately.
IMPORTANT NOTE: The issue can also occur where only one of the
transaction managers above (for example only Receiving Transaction Manager)
does not start. It is also possible to see the transaction manager
status field with value 'System Hold Fix Manager before resetting
counters'
NOTE: This can address issue where receiving related
transactions in rcv_transaction_interface become stuck in ONLINE PENDING
status
The following
additional symptoms may be encountered:
The following error may be encountered:
Routine AFPEIM encountered an error while starting concurrent
manager RCVOLTM.
The manager is not able to start properly. The manager has been put on a SYSTEM HOLD to allow the system administrator to address the issue. When addressed, the "Fixed" button on the Administer Managers screen can be pressed to restart the manager.
iProcurement may display an error like the following:
'The transaction could not be completed successfully. Please contact the system administrator for assistance.' This can occur in iProcurement after patching, and after the executables are compiled and the receiving transaction manager is restarted.
In the Inventory application the Inventory transaction
worker is erring for Internal Orders. There is no information in the log file
and the output is blank.
Error messages at mtl_transaction_interface is showing: Error code : Transaction processor error Error explanation: o concurrent manager is defined to process this request, so it cannot be processed. Contact your system administrator to define a concurrent manager to process this request or to verify that exist when the issue above happens, the receiving transaction manager shows: Actual 0 Target - a given number, for example 20 or 30 Running null
The Oracle Application Manager (OAM) may show
an error like the following:
Manager Name
Program RCVTPO User <USERNAME> Action 1|Unable to remove timed-out m Message ORA-25263: no message in queue APPLSYS.FND_CP_TM_AQ with message ID FBB4C77B44736383E04347001CAC78D3 ORA-25228: timeout or end-of-fetch during message dequeue from APPLSYS.FND_CP_TM_RET_AQ Function fnd_trn_queue.send_message Elapsed Time(1/100sec) 0
Manager log may show:
+---------------------------------------------------------------------------+ Application Object Library: Concurrent Processing version 11.5 Copyright (c) 1979, 1999, Oracle Corporation. All rights reserved. Server concurrent manager started (NODE=<NODE_ID>) : 13-MAY-2015 11:39:27 +---------------------------------------------------------------------------+ ... 13-MAY-2015 11:40:28 : Transaction Manager has shutdown.
In afptm.lc,
monitor_self_exit, a cursor "cursor" is defined static. In
R12.main, execution silently fails.
To implement the
solution, please execute the following steps:
1. Download and review
the readme and prerequisites for Patch
19402657:R12.FND.B "THE
INVENTORY REMOTE PROCEDURE MANAGER WON'T START".
2. Ensure that you have taken a backup of your system before applying the recommended patch. 3. Apply the patch in a test environment where the issue occurs. 4. Confirm the following file version: afptm.lc 120.6.12010000.5 You can use a Unix command like the following:
strings $FND_TOP/bin/FNDTMTST | grep afptm.lc | grep Header
OR adident Header $FND_TOP/lib/afptm.* or Run Diagnostics: Apps Check report for Application = Application Object Library
5. After the patch run
adrelink:
cd $PO_TOP/bin
adrelink.sh force=y ranlib=y "PO RCVOLTM" adrelink.sh force=y ranlib=y "PO POXCON"
6. Bounce the
concurrent managers to instantiate the newly patched code.
7. Retest the issue. 8. Migrate the solution as appropriate to other environments.
Also the following query can be used to determine the file
version:
select af.filename , afv.version_segment1
||'.'||afv.version_segment2 ||'.'||max(to_number(substr(afv.version, decode(instr(afv.version, '.', 1, 2), 0, null, instr(afv.version, '.', 1, 2) + 1) , instr(afv.version, '.', 1, 3) - 1 - instr(afv.version, '.', 1, 2)))) ||'.'||max(to_number(substr(afv.version, decode(instr(afv.version, '.', 1, 3), 0, null, instr(afv.version, '.', 1, 3) + 1)))) version from ad_files af, ad_file_versions afv where af.file_id = afv.file_id and (afv.version_segment1+afv.version_segment2/power(10,length(afv.version_segment2))) = (select max(afv1.version_segment1+afv1.version_segment2/power(10,length(afv1.version_segment2))) from ad_files af1, ad_file_versions afv1 where af1.app_short_name = af.app_short_name and af1.subdir = af.subdir and af1.filename = af.filename and af1.file_id = afv1.file_id) and af.filename in ('afptm.o') group by af.filename, afv.version_segment1, afv.version_segment2; |
||||||||||||
|
|
Wednesday 19 June 2019
Upgrade 12.1.3: PO Document Approval Manager (POXCON), Receiving Transaction Manager (RCVOLTM) and INV Remote Procedure Manager (INCTM) Do Not Start / Die After Restart (Doc ID 1413393.1)
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment