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

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.