Re: Seperate Libraries

From Al Macintyre 405 CD mixed mode

nmenon@cott.com writes:

> Is there any other reason for creating separate libraries for Base BPCS, 
PTF 
>  BPCS and BMR BPCS   in Production Environment, besides testing.

Any new or replacement software has been known to contain new bugs.

I have found & fixed several bugs in SSA BMRs before I installed that 
software on our system.  Do you habitually inspect SSA BMR source code to see 
what they are doing in their fixes?  It can be so time consuming, that I only 
do random checks, focusing on the programs we use the most heavily.

We have installed BMRs into our library list, then had serious problems & had 
to uninstall those BMRs .... it is much easier to uninstall a library from a 
library list than to reconsititute a library that has had a working object 
replaced by a defective object.

In the case of adding a PTF REL in which there are some multiple of a 
thousand fixes & we really very urgently need several hundred of them, but 10 
just broke something, we insert a new library in our list, above the PTF REL 
called PTF whatever # FIX which contains copies of the original BASE, or 
earlier PTF or BMR version that WORKED before the latest PTF broke them.  We 
also report this to SSA, but sometimes getting the problem fixed TODAY is 
more important than the communications to make sure that SSA understands the 
problem ... if they could understand it in a day or two, we could wait on the 
fix, but that is rare.  Any subsequent BMRs are installed above the FIX 
library.

It currently is impossible for SSA to do complete & thorough testing of their 
software in all combinations that can apply for plain vanilla BPCS, not 
counting any modifications a customer may have added to the picture.  There 
was a time that SSA made marketing claims that they had a fool proof system 
for doing this, a system & marketing story that both has been abandoned as a 
total failure.

It is currently possible for some consultants to do complete & thorough 
testing of their client sites, and also some that cannot may claim that they 
can,  but all clients that I have any awareness of elect not to have this 
done due to the expense.

During our Y2K conversion, I briefly looked into us getting our own automated 
testing tools, but it was another tool to have to learn & we could only 
justify its purchase for a narrow time window, so I lived without that 
expense.

We have a library containing a collection of MANY BMRs that have been running 
on our system for 6 months or more with NO PROBLEMS.  It is a pain in the 
neck to move the stuff there, and to eliminate the BMR libraries from our 
library list, but this sort of continuing support is neccessary to avoid 
running out of what can go in a library list.

When the next release comes out ... PTF collection whatever REL number,,
it is supposed to contain everything that was in the old PTF REL & all BMR 
since, but it pays to verify that ... when I compared what was in PTF REL 02 
with PTF REL 01 I found that some BMRs had gone missing from the list, that 
SSA had put in PTF REL 01 but forgotten to include in PTF REL 02.  This is 
why our library list has REL 02 above PTF 01 ... both in our library list.  
It wasn't worth futzing with the why of all this.  We cleared out all the BMR 
libraries from our library list that were superceded by PTF REL 02.

A bad consequence of this SSA architecture is that the total amount of disk 
space needed for all this software is HIGHER than the total amount of disk 
space for all the DATA FILES.

We have separate libraries in our library list for
A library containing user queries ... our power users can run them from 
command line
Our software modification add ons
BPCS software modification add ons from 3rd parties
Files we have added to the BPCS collection, such as new logicals.

Our latest new files are
ECIF ... cross index by customer / item / facility what items we make for 
what customers in which facilities, with date of last shipment, revision 
involved, and production hours needed to make one part (poor man's extremely 
rough cut Capacity Planning estimating tool) which was built by going down 
BOM to access routings on every sub-assembly
HCIF ... end to end cross index of every raw material consumed by every end 
item we use & from what vendor we get it & how much is needed from BOM 
aggregate .... this helps us identify materials orphaned by engineering 
changes, and assists in negotiations for better price breaks from vendors

> From: LACELLE@rcmint.ca (Lacelle, Marc)

Al comments in line where Marc says something &
Al adds to the sub topic

>   Consistency is the main reason. 
>    BPCS environments are based on hierarchical structures. 
>    In common English: 
>     When calling a program or using a data file it will search 
>   through your library list starting from the top to the bottom.
>  
>   A standard library list looks like this.
>  
>   BPCSTCPIP (if you are using CEA or NLV)
>   BPCSXXXUSR  (startup programs, nothing else)
>   BPCSXXXUO   (your custom programs)
>   BPCSXXXUF   (your custom data files)
>   BPCSXXXPTF  (cumm PTF)
>   BPCSXXXF        (base bpcs data files)
>   BPCSXXXO        (base bpcs objects)
>  
>   For this example, lets use INV500D1 (this object has been moded a
>  few times over the years)
>  
>   When using INV500D1 in a bpcs environment 
>   it will first search the TCPIP lib and move on
>   to the next library which is the USR lib. 
>   It will do this until it finds INV500D1 in the PTF lib. 
>   Please note: INV500D1 also lives in the O library. 
>   This INV500D1 is the base object (no mods). 
>   The same method is used for data files, which are in the F library.

We need to be more careful with data files than we are with objects.
I have no problem with having the latest copy of an executable object at the 
top of a library list, in which removing that library from your *LIB or 
moving it lower down is a way to access an earlier version of the program.
I do have a problem with a new version of a data file.
The old version is POPULATED.
I do not want to replace it with a new empty version.
I am also nervous about programs compiled using a logical then having 2 
copies of that logical in library list.
I do not want any risk that sometimes data will end up in the wrong copy of 
the file.
There is also an issue of backup restore sequence of libraries needs to 
connect right logical to physical restored before logical.

Also, if you have a test environment & a live environment, like we do, it is 
Ok to have the same executable software libraries in both places, with single 
exception of BPCSMENU start up library list etc.  It is not Ok to have same 
libraries that happen to contain any data files ... physical or logical.
  
>   If your IT staff would need to mod the INV500D1 program. You would
>  copy the INV500D1 
>   from the PTF lib to your UO library and make the changes there.
>  Always keep the original object in its original library.

Then when a new BMR arrives on INV500D1 you need to evaluate how to merge 
your modifications with what SSA did in their latest upgrade.  Using PDM-54 
on pairs of latest BMR source vs. prior source & your mods vs. prior source, 
can be invaluable.
  
>   You can remove objects from your O library that are present in your
>  PTF library. BUT ONLY THOSE OBJECTS.

And it would be real smart to keep some memory that those objects had been 
removed, in case later on you get another PTF library & consider removing the 
PTF library containing replacement objects whose replacements have been 
removed.

>   For the minimal room on your disk that you reclaim, I for one would
>  not do this.
>  
>   I hope this helps
>  
>   Marc Lacelle
>   Royal Canadian Mint

Al Macintyre  ©¿©
BPCS 405 CD Rel-02 on AS/400 V4R3 http://www.cen-elec.com 
+---
| 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
+---