Successful BS2000 migration at ITZBund

The effect of cold beer or other stimu­la­ting drinks is something that everyone knows. We had an entirely diffe­rent experi­ence in this field over the past year. However, for us it had nothing to do with any treat to drinks but hard work invol­ving the tool-based migration from BS2000 to Linux of a complex software project to manage alcoho­lic bever­a­ges. As usual, a series of new challenges arose from this. This report presents knowledge and experi­ence gained from the coope­ra­tion between Infor­ma­ti­ons­tech­nik­zen­trum Bund (ITZBund) and us.

New BIBER and ZEBRA Enclosures

ITZBund is the IT service provi­der of the Federal Govern­ment. About 2,400 employees advise, support and ensure the ongoing opera­tion as well as provi­sion of infor­ma­tion technology and speci­ally develo­ped IT soluti­ons. Two IT soluti­ons (so-called proce­du­res) assess­ment and collec­tion of beer or alcohol taxes are expec­ted to be migra­ted in the project. The proce­du­res BIBER (beer tax calcu­la­tion) and ZEBRA (centra­li­sa­tion of distil­ling under licence) have been histo­ri­cally evolved and in service for more than 30 years. They produce appro­xi­m­ately 220,000 tax assess­ments with a tax revenue of 740 million euros every year. They were handled on BS2000 while using typical BS2000 tools. In terms of technology, both proce­du­res consist of 60 inter­ac­tive online programs (IFG masks) control­led by the transac­tion monitor UTM and of 300 batch programs (COBOL), and for the control and adminis­tra­tion of which about 200 SDF jobs were used. The entire data is managed in approx. 220 SAM, ISAM and LEASY files.

What you can do today…

We have an in-house develo­ped toolbox named pecBOX (pro et con – Toolbox for Software Migration). All neces­sary migration paths of the project could be supported with this toolbox. The follo­wing table shows these paths and the migration tools used.

Legacy system (BS2000)	Target system (Linux)	Migration tool
COBOL	Java	CoJaC
JCL (SDF)	Perl	S2P
Masks (IFG)	HTML, JavaScript	MaTriX
Files (SAM)	Linux-Files	FiRe
Files (ISAM, LEASY)	Oracle	FiRe
Middle­ware (UTM)	MidaS	–

The fact that quali­ta­tively good migration tools shorten the project duration and trim the budget is nothing new. The project could only so be execu­ted within the speci­fied, tightly schedu­led timeframe. Even the popular saying “ready-to-use tools don’t exist” was found to be true. As it happened, CoJaC and FiRe, for example, had to learn “backward reading” of LEASY files. We favour an exten­sion of our tools over a manual adjus­t­ment of the source code for these adapt­a­ti­ons. In the early stages of the project, it cannot be estima­ted why and how often already conver­ted programs must be conver­ted all over again. A manual
adapt­a­tion would have to be repea­ted each time. Since all tools are based on descrip­tive models and meta tools, they can be adapted within an accep­ta­ble timeframe. In addition, pecBOX includes system compon­ents for the target system. MidaS (Middle­ware as a Service) is an example of this. This tool develo­ped by us replaces the BS2000 transac­tion monitor UTM in the target system. An early load test demons­tra­ted that the perfor­mance of MidaS meets the practi­cal requi­re­ments and thus the use of paid standard software is not necessary.

Knowledge is Power

The first phase of a migration project implies a tool-based reverse enginee­ring with our tool Flow Graph Manipu­la­tor. In that regard, special atten­tion is paid to those aspects which bear risks for the migration. In the present case, these mainly occur­red in data reposi­tory. Accor­ding to the defined migration path, the ISAM and LEASY files were expec­ted to be migra­ted to Oracle tables by FiRe. During the analy­sis, one distinc­tive feature was identi­fied: during program execu­tion, the dynamic contents of the files are enriched by static contents (constants) from the programs and then output by a printer inter­face. The encoding of data and source texts (inclu­ding constants) had to be unified even before the migration. This point did not only apply to an adapt­a­tion of FiRe but it also encom­pas­sed further aspects of the migration. The sooner such suppo­sedly minor aspects are recog­nised, the lower is the effort to remedy them since a confi­gu­ra­tion of the migration tools may alone be sufficient.

Practice makes perfect

Follo­wing a detailed analy­sis and equip­ped with a full toolbox, one should assume that the real migration can be started straigh­ta­way. Our experi­ence proved other­wise. The combi­na­tion of tools and custo­mer requi­re­ments for the first time posed unknown challenges. For this reason, a pilot migration was carried out before the overall project and that provi­ded a verti­cal section through the appli­ca­tion (mask(s), program(s), jobs, data). This enabled us to once go through all migration paths and to use the tools and techno­lo­gies (at least partly). This proce­dure turned out to be useful since we gained important insight into many comple­xi­ties. Thus, for example, we decided to outsource printing to a separate tool and not to map it via soluti­ons existing in the runtime systems. These would have not been suffi­ci­ent for the custo­­mer-speci­­fic requi­re­ments. As a result of this proce­dure, additio­nal requi­re­ments were identi­fied and imple­men­ted before the real migration. This reduced the risk of having to carry out adapt­a­tion of the tools besides the task of the migration.

Divide et impera

The chall­enge of a migration project that reflects all facets of legacy systems is to reduce the comple­xity of the migration and test proces­ses. This was taken into account in the present project by our partner ITZBund by dividing the appli­ca­tion into indivi­dual packa­ges. This division was based on (business) proces­ses which were meaningfully grouped into packa­ges. The thus possi­ble paral­le­li­sa­tion of migration and test offered many benefits in the project. An essen­tial element was also the commu­ni­ca­tion with the ITZBund experts. They know their proces­ses and could provide valid test data. This data and the defined proces­ses also offered the possi­bi­lity of automa­tion. For this, the proces­ses and the suita­ble data were standar­di­sed and trans­fer­red to test cases which enorm­ously reduced the effort requi­red for the test. The division into indivi­dual packa­ges led to the fact that migration and test were manageable at any time and that an overview of the project progress was always available.

You live and learn

The project was switched into produc­tive opera­ti­ons on 22 August 2016. This project again proved that the tool-based approach practi­sed by us works well. This applies in parti­cu­lar to automa­ted language conver­sion from COBOL to Java with the CoJaC tool. Techno­lo­gies and tools can be as fully develo­ped and tested as you like, every migration project brings in new challenges. This also means a not at all insigni­fi­cant effort for our project partner that ITZBund provi­ded through exper­tise and active coope­ra­tion – what could be an example for many others. Only such a close colla­bo­ra­tion can lead migration projects to great success.