BPCS *LIBL Gotchas

See PDM 54 for a tip to help handle upgrades to your software.

The way SSA patches BPCS is to provide replacement code in a library of the fixes that goes in front of everything else in the Library List. After many months, when this is seen to be working Ok, we are supposed to merge the new, battle tested stuff, into the earlier stuff. This presents several challenges.

• IT can fall behind in work to be done
• the actual merger, and purging of unwanted code, can be tedious
• if it aint broke don't spend time fixing it
• There are periodic mass collections of fix releases, in between a dribble of small numbers, so in theory we can replace the dribble of a dozen or so smaller libraries in the list, since the last mass collection, with the latest mass collection, but this needs to be checked. We can have recent small patch collections that did not make it into the latest mass release.
• SSA testing cannot possibly forsee every scenario at every customer, so sometimes there is new stuff that breaks old stuff, so we end up with, in front of the mass release library, a fixit library, with copies of the earlier software versions that the mass release broke
• for some versions of OS/400 there is an upper limit on the number of libraries that may be in a library list
• depending on IBM optimization, there may be performance problems from having many libraries in production list
• this architecture can mean that the execution code for BPCS eats more disk space than the actual data.

Where : Al Mac works may not be typical, but

• we are bumping our heads on the ceiling of library list size,
• the mass release libraries have many thousands of software objects duplicating same names in earlier libraries
• the largest program is ORD500
  • there are 1/2 dozen iterations in the library list of the RPG program, more of its related objects. Some other programs have larger numbers of iterations
  • its compiled object eats 1/2 million bytes of disk space. This is the statistic I am using to say it is the largest.
  • it has 25,000 lines of source code, in which every other line is soft coded
  • it calls at least a dozen other programs that are almost as large