Discussion:
migration to new z/OS release
(too old to reply)
Tony Thigpen
2018-01-02 18:32:55 UTC
Permalink
I am just now starting the research on migrating an os/390 machine to
z/OS. Currently, it is running on a z/10, and we will use an z/OS that
is compatible with the z/10, so a hardware conversion is not an issue.

This OS/390 system has been managed by multiple out-sourcers and
bastardized to the point that we would like to consider just installing
a new, clean z/OS, then migrating the data to it. This is something I
have done many times on z/VSE, but not on z/OS and I know it's not as
simple due to the ICF catalogs and such found on z/OS.

Does anybody have a favorite document that describes such a move and the
things we need to consider? Pointers to "free" tools would also be
helpful as we decide which way to migrate this box.
--
Tony Thigpen

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Chuck Kreiter
2018-01-02 18:44:02 UTC
Permalink
My first install was OS/390 2.8 to upgrade an OS/390 1.2 system and I did exactly what you are proposing. To keep catalog issues from biting me, I'd do an export and import of the user catalogs to new clusters between tests.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen
Sent: Tuesday, January 2, 2018 1:34 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: migration to new z/OS release

I am just now starting the research on migrating an os/390 machine to z/OS. Currently, it is running on a z/10, and we will use an z/OS that is compatible with the z/10, so a hardware conversion is not an issue.

This OS/390 system has been managed by multiple out-sourcers and bastardized to the point that we would like to consider just installing a new, clean z/OS, then migrating the data to it. This is something I have done many times on z/VSE, but not on z/OS and I know it's not as simple due to the ICF catalogs and such found on z/OS.

Does anybody have a favorite document that describes such a move and the things we need to consider? Pointers to "free" tools would also be helpful as we decide which way to migrate this box.

--
Tony Thigpen

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Finnell
2018-01-02 19:21:49 UTC
Permalink
Several areas to consider in migration plan.


1)Exits and Usermods
2)PARMLIB changes
3)WLM migration
4)User Catalogs
5)SMP/E
6)RACF and UADS
7)Backup/Backout
 
Work with SE/ISV to develop plan that everyone is comfortable with.
You may want to lay down a minimal starter system to build your new system. IBM used to deliver MCNVTCAT as part of system upgrades but for some goofy reason decided to drop support.  Alister Grey was smitten enough that he wrote his own RCNVTCAT and placed it on CBT.
 
Brian Westerman does this for a living and if you need support or guidance he'll probably chime in eventually.
In a message dated 1/2/2018 12:45:28 PM Central Standard Time, kreiter_ibm-***@TWC.COM writes:
 
My first install was OS/390 2.8 to upgrade an OS/390 1.2 system and I did exactly what you are proposing. To keep catalog issues from biting me, I'd do an export and import of the user catalogs to new clusters between tests.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2018-01-02 19:08:00 UTC
Permalink
Couple of thoughts

1) Find and download all the MIGRATION GUIDES from IBM

2) Find and download all of the Marna Walle Presentations on Migration from share.org

3) Two ways to do this. One is to just install the new z/OS and then port the applications and test. There are some major changes in control blocks from your release and up. So you may want to validate what will work. Migration guides will help.


UCB moved to above the line
TCB moved to above the line
Language Environment changes need to be reviewed (THDTERMACT and Storage)
Which version of the z/OS? If z/OS V2 + COBOL Compiler V5+ then you need to ensure application libraries are PDS/e

Some other I am sure

But Export/Import the cats will be a good process

Lizette
Post by Chuck Kreiter
-----Original Message-----
Behalf Of Tony Thigpen
Sent: Tuesday, January 02, 2018 11:34 AM
Subject: migration to new z/OS release
I am just now starting the research on migrating an os/390 machine to z/OS.
Currently, it is running on a z/10, and we will use an z/OS that is
compatible with the z/10, so a hardware conversion is not an issue.
This OS/390 system has been managed by multiple out-sourcers and bastardized
to the point that we would like to consider just installing a new, clean
z/OS, then migrating the data to it. This is something I have done many times
on z/VSE, but not on z/OS and I know it's not as simple due to the ICF
catalogs and such found on z/OS.
Does anybody have a favorite document that describes such a move and the
things we need to consider? Pointers to "free" tools would also be helpful as
we decide which way to migrate this box.
--
Tony Thigpen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-01-02 20:52:24 UTC
Permalink
Most likely, we will be going to 1.13. The system is a semi-stagnate
system and a lot of the newer bells and whistles are not needed. We need
to leave the os/390 so we can utilize flash on our 8870s and use our VTls.

