×
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.
Joe Pluta wrote:
But seriously, let's try to fashion a scenario where one normal business
process could somehow cause another business process to fail.
You have a very large customer. Doing business with them means that you
accommodate them as much as possible. One of their quirks is that they
want condiments on a separate order, delivered to a different warehouse.
Your order entry now must ensure that if any item on the order is a
condiment, they must _all_ be condiments. No napkins or cups or
anything else.
The customer determines what a condiment is. Right now, the head office
deems condiments to be salt and pepper.
The purchasing agent calls you up and places an order. Salt, pepper,
cups, ketchup packets and pencils. Your order entry catches the cups,
ketchup and pencils and your order desk tells the agent that you need a
new order for that stuff.
The purchasing agent does her magic to generate a new, proper PO and you
cause the salt and pepper order to update/process. The purchasing agent
then gives you the new order of ketchup, cups and pencils. Your order
entry validates that all those items are non-condiments. While doing
that, the head office calls in and adds ketchup packets to the list of
condiments. They're talking to a different person, in another office,
completely unaware that one of the purchasing agents is giving you an
order at this moment.
So. Between validation (which passed) and update, the underlying RI
situation has changed. If your order entry program simply updates the
order without checking again, the customer will get an improper order,
delivery and invoice. Bad mojo, so you of course have validation in the
update cycle too. But there is still a window between CHAIN, validate
and UPDATE where the underlying RI situation can change as part of a
proper, normal process.
Most RPG programmers get away with not worrying about that window
because it's pretty small, and their transaction rate isn't high enough
to statistically expect an RI change occurring within that window. But
once you've had a multi-million-dollar customer chew you out for not
keeping orders/deliveries/invoices straight, you have a tendency to
avoid future problems of that sort.
No, I suppose commitment control isn't for every situation, but this was
a real situation. It was pure RPG (no SQL) and it was way simpler to
implement than any home-grown alternative.
midrange.com
