Hello,

We've come across a problem in MRP after installing a MPS/ MRP solution. We are now getting a float exception error when running MRP. As shown below.

The problem appears to happen in large item ranges especially through the job daemon but we can get the mrp session to run on smaller ranges on a client.

Anybody come across anything like this before ?

Cheers
Neal

2007-08-06[21:20:44]:E:job004: ******* S T A R T of Error message *******
s/tt/ba/ba/baerrhand.c: #100 keyword: bshell message
2007-08-06[21:20:44]:E:job004: Pid 14455 Uid 0 Euid 0 Gid 1 Egid 1
2007-08-06[21:20:44]:E:job004: user_type S language 2 user_name job004 tty 7 locale ISO88591/NULL
2007-08-06[21:20:44]:E:job004: Errno 0 bdb_errno 0
2007-08-06[21:20:44]:E:job004: Log_mesg: Fatal error: float exception in 'timrp1211s000'
2007-08-06[21:20:44]:E:job004: ******* E N D of Error message *******
2007-08-06[21:20:44]:E:job004:
2007-08-06[21:20:44]:E:job004: ******* S T A R T of Error message *******
2007-08-06[21:20:44]:E:job004: Log message called from /view/port.6.1c.07.04/vobs/tt/ba/ba/baerrhand.c: #100 keyword: bs
hell message

Hello Neal,

I remember having a problem like that while a go. We found out that we had an Item which had a BOM unit equal to zero, this made our MRP run to crash couple of times. We have a little script that checks this on the Item master before running MRP, " if BOM unit equal to zero then update it to one".

Regards,

Carlos Gonzalez

Hello Carlos,
Thanks for the feedback this issue has only just started occuring so we believe it may be related to a set of solutions just recently installed.

When you say BOM unit I presume you mean tiitm001.unom. Is the resolution just to set these values to 1 ?

Cheers Neal

Neal,

Yes, tiitm001.unom is the field and yes, we found that people copies items from one to another Item code and they do not check all fields. This happened after years of running MRP with no problems, it only takes that someone enters a wrong BOM unit. So the script updates field tiitm001.unom from 0 to 1 for MRP Items.

Re the amount of items MRP processes that could generate this error, I do not know how many items you have to process, but we have over 120,000 items with no problems.

Hello Carlos,

This problem is turning into a real nightmare. Support did some initial checks on my item data and it appeared to be ok. However did it via GTM today for all items and running full MRP tonight in debug mode.

Naturally it takes 7 hours to crash making the testing cycle a real nightmare.

Installed sols which we believed caused the problem have been removed but they caused another mrp942 error which when we fixed the float error returned.

Fingers crossed for tonight.

Cheers
Neal

Just to wrap this one up we finally stopped MRP crashing by removing sol 220120 which we believe introduces some new functionality which divides by zero for packaging qty. A new solution provided by support should superceed this.