This is one of several pages relating to the history of the automatic totalizator, its invention in 1913, the inventor George Julius and the Australian company he founded in 1917 which became a monopoly (later an oligopoly) in this field. This page documents the early mechanical and electro mechanical totalizator installations and the Brisbane computer totalizator installation. This is a history only non commercial page. If you wish to start from the beginning then go to the index .

Note - The Premier totalisator was the name given to Sir George Julius' invention.

Contemporary Note 2 - The installations above are documented up to 1937, probably because this document was created around that time. Julius totes continued to be manufactured and installed for a long time after this. If anyone has more information please email me at the address at the bottom of this page. Rio de Janeiro and Caracas are examples of latter-day Julius tote installations of the 1950s.

The Secretary of the Wellington Racing Club writes: "The Automatic Totalisator installed at Trentham has been severely tested during the last two years. The turnover has been exceptionally heavy, on one occasion 102,000 pounds being invested on eight races. It is safe to say that the public are well served, better than ever before, and they in common with the executive of the Club are satisfied that the machine is the best on the market at the present time."

The manager of the Rosehill Racecourse Co. Ltd., writes: "Two 'Premier' Totalisators are installed on the Rosehill Racecourse Company's racecourse at Rosehill, and were used for the first time on the 9th March, 1918. Since that date both machines have been used at all meetings held in connection with this Company, and have given entire satisfaction to both the betting public and the officials of the Racecourse Company. The machines have done everything claimed for them by the makers, and we have no hesitation in recommending them to any Racing Club."

Arthur V Kewney, the Secretary of the S.A. Jockey Club, Morphettville, Adelaide, S.A., writes: "I am directed to inform you that after a 12 months' trial the Committee are very satisfied with the working and the smooth running of the Premier Totalisator which your Company installed for this Club at Morphettville. The machine has fully demonstrated its capability to do all the work that was claimed for it. On Adelaide Cup Day the second time it was in use, the machine handled 36,668 pounds, and on the Cup itself 7,213 pounds 5 shillings was invested, both records for any one machine operating in this state.
Since the installation of the Premier Totalisator in May 1921, 13 race meetings have been held at Morphettville and 253,123 pounds 10 shillings has passed through the machine. "

The W.A. Trotting Association Perth reports: "The Totalisator Machine supplied by your Company has been running continuously on our Course since 29th January 1916. Your machine has proved popular with the public, and has given satisfactory results to my Association. The machine is the first of its type installed on any racecourse in Australia."

C.W.Cropper Secretary Australian Jockey Club wrote on 22 July 1922 "I have pleasure in stating that the "Premier" Automatic Totalisator Machines, which were installed at Randwick Racecourse and are operated by your Company on contract under the supervision of the Club, and which were first used at the Club's Spring Meeting, 1917, have, since their installation, given complete satisfaction. Their accuracy is unquestionable and the rapidity with which tickets are issued by the experienced operators leaves nothing to be desired."

The Secretary of the Wallsend Jockey Club advises: "This machine has been at work on our Course since Christmas, 1917, and has given the utmost satisfaction to my Committee and the general public. There has not been mistake or complaint as to correct workings since its installation, and we will be pleased to recommend your machine to enquirers."

The Secretary of the Newcastle Jockey Club writes: "I am directed to inform you that your Totalisator has given every satisfaction to my committee and its patrons."

The General Manager of the Canterbury Park Race Club writes: "The Automatic Totalisators Limited machines have been in operation on our Course, both in the Saddling Paddock and the Leger Reserve, at all our Race Meetings held since the 23rd February, 1918, and during the whole of that time they have given every satisfaction, no hitch or mis-working having taken place at any time."

Go back to the index    Go to the bottom of the page

The Brisbane Project

The Brisbane totalisator system first opened at the Gabba Greyhound track on Thursday 25 January 1979 and during the following four weeks five other installations were commissioned and 10 race meetings were conducted. Figures available for the first 28 meetings, showed an overall increase of 85% in turnover compared with the same meetings the previous year.

The Brisbane project represented two technical milestones for the company's computer totalisator design.

1. It was the first sell pay system. The predecessors were all sell only systems.
2. It was the first computer totalisator system, where the software utilised an operating system RSX11M

The Brisbane totalisator system was the first on course computer totalisator system for Brisbane and used to calculate dividends for the whole state of Queensland.

The ATL Sell/Pay Totalisator System for the Brisbane Metropolitan and Ipswich Racing Industry consisted of two Mobile Computer Vans ( semi trailers ), each van consisting of a twin PDP11 /34 based totalisator system. In each van the twin PDP11 /34 computers in the totalisator configuration operated in "Hot Standby" mode, the term referring to the twin operation of system computers that are effectively load sharing the transaction inputs with any one computer having the capacity to control the entire system. This concept is one that does not incur significant cost penalties and ensures the following: The loss of one computer has no effect or time loss on the totalisator operation.

All bet transactions were recorded in duplicate files held on separate disc sub systems. Each set of files was updated by a separate computer to reduce to a minimum the chance of data corruption of the same record in both sets.

Each bet transaction on file was identified by a Ticket Serial Number which contained a key to the location in the bet file as to where the bet record was kept.

Communications between the computer system and the J22 terminals was via serial asynchronous polled, multidropped lines.

The DMX11 was a microprocessor controlled multiplexer, which relieved the transaction processors from the overhead associated with communication protocol by polling each terminal on line in sequence, handling data messages between terminals and computers, performing error checks on every message received and transmitted.

The Queensland Racing Circuit had 165 J22 Terminals which were moved between five different venues, servicing Gallops, Trotting and Greyhound racing. The terminals were high performance dual communication ported, micro processor controlled and designed to operate within a computer based totalisator system. The micro processor was a Motorola 6800. Transaction details appeared on the operators alphanumeric display as they were entered. A versatile dotmatrix printer printed the details of the transactions including a computer generated unique serial number onto the tickets in alphanumeric and code form. The ticket was issued through a chute in front of the customer's display.

Winning tickets were fed into the terminal via a chute situated adjacent to the operators display. An opto-electronic reader scanned the bar code and transmitted the bet detail to the computer system for verification, the amount payable was transmitted back to the terminal and displayed to both the customer and the operator, the winning ticket serial number was cancelled, and all this was performed in under two seconds.

Computers were not widespread in Queensland when this system commenced operation and general knowledge of computers was yet to be established. At one of the early operations during a hot period, when it became apparent that the air conditioning was struggling, the suggestion was made "Hose it down". I protested No! No! not the water!

There was no shortage of incidents which appeared comical especially in retrospect. One of the engineering staff was removing his jumper in the operations end of one of the computer vans. He removed one arm from the jumper, then swung the jumper around to remove the other arm. As the jumper passed one of the control terminals a loud crack was emitted resulting from the static discharge. Hey Presto, another application hung and locked in memory. This was a problem in the days of sparse memory resources.

There was a large technological gap to jump, for the engineering staff who had to make the transition from the old electro mechanical system to the new computer system. This I always regarded as an impressive achievement and the magnitude of this achievement was never so apparent as on one week end when I supervised and assisted with some work on an old electro mechanical system. This system strangely enough was being installed as an interim measure to us supplying a computer system, at a new customer's track. This was my one and only experience with a live electro mechanical system. This was a relatively modern one, part of which was based on Uniselectors. One of the technical staff , mechanics as they were called then, indicated that the presence of a DC voltage at a ticket issuing machine had to be checked. As we walked to the ticket issuing machine I noticed that the only tool we had with us was a rather large screw driver. I presumed he had left his meter for measuring the voltage near the machine. When we arrived, the screw driver was promptly inserted in the machine and a spark resulted. My immediate reaction was "well that's torn it". The look of satisfaction on my companions face took a few seconds for me to comprehend. The test was successful!

I have seen many innovative solutions to problems, none as blunt as this one however. Sometimes applications would hang. At a meeting in the early 1980s at Ipswich one of the Race Day Control (RDC) applications hung rendering its associated console useless. Of course as Murphy's Law would have it, the problem manifested itself when the race that this RDC program was controlling had to be closed and selling was still enabled with the race running. This is a problem as someone could purchase a ticket with knowledge of which runner is likely to win or in the worst case knowing the winner. The engineer at this operation came under considerable pressure to stop selling on this location and race. After attempting some eloquent solutions in vain, in desperation he halted the transaction processors! Very effective, it stopped the selling on that race and every other race on every other venue and everything else to do with the tote as well. Although this sounds drastic and I have never seen any action like this before or since this event, the impact was not that great. A restart was performed after halting the processors. The recovery software checked to see if there were any races open that needed to be closed based on the current time having passed the scheduled race start time and then performed stop sell operations on any races found in this category.

Ironically one of the Race Day Controllers was a Catholic priest. He was very cool under pressure, which this system was not short on providing and he had a calming influence on the other Race Day Controllers. He became an unofficial leader. He was the most broadminded priest I have ever encountered. He was a delight to talk to and you could even discuss subjects like reincarnation and the possibility of extraterrestrial life with him without being regarded as a heretic.

A system is not complete without a Jinx. Ironically he was the most beloved of our managers . A man who managed with leadership and led by example. There were some crucial elements that resulted in the success of this project and he was one of them. The staff cherished and looked forward to his visits. The hardware and software celebrated his visits by excelling themselves in their misbehaviour. These strange coincidences were established over many years, to the extent that he would eventually steer clear of the computer systems during his visits, much to the disappointment of the staff working there. One day long after his retirement I had a terrible time during a Saturday afternoon meeting. We had three major problems the most impressive being a disk drive power amplifier board in flames. After it was all under control I staggered out of the computer van and uttered the words to my 2IC "One could be forgiven for thinking that ... was here". I looked up, he was there! Come to say hello and see how we were all getting on!

A computer system has a life cycle, and as the operational cycle starts a set of bugs are inevitably identified that no amount of testing seems to be capable of finding. As the operational cycle continues the incidence of these bugs reduces until a stage is reached where you think all the software problems have been attended to, bar modifications of course. Then just as you have become completely confident in this knowledge, an important application crashes after 6 years of operation. On this occasion I was amused to find that this bug had been with us from the start. A set of circumstances that took this long to eventuate.

I have always had a high regard for my mentors. I have had some excellent ones along the way especially at Channel 10 Sydney. But none have taught me more than the Engineering Manager of Automatic Totalisators . He was another leader by example and another crucial element in the success formula. During the initial installation he stayed at a hotel in the city. The system demanded full attention resulting in 7 days a week work being the norm and finishing at 2AM being common. On a few occasions the team managed to make it to his hotel room prior to midnight, for a bite to eat and a beer. His ability to lean back in a chair with his hands holding a glass of beer on his chest and catch forty winks without spilling a drop was famous.

I always enjoyed applying theory wherever possible. For example, on one occasion, one of the technicians asked for assistance with a fault he was having problems with. He had localised the problem to an op amp integrator circuit. We applied some calculus and determined that a constant of integration was missing. A zener diode in the op amp circuit was supposed to provide this offset. The diode was replaced and the circuit started to function. The technician was ecstatic.

The reverse side to the above later applied. As the number of component failures started to subside after several years, the major problem became contacts. Eventually this accounted for approximately 80 percent of all problems. The solution we devised was to disconnect all connectors and unplug all plug in components, spray the contacts with contact cleaner and reassemble. This procedure became so common that we named it Mumbo Jumbo due to the lack of any scientific analysis. A newly employed young graduate came to me one day rather dejected with the following concern. Do you mean to tell me that I have studied Thevenin, Norton, Kirchhoff, Boolean algebra, complex numbers and calculus ... and all I needed was a can of contact cleaner?

How does the axiom go? What goes around comes around! I spent a day with my eldest son who is now a student of these matters, we worked on propositional calculus converting logic expressions into disjunctive and conjunctive normal forms.

We have workplace health and safety now. We certainly could have done with some then. I recall several occasions, tottering on top of a barbed wire fence with a programmer around 2 in the morning, preparing to jump down outside the track, glad to have escaped the guard dogs again, thinking that when I joined this industry I never imagined that leaving work would be like this. This was our only means of exiting one of the tracks so late. There was no communications to the outside as telephones on course were illegal. Wives worried at home although I think eventually they became accustomed to it.

