| Job Description |
Worked for 15 months (Jan 86/Mar 87) as a Team Leader, at the Sparekassernes DataCenter near Copenhagen, building, integrating and testing a higH throughput OS1/SNA based banking-transaction message switch.The message switch, implemented on an IBM 3084Q running MVS/XA, was only one component in a large banking network. The entire network consisted of, firstly, 1300 Olivetti 1000 minicomputers, situated in Savings Banks throughout Denmark and Greenland. These were connected, via the Danish PTT’s X21 switching network (and satellite links in the case of Greenland), intQ 7 IBM 3725 Communications Processors on site at SDC. The ‘Front End’ message switch being implemented by Logica interfaced the 3725s to a host IBM 3084Q/3090 on which ran an online banking transactions system for all of the savings banks.Physical communications between the 3725s, the message switch and the Host applications was done using standard SNA/VTAM sessions.Logical communications between the Banking Transaction System, running on each of the 1300 Olivetti ‘Local Computers’ in the branches, and the main online banking applications running on the host IBM at SDC, was based on modified OS1 Transport and Session level protocols. Each Local Computer opened a ‘Path’ to the Message Switch, over which it would then establish up to 30 ‘Associations’. These associations could run various type of data streams, passing data as Letter Fragments. One such data stream was for high volume, low content, data consisting of single frangment unacknowledged Letters (STP protocol). An other data stream was for lower volume, high content, data const- sting Of multiple fragment acknowledged letters (SEP Protocol) This second protocol implemented a pseudo OSI Class 4 Transport Layer and included transmission/receive windowing, flow control, Letter fragmentation and re-assembly, re-sequencing, fragment retransmission and acknowledgement.The message switch, which was coded in Assembler/PLl and had a multi task structure, was designed to handler up to 30,000 individual ‘associations’ (data streams) with a throughput of in excess of 300 message pairs per second.During the PLl developement phase
- Acted as team leader supervising 6 programmers during the coding of some 200 separate software modules.
- Responsible for researching and defining the switch’s error methodology.
- Resposible for generating Unit Test scripts against which the programmers tested their completed modules. This involved taking the psuedo code in the Technical Specification and for each module specifing a series of tests which proved that that module had been ‘individually’ or ‘unit’ tested. The resultant output was then checked and the Tech Spec re-updated
During the Coding, Build and Integration Testing Phase
- Acted as team leader supervising 2 programmers during building of the message switch from some 150 Assembler and 200 PL1 code modules. An overlap existed where both teams were being supervised at once, in the period of PL1 code completion and the start of module integration. Responsiblity was assumed, during this period, for control and administration of all software comprising the switch.
- Initiated and maintained a Fault reporting system by which faults in both software and documentation would be logged and corrected systematically. This system not only worked to contol updates and changes to the actual software but also served as an effective Quality Assurance mechanism for the project and ensured that any software changes were always refected in the Tech Spec
- Ran Test-Scripted data validation tests on the message switch. This involved generating several hundred TPNS message decks, running them against the switch and annotating the resultant output for passing to the customer as part of contractual proof of testing.
- Coded and tested some PL1 programming faults overall testing of the fixes for the various assembler and which resulted emerged as a result of the
During the overall system testing phase
- Performed major assembler code enhancements and re-structuring to a project developed, performance testing tool. This program initiated multiple SNA sessions with the switch and then passed data at high throughput rates. The enhancements to this ‘soaker’ included, modifying it to use multiple virtual transmission routes between the CPU in which it is run, and the CPU in which the switch is run. It was also enhanced to allow realistic volume tests to be carried out by passing the data via a 3725 running the X21 networking software (previous use of the soak tester only used the 3725 in a by-pass fashion). New code was added to provide comprehensive recovery for SNA/VTAM error conditions; to allow automatic recovery from session outages and to impose ‘inactivity’ checking for all established sessions.
- Responsible for the setting up and running of performance tests
- Responsible updating pseudo cOde in the Technical Specification to reflect coding changes to some 70 assembler/PL1 modules.
return |