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

The allegation is that Winsopia used reverse engineering of the CICS Transaction Server for z/OS to produce a document entitled “CICS Commands and Parameters” Version 1.3 dated 26 February 2020 (“the CICS Control Blocks Document”) and provided it to LzLabs in breach of clauses 4.1, 4.1.2(b), 4.1.3(a) and 4.1.3(b) of the ICA.

The defendants’ case is that EXEC CICS and the Arg0 parameter analysed by Winsopia do not fall within the definition of an ICA Program; they formed part of an interface for the CICS Transaction Server program and were not subject to the restrictions in the ICA. Further, Winsopia was entitled to observe, study and test the EXEC CICS interface pursuant to Article 5(3) of the Software Directive. Alternatively, it was necessary in order to achieve interoperability of customer applications with the SDM and was permitted pursuant to Article 6 of the Software Directive.

As set out in Section II of this Judgment, EXEC CICS commands can be incorporated into the source code of an application hosted on CICS, enabling it to request specific services from the CICS Transaction Server and underlying components of the z/OS operating system at runtime. EXEC CICS commands are pre-processed by the CICS translator before compilation and link-editing.

The following is a simplified summary of the EXEC CICS process.

The functions invoked by each EXEC CICS command are listed in the CICS Application Programming Guide manual. However, save for limited samples, details of Arg0 are not published.

The CICS Control Blocks Document produced by Winsopia contains a detailed description of hundreds of EXEC CICS commands, identifying the format of Arg0 for each command, including its length in bytes and a table setting out the meaning of each bit or byte in Arg0 for the command.

The CICS Control Blocks document was first produced by John Horswill at Winsopia on 23 December 2013. Version 1.0 was completed on 12 November 2015. Subsequently the document was updated by Kevin Hitchings incrementally through until version 1.3 dated 26 February 2020.

The document was produced by running test programs containing EXEC CICS commands through the CICS translator and documenting the outputs in a word document. On 31 October 2013, Mr Horswill wrote to Mr Rastall explaining the process used:

“The input file … is written from the syntax diagrams in the APR.

This is transferred to the mainframe [and] a job is run using the translator. This generates the output which shows the relevant hex codes next to each of the commands.

From this I generate the two word documents, one contains the HEX codes for each of the commands and the other is a summary of the commands for each control block.

Besides the CICS Application Programming Reference version 5.1, I am referring to the CICS Customization Guide version 5.1 …”

Mr Horswill’s methodology was to analyse the string of bytes produced by the CICS translator for each CICS command, correlating the meaning of the values generated by the CICS translator against values specified in the source code program, so as to derive an understanding of the DFHEI1 parameter list for the full range of CICS commands.

The information in the CICS Control Blocks document was sent to LzLabs and used by LzLabs in development of the SDM.

The experts’ second joint statement contains the following agreed facts:

The disputed issues are:

IBM’s case is that the CICS translator, Arg0 and/or the Language Definition Tables are component parts of the CICS Transaction Server, an ICA Program. IBM submits that Arg0 is part of the architecture of CICS Transaction Server for z/OS and EXEC CICS commands are features of applications written to be hosted on this product. The CICS Language Definition Tables that contain the mapping from EXEC CICS for Arg0 and the various CICS routines that parse and process Arg0 in order to deal with CICS requests are supplied with, and form part of, the CICS Transaction Server for z/OS.

The defendants’ case is that the format of the Arg0 parameter is part of the EXEC CICS interface between the customer application and the CICS Transaction Server, comprising: (i) the EXEC CICS statement in the customer application; (ii) the translated call to DFHEI1 generated by the CICS translator; (iii) the CICS language interface module (CICS stub) inserted into the link-edited machine code; and (iv) the interface program which receives the call from the CICS stub at runtime, providing an entry point to the application interface program load module. The EXEC CICS interface is distinct from the CICS service that is requested by the application and, as such, it is not an ICA Program.

