×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
We have had several instances of a field getting populated with like all 9s
in the negative, off by a few digits.
Look in IBM RPG documentation ... how large can a field be ... 30 digits, 9
decimal.
BPCS uses fields of that size all over the place, and multiplies and
divides them.
Look in the IBM RPG manual where it talks about multiplying fields that are
of the same size as the result fields.
Basically, it looks like BPCS was programmed by people who were ignorant of
some basics of RPG, not making adequate provision for results fields, or
work areas when handling very large numbers, and causing us to get, in IBM
speak, unpredictable results, which are most likely to hit us with what IBM
calls extreme values like ONE and ZERO.
We have found this sort of mess from the "rounding" of unit of measure
conversion, where in our case the UM multiplier is ONE, the value being
multiplied is ZERO, and the result is SOMETHING ELSE, because the way BPCS
is programmed, IBM loses track of some of the numbers.
When we were still on OSG, I cited chapter and verse of this to SSA Tech
Support, identifying specific lines in several programs and faxing them
pages out of RPG Programming Manuals. Their Answer was that is the way the
program is supposed to work (produce random incorrect results). One of
the many reasons we not on OSG tech support any more.
We modified our Billing programs to not do this, so that our prices on
Invoices would be correct.
There is a related rounding bug in CST900 which produces negative actual
costs in the previous levels.
Well, this is interesting...
Yesterday, we had a batch of 56 invoices come out with negative numbers.
The numbers run from -938339 to -938394. The batch ahead ended in 938338,
and
the batch after began with 938395.
In reviewing BIL501, we discovered that if a field in the LDA referred to
as XEDIT is
set to a value of 1, BIL501 multiplies BINVN by -1, and writes that number
back out
to BIL.
Has anybody ever experienced this? Why on earth would one reverse the
sign on an
invoice number? What does it signify?
TIA,
--Chris
-
Al Macintyre (macwheel99@sigecom.net via Eudora)
Al's thoughts http://radio.weblogs.com/0107846/
See Al http://www.ryze.com/view.php?who=Al9Mac
Cure cancer. http://members.ud.com/about/
midrange.com
