BPCS Shooting at IBM Feet

We are a little behind in applying Y2K bug fixes to our BPCS 405 CD mixed 
mode... the old corporate strategy was that requested BMRs & modifications 
would go into test environment, which we use infrequently such as for 
training new people, then at convenience of department involved they test the 
BMR then tell me either that it works so it needs to go in the live 
environment or they go cry on SSA help line regarding what wrong now.  When 
Y2K not in the picture, it does not matter that I have BMRs & our internal 
mods installed in test environment 6 months ago & users not yet got around to 
testing, while other departments religiously test their stuff within a few 
weeks of it getting there.

After a BMR makes it into live environment & no gripes about it for 6 months, 
we move them to a consolidated BMR library, so that the library list can be 
kept somewhat short of filling up.

Last month several people complained to me about garbage dates in MRP & I 
told them that when ALMOST NO ONE in the company has time to test fixes then 
EVERY ONE in the company has to figure out contingency planning because we 
have NO IDEA what might go wrong & you are part of the ones.  In other words 
this aint going to be fixed under current corporate strategies.  My remarks 
led to the corporate strategy being changed.

I am now under orders to install BMRs etc. in the live environment with no 
one doing any testing, but do it in such a way that if we have a problem we 
cannot work around, I can back out the software involved in that BMR from 
whatever library list.  So we now have bunches of fixes in the live 
environment that never made it into the test environment, and will not until 
I get caught up with my BMR backlog.

Each environment has 2 libraries of unique files (BASE & USF) & a low number 
of software libraries that has to be unique because of data structures & 
stuff like BPCS menu & library list, but the vast majority of software 
libraries are shared by both environments - same programs, BMRs, 
modifications, etc. the only difference is that some may have made it into 
one environment library list but not yet the other.

A small handful of SSA fixes come with files - LF PF Data Structures & in the 
early days before I went to IBM school, and when we had consultants whose IBM 
schooling was ahead of mine but not far enough, there were some upgrades 
installed according to SSA instructions without the installer sensitive to 
the nuances of having the identical data files in more than one environment.

I need a better strategy for dealing with this than my usual stumbling around 
& reacting a bit differently every time it happens.  Currently our problem 
files include:

CICL06 LF in REL-2 and some earlier BMR that made it into consolidated library
EVFEVENT is all over the place
HHT in PTF-1 - we not use ASSET
HHTBK in PTF-1 - we not use ASSET
HXX in PTF-1 - we not use ASSET
HXXBK in PTF-1 - we not use ASSET
INQDTA01 & 02 PF & DTAARA in REL-2 and both live & test environments
ITHL40 in REL-2 only = INV900 of REL-2 needs this
KORL03 in REL-2 and both environments - we use MRP
NEH01 in REL-2 and both environments - we not on CIMPath yet
ZML04 in REL-2 and earlier BMR38297

Question of clarification - when SSA updates include a file we ALREADY have, 
does that mean we are Ok we must have got it on a BMR now included in SSA 
cumulative release, or does SSA change the files?

My thinking is - when it is a new file that we did not have before & there is 
only the one of them - compile into live & test environments separately - one 
copy of the object in each one for the data in that environment, keeping it 
separate, and make sure it is deleted from the shared software fix libraries.

If there is more than one - like REL-2 & earlier BMR, or in our environments 
& also in an SSA fix - find the source code for PDM-54 comparison & if it is 
identical, then remove the file from the SSA fix, verifying of course that 
the earlier source was compiled into where it should have gone.

If & when it is not the same, put the older story in the BASE file library 
which is near the bottom of the library list & put the newer story in the USF 
file library which is near the beginning of the library list & remove all 
versions from the shared software libraries.  Then if some problem develops & 
I am told to back out the latest fix, I know it is in the USF library.

Since there is obviously some corruption going on with our files, one might 
ask "How come your users did not notice this Al?"  Oh but they did notice 
SOMETHING, but noticing stuff & knowing what is causing it are two different 
animals.

Al Macintyre
+---
| 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
+---