1
z/OS Server / Re: Upgrade and my 'personal' thoughts
« on: March 13, 2019, 09:05:28 AM »
Hi
Don't missunderstand me at all, as I've said a couple of times at ODUG-meetings:
- I do think that CMOD is doing what it's supposed to do
- I kind of like it, it's more or less self-running.
But..
I've upgraded CMOD a couple of times, and it really is a pain that there's no easy way of 'downgrading'.
regarding..
"
..I know very little product in the market that allow a downgrade without doing some kind of restore..
"
Well I can name a bunch of them.
Like DB2 on z/OS, where you can run 2 version on different members in a
datasharing group, and if you've upgraded to let's say V12 you can then goback to V11.
Until you've been running for a couple of weeks and decide to go to 'new function mode'.
Of course we will do extending tests in our different environment before going into production, but you can't
test everything.
I don't really see the point of restoring some segment tables, because if you've loaded a Bank-statement, and the
Customer has retrieved it, then you just can't remove it by using restore.
We don't keep 1 week of input files saved, they can be deleted/overwritten after the've been succesfully loaded.
(If it's loaded then it's stored in CMOD, why keep backups of them ??).
We also load from other environment's(except z/OS) like windows-clients, and we don't have any control of those.
"..What I did many times, was to clone the production database in a test environment.."
You're running on a distributed environment I presume ?
It's not that easy on z/OS.
And if you don't run with the Storage Set/Node dependecies, then it's not like your production environment, and hence the
test are not complete.
@Justin: I would say that if we ran into some problem after a couple of days, then I would say 'go forward'.
I'm more into be able, in an easy way, of being able to downgrade after a couple of hours in an easy way.
But thank for your 'respect' :-D
/Hakan
Don't missunderstand me at all, as I've said a couple of times at ODUG-meetings:
- I do think that CMOD is doing what it's supposed to do
- I kind of like it, it's more or less self-running.
But..
I've upgraded CMOD a couple of times, and it really is a pain that there's no easy way of 'downgrading'.
regarding..
"
..I know very little product in the market that allow a downgrade without doing some kind of restore..
"
Well I can name a bunch of them.
Like DB2 on z/OS, where you can run 2 version on different members in a
datasharing group, and if you've upgraded to let's say V12 you can then goback to V11.
Until you've been running for a couple of weeks and decide to go to 'new function mode'.
Of course we will do extending tests in our different environment before going into production, but you can't
test everything.
I don't really see the point of restoring some segment tables, because if you've loaded a Bank-statement, and the
Customer has retrieved it, then you just can't remove it by using restore.
We don't keep 1 week of input files saved, they can be deleted/overwritten after the've been succesfully loaded.
(If it's loaded then it's stored in CMOD, why keep backups of them ??).
We also load from other environment's(except z/OS) like windows-clients, and we don't have any control of those.
"..What I did many times, was to clone the production database in a test environment.."
You're running on a distributed environment I presume ?
It's not that easy on z/OS.
And if you don't run with the Storage Set/Node dependecies, then it's not like your production environment, and hence the
test are not complete.
@Justin: I would say that if we ran into some problem after a couple of days, then I would say 'go forward'.
I'm more into be able, in an easy way, of being able to downgrade after a couple of hours in an easy way.
But thank for your 'respect' :-D
/Hakan