HT-2021-000363 - [2025] EWHC 532 (TCC)

The allegation is that Winsopia used the XDC tool to analyse the IMS ACB data structure, amounting to reverse engineering of the same. The defendants’ case is that the IMS modules analysed are not ICA Programs and the analysis was permitted observation, study and testing under Article 5(3) of the Software Directive.

IMS is a hierarchical database system which supports transaction processing. The databases and the information that is stored in them must be predefined using database descriptors (“DBDs”) that are coded as assembler macro statements. Although it is a load module, a DBD is not an executable program; it contains metadata that is used by IMS to document the format of data in the user’s database. Before an IMS database can be accessed by a program, the program must also be defined to IMS, using assembler macros. This is processed by an IBM utility to generate a program specification block (“PSB”), which describes the characteristics of the program, including the data structures required. When a program executes in IMS, IMS must obtain the DBD and PSB, and merge them into an application control block (“ACB”). ACBs are load modules created using an IBM utility, ACBGEN. ACBGEN comprises a number of modules, including DFSUAMB0 and DFSUACB0, which are supplied with IMS as part of the SDFSSRC library.

Winsopia needed to develop support for IMS databases in CPX to facilitate the export of customer data from IMS databases. On 12 August 2016 Mr Palmer at Winsopia contacted Mr Harper, a developer at LzLabs, to discuss potential methods of identifying the DBD libraries required by the IMS unload utility for the purpose of exporting data using CPX.

Following this exchange, Mr Palmer wrote:

“I was able to track down and build the [ACBGEN] utility so I have access to the listings etc where the key write module is DFSUAMB0. I did stick an XDC hook in there and was able to identify where the DBD and PSB ACB library members are written and discovered (I had mistakenly thought there would be some sort of ACB control block) that the DBDs are written as a DMB (Data Management Block) that is mapped in the DFSDMB macro. There are a number of different mapping DSECTs in there but so far it looks good.”

Subsequently, Mr Palmer sent an email to Mr Harper, copied to Mr Payne and Mr Rastall, explaining the work that he had undertaken:

“Compiled and linked IMS code to the extent that I can insert an XDC hook in the code that performs an ACBGEN; thus allowing a better understanding of the critical ACB member attributes I will need to handle.”

In his third witness statement, Mr Palmer explained what he was trying to achieve:

“I was seeking to examine the application control blocks that contain definitions for customer IMS databases. These database definitions are stored in load modules generated by the user as part of the IMS system generation process. I needed to understand the member attributes of these definitions so that I could determine how to “unload” (export) the customer databases as part of the CPX migration process. In order to examine these definitions, I had to first locate them within the load modules.”

Mr Palmer gave the following account as to what he did in his written and oral evidence. First, he located DFSUAMB0, by reviewing the source code of IMS modules which had been supplied to Winsopia as part of IMS. Second, he compiled and link-edited the DFSUAMB0 source code into a load module. Third, he used an Assembler listing to identify the particular offset that he was interested in. Fourth, he inserted an XDC hook at the point of interest, thereby modifying the program binary so that it would invoke and pass control to XDC during execution. Fifth, he executed the modified version of the DFSUAMB0, which was paused at the point that it was about to write the DBDs to a load module. Sixth, he used XDC to inspect the working memory and registers to identify the location of the DBD and ACB library members so that he could understand the attributes of such member definitions.

The experts’ second joint statement includes the following agreed statements:

The issues in dispute are:

IMS v14 is an ICA Program. The ACBGEN utility, including the DFSUAMB0 and DFSUACB0 modules, were provided as components of IMS. Those modules are supplied to IMS users in source form as part of the SDFSSRC library. For the reasons set out above, they fall within the definition of ICA Programs within the meaning of the ICA.

The defendants submit that the allegations relate to the use of XDC on modified versions of DFSUACB0 and DFSUABM0, which were created and compiled by Winsopia and were not ICA Programs. I reject that argument. Regardless of whether Winsopia modified the modules as part of its analysis of the same using XDC, they were component parts of IMS and, therefore, constituted an ICA Program.

Mr Palmer’s evidence established that Winsopia modified the DFSUACB0 and DFSUABM0 modules by inserting an XDC hook, using it to stop execution at the selected point, so as to display in assembly form the material working memory and registers, from which he could identify the location of the DBD and ACB library members. This amounted to reverse engineering of components of IMS.

It is common ground that the DFSUACB0 and DFSUABM0 modules were supplied by IBM in source code form. It is not suggested by the defendants that the analysis carried out on the modules was for the purpose of resolving problems related to use of IMS. Although the defendants seek to argue that the analysis was to modify IMS so that it would work with other projects, Mr Palmer’s evidence did not support such a case. His investigation was not to modify IMS to enable it to work with other projects; rather, it was to enable CPX to extract and export data from IMS to the SDM. He confirmed in cross-examination that the purpose of his work was to automate the process of matching up IMS database definitions to their corresponding databases, so as to speed it up. It follows that Winsopia’s use of the modules was outside permitted use, in breach of clause 4.1.1(d) of the ICA.

The defendants submit that Winsopia’s activities fell within Article 5(3) of the Software Directive on the ground that the purpose was to understand interface information relating to the ACB data structure. I reject that argument. It is clear from Mr Palmer’s evidence that his examination of the working memory and registers in the modules during execution was to understand how IMS defined databases. Such analysis investigated, not just the output of the program but how the program achieved its output, that is expression of the program, rather than its functioning.

In summary on this issue:

This use of XDC to interrogate IMS was not an isolated incident, as evidenced by the email dated 16 March 2018 sent by Bob Maddison of Winsopia to Richard Parkinson, in which he referred to the practice of using XDC to “rummage around” in IMS. The court accepts that XDC was used by a number of Winsopia employees to interrogate the ICA Programs.