Re: BPCS Shooting at IBM Feet

[Ata510@xxxxxxx]

Hi Al, 

Have you read the BMR Change Management document on OGS? It is under the BMR 
area, if you click on that. It explains what BMRs are, what an 'explosion 
library' really is and how it is created at SSA, and why you tend to get the 
same objects over and over again when you order BMRs. It also has some good 
strategies for handling this situation of duplicate objects, except that your 
users appear to feel testing is not a good thing, which is really not a very 
wise decision on their parts.  

You should start looking at source change dates on programs and look at DSPFD 
or DSPFFD on the files, and see if the level identifiers match, number and 
length of fields are the same. If they do match, then don't keep the 
duplicates or older ones. If they are data files, you are going to have to 
make sure that you don't have data in both, and if you do, figure out what to 
do about it. If they are logicals, make sure the logical has built itsef over 
the proper physical with a DSPDBR. Each BMR library has a QTXTSRC member that 
shows which BMRs were picked up and the ones with files delivered usually 
have special instructions telling you how to implement the fix. 

SSA does indeed change the files (but not often) if there is some major 
problem (which, for example between REL01 and REL02 there were LOTs of 
problems in BPCS CD). This is why you should check the file level IDs, or if 
the new program runs and the new file is not there as it should be, you will 
likely get a level check or a failure if a field length doesn't match. 




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