I found the code you referring to. It is BMR 17006. After you understand
what really went wrong, the role of member WORK in file FLT, & the purpose
of the code, you might want to reinstate it.
A CHAIN does not need to be a unique record for the purposes of BMR 17006.
There can be multiple records that match the CHAIN if your data is Ok.
There can be no records that match it, if your data is messed up.
The fundamental problem here is that BPCS is a good ERP but it is not God.
For it to work right, the human population has to behave rationally, with
full understanding of BPCS logic, but that is not realistic.
So we need a higher level of idiot-proofing than comes with the package.
Consider this scenario,
Person-A keys in a batch of labor tickets, does not take the batch to a
conclusion, goes off and gets some more to enter, or gets distracted by
other responsibilities.
Person-B finds a shop order that needs to be manually closed or deleted.
Person-B is not aware that there has been a labor ticket keyed in for that
order by person-A to a labor ticket batch that is still open.
At the time that person-A keyed in the labor, it was accepted, because at
that time it was a valid order. But now it is not a valid order, but it is
still in the labor ticket batch.
Person-A gets done with his or her distractions, is unaware that one or
more of the orders involved have been wiped out by person-B, then runs
SFC620 to post the batch of labor tickets, but now one or more of them are
on orders that are no longer valid.
The update run bombs when it gets to the point of trying to process the
labor tickets on orders that are no longer valid.
There are other variations on this scenario. They all can be avoided if
the number of people doing labor input and update is small, they
communicate with each other, they all use the same JOBQ, they know how to
check on the status of labor ticket batches that are not yet completed,
batches have short life span ... don't key the stuff in & let it sit
around. This includes shop order purge process. We should not be doing a
shop order purge if there is any data in the WORK member of FLT file.
In my nitely chores, I run a list of the contents of WORK member (it should
be empty when everyone done for the day), and list any orders in there
which are on gone shop orders ... I bring that to attention of Production
Control so that they can extract the data, before I kill the individula
booby traps, so the rest of the batch can be posted.
In our case we are doing JIT620 which has SFC620 embedded under the covers.
The software flags each labor ticket as it is posted. It does not flag the
inventory.
In our case we do not have an endless loop, rather the program gets hung on
an error message. I believe the smart move is to take the option to GO
AROUND the problem, so that we lose precision with the transactions on the
problem order, then afterwards make whatever adjustments are needed.
But what can happen, is someone who does not understand the problem, they
cancel the job, then try to restart it. So it processes all the inventory
transactions again, up to the point of crash, then history repeats. We have
had people do this several times before they go to IT and ask for help, by
which time we have tens of thousands of inventory transactions duplicated
and in need of repairs.
After successful SFC620 to a conclusion, all the posted labor tickets
should be gone from member WORK of FLT. You may have arranged for
perpetual storage of what was valid input before the orders got killed,
while labor input was in the works.
Assuming you understand the purpose of the code you modifying to try to
avert future disaster:
The program that updates shop orders ... perhaps an ARE YOU SURE message to
someone trying to kill a shop order when there is a labor ticket in the
works on that same order.
The programs that process labor ticket input ... perhaps a way to recover
short of a crash when hit input on an order that is no longer valid.
The program that purges shop orders ... perhaps prompt screen at the
beginning to warn user that there's unfinished labor posting batch out there.
Warning ... this code is incredibly complicated. I have modified it. It
was non-trivial (meaning challenging on steroids).
Al Mac
405 CD nerd
Does your company use a programming standard that makes it possible to tell
the difference between your company modifications and that which came from
SSA?
We too have found a great many bugs in BPCS, but not all of them came from
SSA.
Al Mac
BPCS/405CD modifier
> > We are using BPCS 4.05 CD PTF1. The last mod to program SFC620 was
> > 24128 09Apr97. This program ran into an endless loop in our
> > production environment.
> >
> > This endless loop seems to have been introduced on 07Aug96 (mod 26JL6)
> > when two FLTK04 CHAIN IPF600LT commands were added at lines 1191 and
> > 1194.
> >
> > Unfortunately, the key being used in these chain commands is not
> > unique, which caused the endless loop.
> >
> > Commenting out the two chain commands seems to have rectified the
> > problem.
> >
> > If you know of any similar bugs in BPCS 4.05 CD PTF1 please let me
> > know.
> >
> > Thanks in advance.
> >
> > Peter Lunde
> > Manager, IT
> > WellSpring Pharmaceutical Canada Corp
> > 400 Iroquois Shore Rd
> > Oakville, ON, L6H 1M5
> > Phone: 905-337-4505
> > Cell: 416-948-5863
> > Fax: 905-337-7239
>--
>This is the SSA's BPCS ERP System (BPCS-L) mailing list
>To post a message email: BPCS-L@xxxxxxxxxxxx
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
>or email: BPCS-L-request@xxxxxxxxxxxx
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/bpcs-l.
>
>Delivered-To: macwheel99@xxxxxxxxxxx
--
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.
Delivered-To: macwheel99@xxxxxxxxxxx
midrange.com