Tony Thigpen
Post by Lizette Koehler
Couple of thoughts
1) Find and download all the MIGRATION GUIDES from IBM
2) Find and download all of the Marna Walle Presentations on Migration from share.org
3) Two ways to do this. One is to just install the new z/OS and then port the applications and test. There are some major changes in control blocks from your release and up. So you may want to validate what will work. Migration guides will help.
UCB moved to above the line
TCB moved to above the line
Language Environment changes need to be reviewed (THDTERMACT and Storage)
Which version of the z/OS? If z/OS V2 + COBOL Compiler V5+ then you need to ensure application libraries are PDS/e
Some other I am sure
But Export/Import the cats will be a good process
Lizette
Post by Chuck Kreiter
-----Original Message-----
Behalf Of Tony Thigpen
Sent: Tuesday, January 02, 2018 11:34 AM
Subject: migration to new z/OS release
I am just now starting the research on migrating an os/390 machine to z/OS.
Currently, it is running on a z/10, and we will use an z/OS that is
compatible with the z/10, so a hardware conversion is not an issue.
This OS/390 system has been managed by multiple out-sourcers and bastardized
to the point that we would like to consider just installing a new, clean
z/OS, then migrating the data to it. This is something I have done many times
on z/VSE, but not on z/OS and I know it's not as simple due to the ICF
catalogs and such found on z/OS.
Does anybody have a favorite document that describes such a move and the
things we need to consider? Pointers to "free" tools would also be helpful as
we decide which way to migrate this box.
--
Tony Thigpen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-01-02 21:03:15 UTC
Permalink
Post by Tony Thigpen
Most likely, we will be going to 1.13. The system is a semi-stagnate
system and a lot of the newer bells and whistles are not needed. We need to
leave the os/390 so we can utilize flash on our 8870s and use our VTls.
​Hum, I am wondering; are you planning to share catalogs between z/OS 1.13
and OS/390? If so, I hope that there exists catalog compatibility
maintenance which allows this.​ I do know that, through the years, IBM has
made updates to ICF catalogs which introduce new records and changed
records which cannot be processed (and at times even tolerated) by back
level code.
Post by Tony Thigpen
Tony Thigpen
--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-01-02 21:10:19 UTC
Permalink
No sharing. Just one LPAR.

Tony Thigpen
Post by John McKown
Post by Tony Thigpen
Most likely, we will be going to 1.13. The system is a semi-stagnate
system and a lot of the newer bells and whistles are not needed. We need to
leave the os/390 so we can utilize flash on our 8870s and use our VTls.
​Hum, I am wondering; are you planning to share catalogs between z/OS 1.13
and OS/390? If so, I hope that there exists catalog compatibility
maintenance which allows this.​ I do know that, through the years, IBM has
made updates to ICF catalogs which introduce new records and changed
records which cannot be processed (and at times even tolerated) by back
level code.
Post by Tony Thigpen
Tony Thigpen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-01-02 19:41:29 UTC
Permalink
How new is "new"? If you are free to do so, I would recommend devising a consist rollout and service plan, taking advantage of static system symbols in, e.g., volume naming.

Likewise, do you have the freedom to change the LPAR setup, or do you have to go with what's on the old machine.

In general, the more you think out and document things up front, the less hassle you will have.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Tony Thigpen <***@VSE2PDF.COM>
Sent: Tuesday, January 2, 2018 1:34 PM
To: IBM-***@listserv.ua.edu
Subject: migration to new z/OS release

