Magical Thinking? Migration of zOS applications to Windows, Linux, or a server farm

July 2025

Magical Thinking - Possibly - Most likely.

Hoping for a migration success doesn't make it happen.

I believe migrations should be held accountable according to the "Magical Thinking" theory, similar to its application in AI.

I recently completed participation in a "lift and shift" migration project. I have participated in a dozen or so migrations.

"Lift and Shift" as opposed to refactoring.

Refactoring involves converting COBOL into Java, Python, C#, or another compiler language, while preserving the zOS functionality.

None of the roughly twelve zOS application migration projects (to Windows, or Linux, or server farms) that I participated in were successful.

The basic list of reasons for failure:

1. Over budget

2. Late in delivery

3. Performance issues

4. Complexity (conversion of datasets to ASCII in particular)

5. Missing functionality on the target platform

6. Over managed

7. Under managed

8. Inexperienced staff / developers

9. Incorrect tool set

Some projects were negatively affected by resistance from the zOS application development team, zOS operations team, and even zOS application users.

A successful migration should be a focused application receiving data from and sending data to z/OS interfaces. The broader the scope of the migration, the lower the probability of its success. In essence, smaller, more controlled migration projects have a higher chance of a positive outcome. 

A reality check - "Lift and Shift” is not a simple process.

1.      Identifying and transferring zOS assets is a complex endeavor

2.      Expert technical support staff / resources from zOS and Windows will be required - including Endevor administrators, IMS and CICS administrators, and of course subject matter experts

3.      A capture plan (DATA, SOURCE, JCL  . . ) is a requirement 

4. Successful execution of a thoroughly vetted plan will dictate the success of this portion of the lift and shift migration

In simple terms, migrating z/OS components requires:

1. Specialist Support: Given the large amount of z/OS inventory to be moved, you will need experts in the z/OS environment on your project team.

2. Extracting Source Files: You will have to get all the source code from your mainframe's storage systems (like Endevor, Panvalet, Librarian, IBM SCM, or GIT).