I had been working one day with one of the technicians on a large indicator board. He was an excellent technician and had been employed soon after the commencement of operation to increase the number of local staff with electronics capabilities. We were on the way back to our office when we came across a race horse with a jockey riding. Race horses are very temperamental. As the technician had been working at the race track for some time by then, I expected him to give the horse a wide berth. We were following the horse and I was shocked when he drove right up to the rear of the horse. I was about to utter "back off" when he hit the horn! Luckily the horse did not mind. The nicknames we earned for ourselves that day do not bear repeating. On another occasion, with another technician who was more horse wise, the opposite was true. We had to get through a gate with the car. The technician got out to open the gate and I remained in the car to drive through. A horse and rider had passed on the other side of the gate and the technician waited for them to reach a reasonable distance from the gate. He then slowly opened the gate which emitted a faint squeak. We were instantly treated to a bucking bronco show.

Go back to the index    Go to the bottom of the page

We used to have a security system. Two neglected firearms wrapped in a cash bag and carried around by a staff member. I used to wonder who would be injured if they were ever used, the target or the user.

A technician was having a disagreement with a programmer one day. The technician shared my stature, close to the ground, the programmer was the opposite. Frustrated the technician eventually strode off, fetched a bar stool, thrust it down in front of the programmer, clambered on top and announced "There, now I can talk to you".

Another technician, a true gentleman indeed , took a disliking to something that was said to him. Obviously angered, a unique event, he searched his mind for a damning reply. The word's eventually came, the worst he could muster "Be careful or I will go and get my big boots on".

At a hotel close to one of the tracks we serviced, they sold beer on tap stored in wooden kegs. This became famous within our company and interstate visitors would often ask to be taken to "have a beer off the wood".

The Brisbane Branch became well known within the company for its maintenance expertise. It ended up performing maintenance on the DMX11s for the whole company. This was a custom built 64 multidrop line multiplexer developed by Digital's special systems section specifically for Automatic Totalisators.

It is with some sense of loss, that one sees a system that one has nurtured so intensely for a decade, enter the decommissioning and disposal part of its life cycle. The consolation is that you are too busy with the new system to think about it. In retrospect, I spent considerably more of this decade with this system than with my family; The modules that were still used at other installations were removed. The semi trailers were sold, with the computer equipment remaining to be scrapped. One CPU box complete with contents was donated to the Power House Museum in Sydney.

I sometimes look at the remaining old spare disk drives, now an anachronism. They appear to be desperately clinging to the remnants of those bit patterns that represented those once all important transactions, recorded the last time they operated, oblivious to the fact that they have been unimportant for over a decade. It reminds me of how wasteful this industry is.

There always seems to be some competition amongst project members to have been associated with the most challenging and difficult of installations. We had some tote installation veterans on this project and they seemed to agree that this was it. I have thought long about what motivation lies behind a greeting from a programmer from this project, that I had not seen for many years, involving a hug that lifted me off the ground. I came to understand it recently when a 20 year reunion of the project team was suggested. Despite the fact that we had all gone separate ways, one of us having realised a life long dream of becoming a farmer and another in the process of realising the same dream, there was never any question of not attending. My understanding after the reunion was that this was the "life boat" principle. We did not share any life threatening experience however we came through a traumatic experience together, and I can only liken the result to the bond that seems to exist amongst those who have shared a crisis. The reunion was held at Coffs Harbour, a central location. The furthest anyone had to travel was from Canberra. One of the wives broke her leg prior to the reunion however this was no deterrent to attending. One of the Motel staff where we stayed two nights asked the question "If you people all used to work together, how come you get along with each other so well ?".

The next generation system in Brisbane was VAX based. With it came a new project manager, a well liked chap with a healthy ego. The embodiment of this ego was his car, a V8 Calais. As a passenger in this car and a pilot I quickly recognised his driving style to be more related to flying than driving. Whilst backing out of a parking space at Eagle Farm Racecourse one day he backed into a large old unyielding Moreton Bay Fig tree. The collision demonstrated the plastic parts of the car and taught some of the metal parts about yielding. Talk about a dented ego!

