The Acme Co.'s "Priority Dispatcher" is one of the most interesting transportation / distribution programs I've ever seen - not so much for what it does (which is impressive but of such limited application that only a hand full of firms could use it), but for what it could (with a few modifications) do.

What Priority Dispatcher does is set up, configure and schedules loads of automobiles being hauled on double-deck trailers used for that purpose (you've probably seen them along the road or parked at car dealerships). There are several different designs of such trailers, each with its own loading characteristics, capacities, etc., and Priority Dispatcher can deal with any or all of them.

The software was designed for a British auto carrier (named Silcock Express, if your interested) which was serving dealerships throughout an area surrounding London. Silcock's auto manufacturer / distributor customers needed to minimize their dealership's order-response delays, while Silcock itself wanted to improve productivity in terms of (1) trailer loading configurations, and (2) routing. Priority Dispatcher allows all tree factors to be balanced according to user-established priorities.

The version I saw run placed primary emphasis on order response-time. Dealership orders (whether for customers or "floor-plan" cars) were logged into the system as received, and dated. On any given day the program was instructed to fill the oldest orders first unless that would result in extreme loading and / or routing inefficiency. Alternatively, however, you emphasize optimal loading patterns, or least-cost routing configurations, with a fairly simple menu-driven series of commands.

Before you start using the system it's necessary to spend a fair amount of time creating a model of your geographic distribution network. To start with, your origin point (a separate model must be built for each separate origin) and every destination you intent to serve must be identified in terms of both name and longitude / latitude coordinates.

Using longitude and latitude for geographic location purposes is, of course, a less then precise method of handling highway routing decisions, since they produce as-the-crow-flies routings which won't always comport with the road network you're using. Priority Dispatcher allows for this by letting you build "barriers" into your geographical model, across which the software is prohibited from constructing routes. It would take a bit of practice to get use to the way this works, but once you did it would give you all the capacity you needed to avoid circuitous routings dictated by the longitude / latitude approach.

It's a unique (in my experience, at least) but eminently sensible, approach to the routing problem. Other routing systems I've seen entail laboriously inputting information about the actual highway network, road by road (or for city-delivery applications , street by street), and then identifying origin / destination points according to where they "intersect" that network - a laborious process that, moreover, consumes massive amounts of both data-storage capacity and, to access it, computer memory. You need a big machine to run such a system (most of the ones I've seen aren't usable on any microcomputer, and the actual "run time" is quite long

Priority Dispatcher not only runs on a standard IBM-PC or compatible (although you have to add the number crunching 8087 board in one of the expansion slots), but does its decision making in a matter of seconds. To be sure, the results aren't quite as precise as offered by the road / street-mapped programs; but with judicious use of the "barrier" option they need not be far off at all-and I expect the simplicity of setting up, and / or making alterations to, the basic geographical model would more then compensate, in most applications, for any slight sacrifice in routing optimization.

Each car order is identical in the system by a letter which represents a different size or configuration of automobile; thus, "A" might stand for a sub compact car, "B" for a compact, "C" for a station wagon, etc. This is necessary because the racks of car-carrying trailers can only accommodate certain sizes and shapes of vehicles in particular positions and / or with particular loading configurations. (The trailer limitations must also be specified, although most commonly used trailer standards are already built in).

To start the day's operation, the user advises what trailers, of what types, are available at the origin. The software then scans the file or unfilled orders and, based on the user-selected priority scheme, advises which cars are to be loaded aboard which trailer, so the assigned cars will fit, and the rout each trailer is to take to get to the dealerships to which the cars are destined.

At the conclusion you can "page through" displays showing this information trailer-by-trailer, or review the entire computer-generated operating scheme as a whole. You also have unlimited opportunities to make manual changes in what Priority Dispatcher has recommended, with the program giving you a running update as to how your changes have affected operating costs.

If you prefer, you can also limit the program's run to particular groupings of destinations (labeled in the software as "zones"), if you want to restrict the movements of your highway equipment.

In terms of "user-friendliness", Priority Dispatcher is less impressive; it was clearly designed for users who would be come familiar with its intricacies through running it almost daily. In some cases, the command structure is poorly documented, or even undocumented, on-screen; and the command menus are not always clearly helpful. Input / output screens displays, while adequate once you get use to them, are likewise parentally confusing to the new user; and the limited graphics used to show load configurations and routings can charitably be describe as primitive.

On the plus side - the very plus side, as I see it - Priority Dispatcher's output is maintained electronically in data files compatible with the popular spreadsheet Lotus 1-2-3. Thus, if your dissatisfied with the particular reports Priority Dispatcher allows to print out, you can simply use Lotus to produce the reports (complete with any requisite calculations) you happen to want. The value of such data compatibility with a mainstream general-business software package such as Lotus is so obvious, and so great, that I continue to be astonished most specialize software developers don't allow for it; but I've only seen a handful of transportation / distribution programs which let you manipulate their output data in this simple way.

As I wrote at the beginning of this review, Priority Dispatcher has only limited applicability in its present form; there are, after all, only a handful of motor carriers handling enough new - car movements on highway trailers. But the potential to modify the basic design to accommodate other types of freight and transportation equipment - or even to eliminate the loading module entirely and use it just for peddle-run routing-is obviously immense. I discussed this briefly with a representative of Acme, and was told that the reprogramming such changes would require would not be extreme.