|
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 :-)
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.