Re: IBMathics

Something that has been giving me indigestion is a systemic phenomena with
how some BPCS code is generated.  In RPG/400, ordinary numbers can go up to
30 digiits & up to 9 decimal places.  BPCS CD uses that sze all over the
place for numbers that have no need to be that size.

If you use numbers of size 30.9 in arithmetic with each other, the rounding
does not only work but you can get bad answers.  The RPG manual spells out
very clearly that when rounding numbers you need to provide space for the
rounding ... the work field needs to be large enough to accommodate extremes
of possible results.

IBM calls it "unpredictable results"  Someone might want to run a search
engine through IBM documentation looking for all the places they use this
phrase.

I think of it as something like the buffer overflow problem of C based
languages that Code Red exploits.

For example ... multiply zero times one in a field of size 30 digits with 5
decimal.
The result is often plus or minus 0.00001
I think this is because the zero & one multiplication has moved itself into
the extreme ends of the work area that does not exist, and it loses track &
drops the one into the low order position.

I have seen BPCS math off by as much as 0.00010 but I think this is the
compounding of several hits of this in different places within the same
program.

I tried to bring this to the attention of SSA but I guess I was talking to a
tecfh support person who did not understand programming, because after I
identified the precise lines of code that were flawed in several programs &
the precise pages in the RPG manual that said what was wrong with the code, I
was told that this is the way the BPCS program is supposed to work.

The systemic problem is that this flaw is in many many programs.
I have looked at several programs that are doing this.
The flawed code is in like hundreds if not thousands of different places in
the program.

Now why would a vendor produce a package with this food for indigestion?
They do not look at the RPG code or the rules for the language.
BPCS runs on several platforms of which RPG on 400 is only one.
They write their code in a CASE LIKE tool called AS/Set, then compile
versions for the different platforms.
So the blame for this flawed coding is at least a step removed from
responsibility of vendor to read the programming manual.

BPCS V8 was just announced, rewritten in RPG IV, using the same AS/Set.
I have not yet heard if they have perpetuated the same flaw.

I fixed the problem in the Billing software, but there's other programs with
the volume of this just too overwhelming for me to fix.  I would think there
might be a market out there for 3rd party BPCS vendors to say

"If you have not modified this or that program, then we have a replacement
version that does not have this problem"

I recently looking at CST600 cost roll-up & CST900 actual cost update from
closing shop orders.  I only made 2 modifications.
1. the print file settings so spool file does not blow up.
2. the logical routings to exclude additional description lines which are
irrelevant to what these programs are doing

I currently have 2,000 items whose standard cost buckets do not add up
because of this CST600 bug, and about 10 items a month with negative standard
costs because of this CST600 bug.

We do not have a good enough handle on our actual costs to know how much
damage the CST900 bug is doing.

or I should say "bug nest" because there are so many places in the program
with the same flaw.

We do not have the $135.00 manual from UPI that is aimed at auditors.
Basically stuff that BPCS invites companies to do or interpret wrongly.
I would hope this topic is included in it.

----- the above is ONE example --- here is another -----

I have written an RPG program with embedded SQL that looks at 100% of our
inventory sorted by type of product, multiply by standard costs, subtotal by
type of product.  The veracity of these totals has been questioned a few
times, so I have added some extra subtotals, and drilled down to the raw data
& verified individual subtotals.  I am satisfied that the results are
accurate to the number of decimal places that I am using.  The program is
called CSTOPS because it is costing the opening balance inventory totals from
month to month.

We have had some concerns with the official opening balance for the month
changing in the middle of the month, and costs fluctuating more than is
reasonable.  This is not an IBMathics topic.  The reasons why this happens
are discussed fully in BPCS_L archives & are mainly due to another bug nest
in BPCS that permits people to post transactions to a closed fiscal period
without accounting being consulted, then BPCS rewrites the closed fiscal
totals without any audit trail.

Due to these concerns, I created a Query/400 called "Cost Big Picture" that
just does the grand totals of product type by facility that is the same
"math" as my CSTOPS program, but the totals are off by tens of thousands of
dollars between the two reports.  It does great catching when the opening
balance jumps.

Now I can write a CSTOPS variant that just does a totals only page consistent
with the original RPG program, but that's not the point.  My point is that
processing the exact same data through RPG as opposed to processing it
through Query/400 would generate significally different answers.  As an
enterprise, our people are heavily dependent on a lot of data from a lot of
different software rools

RPG SQL Query/400 Excel

Now I know from recent news that Excel produces different answers to the same
data depending on which version of Excel you are using.

I have suggested to management that the next time we have a financial audit,
that this topic be brought to the auditors attention, so that they can then
put a 400 programmer on the case & then tell management which computer tools
have what degrees of precision reliability.

----- as for IBM invoices -----

My boss is CFO & that job responsibility comes with a need to find places to
save costs.  On occasion he has asked me for ideas, and close to the top of
my suggestion list is that if we are not validating IBM billing, we are
having a bonfire with corporate funds that we cannot afford to lose.

He put all IBM invoices for the last 2 years in a spread sheet to match up
what we were paying for with what equipment we actually had.

The billing included duplicate copies of the same invoice (some pretty heafty
ones) in which we were billed for something, we paid for it, then a year
later IBM billed us again for the identical purchase.

I had approved payment of some of this.
Our process was flawed.
An accounting clerk brings me an invoice listing some license code or
equipment.
I check it out - sure enough, we have that, we need to pay that bill.
But this process is done by bill.
What we not realize is that IBM is billing us too frequently.
We supposed to pay maintenance on something for X months, which means that
bill should not come again for X months, but we had not been auditing that
fact & we should have been.

The billing included maintenance fees for equipment that we did not have any
more & we had notified IBM at the time of de-installation that it should go
off of maintenance support.

This kind of audit needs to be an on-going process.
It does not matter how many times you catch IBM doing wrongful billing & draw
it to their attention, IBM will continue to do wrongful billing.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
BPCS 405 CD Manager / Programmer @ Global Wire Technologies Incorporated
http://www.globalwiretechnologies.com = new name same quality wire
engineering company: fax # 812-424-6838

===== Prior Perspective =====

From:   Jeff.Bull@ITM-group.co.uk (Jeff Bull)

For those of you who are fans of The Hitch-hikers Guide to the Galaxy, you
should recall that particular branch of Math called 'Bistromathics'.  It is
a branch of maths which kind of explains why restaurant bills never seem to
add up, particularly when a group needs to pay for 'only what they've had'.
The more you break down the bill, the less accurate is the total.

I have suspected for some time that there is a similar but new branch of
Math emerging from IBM, I shall call it 'IBMathics'.  Topically, it is
evident on the WRKACTJOB and WRKSYSACT displays, but also in the Performance
Tools reports, and curiously it has infected IBM invoices.

Does anyone have any other evidence of IBMathics for the list to review ?

Jeff Bull  :-)