Re: MRP Generation. -- BPCS-L

Do you have a test environment & the patience & staff to fully evaluate a 
pilot test of some other reality than the one you are accustomed to?

Have you tried out any of the MRP simulation options?  We have not found the 
time to study them ... I have thought that since the simulation data is in 
different named files of similar structure it might be practical to do 
simulation different way than regular stuff then create some report to 
compare the two & give us the differences between the two approaches to 
process the same data.

Some of our customers send us their forecast data once a year or every six 
months.
There was one weekend that we did a total backup, then a clerk was brought in 
on Saturday to key in the total forecast as if it was legitimate on this one 
customer, then we ran full regens & tons of reports & several managers were 
on site for a good bit of Sunday inquiring into the data & extracting 
additional reports, then we restored everything from the Friday backup 
instead of deleting the input, because they did not want any of that 
distracting stuff in our history, and did not seem to be interested in my 
suggestion that we create a dummy customer just for this.

Hey a restore takes like 10 times longer than a backup, and I am backing up 
access paths.  We also have the complication of logicals in libraries 
alphabetically wrong sequence vs. libraries of physicals that we never got a 
round to fixing   I guess the output on the departmental planning side was so 
disappointing compared to the effort because we did this only the one time.

According to the documentation that I have digested, and I find it to be a 
bit mind boggling to really stick to my brain, so I may have missed some 
nuances, SSA has designed MRP500/600 in 405 CD so that there are two 
different flavor structures of how we can run them to manage our companies.

It is possible that the consultant studying the code has realized this, 
without noticing the on-line documentation that explains the differences 
between the two, so you want to be sure to bring that documentation to their 
attention, in case not already aware of it.  Programmer Consultants probably 
more comfortable with this approach ... Command Line WRKOBJ BPCSDOC, when you 
are in the regular BPCS library list, for purpose of identifying what library 
it is in, then access it via WRKMBRPDM & position the list to SSARUN.  I 
generally steer my users into this information via the DOC menu for security 
purposes, as I can limit people to studying the data without accidentally 
deleting it for example.

The flavor we now use is 500 then 600 for facility whatever, then 500 then 
600 for next facility, until all facilities have been done, or run 500 for 
every facility then 600 for every facility, individually.

The other official SSA flavor is 500 then 600 one time in which the facility 
field is blank.  This latter approach can be done even when we are facility 
specific on everything, which we are, in BOM routings Costs Inventory etc.  
The help text on this & the DOC menu SSARUN (I don't remember the number) 
spells out which files what data is extracted from.

Actually studying this, if I had my druthers, or the patience to do serious 
modification here, I would like a mixture of the two ... when CIC & IIM are 
in disagreement, certain fields I would like from IIM & certain fields from 
CIC, and other analysis of this nature, but the current reality is to choose 
all of one or all of the other & for the nature of how we have populated the 
fields, running global 500 then 600 in facility specific reality would 
produce very bad results for us compared to facility 500 then 600.

Now one nuance I have not researched is to mix & match them, where 500 all 
facilities then 600 all facilities except one is global & the other is 
facility specific.  In other words I was studying documentation from 
perspective of pros & cons running the whole thing global or the whole thing 
facility & decided that global would be a disaster for us, but if anyone did 
that by accident, a full regen by facility would fix it.

That is TODAY reality choices for us.  

Given the mountain of modification requests I am currently faced with, and 
the degree to which people are happy with MRP compared to such things as 
getting a handle on actual labor variances, bottleneck analysis, 
experimenting with phantom operations in production, recovering from major 
oops more gracefully, identifying machine mold applicator factory assets 
seriously under utilized, correlating non re-usable shared components 
orphaned by engineering changes, reverse engineering where JIT300 gets its 
average rates, doing a better job of cleaning up all the garbage accumulating 
in BPCS files, competing effectively through B2B, etc etc

I do not perceive me doing ANY modification work in the MRP area for many 
many years for 405 CD if at all, beyond what we have already done, which was 
extremely trivial on the scale of this application.

Some time I think it might be fun to trade info on neat modifications we have 
attempted different places ... what worked out great & what turned into a 
bummer.  However it is obvious that the 405 CD world is rather alien to the 
V6 crowd.

> From: Lisa.Abney@universalflavors.com

>  Al ... (or anyone else who has an opinion!)
>  
>  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.

When we were on BPCS/36, I copied the OCL to do MRP500 & 600 then seriously 
re-defined names of work fields used, so that each facility (on BPCS/36 
facilities were accomplished via separate data base files environments) used 
work file names that were unique to that facility, so that we could be 
running MRP500 then 600 simulataneously on different jobqs, for different 
facilities without mutual conflict, other than IBM performance issues.

The reason for this was that in BPCS/36 the work file names were based on 
MRP500 & work station-id, with nothing facility specific built in, so if you 
had one user try MRP500 600 on one facility & another try it on another 
facility, the two runs would get seriously entangled.  Also I was working 
towards a string of nightly tasks to run the whole thing without waiting for 
anything to end before doing next step ... something that has now come with 
405 CD.

I would not want to try MRP 500 600 for different facilities in different 
jobq at same time on 405 CD without seriously studying how it handles & names 
work so far, which I have not tackled.

Al Macintyre  ���
MIS Manager Programmer & Computer Janitor of BPCS 405 CD Rel-02 running on 
AS/400 V4R3 http://www.cen-elec.com Central Industries of Indiana--->Quality 
manufacturer of wire harnesses and electrical sub-assemblies
+---
| 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
+---