IBM publishes a list of available EXEC CICS commands from which a customer can select a specific command to incorporate in its application for the purpose of requesting a CICS service at execution. The process of translating the EXEC CICS command into the source code language of the application and generating the CALL to DFHEI1 with the Arg parameter list, including Arg0, is carried out by the CICS translator (which can be embedded within the compiler) using the Language Definition Tables. The CICS translator and the Language Definition Tables are component parts of the CICS Transaction Server for z/OS. For the reasons set out above, such component parts fall within the definition of an ICA Program for the purposes of the ICA.

It is said by the defendants that the CICS translator process occurs at the pre-compilation stage whilst the application is in source code form. That is correct (save where an embedded CICS translator is used) but it does not change the characterisation of the process. The process is the generation of code, including the Arg0 parameter, by component parts of the CICS Transaction Server.

It is also said by the defendants that the EXEC CICS interface is not part of the CICS service in that it merely generates the call and parameter list, including Arg0, to the service in the appropriate source code language. That is an oversimplification of the process, which involves complex algorithms with many variables, selected by the CICS translator by reference to the Language Definition Tables. The specific content, parameters, sequence and combination of the instructions are dictated by software which is the intellectual creation of IBM Corp (licensed to IBM and to Winsopia through the ICA). Although this process takes place prior to the call to the required CICS service, it is an essential part of the operation of the CICS Transaction Server.

IBM’s case is that the defendants derived most of their information about Arg0 not from public sources but through use of Winsopia’s mainframe, involving the systematic analysis of outputs of the CICS translator, amounting to reverse engineering.

The defendants’ case is that its analysis was limited to the EXEC CICS interface; it did not investigate how the CICS middleware processes the API commands, or the underlying processing within the runtime environment to deliver the CICS service requested.

Mr Stephens described the process used to create the CICS Control Blocks document in his first report. Winsopia wrote test applications which invoked each of the relevant CICS commands. This involved invoking the IBM compiler with the test applications as input and using standard compiler options to cause the listings to be created as part of the compilation process. Winsopia compiled the test applications on its mainframe and reviewed the compiler listings created by the compiler. From a review of the compiler listings, together with publicly available documentation, the information in the CICS Control Blocks document was created.

In Appendix 4 to his first report, Mr Stephens explained the analysis that Winsopia could carry out based on the compiler listings:

It is clear from the above description that the test programs were designed to produce a compiler listing which would disclose for each test case the hexadecimal code generated by the CICS translator and the parameters determined by the Language Definition Tables. As such, it amounted to reverse engineering of the CICS translator and the Language Definition Tables, component parts of the CICS Transaction Server, in breach of clause 4.1.3(a) of the ICA.

LzLabs admitted that reverse engineering was used to create the CICS Control Blocks document. On 22 June 2014 Mr Taylor of LzLabs sent an email to Steve Towns and Mr Broussard at Texas Wormhole regarding two DRs, including the following:

“…the requests need to be modified further. I have talked this over with Ira. You need to find a way to ask them to discover the API and surface it in their own words. Not just ask them to send you listings or write what they see in the listings.

… the second request is that someone please continue the work started by John Horswill. His API document is excellent and it details most of the information we need to know. I don't want to wait for this however. The document has information on HANDLE ABEND but it is incomplete and does not answer this question.

On DR0068 you need to NOT ask for listings, but instead ask how COBOL implements the handle abend API. I think it is totally legitimate that you state your belief in how it works and attempt to get confirmation. I have perused the literature, i.e. CICS manuals, and it is very scanty on how it treats COBOL. It has a paragraph about how it deals with assembler, restoring the registers, but it is silent on COBOL. Having them write a series of COBOL programs, or possibly getting Martin to do it, if they do not have the time, might be a way to go. Also having them analyze the assembler listings and surfacing the information in the API document (Horswill’s PDF), would also be legitimate. If there are edge cases that you think might exist (you mentioned very large COBOL programs as a possible example), then we could get them to write those as well. This would accomplish a couple of things; It would begin to give us the start of a QA suite, that we could run in both environments (MF CICS and LTE); It would validate behavior of COBOL and handle conditions (as well as HANDLE AID and HANDLE ABEND).

