Topic
  • 2 replies
  • Latest Post - ‏2013-08-24T20:01:58Z by A. Baghdadi
A. Baghdadi
A. Baghdadi
2 Posts

Pinned topic Reorder Process Automation Error

‏2013-08-21T15:42:41Z |

Hello !

 

I am facing a quite disturbing issue regarding the automation of the reorder of a storeroom item in the Inventory application .

The scenario goes like this :

I wanted to automate the reorder process of a storeroom item . Hence , I opened the inventory application , went to the desired item record and checked the "Reorder" option under the "Reorder Details" Tab .

 

( Check Attachments for details )

 

Then , I configured the CronTask named "ReorderCronTask" so it can reorder my item that has the "Reorder" option enabled .

It is configured and active to run every 1 minute ( For Test Purposes Only )

The CronTask instance has the following parameters & Values :

 

directissue : ( Empty )

directissue :  ( Empty )

ignorereorderpoint : 0

leadtime : 0

logfile : c:\New Folder\reorderlog.txt

storeroom : CG-SUEZ,MYROOM;

useagreement : 0

 

The issue I am facing is that the order log always shows the following message : 

 
Reorder cron task Wed Aug 21 18:28:09 AST 2013
Reorder cron task processes storeroom MYROOM in site CG-SUEZ.
BMXAA3482E - Another reorder process is running for the same storeroom you are trying to order by someone signed in as you.

 

I have tried many many things to solve this issue , including :

Changing the value of the system property "mxe.reorder.previewtimeout" : I tried 0 , 1 and 2 as values

cancelled all POs and all PRs that are already available in the POs and PRs application

Cleared all data from "ReorderPad" and "ReorderMutex" tables

Clears the locks on via Select Action => Reorder => Clear Reorder Locks in Inventory application in the record of the item I was testing

Stopped / Started CronTask many times

Reloaded CronTask instances several times

Restarted the computer itself

Restarted the application server

Changed the "Run As' field of the CronTask , so it can run as a different user than the one already logged

 

I even tried to clear the text from the log file itself and to add / remove more storerooms to the CronTask instance to process . Nothing really worked !!

 

The weird thing is this used to work , but now : It doesn't !

 

I have attached the pictures of the item I was working on for further details .

 

Here are the details of  my installed system

 

App Server : IBM WebSphere Application Server 7.0.0.15 
 
Version : IBM Maximo Asset Management 7.5.0.4 Build 20130129-2023 DB Build V7504-00
IBM Maximo for Service Provider 7.5.1.0 Build 20111024-1425 DB Build V7510-06
Tivoli's process automation engine 7.5.0.4 Build 20130129-2023 DB Build V7504-38
IBM Maximo Asset Management Scheduler 7.5.1.0 Build 20130129-2023 DB Build V7510-124 
 
Server OS : Windows Server 2008 6.0 build 6002 Service Pack 2 
 
Server DB : DB2/NT 9.7 (SQL09074) 
 

Platform Details :

Windows Server 2008 Standard SP2 ( x32 )

 

Really appreciate the support in advance 

 

Best Regards

Baghdadi

Attachments

Updated on 2013-08-21T15:54:47Z at 2013-08-21T15:54:47Z by A. Baghdadi
  • swkim90049
    swkim90049
    291 Posts

    Re: Reorder Process Automation Error

    ‏2013-08-22T17:34:39Z  

    Who is the corn task running as? Can you change that user name? Or try logging in as a different user into Maximo so the corn task user and your logged in user is different?

    Updated on 2013-08-22T17:35:23Z at 2013-08-22T17:35:23Z by swkim90049
  • A. Baghdadi
    A. Baghdadi
    2 Posts

    Re: Reorder Process Automation Error

    ‏2013-08-24T20:01:58Z  

    Who is the corn task running as? Can you change that user name? Or try logging in as a different user into Maximo so the corn task user and your logged in user is different?

    Hey SWKIM 

     

    I have already contacted IBM personally and they told me that this is a bug .. here is their response as it came ( Quote )

     

    " I have received your PMR regarding cron task reordering issue.

    This issue has been identified as a bug in APAR IV46100 and the issue can be replicated in Maximo 7.5.0.4 with DB2 database. I will monitor this APAR status from now on, once the fix is out then I will inform you accordingly. "

     

    So ... that figures !

    Guess we'll just have to wait for the next fix pack/patch :'(

     

    Thanks a million , though !

     

    Cheers

    Baghdadi