IBM Mainframe Forum Index
Log In
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register

Looking for experience sharing for z/OS migration

IBM Mainframe Forums -> All Other Mainframe Topics
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Francis Tchang

New User

Joined: 03 Dec 2014
Posts: 4
Location: Hong Kong

PostPosted: Tue Dec 09, 2014 7:46 am
Reply with quote

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

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

Planned to migrate to the environment:
z/OS version 2.1
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).

Back to top
View user's profile Send private message

Active Member

Joined: 30 Nov 2013
Posts: 869
Location: The Universe

PostPosted: Tue Dec 09, 2014 9:00 am
Reply with quote

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.
Back to top
View user's profile Send private message
Ed Goodman

Active Member

Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Fri Dec 12, 2014 9:02 pm
Reply with quote

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.
Back to top
View user's profile Send private message

Active User

Joined: 01 Sep 2006
Posts: 262

PostPosted: Sat Dec 13, 2014 6:51 pm
Reply with quote

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
Back to top
View user's profile Send private message
Robert Sample

Global Moderator

Joined: 06 Jun 2008
Posts: 8569
Location: Dubuque, Iowa, USA

PostPosted: Sat Dec 13, 2014 10:25 pm
Reply with quote

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.
Back to top
View user's profile Send private message
Pete Wilson

Active User

Joined: 31 Dec 2009
Posts: 489
Location: London

PostPosted: Fri Dec 19, 2014 9:51 pm
Reply with quote

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 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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> All Other Mainframe Topics


Similar Topics
Topic Forum Replies
No new posts Need opinion on mainframe to cloud mi... General Talk & Fun Stuff 6
No new posts DB2 to Postgre migration DB2 5
This topic is locked: you cannot edit posts or make replies. COBOL/CICS with real time MQ Series u... CICS 2
No new posts DFSMShsm dump tape migration to new t... IBM Tools 1
No new posts sharing PLI storage PL/I & Assembler 2
Search our Forums:

Back to Top