Development

Quality Approach

LOLA took a quality approach to applications development .

Before any programming work started a Standards Manual was produced and application programs had to obey the rules.

There were also a set of general subroutines created which had to be used for processing dates, addresses and names.

• The date subroutine proved beneficial when it came to the year 2000. It was amended to cope with the new century dates - this despite the fact that the storage area for dates was only 5 digits - the dates being stored in YYDDD format.

Program specifications, flowcharts and code were all subject to 'walk-throughs' by all team members so that errors could be found and corrected at an early stage.

Once written, the programs were tested by programmers before being handed over to system analysts.

Systems were backed up regularly and could be rolled back to previous versions if necessary. Programmers were on call-out overnight when batch jobs were run, and errors were usually fixed immediately.

Typical Programmer Training

LOLA recruited trainees regularly and provided lots training to all staff.

Jim Fothergill, provided this list of IBM programming courses that he attended during his initial years at LOLA. In fact, his first courses were undertaken whilst initial staff were still employed by London Boroughs Management Services Unit.

Jim joined LBMSU/LOLA straight from Southampton University where he undertook a BSc in Maths & Electronics and a MSc in Numerical Science & Computation. He joined via a LBMSU careers day.

1. OS background for programmers (07/70 LBMSU)
2. OS access methods (08/70 LBMSU)
3. Assembler (08/70 LBMSU)
4. PL/1 workshop (06/70 LBMSU)
5. Systems design & analysis (08/70 LBMSU)
6. PL/1 extensions (08/72 LOLA)
7. IMS (no cert)
8. JCL (no cert)

Typical Development Cycle

When former employee Heather Rogers retired she gave a short talk on how program coding and testing was undertaken. You can read it here [⇗] (opens in new tab/window).

It includes some recollections of office life at LOLA in the 1970s.

 

 

 

PL/1 Module Tester

At first there were very few terminals (visual display units or VDUs) for testing on account of the cost. Besides, programmers sitting at terminals testing was unproductive. In 1971 the Application & Technical Support Groups jointly developed a test harness using the PL/1 Preprocessor .

This simulated terminal input using punch card input and the display output was printed. This allowed a programmer to test their on-line transaction without the need to book a display terminal and to have to key in the data for all the test conditions. It also allowed a set of tests to be repeated easily.

Additionally it simulated the database calls alleviating the need for each programmer to have their own set of databases or to share a database with others.

Once the unit testing was completed the Preprocessor could easily be switched off and the module incorporated into the transaction program and then tested on a real terminal using a testing database called Utopia.

 

Memory and IMS Constaints 

The first IBM 360/50 only had 512MB of memory so programs were written in segments with a control module that would load the segments in turn as the transaction (or batch program) progressed.

This also addressed an IMS constain. Many of the IMS definitions such as physical and logical databases, and program definitions, were limited to 512. But LOLA wanted to keep each authority's system separate (and have a test system call Utopia). This worked out at just 100 definitions per authority and given that LOLA would eventually write over 300 programs, was far from sufficient.

So the control module was just 1 program definition / transaction in IMS terms. This gave rise to another problem. IMS kept a log of database changes and would lock the data while a transaction was modifying a database, so if the program aborted would roll-back the changed data.

So the control module had to hold the data base changes and apply them at the final step along with maintaining a scratch pad for the transaction to remember that user's interaction (the same transaction could be run on more that one terminal simultaneously).

References

1. As recalled in February 2021 by Martin Jackson, LOLA programmer 1970-2006 and previously at LBMSU from 1968.

2. The PL/1 Preprocessor was a scripting language that was loaded with the programmers source code and could modify the PL/1 source code before it was compiled. Thus calls to/from the IMS terminals and to/from the IMS databases could be intercepted and simulated. As recalled in March 2023 by Alan Cooper, LOLA Applications Support Group 1970-1975. Alan, along with Noel Sant and Joe Stansbury, developed the PL/1 Module Tester View here [⇗].

   PL/1 (Programming Language 1) was IBM's procedural and imperative computer programming language that aimed to meet both commercial and scientific programming needs.

3. As recalled in May 2024 by Alan Cooper, LOLA applications support programmer from 1970-1975.