3. Handling BMS/IMS Macros: If BMS or IMS macros are stored in a third-party product (like GT Software's BMS/TS Assist/TS), they must be extracted and presented as individual mapsets or MFS formats. 

Gathering data files is the most demanding aspect of a lift and shift migration. I will discuss this further in the document (EDCDIC datasets, GDG, HSM migrated datasets, VSAM, RECFM=VB, etc.)

Think about the IBM TS1160, TS1170 tape cartridges and the picker hardware, which now have a capacity of 5 TB to 50 TB per cartridge. Does picker hardware even exist on Windows / Linux / server farms?

The download protocol matters

An FTP download without the parameter "mode binary" is ok if it can be ascertained beforehand that source code does not contain “over punched" literals.

The alternative is to use "mode binary" - this will require converting the EBCDIC source to ASCII via a utility in Windows.

No "modernization" literally means the source from zOS is already functional and in production.

In theory every COBOL program conveyed to Windows will function as it does under zOS.

No modifications are required (perhaps my optimistic viewpoint).

There is absolutely no need for a fanciful Integrated Development Environment (IDE).

The IDE is foreign territory to zOS programmers - the learning curve is long, tedious, and frustrating.

ISPF is not considered a tool that "new age" developers feel comfortable using

The most basic of zOS tools is the ISPF Editor.

SPF editing is not provided by any of the popular IDE(s).

Most IDE(s) will impose an editor of their own design or suggest a "C" / Java centric 3rd party editor.

Few if any of the editors offer the familiarity and power of the zOS ISPF editor.

Staffing issues occur because zOS application programmers are not used to working with the Visual Studio or Eclipse editor/IDE, whereas programmers who use Visual Studio or Eclipse are not familiar with ISPF as an IDE and editor.

This is a crib sheet for Visual Studio keyboard shortcuts - Yikes !

An enhanced Visual Studio IDE - Yikes Again !

The above certainly looks appealing, boasting a multitude of features, but is it suitable for a lift and shift? I doubt it.

Remember, Lift and Shift involves migrating an existing production application.

The ISPF IDE

The ISPF editor - Really Is there any other editor ?

The mechanics of development do not align well.

It is not very effective to train developers who are experts in cutting-edge technologies with zOS disciplines. These developers are used to working with a GUI interface, and some consider ISPF to be outdated and too complex.

I have observed 3 - 4 week training courses of COBOL vendor IDE(s) wrapped around VS or Eclipse directed at zOS application staff. Acceptance was questionable.

So many features in the "state of the art" IDE(s) are not germane to zOS COBOL application development practices.

In certain cases, the "state of the art" IDE(s) were reluctantly adopted, with ISPF as the default backup option.

In other instances, the IDE were too unfamiliar, rooted in Windows/Linux expertise, leading to the training being seen as unrelated to their development tasks.

Hiring contractors for the migration will lead to a variety of skill levels.

Some individuals will have zOS training, while others will be trained with cutting-edge skills.

Only a few will be adept in both areas.

Keep in mind that clients are spending money on outsourced migrations where the necessary skills may not be ideal. This will affect the delivery time commitments.

On a side note, I am skilled in zOS, but not in "state of the art" technologies.

I estimate that I could produce compiled and tested code in a quarter of the time it takes "state of the art" developers with similar tasks.

This is my endorsement for WINZOS, which I utilized for my migration activities.

I wasn't the only one; several of us struggled to understand or use the vendor provided IDE.

It's easy to get captivated by the flashy features of sophisticated IDEs, losing sight of the main goal. The focus gets lost amidst the sandbox distractions. I'm not concerned that copybook "A" is also utilized in programs A1 through AZ, or that PART-NUM is referenced 300 times in programs. Remember, this is a "lift and shift" discussion.

Keep the migrated dataset in EBCIDC

Do not even think about converting terabytes+ (petabytes?) of EBCDIC data to ASCII.

The reality of converting from EBCDIC to ASCII is hookah based nonsense (my opinion obviously).

Dataset migration

If you decide to convert zOS datasets to ASCII, then good luck!  

Testing with copies of production datasets might be acceptable.

A far better unit testing approach is, of course, testing with related subsets of production data.

I suspect that having a test bed of subset production data is mostly wishful thinking.

A test plan is of your own design. I can advise that VSAM datasets must undergo a conversion to the platform's VSAM support.

I can also advise that RECFM=VB datasets must undergo a conversion to the platform's QSAM support.

There are platform utilities available for these conversions. 

Tool sets

If the goal is "modernization," such as a graphical UI, HTML, or XML presentation, then COBOL would be the least preferred programming language (in my opinion).

Presuming the migration is to use EBCDIC datasets, the tool sets of my choice are Micro Focus Enterprise Developer (ED) and Micro Focus Enterprise Server (ES). Rocket Software acquired Micro Focus. I do not know whether the ED / ES product naming conveyed to Rocket Software.

The caveat here is the complexity of the ED IDE.

It will be foreign to zOS application developers.  

Consultant assistance is needed for setting up the appropriate environment for both ED and ES.

Many people, myself included, think that Rocket Software's ED product is too complex, and that Micro Focus Mainframe Express, despite being a discontinued product, is better suited for z/OS application developers. To tackle this issue, it would be advantageous to convince Rocket Software's sales team and management to consider providing Mainframe Express (MFE) as a more fitting option.

Essentially, Rocket Software's ED product is overly complex for z/OS developers, whereas Mainframe Express is a more appropriate choice, despite being a discontinued product. It's crucial to explore the possibility of obtaining Mainframe Express from Rocket Software as an alternative to ED.

We effectively utilized MFE for this migration task. We understood the limitations, particularly that the MFE Enterprise COBOL compiler was outdated compared to the current Micro Focus Enterprise COBOL compiler. Micro Focus and the contracted project management opposed this approach.

Aside from the user-friendliness of MFE, we identified defects in ED. Micro Focus developer management estimated that resolving these defects would take weeks to months.

When we were content that the migrated code was functional we passed it back to ED / ES

ED is compatible with assembler language.

ED generates an ED execution binary.

Nonetheless, the assembler binary will not transfer to ES.

ES does not support assembler modules.

This is unusual – even if an application suite is verified with ED – having assembler modules in ES will lead to the equivalent

of a S806 abend, indicating “MODULE NOT FOUND” or an explicit diagnostic indicating that assembler programs are not supported by ES.

Due to the ES constraint, it is necessary to convert assembler modules into COBOL.

Transforming assembler to COBOL can be challenging, particularly when the assembler programs call zOS services.

I recommend choosing WINZOS as the IDE for migrating batch applications.

Once we were satisfied that the migrated code had been thoroughly reviewed, we returned it to ED / ES.

In my opinion, Micro Focus Enterprise Server is the only production solution for migration.

Disclaimer

All opinions, findings, conclusions, or recommendations presented in this material are exclusively those of the author and do not reflect those of any other entity or organization.