MVSFORUMS.com

[mace]

I have a samll problem. We had a contract problem and we are at 1.6.
The are no fallback/toleration ptfs for this big of a jump.
So my question is:
If I get 1.10 place in on several packs and in commnd00 vary all other dasd off do you think it will be ok?
Any suggestions for how to gracefully get the old catalogs over, besides
doing backups incase the ipl failes??
The guy before be has our test system and production systems joined..not smart IMHO, but that is what I'm fighting.
Any and all suggestion are appreciated
_________________
Thanks
Mace

[taltyman]

A few questions.
Test and production joined, do you mean in a sysplex?
Do you have any kind of a rescue lpar? A small IPLable lpar that can get to your prod/test dasd?

Here is the way we do z/OS upgrades and maintenance.

All our z/OS target datasets are on what I will refer to as a set of cloneable res volumes.
These datasets are all SYS1 high level dataset names and are all in the master catalog.
These volumes are all named with the 1st few characters the same. Such as SY****
The last 4 characters are: position 3 - lpar ID (such as B), position 4 - maintenance level (such as P), position 5 - the character R (indicates a res volume) and the last position is a sequential ID. So for our 1.9 system the cloneable set for lpar B could be SYBMR1 - SYBMR5 and the next maintenance set could be SYBNR1 - SYBNR5.
ALL the datasets on these volumes are cataloged using a symbolic name that is built and used during the IPL by IEASYMxx.
Example:
SYMDEF(&SYSR2.='&SYSR1(1:5).2')
SYMDEF(&SYSR3.='&SYSR1(1:5).3')
SYMDEF(&SYSR4.='&SYSR1(1:5).4')
SYMDEF(&SYSR5.='&SYSR1(1:5).5')
and a listcat for one of these datasets will look like this.
NONVSAM ------- SYS1.LINKLIB
IN-CAT --- CATALOG.MASTER.SYST.ZOS19
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2008.059
RELEASE----------------2 EXPIRATION------0000.000
VOLUMES
VOLSER------------&SYSR1 DEVTYPE------X'00000000'
Entries in PROGxx for APF will look like this:
APF ADD DSNAME(SYS1.SCEERUN) VOLUME(&SYSR2.)

techniques like this make installing maintenance very easy. I simply point the load address to the IPL res volume that I want and do a load clear. Fall back is to simply IPL back on the previous set. Note that EVERY dataset on these volumes is read/execute only. Datasets like PARMLIB, IPLPARM, BRODCAST etc are NOT on these volumes. Those datasets are on other system packs.

Now to switch OS releases that opens up another set of problems. It is almost impossible to put the datasets on the same volume that they were on before. That means that sys1.xxxxxxx may have been on volume 2 and now it's on volume 3. That means you will have to do catalog work to make this a smooth transition. They way I do it is to make a copy of my master catalog. Connect it to the current catalog and recatalog all of the datasets that are part of the clone set of res volumes into this new catalog. Now when I IPL I point to a LOADxx member that points to the NEW master catalog. And to return to the old release I use the previous LOADxx that points to the old master catalog. Of course you have to do the catalog copy and recatalog work just before the IPL of the new release and when the system is quiesced so you don't lose any newly cataloged datasets or ones that may have moved. I have a batch job set up to do this quickly. Also make sure the master catalog is allowed to only be updated by people, etc that should have that priviledge. That makes it much trimmer and easier to manage.
Also with each new OS there are typically other changes that need to happen like new dataset names, etc in started tasks, PROGxx, etc. We handle that by having a prebuilt set of old/new datasets and use a batch job to update the libraries as needed between any IPL.
HTH

[warp5]

There are a lot of issues here. First, you do not have a small problem, you have a big problem. Not even Z/OS 1.7 can migrate to Z/OS 1.10, you have to be at least at Z/OS 1.8! I am currently at Z/OS 1.7 and we would like to go to Z/OS 1.10, but instead we have installed a Z/OS 1.9 to make sure that migration will function. The big issue here is if you will be sharing your catalogs between the releases. Your first problem is how are you going to build your Z/OS 1.10 system? You have to define the system from your Z/OS 1.6 and then share catalogs with it. In theory you could have a running Z/OS 1.10 and then change over to it in one big move, no sharing of catalogs between releases, etc., but do you have a chance to duplicate your entire system to test if that would function?
I just looked at the documentation, you can go from z/OS 1.6 to z/OS 1.8 to z/OS 1.10. There are some big changes in Z/OS 1.9 that can also affect your vendor products. What you can do is start upgrading all your vendor products so that they can run with the higher releases, that is a lot of work too.
Really, there are so many issues here that it is hard to give answers. Perhaps you can ask some specific questions. In any case, if you want to be on the safe side you will have to take two jumps, 1.8 first and then 1.10.

[mace]

The problem is 1.8 can't be ordered any longer.
we had a 'contract ' problem with IBM and we couldn't get 1.8, the problem was resolve just after the stop order date for 1.8.
I knew I was in trouble .
I have all 3rd party stuff up 1.8(because that is where I thought I was going) and will move then to 1.10

My BIG concern are the cats. I'm thinking I can b/u the cats they when I try to bring up 1.10 . If it fails restore the 1.6 cats back and retry at a later date repeating the process.
If the migration works then stay at 1.10.

What I mean by connected is the test system and the production system shr some cats with each other. I have never worked in a shop that did this, I have disconnt/conn cats before but never shr'ed them
_________________
Thanks
Mace

[warp5]

I would think you could still get 1.8, perhaps not exactly in the format you would like, but an installable system. Maybe your IBM SE can help find a company that has a similar setup to yours and you could borrow the tapes from them.
We share catalogs, but only one system has write access to them, other systems just read them, each system has its own master catalog, only user catalogs are shared. We share datasets and catalogs that are common to all systems (one system has write access, all others read), for example the rexx/clist datasets and the appropriate catalog.

[nevilh]

[mace]

I get
"page cannot be displayed" when I click the link
mace

[nevilh]

sorry for delay..... try http://mcevsl.mainz.de.ibm.com/factory/