We have heard a lot of lines during the lifetime of the PDP11 system "That boat's gone", "We will cross that bridge when we come to it", "You are talking again you should be listening", "I never make decisions when I'm drinking", the one I found particularly amusing was "This job would be great except for the horses".

There was always a group of programmers that I have whimsically cast in the genus, genius. One of these programmers developed our new generation DMX, unlike its predecessor it was a diskless PDP11 based front end processor. The program was written in assembler and executed without an operating system. For those of you familiar with the "real programmers" sayings, he did not eat quiche. It performed its own memory allocation and deallocation, queuing, interrupt servicing and prioritising. The pièce de résistance was the state machine which kept track of the protocol on the many serial lines. Many will argue that there is an element of art in software. If we could draw an analogy to literature, I would describe this piece of software as poetry in motion.
He liked using a line editor. Commands were issued for everything. To correct a spelling mistake a command would move the cursor to the line number, another command moved the cursor to the character number yet another command deleted the offending characters then a command was issued to enter insert mode and then the correct characters could be typed.
He would work with three terminals at once with the keyboards end to end forming an arc in front of him. His hands would dart across the keyboards which gave the impression of someone playing an organ more than someone writing software. He usually wore headsets listening to classical music. A bystander could always tell when the point of peak creativity had been reached. His hands would take long vertical single fingered stabs at a keyboard and you would hear the utterances "PING" and "TING". Oh I almost forgot, he always wore boots.

Brian Conlon

Two of the most interesting maintenance areas were the phase locked loop in the disk drive read electronics, and processor internals.

The phase locked loop represented my first experience with the ECL logic family. The rest of the system was mainly TTL with some DTL in the tape drives. We later upgraded to MOS memory.

The processor internals was interesting as it usually meant working at the micro instruction level. On one occasion a processor was failing the power up sanity checks. By stepping through the micro code a faulty flip flop was discovered in the Bleg of the ALU.

Considerable work went into maintaining servo systems, particularly the tape drive capstan and reel motors. A lot of disk positioner servo alignments were performed. Many Unibus problems were rectified. It is ironic that after analysing so many Unibus problems, when we installed the next generation machine, VAX based central site, we received Qbus display panels. These were never used due to the increase in reliability. The display panels would only have been useful for a cursory check however, as many problems required dynamic analysis. The large Unibus cables that extended the Unibus into the expansion boxes were always a source of problems. It was difficult to keep them tidy and out of harms way and they always seemed to twist the wrong way at the destination requiring some fancy folding.

Something else that has disappeared is the machine code diagnostic maintenance loop. Often during the analysis of a problem the need would arise to produce a set of specific recurring signals in the hardware for monitoring with a CRO. Supplied diagnostics would rarely cater for such tight, specific and continuous loops, as it is difficult to predict what type of diagnostic loops are required for repair until a failure occurs and it is close to impossible to predict what is going to fail. These supplied diagnostics would identify a failing device or module and usually indicated an area within which the failing component could be found. Sometimes the supplied diagnostics could be configured to loop on a particular test which would produce signals suitable for identifying the faulty component. When this was not the case it was time to write your own loop. As you never seemed to have access to a development system with an assembler to write the diagnostic loop with when you needed one, it was written in machine code. We ended up with many of these fault specific machine code programs. They were toggled into memory via the console. Some pieces of equipment had recurring problem areas and after having recognised these repetitions, an assembler was used to write more extensive fault specific diagnostic tests. These reduced time to repair considerably. Look at a PDP11 machine code program

Talking about machine code, of those who knew the PDP11, will they ever be able to erase instructions like 112737 000101 177566 from their memories? I doubt it!

It is interesting to compare the 16 bit word length, 124K words of main memory 4K words I/O page, 50MB disk drive and 46MB tape storage with current figures. To give some idea of the level of integration the disk controllers consisted of 5 hex height boards. The dimensions were 15.6 X 8.4 inches.

