Duncan's TSB Years:

Mr Dyson, my computers lecturer once commented that he wouldn't be supprised to hear of me working for NASA. I was still living in Andover, a suburb of TSB Trust Company. TSB's Head Office was situated about 200 Meters from my house, and as I knew they had some pretty serious computing interests, I gave them a try first.

I started as a Technical Assistant - dogsbody to a team consisting typically of a senior analyst, a couple of analysts and half a dozen programmers of various grades. I was in the IT Development department, and we were tasked with examining new and emerging technologies useful to the company, and identify how they could be put to use - this covered examination and introduction new analytical and programming methodologies for new developments, technical evaluation of mainframe expert based systems for the business departments, and PC technology.

Progression from T.A. required learning all about how the software systems were currently developed and maintained, this meant three weeks of training in London on MJSD design and COBOL programming, shortly after this I was pronounced Junior Programmer, and started on the Programmers Workbench.

The programmers workbench was a clever project - The 'Real' systems at TSB, I.E. those which number crunched the customers policies each night were run on the Mainframes (you couldn't hope to process that sort of volume of data on a PC, but the development and maintenance of the software (COBOL) was being performed on-line, this resulted in it being very expensive. The proposal was to put in place a PC network for the programmers to work on, this alone would save them £1000 per terminal per annum by replacing an expensive mainframe terminal with a cheap PC. As some of the Systems departments had over 100 programmers, this meant big money.

The proposal was only applicable to new developments, by using a JSD design tool, programs could be written in a flowchart-type form (To equate an MJSD design to a flowchart is probably an insult, but to the un-initiated, it will suffice). The output of the JSD design program could be fed through a Cobol pre-compiler (it's output is COBOL). That code can be fed into a Cobol programmers workbench, still on the PC, and the program can be tested. Once working, it is uploaded to the Mainframe for system testing prior to going live. The big saving here is in CPU core time - something like a quarter of the mainframe's core time is devoted to system development and maintenance.

Both these proposals were implimented, and succeeded. Our next goal was to try and make it work for those departments which had existing systems being maintained, The problem was that the department we tried to conquer presented the ultimate in worst case scenarios: The code they were using was not written in-house, it was a standard package which had customised cobol modules added on, it was these modules that the department were maintaining, they had no source code for that purchased core. This meant, basically, that we couldn't run the system on a PC, as the code could not be re-compiled with 8086 machine instructions. It seemed pretty hopeless, until we hit upon the following solution:

If we could download the module (which we do have the source for) and add Cobol instructions to sample and store all data that gets passed into or returned from the module, then it can be re-compiled for the mainframe, and run through a test cycle. The program and the saved data can then be returned to the PC, the code once again modified to re-insert the data, and check the return data at the appropriate times, and the program can now be run without the core module. The test harness does the work instead.