In order for this site to work correctly, and for us to improve the site, we need to store a small file (called a cookie) on your computer.
By continuing to use this website, you agree to our cookies and privacy policy.
Home page Home page Home page Home page
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel

The Programmer's Exchange (PX) - A Review


If you've ever had to produce an update diskette for a remote system and found yourself struggling to remember which programs have been changed and which indexes have been added, then PX could be the utility for you. It's one of those "I must write one of these myself" tools that you somehow never seem to find the time for. Now Harmacek Data Systems have done the work for you with a utility which has been tried and tested in the field and proved to be so useful that they've now decided to share it with the rest of us (for a small cost, of course...)

Product Description.

The Programmer's Exchange is a tool which tracks amendments to any file in an AREV application. It has two main components: firstly, an MFS which is placed on all files to be monitored (including dictionaries) which generates audit records whenever a write or delete operation is encountered; and secondly, a suite of programs which allow a transmission file to be created from the audit of changes. This file can then be sent via diskette or modem, and is uploaded by another process at the remote site, applying the changes automatically. During the upload process, indexing information can be ignored simply by setting a command line flag if required.

Other features include the ability to report on transactions already held, and to toggle the auditing MFS on and off. Since this is achieved using TCL commands (e.g. PX SUSPEND) it can easily be interfaced with any R/Basic programs.

Installation and Use.

PX comes on a single diskette, and it has a comprehensive user manual provided (in fact, given its target market it's almost too comprehensive in places). The manual is generally helpful and easy to follow, although personally I would have put the large bold-type warning message about not using the DOS copy command at the beginning instead of tucking it away on the last page.

The installation is composed of two phases. Firstly, the software is loaded via a simple collector window process. Since PX is designed to work across accounts and applications the installation process defaults to the VERBS and COMMANDS files, although this can be overridden if required. I found only one glitch during this process when a W504 error message (The DICT.PX file on the REVBOOT volume is not available...) appeared. After acknowledging the message, the system recovered of its own accord and carried on to a successful completion - or so it appeared.

The second installation phase is to apply the MFS to all the necessary files in an application. N.B. PX does not itself order the MFS chain if other MFS's are already present. The manual provides step by step instructions on how this can be achieved, but it necessarily assumes that the user will know the implications of ordering certain MFS's in certain ways. Again this process needs to be repeated once for each application. A collector window allows the user to select a volume and file list. Judicious use of a pre-tagged multiple selection popup to highlight dictionary files and system program files makes this process very straightforward indeed. However, another annoying (and avoidable) glitch soon detracted from this friendly feature - the help associated with the MFS window didn't work. Pressing F1 leads to a "HELP*2 is not an argument for MFS.SUB" error message. A quick analysis of the source code (yes, most of it is provided) soon identified the offending line (CASE ARG[1,5] = "HELP" - work it out for yourself), but it might be argued that a little more testing before release might have avoided this one! Certainly on the fourth prompt where the offending error ("MGS.SUB cannot be executed...") is down to a simple spelling mistake, we have a right to expect better after shelling out our hard earned shekels.

However, having said all this it must be emphasised that these are only installation errors, and the actual package itself works like a dream. Once it's installed you would never know it was there. The MFS quietly audits entries, amendments and deletions to programs, templates, popups etc..., it tracks new and amended dictionary items including symbolics, and picks up changes to the indexing via the dictionary item flags. The audited information is held in the PX file and can be examined at any time.

Transmission of data is achieved by the command line utility PX (unfortunately there is no source code for this one). E.g. PX TO A: creates transfer files, while PX FROM A: would import someone else's transfer files. The manual suggests that this is very much a two way process - changes from one site should be transmitted to a second site, then changes from the second site should be transmitted back to the first site. While some people doubtless work this way in practice, it would be very dangerous to attempt this sort of update using PX as there is NO contention logic in place. Instead of getting one unified application at the end you could easily end up with a worse mishmash than you started with whenever the same record has changed in different places! In practice it is better to make changes on only the master system for distribution to remote sites, but, caveat user!

As PX currently stands (version 1.0) it must be installed on both master and remote sites, which leads greatly to temptation to use it as a two-way process. A nice feature would be for the PX TO process to create its own upload program when it makes a transfer. This would mean that PX would only ever have to be installed on the master site. Over to you Dave... (Added in latest version - Ed)

Other PX command line options are to list current transactions, and to suspend and resume auditing. One minor gripe - where such lists are presented the report viewer is not used! It's just like being back in G2B (much loved then, but not missed now), and I hope that a generally excellent package isn't going to be judged too harshly on its failure to provide a consistent AREV interface.


The package overall should prove invaluable to the serious developer responsible for maintaining distributed systems. The few blips found were solely in the set-up and interface processes, which show some signs of having been cobbled together quickly to get the in-house package onto the market. They are, however, fortunately minor, and I know that they are already being addressed for the next release.

If all you care about are changes to programs (BP, TEMPLATES, POPUPS etc.) then you probably don't need PX; it is just as easy in practice to transfer the entire program volume. (Unless you're one of those unfortunates whose application was entirely developed in SYSPROG and REVBOOT, in which case PX is more of a necessity than a luxury!) The real strength of the package however, lies in its monitoring of changes to a dictionary, allowing changes to symbolics to be traced effortlessly, and also making the remote maintenance of indexing a delight rather than a chore.

Given a certain Mr. McAuley's reliance on odd scraps of paper to track system enhancements (qui, moi? - Ed), suffice it to say that PX is likely to become a valuable addition to the Sprezzatura software library !


PX has been tested in versions 1.16,2.03, 2.11 and 2.12 for DOS ONLY. Its transfer process relies heavily on the OS suite of commands, and it is not yet guaranteed for the OS/2 or UNIX versions of Advanced Revelation.

PX is available for $139 from Harmacek Database Systems, 11 Grant Road, Winchester, MA 01890-1016. Telephone orders may be placed at (617) 721-1452, FAX via (617) 721-4656, CIS [73750-1044]. MasterCard, VISA, and corporate purchase orders are also accepted.

(Volume 4, Issue 3, Pages 4-6)
Pixel Footer R1 C1 Pixel