The disk drives used the Modified Frequency Modulation method of recording which gave them a packing density of approximately 5600 bits per inch. There were 678 data tracks per surface, 8 heads and 3 platters. Maximum seek time 75 Msec average 38 Msec. The size was 7 X 22 X 19 inches weighing 65 Lbs. These drives were revolutionary with equivalent drives at the time being considerably larger.

The tape drives used Phase Encode recording giving a 1600 characters per inch packing density. They also were capable of Non Return To Zero Inverted recording method at 800 characters per inch for compatibility. The dimensions were 24 X 20 X 19 inches and weight 155 Lbs. Reel diameter was 10.5 inches and we used 2400 ft tapes.

The fact that the systems were mobile combined with air conditioning that did not cope well during hot periods, resulted in no piece of equipment escaping failure on multiple occasions. There was always something in need of repair. I think the most reliable pieces of equipment were the KSR33 Teletypes. When thinking of reliability an often overlooked piece of equipment is the test equipment. Our Tektronix 465 Oscilloscopes purchased in 1978 are still our prime piece of test equipment today 11 February 1998.

A significant improvement in the departments capabilities was realised after many years of operation, when we had appropriated sufficient parts to put together an additional simplex system. This became our maintenance system and for the first time maintenance could be performed without the fear of taking a retrograde step with one of the systems required for operations. This system went on to serve a second purpose. It allowed us to establish a development system and perform our own software maintenance. The software was written in Ratfor a structured version of Fortran. Once the software maintenance was established we had need of a tape drive for backup, as the disk attached to this system could be off to see active service any time one of the disks in the on line systems failed. We then needed to be able to restore the latest copy of the development system to the new disk once it was repaired.

We managed to acquire a TU10 tape drive and controller from the Sydney head office. This was a faulty drive that no one else wanted. It had not been used for a long time. It was a museum piece then. There are two types of faults that are more difficult to repair than others. These are compounded faults and intermittent faults and this drive had both. By the time we had it working there were 11 individual repairs logged in the maintenance log book. The first job was to acquire a vacuum motor, which was missing on the TU10. Another fault provided an opportunity to apply some of the theory mentioned above. The tape was moving at 61 inches per second in synchronous forward instead of 45, with the forward speed servo pot adjusted to minimum velocity. The output of the capstan tachometer was insufficient to bring the capstan motor speed within adjustable limits. As we could not acquire a replacement tachometer an amplifier was designed and installed to provide the correct level to the capstan servo master summing amplifier. After contending with the 11 faults we had our backup. I cannot recall any other occasion in my maintenance career when a piece of equipment had any more than 2 individual faults let alone 11!

Some of the software problems were quite interesting as were some of the interim solutions. On the opening night we discovered that the transaction processing task would occasionally enter an infinite loop. As mentioned above, this was when the disks stopped clanking and the Chief Programmer flew into action. This task would have to be aborted and restarted. Other tasks would have to be aborted and restarted from time to time for different reasons. The problem was that sometimes after issuing the abort command the task would end up marked for abort but the abort would not take place. The solution was Open, a utility that opens memory locations in the executive, for examination and modification. The interim solution was to determine the start address of the Task Control Block, then apply an offset to a status word. The status word was examined and modified to reset some bits leaving others unaltered. If you got it right the task would abort. This seemed like a very risky business however prior to the bugfix this was the only way out other than incurring the lengthy delay associated with a restart and as we know, people are not normally patient where money is involved.

When a failure occurred resulting in the need for a restart many transactions could be stored in the shared memory linked list that were not stored on disk. A program was quickly written to flush these transactions to disk. This however sometimes left the transaction files on both disks which were supposed to be identical, differing from each other. It was then necessary to manually cross reference the transactions in question to ensure that they were all recorded on both disk drives. These sorts of problems received top priority and were rectified as quickly as possible.

In the decade of operation, reliability improvements were achieved, however one never felt confident that you would conduct an operation and have a trouble free day. These improvements resulted from three events. First, the computer systems in both semi trailers were reinstalled, paying particular attention to cleaning up the mass of wiring which lay in a fairly hostile environment with many jagged edges inside the racks. Secondly, improving the air conditioning system. Finally the burn-in principle. I became a firm believer that systems underwent a burn-in period. Each time the system was subjected to higher temperatures the marginal components would fail. The more components failed and were replaced, the fewer marginal components remained improving the reliability. Each time we had air conditioning problems with the predictable component failures, the more robust the system became after the repairs.

