MRP Full Gen not ending (R3482)

[tmackin]

We have a scheduled job to do a full gen for MRP (R3482) that has stopped working/ending. I found sales orders out to 2011 so I updated the calendar. I thought there might be a problem with a BOM, so I rand the Integrity Analysis (R30601)with no problems found. I created a new version from scratch with no luck. I tried running with and without clearing tables F3411,12,13. I tried creating logs but couldn't retrieve them (too big!). I ran a series of gens for ranges of item numbers to encompass all within the B/P and they all ran to completion. Now I don't know where to go from here and would appreciate some input on suggestions for further investigation.

Any advice would be greatly appreciated, thanks in advance.

 

[Stephen]

Hi,
Try defining the calendar for 2012 and re-run. what is the time-horizon you are giving in the processing option?

 

[JMast]

Not sure I have an answer, but I have some things to consider.

Locking possibilities:
Are you running this job while users or other UBEs are on/running? I wonder if there is a locking conflict with another application.

Are you running MRP in multithreaded? This may cause MRP to "lock on itself" if it is trying to plan a finished good and a component of that FG at the same time.

Data Corruption Possibility:
Is there a "busted" record in Item Master, SO Detail, PO Detail, WO Detail, or the Forecast that could be causing MRP to "loop" or plan continuously for a given record.

Now the trick is what to look for. Please let us know the answers to the above questions (except, of course, the busted record).

Another quick question: How large is the F4211? The size of this table has an immediate impact on how long MRP runs.

Jer

 

[Larry_Jones]

Tim,

what does "stopped working/ending" mean?

It ends immediately?
Runs a while and then ends normally?
Runs a while and the ends with a Error?
Runs and never ends?

 

[JKelly from the Hills]

We had a similar problem and tried all sorts of things relating to data eg corrupt items,cursive boms. We ran the Bill of material structure analysis R30601 and like you broke the data into smaller chunks and the MRP ran perfectly. We had our CNC look into it and the answer turned out to be related to the number of levels/depth of our Boms and the fact that we did not have enough memory allocated to the running of the MRP.
To avoid the "out of memory" problems we set the following settings in our Enterprise Server running HP-UX 11.11

maxssiz=200802304 (191.5 MB) Max Stack Segment Size for 32-bit Processes
maxdsiz=1073741824 Max Data Segment Size for 32-bit process

maxssiz_64bit=200802304 Max Stack Segment Size for 64-bit Processes
maxdsiz_64bit=1073741824 Max Data Segment Size for 64-bit process

Some good recommendations came from the attached document.

note: at the time we were running 8.49 and we are now on 8.96. I am sure there is a later document.

 

[tmackin]

As my subject stated, the program runs and does not end



Timothy P Mackin

Sr. Business Systems Analyst

OFS Fitel, LLC

55 Darling Drive

Avon, CT 06001

860-678-6578 (O)

860-883-6553 (M)



_____

From: [email protected] [mailto:[email protected]]
On Behalf Of Larry_Jones
Sent: Tuesday, October 27, 2009 6:24 PM
To: [email protected]
Subject: Re: MRP Full Gen not ending (R3482)



Tim,

what does "stopped working/ending" mean?

It ends immediately?
Runs a while and then ends normally?
Runs a while and the ends with a Error?
Runs and never ends?

Larry Jones E1 8.9 - TR 8.97.2.1 on Win 2003. Oracle 11g 64bit Wintel,
OAS 10.1.3.1 Upgrading to 9.0!

_____


The entire JDELIST thread
<http://www.jdelist.com/ubb/showflat.php?Cat=3D&Board=3DApps&Number=3D152 is available for viewing.

Looking for a job? Check out the Job Opportunities forum

This is the JDELIST EnterpriseOne Applications Mailing List.

To unsubscribe from this list via email, Click here
<mailto: [email protected]?Subject=3DUnsubscribe&Body=3DSirs,% 0A%
0APlease remove this address from the JDELIST Enterpris

 

[tmackin]

Jer, job runs in a single-threaded queue overnight with no one online.
F4211 is not big at all. Job usually ran in 10-15 minutes.



Busted records?? How to tell?



Timothy P Mackin

Sr. Business Systems Analyst

OFS Fitel, LLC

55 Darling Drive

Avon, CT 06001

860-678-6578 (O)

860-883-6553 (M)



_____

From: [email protected] [mailto:[email protected]]
On Behalf Of JMast
Sent: Tuesday, October 27, 2009 5:11 PM
To: [email protected]
Subject: Re: MRP Full Gen not ending (R3482)



Not sure I have an answer, but I have some things to consider.

Locking possibilities:
Are you running this job while users or other UBEs are on/running? I
wonder if there is a locking conflict with another application.

Are you running MRP in multithreaded? This may cause MRP to "lock on
itself" if it is trying to plan a finished good and a component of that
FG at the same time.

Data Corruption Possibility:
Is there a "busted" record in Item Master, SO Detail, PO Detail, WO
Detail, or the Forecast that could be causing MRP to "loop" or plan
continuously for a given record.

Now the trick is what to look for. Please let us know the answers to the
above questions (except, of course, the busted record).

Another quick question: How large is the F4211? The size of this table
has an immediate impact on how long MRP runs.

Jer

E1 8.0 SP23_K, Win2003, SQL Server 2000, all fat client

_____


The entire JDELIST thread
<http://www.jdelist.com/ubb/showflat.php?Cat=3D&Board=3DApps&Number=3D152 is available for viewing.

Looking for a job? Check out the Job Opportunities forum

This is the JDELIST EnterpriseOne Applications Mailing List.

To unsubscribe from this list via email, Click here
<mailto: [email protected]?Subject=3DUnsubscribe&Body=3DSirs,% 0A%
0APlease remove this address from the JDELIST Enterpris

 

[tmackin]

Will have CNC look into memory allocation. Most items have LLC less than
5 with a handful at 7.



Timothy P Mackin

Sr. Business Systems Analyst

OFS Fitel, LLC

55 Darling Drive

Avon, CT 06001

860-678-6578 (O)

860-883-6553 (M)



_____

From: [email protected] [mailto:[email protected]]
On Behalf Of JKelly from the Hills
Sent: Tuesday, October 27, 2009 8:30 PM
To: [email protected]
Subject: Re: MRP Full Gen not ending (R3482)



We had a similar problem and tried all sorts of things relating to data
eg corrupt items,cursive boms. We ran the Bill of material structure
analysis R30601 and like you broke the data into smaller chunks and the
MRP ran perfectly. We had our CNC look into it and the answer turned out
to be related to the number of levels/depth of our Boms and the fact
that we did not have enough memory allocated to the running of the MRP.
To avoid the "out of memory" problems we set the following settings in
our Enterprise Server running HP-UX 11.11

maxssiz=3D200802304 (191.5 MB) Max Stack Segment Size for 32-bit Processes

maxdsiz=3D1073741824 Max Data Segment Size for 32-bit process

maxssiz_64bit=3D200802304 Max Stack Segment Size for 64-bit Processes
maxdsiz_64bit=3D1073741824 Max Data Segment Size for 64-bit process

Some good recommendations came from the attached document.

note: at the time we were runnin g 8.49 and we are now on 8.96. I am
sure there is a later document.

john kelly JDE 8.10 Unix Oracle DB

_____


The entire JDELIST thread
<http://www.jdelist.com/ubb/showflat.php?Cat=3D&Board=3DApps&Number=3D152 is available for viewing.

Looking for a job? Check out the Job Opportunities forum

This is the JDELIST EnterpriseOne Applications Mailing List.

To unsubscribe from this list via email, Click here
<mailto: [email protected]?Subject=3DUnsubscribe&Body=3DSirs,% 0A%
0APlease remove this address from the JDELIST Enterpris

 

[tmackin]

Added 2012 with no improvement



Timothy P Mackin

Sr. Business Systems Analyst

OFS Fitel, LLC

55 Darling Drive

Avon, CT 06001

860-678-6578 (O)

860-883-6553 (M)



_____

From: [email protected] [mailto:[email protected]]
On Behalf Of Stephen
Sent: Tuesday, October 27, 2009 8:30 PM
To: [email protected]
Subject: Re: MRP Full Gen not ending (R3482)



Hi,
Try defining the calendar for 2012 and re-run. what is the time-horizon
you are giving in the processing option?

_____


The entire JDELIST thread
<http://www.jdelist.com/ubb/showflat.php?Cat=3D&Board=3DApps&Number=3D152 is available for viewing.

Looking for a job? Check out the Job Opportunities forum

This is the JDELIST EnterpriseOne Applications Mailing List.

To unsubscribe from this list via email, Click here
<mailto: [email protected]?Subject=3DUnsubscribe&Body=3DSirs,% 0A%
0APlease remove this address from the JDELIST Enterpris

 

[JMast]

Re: RE: MRP Full Gen not ending (R3482)

I forgot to mention what JKelly brought up, so I am glad he did. Are there any resource constraints on your server while MRP runs? Any event viewer or jde.log errors?

Any changes on the server, like a SQL backup, tape backup, virus scan, etc... that is new at the time MRP runs?

I brought up the busted items since the problem seems to be either server performance or data change related.

Typically, for busted items, the first thing to look for is zero records in the key tables. For example, sort the PO Detail by doco and see if a record has a zero in DOCO. Often, this shows up on a business view that joins 2 tables which causes the UBE to process every record when it hits the busted key which dramatically increases the runtime. This is not likely to be the problem since the small batches run, but it wouldn't hurt to use a query to review all the Item Branch MRP settings (I would list them all in one query which makes it easier to scan for differences between similar items).

Since your MRP doesn't take long to run, something to try would be to run all the small batches, copy the F3411 to a backup table, clear the tables, and run it in one batch like you used to. When you are confident it has run longer than normal, you can run queries comparing the backup table to the newly loaded F3411 and look for differences. I would probably start with a row count by item number query on each table and see what is different.

Jer

 

[tmackin]

RE: RE: MRP Full Gen not ending (R3482)

Thanks, will check databases



Timothy P Mackin

Sr. Business Systems Analyst

OFS Fitel, LLC

55 Darling Drive

Avon, CT 06001

860-678-6578 (O)

860-883-6553 (M)



_____

From: [email protected] [mailto:[email protected]]
On Behalf Of JMast
Sent: Wednesday, October 28, 2009 8:56 AM
To: [email protected]
Subject: Re: RE: MRP Full Gen not ending (R3482)



I forgot to mention what JKelly brought up, so I am glad he did. Are
there any resource constraints on your server while MRP runs? Any event
viewer or jde.log errors?

Any changes on the server, like a SQL backup, tape backup, virus scan,
etc... that is new at the time MRP runs?

I brought up the busted items since the problem seems to be either
server performance or data change related.

Typically, for busted items, the first thing to look for is zero records
in the key tables. For example, sort the PO Detail by doco and see if a
record has a zero in DOCO. Often, this shows up on a business view that
joins 2 tables which causes the UBE to process every record when it hits
the busted key which dramatically increases the runtime. This is not
likely to be the problem since the small batches run, but it wouldn't
hurt to use a query to review all the Item Branch MRP settings (I would
list them all in one query which makes it easier to scan for differences
between similar items).

Since your MRP doesn't take long to run, something to try would be to
run all the small batches, copy the F3411 to a backup table, clear the
tables, and run it in one batch like you used to. When you are confident
it has run longer than normal, you can run queries comparing the backup
table to the newly loaded F3411 and look for differences. I would
probably start with a row count by item number query on each table and
see what is different.

Jer

E1 8.0 SP23_K, Win2003, SQL Server 2000, all fat client

_____


The entire JDELIST thread
<http://www.jdelist.com/ubb/showflat.php?Cat=3D&Board=3DApps&Number=3D152 is available for viewing.

Looking for a job? Check out the Job Opportunities forum

This is the JDELIST EnterpriseOne Applications Mailing List.

To unsubscribe from this list via email, Click here
<mailto: [email protected]?Subject=3DUnsubscribe&Body=3DSirs,% 0A%
0APlease remove this address from the JDELIST Enterpris

 

[tmackin]

Problem solved!! Oracle told me to have the SF caendar go out a minimum of 5 years. We never went out more than 2 years and had no problems. Wondering what may have caused the program to hang on a date conversion.

 

[Terry DeMoure]

Ironically the Shop Calendar problem was impacting us herfe too but not in stopping it from completing, but actually stopping it from running.

Did you check your business object reservations to see if perhaps you might have a corrupted order recored somewhere?

 

[Terry DeMoure]

With us it was sales order requirements that were added out in the future beyond the number of shop calendar yearsd we had loaded. It wasn't so much a date conversion problems as much as it was that MRP did not have a calemdar platform to process from.