Re: Exit point programs

While there may be an infinite number reasons to use and Exit Point program
but a most common use is to provide either or both of the following.

1) a pass/fail filtering on the properties of the calling program or calling
user.

2) a more every day use is something that should be available in more
software and that is the ability to allow the organization using vendor
software to define and execute its own additional editing of data keyed on
entry screens.

We do the latter at some critical points in the software we write and
support. We also provided the ability for the Exit point program to able to
ADD displayable data on the screen which is the next logical screen in the
flow.

An example would be our application which provides information to a
proprietary database about certain products, this information is not part of
a users own database, but the user would like their own quantity on hand and
pricing to appear on what are our generic screens. We allow the customer to
modify the rightmost 40 characters on the screen of certain screen record
types.

In fact our whole application is essentially an exit point program that is
called from within a users own Point of Sale system or back office phone
ordertaking system. Our stuff is called by and calls exit point programs.

I've added stuff like that to existing software but it really isn't anywhere
near as flexible as when the flow of the exit point software is designed
into and BEFORE the main application itself.

This is a great way for a vendor to partially isolate itself from having its
programs modified so that the customer can not stay current with releases or
having to take customer support calls from programmers who have screwed up a
huge program while trying to add a simple custom tweak. I've been on both
sides of that fence myself many times and that is why I put exit programs in
plenty of spots.