Looking for experience sharing for z/OS migration

Francis Tchang · New User Joined: 03 Dec 2014 Posts: 4 Location: Hong Kong

My department would like to migration from OS/390 to z/OS. The situation is as below:

Current environment:
OS/390 version 2.9
CICS/ESA 4.1
DB2 version 7
COBOL/OS390 version 1.2

Planned to migrate to the environment:
z/OS version 2.1
CICS/TS 4.2
DB2 version 10 or 11
Enterprise COBOL 4.2

Grateful to have your experience sharing (if you performed the similar migration) about any problem/consideration we should pay attention to and any hiccup(s) occurred during your migration (and how you fixed it).

Thanks!!!

steve-myers · Posted: Tue Dec 09, 2014 9:00 am

I can only offer thoughts about converting to z/OS.

The JES2 for z/OS 2.1 will not warm start from the OS/390 SPOOL volumes.
Similarly, if you must back off, the OS/390 JES2 will not warm start from the z/OS 2.1 JES2 SPOOL volumes.
If you have JES2 reader exits - I don't have the numbers memorized - you will have to rewrite them. This is not trivial.
Jobs submitted through the internal reader - most likely, most of your jobs - will not be processed by the traditional JES2 reader exits. There are new exits for this purpose. You will have to write them. This is not trivial.
All other JES2 exits will have to be reasssembled. Other than that, I don't think you will have to make any changes to them. I haven't followed this in great detail so I can't offer any insights here.
I think you'll find all of your vendor products will need to be updated.
Assembler programs using WTO with QREG0 will have to be updated. The good news is the updates should run on OS/390, so you can do those updates before the conversion.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

COBOL conversion gotchas that I remember:

- Default compiler options were not in place for old version, so needed updated in new version

- Static dynamic load modules don't work the same

- Comparisons works a little differently now, if you have numbers comparing to strings of numbers for example

We were coming from COBOL II, so these may not apply to your situation.

IBM has a fantastic migration guide that covered all of this stuff. Our problem was that no one wanted to read it before they started converting. Or to be more precise, they wanted everyone ELSE to read it, then argue with them about the need to do any of the prep work.

nevilh · Active User Joined: 01 Sep 2006 Posts: 262

I assume you have already talked to IBM about this. I am sure what I am about to tell you is similar to what they told you.
There is no migration path from OS390 to z/OS 2.1. Your only chance is to build a 2.1 system and then migrate the Applications.
You cannot IPL the system with 2.1 and then stop the system and IPL with the old OS390 system . It simply will not work, there are no Toleration PTF's for the old OS390 and the DFP versions between the two systems are not compatible

Robert Sample · Posted: Sat Dec 13, 2014 10:25 pm

You are unlikely to find anyone with direct experience in such a migration -- not on this forum, not on ANY forum anywhere. OS/390 2.9 came out in 2000, so you are wanting to jump 13 years of systems changes.

Broadly speaking, you don't really want to consider this a migration -- you want to consider this a brand new installation of z/OS and proceed on that basis. The usual mechanics of upgrades (applying toleration -- also called coexistence -- PTFs, bringing up the new system for testing, then reverting back to fix problems) simply is not possible with a 13-year gap. I would recommend extra time for application testing since there are a LOT of differences between the circa-2000 products you mention in your post and the circa-2013 products. Applications may not behave as you expect in the new environment.

Pete Wilson · Posted: Fri Dec 19, 2014 9:51 pm

Wow, very ambitious and a fantastic opportunity. I hope you have people who know both environments rather well.

As already suggested, this has to be considered a data/application level migration into an entirely separate new Z/OS environment that you have set up. By separate, I would suggest physically separated at hardware or IODF level otherwise you run a serious risk of corruption. I think it would be impossible to run OS390 and Z/OS together within a sysplex anyway.

One of the first steps would be to identify anything you can avoid taking across to the new Z/OS environment including legacy applications and OEM/ISV software. The less you have to set up there the better. Many Z/OS features can replace old ISV functions.

If you have any applications that link to off-host windows or unix somehow and which must be kept synchronised with the host OS390 then how will you do that in the new Z/OS environment, and do you need to at all. Many things can be run within Z/OS which can support Linux and other O/S's internally.

You need to make sure the new Z/OS environment is set up using very well defined future proof standards for everything from RACF, DFSMS, usercatalogs, volsers, dataset naming standards, backup/archiving and utilising as many of the up to date features as possible. If you fail to get good standards in place at this stage it will plague you forever. Also think big...design for much larger growth than you expect so you don't limit yourself and have to redesign later. Go for largest capacity volume as practicable to limit your UCB & PAV requirements, especially if using or planning to use PPRC or suchlike to mirror the environment.

You need consider your Disaster Recovery procedures. Can they deal with two entirely separate environments that may have to co-exist for an extended period?

Assuming the OS390 & Z/OS are at the least in separate sysplexes, and if you're running applications in parallel on both for testing, you have to work out how to port the data from OS390 to Z/OS (never the reverse!). Chances are it may have to be via a network connection if you don't have stand-alone native tape. You may have to do this in bulk and on a regular basis and if you have a large amount of data? it could be a challenge in itself. You have to consider not just DASD datasets but any that have been archived and also Tape files.