Re: Maintaining current BMR's

The BPCS BMR experience is a pain in the ### but, there are a couple of ways 
to make it easier.  As was mentioned earlier, only apply the bmr if you find 
the problem.  Also, when you order a bmr, you can do a DSPOBJD of the *PGM's 
in the bmr and the BPCSPTF library to an outfile and then use query to join 
the two files together via program name.  If the source dates are different, 
then those are the only programs that you have to test and then apply.  If 
the source dates are the same, then, the program you are currently running is 
the one that is on the BMR tape.  

The way the BMR explosion works is that you get EVERY program associated with 
the BMR that you order.  In most cases (if you are not too far back on CUM 
tapes, you will be running the programs that are included in the bmr).  Yes, 
there are a lot of changes that have taken place but here is a good example.  
I am working for a client that is running 6.0.04 MM AS/400.  We applied the 
july cum three weeks ago.  We also just received the "latest" Y2K group BMR 
as well as two other BMR's that were needed to fix INV500 transactions.  The 
Y2K and INV500 BMR's when all put on the system was about 280 programs.  Only 
40 of which were changed since the versions that were running in our PTF 
library.  

I agree it is a daunting task, but, trying to test the 280 vs 40 turned out 
to be not that bad.  

Jeff


In a message dated 12/30/1999 6:25:06 PM Eastern Standard Time, 
Cdoe@barton-instruments.com writes:

> you have my sympathy. we have not been able to determine how to handle the 
> bmr process. and ssa just does not want to acknowledge the problem. 
> furthermore trying to adapt a policy of applying the cum tapes doesn't work 
> either. when you have a problem you order a bmr and install it. when the 
next 
> cum package is distributed it may or may not include the individual bmr's 
> that you have installed, if it does not, then you have to reorder the bmr 
and 
> reapply it. (don't just reapply the original bmr. while it may not be on 
the 
> cum package, some of the objects included in the bmr distribution may have 
> been updated by the cum package. you need to reorder the bmr).
>  
>  
>  we had serious problems with the bpcs cfg module and probably had a 
backlog 
> of 25 or so individual bmr's that needed to be applied. to have ordered 
them 
> and applied them individually would have been impossible. ssa offer to cut 
us 
> a special tape that consolidated all of these individual bmr's into one 
> distribution. this helped, but you have to get them to do it!
>  
>  >>> <RickCarter@holley.com> 12/30 1:05 PM >>>
>  AS400 Version 6.1  Mixmode
>  
>  Does anyone have any break through ideas on how to best stay on top of the
>  BMR issue with SSA.  For instance, on 12/29/99 the most recent passed BMR's
>  for version 6.1 included roughly 194 BMR's for the AS400.  How in the world
>  does one monitor and keep the most current mods applied to their system.
>  At this point, we typically don't worry about a fix until we encounter the
>  problem but with all the Y2k issues, etc, I've been monitoring OGS more
>  closely and it's scary to see this many BMR's for one time period.  Is
>  there a proper way to deal with this other than by trial and error or
>  better yet run and fix .
>  
>  Thanks
>  
>  
+---
| 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
+---