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

This allegation concerns the removal of Language Environment CSECT data areas from the scrub list.

CEEBETBL specifies the addresses of other CSECTs, including CEEBLLST and the termination stub routine address. CEEBLLST declares the language list for the load module or program object. The CEESG* CSESCTs specify the addresses of CSECTs specific to each language. They are provided by IBM in the SCEELKED library with z/OS. As such, they are ICA Programs for the purpose of the ICA.

On 22 June 2017 Tim Sneddon of LzLabs sent an email to Mr Jaeger, asking whether certain of the above CSECTs could be included in the load modules sent from Winsopia:

“According to the manual they aren't executable code, but parameters lists and item lists that give details about how a load module should be handled and which language run-times should be initialised.”

On the same day, Mr Bowler of LzLabs identified a number of additional CSECTs that should not be redacted because they could provide useful information.

On 12 September 2017 as recorded in the Bugzilla Ticket 354-A, Winsopia removed these CSECTs from the scrub list.

On 15 September 2017, following receipt of Mr Bowler’s preliminary analysis of program objects produced by the IBM C and PL/I compilers, Mr Bond sent the following email to Mr Bowler, Mr Sneddon and Mr Jaeger:

“Roger's analysis was very informative, as was Tim's pointer to the relevant documentation in the Language Environment Vendor Interface manual.

My conclusion is that we will need most of the contents of the CEEBETBL, CEEBLLST and CEESGnnn sections. I don't know if we need the contents of xxxINPL - I defer to Roger and Tim for those. Each of the sections that I listed contains pointers to things that we will need to initialize the environment…

There really isn't any other way to get this information except to have these sections. This is because information external to the loaded program, such as information about names, is not always available…”

After receiving these CSECTs from Winsopia in unscrubbed form, LzLabs’ developers used the Language Environment Signature CSECTs CEESG003 and CEESG011 to create data structures in the SDM source code that were equivalent to those contained within the original unscrubbed IBM CSECTs.

The creation of those data structures, together with modifications to the SDM loader, enabled the SDM to reconstruct these CSECTs in load modules from which they had been scrubbed, with the result that Winsopia could then return them to the scrub list.

The experts agreed in the second joint statement that some, but not all, of the format of the relevant CSECTs is available in public documentation. Mr Bond’s initial evidence was that LzLabs developed the SDM loader solution using information from public sources but, having been shown contemporaneous document in cross-examination, he accepted that Winsopia supplied LzLabs with load modules containing unscrubbed versions of the relevant CSECTs, and that Mr Bowler used information in those CSECTs to determine the length and format of the data structures.

On 25 September 2017 Mr Bowler made a Git commit, recording the addition of structure definitions to the SDM implementation of the relevant CSECT data structures.

When shown a copy of the Git commit, Mr Bond agreed in cross-examination the following:

“Q. So, on the face of it, what Roger Bowler has done has investigated the contents of the CSECTs, the data structures in the CSECTs, using a combination of IBM documentation and, where that wasn't complete, actual CSECTs produced unscrubbed by Winsopia?

A. It does appear to me that way.

Q. Then he copies the structure, doesn't he, into the SDM?

A. He copies the definition of the structure into the SDM.”

In summary on this item: