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

The allegation is that Winsopia failed to scrub properly IBM module DFHEI1 and, as a result, such modules were transferred outside Winsopia’s Enterprise and used on non-designated machines.

CICS programs are bound with a CICS stub which has an entry point called DFHEI1. IBM supplies the DFHEI1 CSECT with CICS as part of the SDFHLOAD library; another version of the DFHEI1 CSECT is supplied with IMS within the DFSLI000 load module.

A third-party software product, DL/2, allows programs designed to use IMS databases to use Db2 databases without application charges. Winsopia used DL/2 processing by converting customer IMS load modules to a DL/2 compatible format when migrating them to the SDM.

The experts agreed in their second joint statement that, for applications using the EXEC DLI API, the DL/2 process provided a replacement ‘DFHEI1 stub’ but did not remove the original ‘DFHEI1 stub’; it simply renamed it ‘DFHEI1X’. Prior to November 2018 CPX was not programmed to scrub ‘DFHEI1X.’ As a result, load modules transferred by Winsopia to LzLabs contained both the replacement DFHEI1 stub and the original CICS or IMS DFHEI1X stub.

This issue was highlighted by Mr Spencer of LzLabs in an email dated 24 November 2018:

“It looks like DFHEI1X is the real IBM DFHEI1 that has been renamed to X by the DL2 conversion process. DFHEI1 is the CIRCLE intercept module for that entry point ...

What we need is for … DFHEI1 to be renamed … and NOT redacted (it is circle code), it is not being renamed in the CPX we receive. DFHEI1X should not be renamed and SHOULD be redacted since it contains the IBM DFHEI1 code now.

We can add a "wormhole" on our side for DFHEI1X to treat it just like we would DFHEI1.”

In response, Mr Palmer stated that he had updated the CPX rules file as requested, although in a further email dated 29 November 2018 Mr Spencer noted that the CPX renaming problem had not yet been resolved.

There is evidence that the renaming problem occurred in respect of load modules transferred by Winsopia to LzLabs in 2018, as set out in DR-3435, DR-3552 and DR-3107. There was difficulty in analysing some of the DR material as a result of corrupted files. However, the experts agreed in their second joint statement that DR-3107 showed evidence that the DFHEI1X module was sent to LzLabs. In cross-examination, Mr Stephens agreed that it showed that DL/2 applications contained CICS renamed stubs. The DR-3552 evidence was inconclusive but it is likely that the IMS DFHEI1X module was sent to LzLabs given that the relevant program was the subject of Mr Spencer’s November email.

On the basis of the above evidence, I find that on the balance of probabilities Winsopia transferred load modules to LzLabs containing the renamed DFHEI1X module. Regardless of whether the programs originated as customer applications, they were processed by Winsopia on its mainframe, using DL/2. As set out earlier in this judgment, the acts of loading, displaying, running and storage of applications containing IBM CSECTs involve reproduction of the IBM software and are subject to authorisation under the terms of the ICA.

It is common ground that IMS Versions 12, 14 and 15 are ICA Programs. The IMS version of DFHEI1 is a CSECT in the DFSLI000 load module provided with IMS. It follows that the IMS DFHEI1 CSECT is a component of an ICA Program, and therefore an ICA Program. For the reasons set out in paragraphs [185] to [193] above, the terms of the Licensed Program Specification for IMS do not permit export to LzLabs for the purpose of developing the SDM.

It is also common ground that CICS Transaction Server for z/OS Version 5 is an ICA Program. The CICS version of DFHEI1 is provided by IBM in the SDFHLOAD library supplied with CICS. It follows that the CICS DFHEI1 CSECT is a component of an ICA Program, and therefore an ICA Program.

In summary on this item: