AUSTRALIAN ARMY MAINTENANCE MANAGEMENT SYSTEMS
The Background to MODERNISEThe Royal Australian Electrical and Mechanical Engineers(RAEME) were the first in the Australian Defence Force to obtain a mainframe computer system for the purposes of collecting statistical data they thought would be helpful in guiding management decision making. This system was introduced in 1969 and was called MODERNISE. It ran on a Honeywell Mainframe. By 1980, the rest of the Defence Force had caught up. New mainframes, in the form of UNIVAC, were being introduced into service and this necessitated the transfer of the MODERNISE system across to the new environment. To save money, Computing Services Division insisted that there be no enhancements to any systems being transferred.
Posting to DGEMEIn 1980 I was promoted to Major and appointed to be the Staff Officer Grade 2 (SO2) in charge of EME Systems Development. Prior to this posting, I had been in charge of a Workshop Platoon servicing all of the units in the Australian Capital Territory, a major dependent unit being the Royal Military College and the various Defence Headquarters. I had come to the attention of the Directorate of Electrical and Mechanical Engineering because I had developed a Trade Repair Accounting system, written in FORTRAN 77, to run on a DEC 7 mini-computer at the Faculty of Military Studies, Duntroon. This system facilitated management of the workshop's financial ledger and reporting all contract repair activities to the 2nd Military District. (Click here for more details)
The Personalities at DGEMEI reported to a Staff Officer Grade 1 (SO1), Lieutenant Colonel Mike Burgess. Mike was a jovial person who knew little about computers. His expertise was in super-hetrodyne radio receivers, a subject he had previously taught at the RAEME Training Centre Bandiana. Because of this I was left pretty much alone to develop things as I saw fit with Mike supporting me wherever he could; particularly in the area of crafing staff papers. Assisting me initially was Warrant Officer Class 1 Warren Wilde, an experienced and competent Warrant Officer who was also an extemely decent person. After about a year Warren was replaced on posting by Warrant Officer Class 1 Spike Wiseman. Though a different personality to Warren, Spike was an excellent and supportive assistant. In my previous posting at ACT Workshop Platoon, I had come into contact with an exceptional soldier, Stevan Vujovic, an ex-apprentice who had gone on to do a degree in Physics in his own time. I recommended Stevan for Officer training and, after graduating from the Officer Cadet School, Portsea, he spent time supporting me as a 2nd Lieutenant at EME Systems. Stevan knew a great deal at the practical level about computing and communications, having previously been trained as a radio technician. Stevan and I both shared the view that the future lay in small systems.
The Advent of Personal Computers - and the Vision of Small SystemsThe vision concerning the need for small systems was simple. Small systems had the potential to help people perform their duties in the workplace. By providing this support, users would have a vested interest in ensuring the information being input was complete and accurate. Not only would these systems materially benefit quality and productivity in the workplace, they would provide every possible detail required by any database system being used by senior management for high level decision making. There would be other benefits as well. Should communications be cut, these small systems would continue to provide useful service to the workforce. Additionally, the detail of transactions in the workplace would not have to be sent back to a central database; only the summary information. This would improve security and reduce the amount of data that had to be transmitted.
The Computing Services View regarding Small SystemsAt that time, small, semi-portable "Microprocessors" as they were then called were beginning to make an impact. These later came to be called "Personal Computers" or PCs by IBM. Computing Services Division considered them to be play-things, distractions from the "main-game". In 1979, I was in charge of a workshop platoon at the Royal Military College and I tried to obtain a Hewlett Packard Microprocessor with a "massive" 64 kilobytes of Random Access Memory. I remember Richard Fullford (an officer who later took over from me at Systems Development, DGEME) telling me this was excessive. (I'm sure Richard would cringe if he remembers that for he went on to do an excellent job in System Development!) I intended to use this desktop computer to run a program that would help my staff manage contract repair accounting. Even then, I saw the need for graphics and appreciated the demand these would make on computer memory. Despite writing countless submissions, there was no way CSD would agree to my obtaining a desktop Microprocessor based computer! When I arrived in DGEME, I encountered the same prejudice by CSD towards Microprocessor based systems. They believed these systems would never compete with mainframe and minicomputers in the near term. In order for small systems to be effective there had to be a means by which they could exchange data with other systems and, if necessary, be connected by cable to these systems. I saw possibilities in using small systems to pretend they were the computer terminals of mini-computers such as those used by MAWD in base workshops or SCUBA in Supply Battalions. In doing this, it would be possible for the small system to appear to these mini-computers as if it were a person operating the terminal and be able to input through the transactions that existed on the mini-computer any amount of data the small system had collected. Using the existing transactions on the mini-computer had a number of advantages:
Small Systems - The Trading Post ExperienceIn early 1981, Stevan and I visited the newly formed "Trading Post". This was a paper that specialised in selling second hand articles. It cost nothing to place an advertisement in the Trading Post but sellers were expected, on successful completion of the sale, to pass a percentage of the proceeds back to the Trading Post. The Trading Post was founded by an ex-Navy officer called John McAllery. The idea of not charging for the advertisement was novel but the novelty of this operation did not end there. It was the first newspaper in Australia (and possibly even in the world!) to be completely computerised from the time the telephonists took the details of the product to be sold from their customers to the printing of the paper. Everything was done using Z80 based microprocessors running the MPM operating system; the various programs that helped were written in BASIC. So much for Microprocessors being "play-things"!
The Ineptitude of Senior Defence Computing ManagementIt was interesting to me as a comparatively junior officer to note that the people working within CSD at the lower levels were eager to please, talented, frustrated with senior management and, above all, hardworking. The problems with CSD resided with the senior officers running the organisation. In a number of instances, these officers were in CSD because they saw it as a means of pre-discharge training. Their scheme was to make the necessary contacts in the EDP industry to find a well-paying job on "civvie-street". Others, having not done well in their chosen profession of arms, sought promotion by insinuating their way into CSD. Whatever the reason, CSD seemed constantly incapable of making a correct decision at the strategic level. At a time when mini-computers were being produced with compilers that would allow programming in high level languages such as FORTRAN, COBOL or BASIC, they purchased Perkin Elmer computers that could only be programmed in a language called "Common Assembly Language" (CAL). The consequences of this meant that programs took much longer to write, had a very poor user interface and were much more expensive to produce. It is possible that CAL was very efficient in its execution but high level languages of that period generally supported compiler instructions which allowed the execution of "inline" assembly code wherever there was a need for extreme speed. The choice of Perkin Elmer over other similar mini-computers, such as DataGeneral, that did support high level languages, put computing in Defence back around 10 years until Army insisted on obtaining PRIME mini-computers and operating them within its own organisation.
Interfacing with Supply SystemsOver the two years, I worked closely with a team of Ordnance officers involved in the development of a new family of Supply Systems; our working relationship becoming very close as we fed off each others efforts. Like me, they encountered nothing but stubborn resistance and a complete lack of cooperation from the senior management within Computing Services Division. I had found that the provisioning formula in the Ordnance Supply Manual, called "PAM 4", was mathematically incorrect so I rewrote it, much to the delight of LTCOL David McLachlan (later Major General McLachlan) who commented I should have been a supply officer. The Supply Systems people, like myself, saw the future in small, portable hardware running stand-alone applications, focused on serving the needs of the workplace. At the time, they were working on a microprocessor based system called DICVAS, standing for Divisional Inventory Control, Visibility and Accounting System. In took until 1996, 12 years after EMEMic was commissioned, for EMEMic to be interfaced with DICVAS such that parts requests filled out on EMEMic could be sent electronically to DICVAS. The reason for it taking so long for these two systems to be able to exchange data may be found in self-interest, internal politics and a senior leadership devoid of imagination and technical competence.
The Birth of AutoQIn the bottom of G-Block, there was a Wang 2200 MVP mini-computer operated by an Infantry Officer called Captain David Barclay. The purpose of this machine was to hold all of the Army's establishment data. One essential aspect of military administration is to be able to create what is called a "Capital Equipment Discrepancy List", a CEDL. The structure of any unit both in terms of its manning and its equipment (materiel) is determined by a document called the Establishment. The Establishment Document is called an "Entitlement" document,ie, it lists everything a unit is entitled to hold. The CEDL is created by comparing that which a unit is entitled to hold against that which it is actually holding. I impressed on the SSRP that if Defence provided its Q Stores with a microprocessor that assisted staff manage the stores, then this application would list all of the items that were presently being held. In a similar vein, if the unit orderly room had a microprocessor-based application that helped them account for personnel, this would provide a listing of all of the personnel positions, those that were presently filled and the qualifications of the personnel filling them. I called the Q system AutoQ and the personnel system AutoPers. By these two systems periodically passing up their data and this data being compared to the establishment data held on David Barclay's Wang, it would be possible to automate the production of the CEDL. AutoQ became a reality. AutoPers never saw the light of day and even today, personnel management within the Army is very poorly handled at unit level. Units have no computer systems help to do something as basic as mark the daily roll for example.
What happened?!!By the time I left DGEME, the specification of EMEDATER was complete and a CSD team was well underway developing the database schema and writing the code. Also well on its way was the development of EMEMic. This project was to be executed at ACT Wksp Platoon by a team of two programmers working in close cooperation with the workshop staff. All up it cost around $300,000. EMEDATER came on line in 1982. It cost less than $2 million to produce. AutoQ was introduced into the Army sometime after 1982 and DICVAS became a reality thanks to the efforts of my friends and colleagues in Supply.