One last note on maintenance. It has nothing to do with PDP11s however during the lifetime of this system I was sent to Boston to attend a course on VAX11/750 processor internals. These machines were being used elsewhere in the company and needed some in-house support. A language had been developed for writing micro code for this processor and we were examining parts of this, at the course, to familiarise ourselves with it. I knew the architecture of the VAX and when the lecturer started talking about writing to a particular internal processor register I asked the question "That is a read only register, why are we writing to it here?". The answer was quite obvious, "We are implementing that architecture with this code and the processor has to be able to write to this register at the micro code level so that the macro level machine code instructions have something meaningful to read from it". I instantly felt that I had walked through a proverbial door, I was no longer on the outside looking in at the architecture, I was on the inside implementing the architecture, looking out!

To complete the chronology of the on course tote systems in Brisbane I will make a quick observation of the VAX system and its successor. The VAX was a central site system. Work commenced on the Brisbane VAX tote project in 1986. A significant level of improved reliability was attained from not having to move the system from track to track. The job went from being hardware intensive to being software intensive. The Brisbane branch performed its own software maintenance and enhancement programming. This was done using Pascal and VAX assembler. We also assisted the Systems Department with overseas projects when their resources were being over committed.

We Installed a new system in 2003. Transaction processors, ticket issuing machines, display systems - all PCs. Spanning a quarter of a century we have gone from a technical staff of 10 permanents to 2. I have a good friend Brian. He is a check and training captain on Boeing 747s. When I asked him what he thought of the "new" 400 series, shortly after his conversion from "the classic" he replied that the operation was far superior. This was despite the loss of two crew members to technology, the flight engineer and the second officer. I feel the same way about our situation. Ironically I have never felt so "at ease" with any of the predecessor systems as I do with this one. The two staff remaining are myself, Brian, and you guessed it, another Brian.

I am going to allow myself the liberty of diverting here. Some moments, unknown at the time, become life time memories. This one has nothing to do with totalisators except that it is of a technical nature, aviation, and George Julius presided over the establishment of a Division of Aeronautics. There is a second connection described in the next paragraph. Brian, mentioned in the last paragraph, taught me a major part of what I know of aviation. In January 1972 during my ab initio training, prior to first solo, we were on climb out of Bankstown heading for the training area. I noticed Brian had craned his head forward and seemed to be intent on one of the instruments. I scanned the instruments in the vicinity of his fixation and could not find anything wrong. I looked at Brian to check the vicinity of the instrument panel that had captured his attention. Again I could not find anything wrong. I thought that any minute now I would be informed of what I had missed. When no words ensued I moved my head forward and looked back at his face. His eyes were closed! The words that eventually came related how hard the night before had been. I probably made more of this event than was intended however it left me feeling that I had been paid the greatest complement of all, he felt safe enough to have left me in command, for what was probably, albeit, a fleeting moment.

There is one more connection between the previous two paragraphs and totalisator history I will mention. The Boeing 747s that Brian was flying would have spent time in the Boeing 747 hangar at Kingsford Smith Airport. This hangar won an IES (Illuminating Engineering Society) Industrial Lighting Award for Julius Poole & Gibson and architects Stafford Moor & Farrington in 1973. Julius Poole & Gibson were also involved in the design of the operating mechanisms for the enormous hangar door.

Brian Conlon

• Information has been extracted from Automatic Totalisators company magazines and documents.
• Thanks to Matthew Connell from the Powerhouse Museum in Sydney for supplying an extract from the document "A Sound Investment for the Race Club ATL" which more than doubled the documented installations from my previous source.
• Thanks to Bruce Rutter for providing a copy of the company document "Straight Betting".
• Thanks to Ian my 11 year old son (1997) who was a great help with the typing, the html and the images.

Comments and suggestions welcome to totehis@hotmail.com

Previous page

Go to the index

Top of the page

Next page