Re: BPCS V404 ORD570 Order Confirmation -- BPCS-L

From Al Macintyre V405 CD

How long have you been operating on V404 as a company & is this a relatively 
new problem, or something you just noticed & narrowed down to this cause?  
You might also check the BPCS_L archives.  I seem to recall that other people 
ahve reported inconsistent random problems with customer orders experiencing 
weird glitches in which various people tracked them down to particular 
programs.

There are actually several steps to shipping ... pick confirm ... and woe 
betide you if you do them in the wrong sequence.  There are many 
opportunities for human error.  This process is not exactly user friendly.  
It could be human error that is causing your problems, especially if the 
people hired for the shipping department were hired for reasons other than 
their computer interfacing skills.

Does anyone do any validation that the totals they get from BPCS are correct?

Like total cartons out the shipping dock to various trucking companies vs. 
total cartons BPCS says went out the door & billed to our various customers?

It seems to me that there is an enormous volume of people trying to do their 
jobs & the suspicion of bad data various places ... how do we know the total 
dollars this place or that place is in fact the correct figure?

Since you are not on an officially Y2K fixed version of BPCS, could you tell 
us what you did instead to survive?  There were literally thousands of fixes 
that I saw after base 405 CD that were date related.  Something was done to 
make your V404 survive-Y2K, or you did a typo & you really referring to V606. 
or V604 or something.

What I am hinting at is that you cannot possibly be on a vanilla unmodified 
version of BPCS if in fact you are V404.  You either must have used one of 
the 3rd party outfits out there to make your V404 work through the Y2K 
distraction, or you are using ridiculously low volume of total BPCS modules 
... like no inventory, no MRP, no shop orders.

I am assuming that V404 is very similar to V405 CD ,,, we never ran on 404 
... we came from BPCS/36 ... in any case, our shipping creates a "B" record 
in ITH & a related record in BBL from which we get the Billing.  Are you 
saying that you do not get an ITH record, or that you get one but the values 
in there are not correct?

We have some legitimate zero price records related to inter-facility 
shipments that go through our system as a re-supply order.  Now we do have 
some internal company politics problems due to purchasing dept insisting on 
copying resupply requirements as purchasing requirements for convenience of 
their reports, and then recieving resupply against purchase orders, so the 
resupply never gets relieved, but we have been able to narrow down the cause 
of zero times one equals 0.001 to BIL522 where it does the unit of measure 
conversion without a big enough work field for RPG, which I consider to be a 
systemic problem all through BPCS.

In other words, RPG has a maximum size of numeric values of 30.9 (30 digits, 
9 decimal) and many BPCS fields are pushing that size, and they multipliy & 
divide each other such that there is no space for the numeric overflow.  Now 
the RPG manual will tell you that unpredictable results come from mathematics 
in which the work field is too small to contain all the digits required, like 
trunctation in a calculator not to enough decmal places only worse because 
the program loses track of where it was in the math, but RPG is not big 
enough for BPCS to do straight multiplication & division on many fields.  

There needs to be some more involved calculations to handle the numeric 
overflow, but SSA programmers have not yet aquired that skill, and besides, 
the definition of field sizes is so far removed from the actual math that it 
is non-obvious when fields are inappropriately sized for the operations.

I am amazed at the code that has been accomplished here ... how many million 
man years of programming does BPCS represent ... but there are some patterns 
of programming practices that are asking for trouble.

My management has not seen fit to make AS/Set available to me & I predict 
that if your programmer does not have AS/Set either, then 4 weeks is an awful 
short time ... allow for perhaps 4 years to solve this problem due to the 
sheer size of ORD570 & the nature of the "source" code generated by As/Set.  
ORD570 & ORD500 are two programs that I have had to give up trying to debug 
without As/Set.

Al Macintyre  
Programmer & etc.

>  From:    SavoyG@troycorp.com (Savoy, Gregg)
>  
>  We are experiencing significant problems with Order Confirmation.  The
>  problems are inconsistent.  Our shipping person runs ORD570 several times
>  each day (start and stop).  It appears with each "batch" there are shipped
>  lines that are not costed nor updated to the ITH file.  In addition, we 
have
>  had zero cost updated inconsistently either from this problem or another.
>  Based on our research this problem has been occurring since the system was
>  installed.  These programs are "vanilla" except for Bill of Lading layout
>  changes.
>  
>  My programmer has been debugging this program (and its called programs) for
>  about 4 weeks (he is interrupted several times each day) but he has not 
been
>  able to identify specifically what is causing the problem.  
>  
>  Can anyone provide some insight into what might be at the root of the
>  problem?  It appears this problem is in the base code so others must have
>  encountered it.
>  
>  Thanks,
>  
>  Gregg E Savoy
>  Director Information Technology
>  Troy Corporation

+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---