I am just now starting the research on migrating an os/390 machine to
z/OS. Currently, it is running on a z/10, and we will use an z/OS that
is compatible with the z/10, so a hardware conversion is not an issue.

This OS/390 system has been managed by multiple out-sourcers and
bastardized to the point that we would like to consider just installing
a new, clean z/OS, then migrating the data to it. This is something I
have done many times on z/VSE, but not on z/OS and I know it's not as
simple due to the ICF catalogs and such found on z/OS.

Does anybody have a favorite document that describes such a move and the
things we need to consider? Pointers to "free" tools would also be
helpful as we decide which way to migrate this box.

--
Tony Thigpen

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-01-02 20:54:57 UTC
Permalink
"new" is, in this case, z/OS 1.13. We need to be able to flash our 8870
and also use our VTLs.

I can do what ever I want to the IOCP. I currently have to manage it and
the OSAs with z/VM as OS/390 does not understand a z10. I also have a
spare z10 I will use as a sandbox to test on.

Tony Thigpen
Post by Seymour J Metz
How new is "new"? If you are free to do so, I would recommend devising a consist rollout and service plan, taking advantage of static system symbols in, e.g., volume naming.
Likewise, do you have the freedom to change the LPAR setup, or do you have to go with what's on the old machine.
In general, the more you think out and document things up front, the less hassle you will have.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Tuesday, January 2, 2018 1:34 PM
Subject: migration to new z/OS release
I am just now starting the research on migrating an os/390 machine to
z/OS. Currently, it is running on a z/10, and we will use an z/OS that
is compatible with the z/10, so a hardware conversion is not an issue.
This OS/390 system has been managed by multiple out-sourcers and
bastardized to the point that we would like to consider just installing
a new, clean z/OS, then migrating the data to it. This is something I
have done many times on z/VSE, but not on z/OS and I know it's not as
simple due to the ICF catalogs and such found on z/OS.
Does anybody have a favorite document that describes such a move and the
things we need to consider? Pointers to "free" tools would also be
helpful as we decide which way to migrate this box.
--
Tony Thigpen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Timothy Sipples
2018-01-03 07:38:52 UTC
Permalink
You can go all the way up to z/OS 2.2 on an IBM z10 machine, and (if you
hurry!) z/OS 2.2 is still orderable through ShopZ. I would go place that
order, right now. End of Marketing for z/OS 2.2 is January 29, 2018, but I
would try to avoid cutting it too close. Match up the middleware,
compilers, and tools too, of course.

IBM's introduction of Multi-Version Measurement (MVM) in early 2017
*should* mean either the same monthly license operating system charge or a
negligible difference, and with no financial urgency to beat a Single
Version Charge deadline. However, you will remain at "status quo" full
machine capacity licensing (and on z10 MSUs) unless and until you get
OS/390 (and any 31-bit IPL'ed z/OS, which was technically possible up
through z/OS 1.5) completely removed from that machine. "Better late than
never" in getting that fixed.

z/OS 2.2 is also IBM supported, and that's terrific because you'll be able
to get IBM's help, open PMRs, etc. on the destination side of this
migration. Moreover, there's no End of Service date announced yet for z/OS
2.2. If IBM follows its past practice, z/OS 2.2 will reach End of Support
on September 30, 2020, and there will be up to 24 months of fee-based
Extended Support available in a pinch. With z/OS 2.2 you'll also be better
positioned to forge ahead to a more efficient machine on a newer z/OS
release.

Absent a really compelling reason otherwise, I'd forge as far ahead as you
can. And there's at least one compelling reason to do exactly that: IBM
support on the target. Regardless of your final decision, I'd put in an
order, now -- well, OK, after a *little* due diligence, but don't wait too
long. This week would be a really good idea.

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, AP/GCG/MEA
E-Mail: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Timothy Sipples
2018-01-03 07:48:42 UTC
Permalink
Unfortunately the vendor wants to charge us an unreasonable
amount for this "custom coding".
OK, but there are some assumptions in that short sentence that might not
hold. One is that "the vendor" must necessarily be the actor/doer. Another
is that "coding" is necessarily involved in addressing this business need.

