This, my friends, is very, very cool. DZ's Back Office is a huge FoxPro 2.6 application (several megabytes), and their distribution system for updates was via Xcellenet over dial up telephone lines using 14.4 modems. This makes for very slow and costly transfers and updates.
I analyzed the back office and found that it actually consists of several separate subsystems and a common interface. Looking at the pattern of updates in the past, it was also evident that usually only one or two subsystems were updated at a time, making it wasteful to send a single large EXE every time a subsystem changed.
On the other hand, it wasn't feasible from a control standpoint to leave the application as loose components and send only the changed program code. The reason, of course, is that Xcellenet transfers (at least ours) can be a buggy, and you'd wind up with only part of an application in place. Some kind of compromise was in order.
I split the back office into the common interface (which was an EXE) and several application modules (FoxPro APPs, similar to overlays). This in itself is common practice. What was different about this method was that the version and major and minor revisions were coded into the APP files, and each APP was encapsulated in a framework that enabled it to respond with the version and revision when queried by the common interface or by another APP. The version numbers were set up so that dependencies could be drawn between various APPs. This was superior to checking date-time stamps, since these could be changed in transmission, or inadvertantly by programs such as TOUCH.EXE
During startup the process went something like this:
The Common Interface (DZ) starts.
DZ queries an internal table to determine what APPs (including version and revision) it supports. APPs are ranked according to business criticality.
DZ reads the disk to find out what APPs are installed. For each installed APP, DZ queries the APP for its version and revision.
DZ now reports to the operator the status of the Back Office system. Based on its queries, one of several thing can happen:
The system begins normally. No warnings are issued.
One or more non-critical systems were not present or had improper revisions. The operator is informed of the problem and is instructed to call the Help Desk. He is informed that Operations can begin, but that the non critical system functions will have to be worked around until the problem is resolved. The system starts normally, except that the invalid functiions are not available.
One or more critical systems were not present or had improper revisions. The operator is informed of the problem and is instructed to call the Help Desk. Failure of the critical system prevents the proper opening of the Back Office software in that it can result in financial damage. The store manager is instructed to begin manual store operations until the problem is resolved.
This method of handshaking is structurally sound and resulted in a savings of several thousand dollars per year in telephone costs for updates, as well as improved response time for module development in that the modules were smaller and more clearly defined instead of being lumped together in a huge code pool.