RE: MRP Generation. -- BPCS-L

One more to all those who have already posted on this topic.  In the
HP/Oracle environment we found, if we launched MRP500 for more than 1
facility at the same time, the KMR records did not clear for all facilities.
Apparently, in order to clear the KMR files, BPCS/Oracle uses a table lock
on KMR while it deletes the appropriate facility files.  The other MPS/MRP
runs timeout trying to access the table and move on.  We found multiple
requirements on parts when this would happen.

Solution: wait 5 minutes in between starting each MPS/MRP run.  This maybe
unique to the Oracle environment.

Kent Van Horn

-----Original Message-----
From: owner-bpcs-l@midrange.com [mailto:owner-bpcs-l@midrange.com]On Behalf
Of Zieske@nexgensoftware.com
Sent: Monday, July 24, 2000 10:09 AM
To: BPCS-L@midrange.com
Subject: Re: MRP Generation.


Lisa Wrote

<Any reason you know that you run MRP500/600 single threaded?  We run a
similar
environment (4.0.5, using DRP, with many facilities, run MRP/DRP cycle each
night), and have a consulting group analyzing our environment, and
suggesting we
run all (or at least several) MRP500's and then MRP600's simultaneously.
Of
course, I told him we couldn't do that, since we've NEVER done it that way
before.  He claims he's analyzed all the programs, and they appear to be
designed to be able to run that way.

Any thoughts?

>
The facilities 500/600 cycles  can run independently of each other, however
the 500/600 cycles within a facility should be single threaded. Also a
global run can not coexist with any facility specific run.  4.05 locks
facilities to do MPS/MRP runs. DRP is a more difficult question, but not
because it physically can't run with the others. Physically the only
requirement is that you have to work each facilities DRP run into the
single MPR/MPS thread for a facility. However, DRP is designed to cross
facility boundaries and affect the planning at a different facility. This
means you have to logically sequence runs properly to get a complete plan.
The good news is that if they do plan out of sequence, it is self
correcting next run, but you can temporarily end up with plans that are not
yet synchronized to the new DRP requirements. My preference is to remove
DRP from the multiple facility running at the same time scenario.

But of course there is the gotcha. With the proliferation of PC based
terminal emulators, and the BPCS habit of using truncated work station
names to build work file members, the possibility exists of two jobs
stepping on each others work files. (This is normally prevented in BPCS
during the normal on-line submission of jobs, but I am assuming you are
setting up some kind of batch submission process) Easy to prevent, but mass
confusion if it happens.


Harmon Zieske
Nexgen Consulting help line.

+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---

+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---