R3483 Ends in error (MRP)

srijde

Active Member
All,

We are running Multiple Branch/Plant version of the MRP (R3483). The Planning months is currently set at 10. For the past 4 days it does not complete and ends in error.

Anyone out there experienced this issue?

It is a production critical issue and trying to resolve it ASAP. Any input or suggestions please?

By the way, the infrastructure team have looked at the servers and Database. No strange usage of memory, Database or the CPU.


B7.3.3.3 / Update 6, Service Pack 23. The Back end is Unix, and the DB is Oracle. Oracle version is 9.2.0.8.


Thanks in Advance
Sriram Visvanathan.
 
Re: RE: R3483 Ends in error (MRP)

Hi,
All I know is that the MRP needs to be run for Multiple Brach/plants together because of the integration between those Branch/Plants. And a similar issue arose before and the planning months have been reduced from 24 to 13 months and now we are reducing it to 6 today to see a successful run.

Don't know about the demand outside the shop calendar??

Please explain...

I am a Technical Analyst...

Thanks for your response,

Sriram Visvanathan.
 
RE: RE: R3483 Ends in error (MRP)

If you have any order that has a requested date outside the last entry in
the calendar then it will fail. If the last date of the calendar is 12/31/07
and you have a customer order with a date requested of 2/28/08, then the
system gets confused.
 
Re: RE: RE: R3483 Ends in error (MRP)

tmackin,

Are you saying that the UBE will end with a status of 'E' when the shop floor calendar is not setup?

OR The UBE Completes with a status 'D' and the .pdf will list the error message?

Please confirm.

We are getting an 'E' status for the UBE and no .pdf is genereated. But by reducing the planning horizon the UBE completes fine.

Thanks,
Sriram.v.
 
Re: RE: R3483 Ends in error (MRP)

Have you been purging the data? If I recall a similar issue - when the list
gets too big, the function(s) crash out/time out and give exceptions.

How big is your F3411, F3412 and F3413 (especially - not the F3412). If the
F3412 is too big - your functions will die (at least in 8.12)

(db)




--
 
Re: RE: R3483 Ends in error (MRP)

Daniel,

The Next step that we are considering is to go for a purge and archiving solution.

Here are the counts :
F3411 -- 218475
F3412 -- 665413
F3413 -- 1161972

Thanks
Sriram.
 
Re: RE: R3483 Ends in error (MRP)

Out of curiosity - if you did an SQL Group By with count on Business Unit /
Item - what are your counts withyin the F3412? We had items with 250K
counts... basically items that were in quantities of 500-ish... that when
the ube was run it cleared the file and regenerated - with very eroneous
numbers.

might look at the mcu/itm group by counts and see if something pops out at
you.

(db)




--
 
Re: RE: R3483 Ends in error (MRP)

Daniel,

Here are the Counts in F3412 by Branch/Plant

Thanks
Sriram.V.
 

Attachments

  • 125394-F3412 Counts by MCU.xls
    156 bytes · Views: 87
Re: RE: R3483 Ends in error (MRP)

Not knowing if those are normal counts - but when our items per business
unit reached/exceeded 250K (like one of yours)... we died!

What I was really looking for was:
Branch/Plant, Item #, Count of items per B/P..

When that count was over 250K - our functions on Solaris 'excepted' and
died. I do not know the magic number.... but, when the issue was resolved
our total file count for the F3412 went from 4.7M (million) to 75K total
records...

I'll see if I can find the specifics for our issue.

(db)




--
 
Re: RE: R3483 Ends in error (MRP)

Daniel,

How did you resolve the issue though?

Thanks,
Sriram.V
 
RE: RE: RE: R3483 Ends in error (MRP)

If my memory serves me correctly, the UBE ended in "E" status. All I did to
confirm the problem was to see how far out the calendar went and the started
inquiring on F4211, F4311 for DRQJ greater than the last date in the
calendar. We have now put in place a process to update the calendar each
December by one year for each BP, giving us a horizon of 2 1/2 years at all
times.
 
Re: RE: R3483 Ends in error (MRP)

Daniel,

How did you resolve the issue?
Can you please provide me with the specifics of the issue and resolution?

Thanks
Sriram.V.
 
Re: RE: R3483 Ends in error (MRP)

Ok - I'm a dysfunctional person... maybe you can better understand the
'functional' aspect of this quote;
"
The cause of this was finally traced to data contained in the current Xe
Production environment and converted up to the IN Test Environment. The
specific data was contained in the F4102 file and specific to the Quantities
section of this table.

Item 51681 in branch 1001 had a Safety Stock Value of 500,000. In addition
the same item in 1001 had a multiple order quantity value of 2. There were
also other "Quantity" values for this item which were to say the least
"questionable".

When we ran the DRP (Robot Version) program which clears all of the planning
tables (F3411, F3412 and F3413) and recalculates Single level DRP and MPS
for some specific plants, the tables cleared and the same 7.5M records were
regenerated.

"

I'm not completely sure which data items were actually changed - but I do
know that after the data was changed, the total table count (when same
version of R3483 was run) went from 4.7M to 75K records... The users got a
HUGE performance boost, the screens and applications did not 'except' and
life is much better!

(db)



--
 
Re: RE: R3483 Ends in error (MRP)

Daniel,

Thank you for providing the specifics of the issue.

I have looked at the Safety stock level in our Branch/Plant File. We have about 51 Items that are having Safety stock between 60000 and 300000.

I have instructed my functional lead to take a look at this and advice.

Anyone else with other suggestions as to why this will be failing??

We have been in touch with Oracle Support to help figure out the issue. Currently running the UBE with debug logging to send to Oracle.

Thanks
Sriram .V.
 
Re: RE: R3483 Ends in error (MRP)

All,

Thanks to all replies.

We have called the Oracle Support to help finding the cause of the R3483 Abend error.
We have done all the requested items from Oracle to find the root cause of the issue. In doing that after 2 weeks of running the MRP with a Lower Horizon (From 13 Months to 6 Months) when we got the similar environment setup and the data was copied from production.
We ran the MRP with the 13 Months Horizon and it ran OK without errors instead of ending in error. Which points us to having some data issues before.

Now we have changed the Production MRP Run also to the previous horizon of 13 months and it is running OK.

But yet still don't know what was the root cause for MRP to fail before?? Any suggestions.

Oracle support is directing this to not being up to date with the SAR's relating to MRP.

Now we are restoring the production data as of the date it failed and will be running it to see whether it fails.

If anyone out their has knowledge on the data issues with MRP please let me know.

Thanks in advance
Sriram Visvanathan
OneWorld XE SP23 Update 6 L1, Oracle Database, Unix Server.
 
Back
Top