Try to keep in mind that the clean room process we are going thru, is that all "reverse engineering" is done in England (or the EU) as the laws in these jurisdictions are clearer. John Horswill’s PDF document is the beginning of the remediation that is being done, so that we can legally state that the original work could have been done. ”

In cross-examination, Mr Taylor agreed that the reference to “reverse engineering” was reverse engineering of Arg0 that was done by Mr Horswill and Mr Hitchings to produce the CICS Control Block document. He also agreed that the remediation referred to was a request for Winsopia to produce a document that could have been used to get the information already deduced by Texas Wormhole or obtained by LzLabs through reverse engineering from compiler listings and used in the SDM.

I accept the defendants’ submission that IBM publishes the format of the Arg0 data area and the Arg0 values for some EXEC CICS commands, showing the output from the CICS translator for those commands and their parameters. That was demonstrated during cross-examination by reference to published IBM documentation. However, Winsopia did not confine its analysis to the publicly available information. The experts agreed that the level of detail in the CICS Control Blocks document goes to a level of granularity which is far more detailed that that published.

The defendants’ case is that Winsopia’s actions fell within permitted observation, study and testing of the CICS interfaces pursuant to Article 5(3) of the Software Directive. They submit that each of the matters being observed, studied and tested by Winsopia related to ideas and principles underlying the programs, such as interfaces contained in, and used by, the test programs; the division of responsibility between the executing program and the runtime environment; and the nature of the interactions between the compiler, customer application and runtime environment.

I reject that submission. Winsopia did not confine its actions to examining the input and output of each test application to determine the functioning of the CICS Transaction Server. Winsopia’s analysis involved deciphering Arg0 and the parameter list for each EXEC CICS command and identifying the appropriate EXEC CICS interface program to determine how it operated. Such detailed analysis of the compiler, customer application and runtime environment investigated, not just the output of the program in response to a particular input but how the program achieved its output, that is, expression of the program, rather than its functioning.

It matters not that the component parts being analysed by Winsopia included the CICS interface. What was interrogated was not confined to the principles and ideas underlying the interface but rather it extended to the precise instructions and parameters generated by the CICS translator that formed an essential part of the implementation of the CICS Transaction Server Program. Such reverse engineering was not permitted by the terms of the ICA and did not fall within the observation, study and test exception of the Software Directive.

The defendants rely on an argument that the analysis of Arg0 was necessary in order to achieve interoperability of customer applications with the SDM.

Professor Donaldson agreed with Mr Swanson’s understanding that Winsopia’s aim was to decipher Arg0 and the remaining parameter list for each EXEC CICS command and match that to the appropriate EXEC CICS interface program such that an alternative could be substituted for the CICS runtime. Professor Donaldson’s opinion is that this information was necessary in order for LzLabs to develop support for customer programs relying on CICS services. Without a replacement interface capable of handling the parameters passed by those programs, it would have been impossible for those programs to interact, or communicate, successfully with the SDM.

That is correct from a technical point of view but, of course, it assumes that LzLabs does not simply recompile the customer program, an option always available to it. As stated by Mr Swanson and agreed by Mr Stephens in cross-examination, if LzLabs worked from customer source code and had their own translator capable of parsing EXEC CICS commands, there would be no need to understand the information passed to DFHEI1 or Arg0.

It follows that reproduction of the code and translation of its form were not indispensable to obtain the information necessary to achieve interoperability so as to engage the Article 6 exception.

Further, Article 6(2)(c) provides that information obtained by reproduction of the code and translation of its form is not permitted to be used for the development, production or marketing of a computer program substantially similar in its expression, or for any other act which infringes copyright. Development of the SDM was intended to provide an alternative program to call equivalent services to those provided by the CICS Transaction Server, using the same CICS commands and parameters, and producing the same responses. This was substantially similar in expression to Arg0.

It is not in dispute that the CICS Control Blocks document was supplied by Winsopia to LzLabs for the purpose of development of the SDM by LzLabs. The information supplied included the hexadecimal code for Arg0. That amounted to a direct transfer of part of the CICS Transaction Server software and was in breach of clauses 4.1, 4.1.2(b) and 4.1.3(b) of the ICA.

In summary on this issue: