Having been running MRP session as part of a job suite of 7 sessions for some 20 weeks with no errors ; this week we receive a message "Runtime Error"

We have not changed job during the 20 weeks running it at the same time each week

Is there any particular log file that can be interrogated to assist in understanding reason for this category of error or can anyone assist in any other suggestions

4c4 SP8

Thanks in hope !

Hi,

Pls. take a look into $BSE/log directory.
For example log.ba6.1 or log.bshell or the others.
Also you can take a look into Display Job History Messages ttaad5512m000 Sometimes you can find the problem there too.
Are you running Baan on UNIX / ORACLE?

GN

Hi GN

Thanks , we had already looked in log.bshell to find nothing but your post made us rexamine logs in sure enough in log.informix we found an answer of sorts with err -458 with a message long transaction aborted ! and a recommendation in the err definition to speak to the programmers about the transaction or the aministrators about the log file size . hmmm !!!
Well we can speak to Baan but the logfile was at 100mb of a 2gb limit ! and it successfully copied it to disk !

So we are still seeking a reason an a solution !

Dates outside the calander can cause problems.

Thanks for the tip Naabi0 !

We did find a date outside the calendar but it was for an order which was excluded from MRP

However we reran MRP last night and the "problem" did not reappear so we are still uncertain as to the cause

Hi Frank,

May it be the reason that a lot of records should be changed that day? And a lot of orders should be created / replanned?

Regards,
GN

Hi GN !

Could be but no real changes from previous week or last night's run ( we are told by users)

Further to previous , we were told by Baan to increase logical log size but and MRP ran ok but we are not convinced this was cause of the problem since we had no error log messages and when we reran on our test system without increasing size of logical logs MRP ran through ok !

Could it be that an application lock could have caused it ?
No user was on the sytem as it was 21:00 Saturday

Also two of our discs were rebuilding themselves onto the hotspares duting the weekend although we do not know the exact timings so this may have contributed