Re: QPFRADJ/BPCS - more info

Samantha

Your system is obviously much larger & more complex than I am accustomed to.

i mentioned in an earlier post that the folks on BPCS_L might be able to help 
you in addition to help on MIDRANGE-L, particularly folks on BPCS_L who are 
on the samve version of BPCS as you & with a similarly loaded machine.

David recently said the midrange dot com archive server is up again so you 
might go to the BPCS archives & do a search engine on posts about BPCS 
performance issues.
http://archive.midrange.com/bpcs-l/index.htm

There are people with horror stories there about changing things & some jobs 
going from 10 minutes to 10 weeks, but the problem was more due to upgrading 
to a new & improved version of BPCS or new & improved version of OS/400 
without getting the IBM PTFs that are BPCS specific, such as the one to fix 
data base performance when IBM improves SQL so that it is BPCS hostile, so 
you get PTF to get your old performance back again.  I not remember the 
numbers, you need to check the archives.

There are lots of things that need to be done to manage BPCS properly that 
are not well documented, and while there is a lot of what I consider to be 
reasonably good & inexpensive BPCS documentation out there, it is not well 
documented what all is available.  But you can find references to this on 
BPCS_L archives.

Your original consultants should have told you about the stuff that was 
relevant at the time you were setup, but your business needs will evolve, as 
will the personnel who were on site at time of consultants being there, and 
there can be a problem with corporate memory going out the door in the heads 
of people who no longer work for the company.  So there ought to be policies 
in place to minimize that damage.

We are a BPCS version 405 company on AS/400 model 170.
We run a score of BPCS reorg jobs weekly, and several more frequently & have 
created our own menus because there is a right sequence to run this stuff, 
and it has no correlation to the sequence of how they are on the native BPCS 
menus.

If those jobs did not get run, then some deleted data would accumulate to 
infinity.
We found out about some of these jobs by accident ... there was some stuff 
our original consultants should have told us but did not, so as a result we 
had some files that had accumulated several million deleted records between 
the time we went to a particular version of BPCS & found out about what we 
could do about this.
As far as OS/400 concerned they really not deleted so we could not use the 
OS/400 reorg routine, they were "soft deleted" according to BPCS rules, so 
you have to know what BPCS reorg to run (for our version it is SYS120C off of 
SYS/23/12 menu).

We have had some internal discussions about how long to retain the data that 
BPCS gives you some say about how long to retain it.
There is some stuff where in BPCS you say you want to keep the data for like 
360 days, but in reality BPCS stores the data to infiinty.

We learned the hard way that if we purge history of data relevant to shop 
orders that remain open longer than we retain that history, those shop orders 
cannot do a normal purge.
We learned the hard way that if we restart shop order numbering at a low 
number while the previous time that shop order number was used in the 
history, the old history corrupts visibility of the new history.

There are some reorg jobs that are safe only to run at a particular point in 
EOM check list, provided it is not a month when Physical Inventory is being 
run.
Lists of what these jobs are, with respect to which version of BPCS, and 
which application modules you using with what tailoring, are found in 
abundance in the BPCS_L archives.

Depending on where you get BPCS tech support, you may be able to access BPCS 
on-line encyclopaedia of solutions from the SSA GT OSG web site.

BPCS comes supplied with all files that any tailoring combination might want, 
but probably 90% of the BPCS files are not populated, and they clutter up 
your system.

BPCS has the habit of adding members to files and data areas based on the 
naming of work stations & never purging empty unused ones, so if there is any 
volatility in your work station naming conventions, there will be growth in 
unneeded members.
If you look at the lists of names, they date back to SSA original development 
on work station names your company nver ever had.
I have identified, thanks to *OUTFILE analysis, a rather large number of BPCS 
files each of which have a rather large number of unwanted members.  I am 
talking about tens of thousands in the aggregate.

In addition, there are several BPCS files that do not come with purge 
software.
They will accumulate dead records to infinity unless you develop your own 
purge software, which is one of the many projects that keep me busy, or you 
can buy a packaged solution to this problem from some place like
http://www.unbeatenpathintl.com/

Click on products & services, then bells & whistles, then other
What you are looking for is BPCS LITE

Your list of subsystems includes ROBOT so that tells me you are using 
something from HELP SYSTEMS.  Their web site has forums for people who use 
ROBOT in BPCS, that also address performance issues.  You might want to go 
lurk there.
http://www.helpsystems.com

http://www.as400network.com
has some great books & articles on 400 performance
some of which you can download for free, but you will probably want to 
purchase one of their inexpensive books that introduces you to 400 
performance in general

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---