John McEneaney started working on computer systems soon after Aer Lingus hired him in the 1960s. He remained in technical roles throughout his career, progressing from programmer to technical adviser to IT consultant.
He gained his first programming experience on the IBM System/360 mainframes that ran the airline’s passenger reservations system and were, at that time, the largest computers installed in Ireland.
I started in the central reservations / reservations control section of Aer Lingus two days before my eighteenth birthday in 1964. At that time, airline reservations was an almost totally manual process, passengers interacted in public offices or on the telephone and back-office functions used inventory summary cards – one per flight/date. The booking offices and telesales staff hand-wrote the reservations transaction on punch cards, which were then passed to ‘Central Res’ via a multichannel conveyor belt, which ran the full length of the office in O’Connell Street, Dublin. My role – as a basic Grade 4 clerk – was to assign a seat space to each new reservation or free it up for cancellations. Once the flight inventory card had been updated, the passenger data cards were punched on Powers-Samas unit record equipment. (To my provincial ear, this sounded like ‘Par Sams’!) The process was slow and labour-intensive, but it worked!
At the end of 1964 or early in 1965, Aer Lingus moved Central Reservations to its new head office block at Dublin Airport and in March 1965 I moved to the systems department, as a ‘console operator’. Tom Clerkin, then reservations control superintendent, asked how I had done in the aptitude test. When I asked what an aptitude test was, I was immediately despatched to the personnel department in Corballis House (sadly demolished in 2007 to make way for another soul-less addition to Dublin Airport). A couple of days later, he asked me if I would like to operate a computer – ‘what’s a computer?’! My initial training was at IBM with Brian Rothery, who had spent quite a bit of time at Bell Canada; he was still famous there in 1974 when I began working at Bell Canada in Montreal.
Aer Lingus was replacing the inventory cards with a Bunker-Ramo computer, which kept seat inventory for its entire route network. The Bunker-Ramo was powered by valves and relays and relied on two enormous head-per-track drums, which operated close to the windows of the room, which were always open, to try to dissipate the heat the system produced!
The IBM 1440 at Aer Lingus in the mid 1960s with members of the systems department (l-r): Tom Wall, Nora McSweeney and Pat O’Molloy.
(Photo source: Paddy Kilduff. Photographer unknown.)
The unit record equipment was replaced by a card-based transaction processing system on an IBM 1440 computer, programmed by Aer Lingus’s own programmers – probably with assistance from IBM. This computer was one of the biggest in Ireland at the time – a whole 16K of 6-bit characters, using BCD. It had four washing machine sized IBM 1311 disk drives – one of which was a spare – with a total storage capacity of 6 megabytes. It had an IBM 1210 paper-tape reader-punch to take information from the teletype-like communications. This was where I first met Joe Clarke, who later became a data communications specialist at ICL, Nixdorf and his own consultancy firm, Network Facilities.
The main input/output devices were an IBM 1442 combination card reader/punch and an IBM 1443 printer. The card reader used a photocell to read the card column-by-column, before it passed it through a hole-punching unit. The geniuses in Aer Lingus systems – I was not one of them! – speeded up throughput by punching the result codes in columns 1 and 2, rather than clunking through 78 spaces before punching the code in columns 79 and 80. That is just one example of the non-traditional thinking used in Aer Lingus!
The ‘operating system’, which was known as OpZero in Aer Lingus, was home-grown as well. A whole 7.7K (of those 6-bit characters) was assigned to it. Transactions on card were identified as ‘sale’ by ‘NN’ or ‘SS’, ‘confirmation’ by ‘HK’ or ‘KK’ and ‘cancellation’ by ‘XX’. Because transactions could not be sorted by type – a ‘sale’ might be dependent on the prior processing of a cancellation, or vice versa – OpZero read each card and analysed its transaction code. If the relevant program had been used for the preceding transaction, it was re-used; if not, OpZero read in the relevant program over the existing one and the cycle continued. (I suppose you could say it was one of the first paged-memory systems!)
I spent about a year and a half as an operator, running the reservations system and running program compilations and test packs for programmers such as Declan Kiely and for Roy Johnston, who did economic modelling in Fortran.
Having cut my teeth as a console operator I then did formal programming training and began programming in or around September 1966. I worked with Emmet Wilson in documenting Opzero and some of the more esoteric routines programmed by Eamon Giblin (who was revered as something of a ‘mad genius’!)
All of the programmers on the IBM 1440 used Autocoder, which was a forerunner of the Assembler/360 low-level programming language which we used later on the System/360.
I also learned some machine code from Nick Spalding, who at that time was an IBM field engineer, and who had to repair the system when – I think it was on a Saturday – I pulled the ‘Emergency Pull’ handle, when I saw smoke rising out of the top of the CPU! Nick told me I should not have pulled so hard on the handle, as I bent the mild-steel panel on the console!
In early 1967 I transferred to the project that would introduce a real-time reservations system, based on IBM’s new System/360 hardware and its IPARS reservations software. PL Byrne was the manager over all of what would later become IT. David Kennedy was head of systems and Denis Behan was the overall IPARS project manager. My first supervisor, Brian Ennis, was a systems analyst.
We began training in Assembler/360 at IBM, where John O’Leary was the trainer. Assembler/360 allowed the coding of programs using mnemonics, translating each ‘programmer statement’ into one machine instruction – or in some cases to a small pre-defined routine. Because the new mainframes had not yet been delivered to Aer Lingus, a number of us then did some initial work on CIE’s System/360 at Oriel Street.
Aer Lingus had unbelievably forward-thinking ideas on training and development. Some of the techniques that I learned there were still innovative in the late 1980s and early 1990s! In the IPARS project we had weekly afternoon training sessions where someone (in turn, and usually, junior on the team) would give a short talk on their secondary area of expertise. Since it was the area I knew less about, I had to do a lot of research before trying to impart knowledge the rest of the team, many of who would already know the subject far better than I did! It was really great training.
The Astral operating environment consisted of the IPARS Airline Control Program (ACP) which, as far as I can recall, was fairly monolithic. When it created a ‘message’ – a transaction consisted of a number of asynchronous, self-contained messages – it initiated the first of a series of ‘program segments’ which then used the data in the input-message to determine program flow. ‘Segments’ were organised into ‘programs’ which, in turn, were grouped into ‘packages’, each of which dealt with a particular function, such as seat inventory or communications to other airlines. Because most programs were developed in parallel with each other, a test environment was created where the input to a ‘segment’ could be simulated, where the data required (e.g. disk records not yet created – or ‘impossible error conditions’) could be created for that test run, and the interaction with other segments simulated, and hand-off made to the next segment in the sequence. I do not know if Declan O’Riordan of IBM developed this environment, but he was its champion. He left IBM to join what was then Arthur Andersen, ending up as the partner-in-charge, in Chicago, of what became Andersen Consulting.
Kevin O’Brien of IBM was responsible for ‘model airline testing’. The best analogy I can come up with for this is ‘destructive system-testing’. He was aided and abetted by Kevin Kelly, who was responsible for the ACP. ‘Model airline’ ran multiple 22-day cycles, emulating a month’s transactions; it was thoroughly exhaustive testing.
The two Kevins ran their applications tests late in the evening or overnight. The rest of us plebs (I was a member of that team) devised and prepared the tests. The night shift collated and ran the test packs. The morning shift reviewed the ‘dumps’ from the testing, analysed the bugs and farmed out the results to the guys who had responsibility for the relevant area. The day shift helped to make the changes and prepare re-tests. The cycle continued the following evening.
There was so much activity and handovers that we practically lived in a nearby pub – Kealy’s of Cloghran. The night shift went there for breakfast and a handover to the morning lot. Everyone who was still around at lunchtime went there for a handover to the late shifts! And a number of us would usually go there in the evening for a sort-of dinner!
When the system went live, Aer Lingus used Astral as the name for its implementation of the IPARS. Emmet Wilson became the ‘coverage’ lead, providing applications support for computer operations. He delegated error analysis to a small group that included me. In the event of a failure, the system generated a ‘core dump’ that contained the addresses of each program segment which was active on the message (a related series of ‘messages’ constituted a ‘transaction’) and the addresses – both disk record and memory block – of all data associated with the message. I now refer – grandiosely! – to the task of analysing these ‘core dumps’ as ‘front-line error analysis’!
There was a huge number of dumps to be farmed out (well over 100 per day, initially) for detailed analysis and resolution. I know that we were overloaded, because I got considerable grief from guys who were more interested in completing their development projects than in fixing ‘my’ problems. At any time there were 40 or 50 problems under active investigation.
Senior programmer Pat Kenny, who had been one of the first Aer Lingus programmers to work on the System/360, believed that there was a better way. Pat, who was not part of the ‘coverage’ group, designed and implemented a little automated routine which was, in effect, an error trap. Instead of crashing the ‘message’, the system issued a warning code and message, so that we could fix the affected data. We were very good at correcting data. And, if Denis Behan gave his approval, we sometimes fixed programs on the fly.
The biggest failure was discovered late one night, when a significant portion of Astral’s passenger detailed data was accidentally overwritten on the IBM 2314 storage subsystem attached to the System/360s. Astral created each passenger name record (PNR) by storing data items of varying lengths in a chain of fixed size records. The disk drives on the IBM 2314 were formatted to hold records in one of two sizes – 381 bytes or 1055 bytes – that the system held in a pool and assigned when they were required. The disk pool for PNRs also allocated records for Astral’s pre-formatted output messages.
Aer Lingus modified the Astral reservations system continuously after its introduction. This picture shows its ‘green screen’ interface on a Raytheon PTS-100 terminal.
(Photo source: Aer Lingus brochure from 1975 courtesy of Tom Marum and Pat Cormican. Photographer unknown.)
The crisis arose when the system detected a reorder level for those pool records, assigned disk space that was already occupied by PNRs and overwrote the passenger data. While the detailed information (contact details, special services and other unique passenger-specific information) was overwritten, the main key data was available from the passenger name index (PNI) records, which were in fixed locations, accessible through a routine, ‘FACE’ (‘File Address ComputE’), which was ‘corefast’ (available at all times, and not subject to ‘interrupts’). Each PNI contained a list of all the PNR addresses – so the overwritten records would come to light when the record type retrieved was an ‘OM’ (Output Message).
Management decided that sufficient data was available from the PNI records to manage the reservations and that the PNRs affected would be identified as having missing data. This was done by repairing the ‘chain’ information from the PNIs, so that each erroneous link pointed to a single ‘dummy’ PNR for a ‘Mr Astral’; when that was retrieved by a reservations agent, (s)he knew that the data was incomplete. I was one of eight Aer Lingus people who set about reconstructing the PNI links. The erroneous record addresses were modified, in hexadecimal format, keyed in on IBM 2915 ‘green screen’ VDUs. Members of the IBM team, including its operating system experts, joined in the effort. It took us almost 24 hours to rebuild the records.
I spent three or four months working on error analysis, but I was impatient and did not want to be stuck on ‘maintenance’ for years. In May 1969, after a discussion with PL Byrne, I went to Toronto to work for UNIVAC, which was developing Air Canada’s Reservec II reservation system. This was written in Fortran and based on a multi-processor UNIVAC 1108, with UNIVAC 418 real-time computers as front-end processors – probably doing the same job as the IBM 2703 communications controllers on IPARS.
Two of my Aer Lingus colleagues had already joined UNIVAC. Jeanne Mallon started the rot, followed very quickly by Richie Pyne. Michael McGrath came over a few months after me. Michael was assigned to UNIVAC’s then-new 9000 series, which (largely) emulated the System/360, but had a number of superior features.
As at Aer Lingus, the Reservec II team was a mix of Air Canada and UNIVAC people and I have difficulty now in remembering who was Air Canada and who was with UNIVAC! My team was headed by Vic Kalukas, the first of two Lithuanian-Canadian bosses I had in Canada. My overall manager was Vera Goodmanson, an American, who was among the top three managers I have encountered. I think of her when I sometimes use one of her favourite phrases; if I wanted a meeting with her, I would ask ‘Are you free, Vera’ to which her reply was invariably ‘No, but I’m very reasonable!’.
While I loved working on the Air Canada project – sometimes 10 or 11 hours a day – I hated Toronto. My brother, who at that time was an aircraft electrician at Aer Lingus, visited me in late October / early November and, while viewing the partially-frozen Niagara Falls, persuaded me that I would be happier in Ireland, so I returned home just before Christmas.
I had arranged interviews with a number of organisations in Ireland and, in early January, I had about seven hours of tests and interviews with Bank of Ireland. (IBM salesman Joe Cunningham had told me when I was leaving in May that the bank was going to buy IBM System/360s and they would be looking for experienced programmers; he was wrong, they bought ICL 1900s!) Bank of Ireland offered me a job as a systems analyst, but Denis Behan and Brian Ennis persuaded me to re-join Aer Lingus, where I spent a further four happy years as a ‘lead programmer’.
I met my wife, Marie, while playing badminton – she was secretary to Aer Lingus finance manager Michael O’Shea – and if I was at the lifts /staircase, I could always tell if Marie was working because of the ‘machine-gun’ speed of her typing!
After my return to Aer Lingus in February 1970 I supervised modifications and fixes to Astral. These could be applied only after very strict testing and acceptance procedures with sign-off by me for the applications tests and by Kevin Kelly for the ACP aspects. We reported to Brian Ennis, who was now real-time systems controller and gave the final approval for the changes. I liked his management style and learned a lot from him which was very useful to me later in my career. Brian moved to an accounting function in 1973 and his successor had a different style which I did not like and which made my job much more difficult. That, together with my decision to get married, gave me a reason for seeking another job and Í secured one with United Aircraft of Canada (UAC). It took me several months to persuade Marie to marry me and move to Canada!
I was very lucky to meet John Carroll on my first or second day there in March 1974. John, who came from Littleton in Tipperary, had qualified as an engineer at University College Cork. John’s wife, Eleanor, was a ‘mother hen’ figure who welcomed all newcomers and invited us to spend Easter with them. Some of those expats made major contributions to IT in Canada and to Canadian business, both before I went there and after I returned to Ireland.
My training at Aer Lingus paid dividends in providing ideas which allowed me to decimate the disk storage requirements of UAC’s ‘material flow’ system; it was the first of many occasions when techniques I learned at Aer Lingus ‘wowed’ my later colleagues!
The leading-edge tools and techniques we used – and sometimes developed – at Aer Lingus stood me in incredibly good stead for more than two decades. I am still amazed at how much we could do with incredibly few resources. There was a fantastic esprit de corps in the whole company and especially in IT. Most of the people there were in their late teens or early twenties and, while there were the inevitable rivalries, we pulled together as a team and made the thing work! The were also many romances and a few weddings!
Last edit: April 2019
© John McEneaney 2019