Re: Insure DB consistency in case of recovery

Rob

With respect to developing software to monitor everything that could possibly
go wrong in BPCS, and see that it goes right instead, I think that your
manufacturing company has the size and staff and budget that it is possibly
doable, but your competitor Global is a fraction of your size for whom it is
not doable, but fortunately for Global we are not in direct competition & the
kinds of things that can go wrong in BPCS are not business crippling & there
are other ways to identify BPCS failures, of software or human error or
connectivity, and repair damage, than using triggers.

We use Query/400 to identify scenarios of files data out of sync with each
other, and also plain vanilla BPCS stories, then we have reorgs to fix them,
some supplied by SSA & some software that I wrote, and I have some that I got
from BPCS_L but have not yet implemented.  In a few cases, stuff goes wrong
with a disturbing frequency such that management wants improvements to our
system of early warning that something has gone wrong, and a review of what
causes the errors.  This latter has led to some modifications to prevent
certain error conditions from initiating a cascade of more errors.

I am not proficient in DB rules and triggers.  My guess is that they can stop
a bad thing from happening but they cannot ensure that the right stuff
happens.  However, in our changing world of how people can access 400 DB from
PC tools & other products that are not governed by BPCS business rules, we
are getting closer to the point where this sort of security protection will
become essential.

I have found BPCS programs that have bugs, thousands of them in the same
program such as CST600 for example.  I would hazard a guess that our version
of BPCS comes supplied out of the box with in excess of a hundred thousand
bugs, most of them duplicates of each other, that open a window for some 3rd
party vendor to offer software that re-writes BPCS source to eliminate 99% of
the bugs that come with BPCS.  I have no idea whether the V6 V8 re-writes
changed SSA practices that led to AS/Set generating code in violation of IBM
RPG rules.  I  called this to the attention of SSA, citing specific RPG code
and specific pages in specific IBM manuals, when we were on SSA tech support
& SSA unwillingness to fix this was one of the reasons I reccommended that
Global switch to 3rd party tech support.  An ordinary manufacturer customer
is not going to have the staff & budget to fix that sort of thing.

This is also one of the reasons why I have been looking into ERP alternatives
to traditional commercial software vendors & I think Rob Dixon's approach is
one that has a lot of merit.  There are several promising alternatives.
There may come a day when Global outgrows our version of BPCS and needs to
move up to some other ERP, and they may ask my advice on what direction to
take, and right now the obvious choice is between the devil we know & are
somewhat able to cope with, and some other possibilities where I do not yet
have a map to where the evils are hidden, and may never have enough clues
until we are mired in that other reality.

Thanks again Rob for your truely mind expanding questions.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)

> Alister,
>
>  I am building extensive error checking in my trigger programs.  Then I use
>  UPDDTA to test.  Now, however let's look at your existing programs.
>  Knowing that you're a BPCS shop.  Let's say one of these programs does a
>  write or an update and the trigger indicates a failure.  Will they handle
>  it in a proper method?
>
>  Rob Berendt