Are we confident those assumptions are correct?

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, AP/GCG/MEA
E-Mail: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Michael Knoll - XPS
2018-01-03 08:05:51 UTC
Permalink
Hi,
we're offering a product called HostDrive that would be able to do what
you're searching for at a reasonable price (http://www.xps-software.com).
Using HostDrive you're able to automate the file transfer process from IBM z
to a Java platform where our Java server application will receive the data
and carry out any task you desire. If necessary, the needed business logic
can be implemented e. g. using a Java program. Please contact me if that may
be of interest to you!

Kind regards

Michael Knoll
XPS Software GmbH
Untere Hauptstr. 2
85386 Eching
Germany
Tel: +49-(0)89-456989-13
Fax: +49-(0)89-456989-29
Web: http://www.xps.biz
Geschäftsführer/CEOs:
Georg Moser
Michael Knoll
Heinrich Kislinger
HRB München 79069



-----Ursprüngliche Nachricht-----
Von: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] Im
Auftrag von Timothy Sipples
Gesendet: Mittwoch, 3. Januar 2018 08:50
An: IBM-***@LISTSERV.UA.EDU
Betreff: Re: JZOS on open systems question
Unfortunately the vendor wants to charge us an unreasonable amount for
this "custom coding".
OK, but there are some assumptions in that short sentence that might not
hold. One is that "the vendor" must necessarily be the actor/doer. Another
is that "coding" is necessarily involved in addressing this business need.

Are we confident those assumptions are correct?

----------------------------------------------------------------------------
----------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, AP/GCG/MEA
E-Mail: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Frank Swarbrick
2018-01-04 00:14:44 UTC
Permalink
I'm never confidant in my assumptions. :-) What are you thinking? Certainly if we can do something "without coding" we would be interested. We're also interested in any solution NOT requiring z/OS. (Seems an odd requirement to discuss on ibm-main, but there you have it.)
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Timothy Sipples <***@SG.IBM.COM>
Sent: Wednesday, January 3, 2018 12:49 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: JZOS on open systems question
Unfortunately the vendor wants to charge us an unreasonable
amount for this "custom coding".
OK, but there are some assumptions in that short sentence that might not
hold. One is that "the vendor" must necessarily be the actor/doer. Another
is that "coding" is necessarily involved in addressing this business need.

Are we confident those assumptions are correct?

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, AP/GCG/MEA
E-Mail: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2018-01-03 21:21:44 UTC
Permalink
Post by Chuck Kreiter
I am just now starting the research on migrating an os/390 machine to z/OS. Currently, it is running on a z/10, and we will use an z/OS that is compatible with the z/10, so a hardware conversion is not an issue.
This OS/390 system has been managed by multiple out-sourcers and bastardized to the point that we would like to consider just installing a new, clean z/OS, then migrating the data to it. This is something I have done many times on z/VSE, but not on z/OS and I know it's not as simple due to the ICF catalogs and such found on z/OS.
Does anybody have a favorite document that describes such a move and the things we need to consider? Pointers to "free" tools would also be helpful as we decide which way to migrate this box.
--
Tony Thigpen
Tony:

Take a look at tools on cbttape.org <http://cbttape.org/>. Myself, I have an old copy of the IBM freebie that came on the IPO and maybe PDO that generates the idcams control cards.
A long time ago IBM dropped the programs but thank goodness it was kept by the people who work in the real world.

I have always been an advocate of keeping datasets out of the mastercat. A *LONG* time ago we used to protect the master cat by putting a password on it, RACF and IBM’s willingness to standardized things helped out a lot.

Back in the early days of MVS, I had one of the joys of answering calls about DSN not found when people didn’t use a standard installation dsn. AT the time we were putting on massive amounts of fixes and new resvolumes were going at 1 every two months. It finally hurt people enough that they learned the hard way. When we got semi stable we put a password on updates to the master cat. That stopped that dead in the tracks. We got nasty feedback from the users and we just pointed at the standards manual. I wish we could have had RACF at the time, but management wanted a stable MVS before going after dsn standards.

Ed


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...