| Author |
Message
|
| bkiran2020 |
 Posted: Mon Feb 27, 2017 4:27 am Post subject: decommission is mainframe queue manager |
 |
|
Master
Joined: 20 Jan 2011
Posts: 243
Location: US
|
| What are steps required to decommission the mainframe queue manager |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Feb 27, 2017 4:49 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The steps documented in the setup manual for IMQ for z/OS, but in reverse order.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 27, 2017 5:35 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You could always just unplug the mainframe.
Ideally right *after* you've found a new job, but...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| bkiran2020 |
| Posted: Mon Feb 27, 2017 5:39 am Post subject: |
|
|
Master
Joined: 20 Jan 2011
Posts: 243
Location: US
|
| bruce2359 wrote: |
| The steps documented in the setup manual for IMQ for z/OS, but in reverse order. |
 |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Feb 27, 2017 5:56 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mqjeff wrote: |
You could always just unplug the mainframe.
Ideally right *after* you've found a new job, but... |
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 27, 2017 6:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| You could always just unplug the mainframe. |
It takes more than that to stop System z hardware.
A project manager, many years ago, once asked me what was the most likely kind of hardware problem to bring a mainframe down; he was filling out a risk assessment form intended for distributed systems. I pondered for a moment and replied:
"An anti-tank missile, fired a close range. Also they'd need to know which of the nearly identical blue boxes to aim at"
He thought I was joking. So I took him into the machine room and pulled a CPU card out of the Dev machine while it was still running. He thought we'd be lynched but no-one noticed.
Like I said, a long time ago in a simpler age. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Feb 27, 2017 6:26 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| ...So I took him into the machine room and pulled a CPU card out of the Dev machine while it was still running... |
You sure that wasn't the Coke machine standing next to it? 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 27, 2017 6:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| mqjeff wrote: |
| You could always just unplug the mainframe. |
It takes more than that to stop System z hardware. |
I might have meant "destroy all the mains coming into the building" by "unplug"...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| elkinsc |
| Posted: Mon Feb 27, 2017 6:51 am Post subject: And then your DR site takes over |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 27, 2017 7:13 am Post subject: Re: And then your DR site takes over |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
 
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| elkinsc |
| Posted: Mon Feb 27, 2017 7:16 am Post subject: On the serious side |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
If I were removing a queue manager from z/OS, some steps I would consider include:
1) Stop the CHIN for a few weeks and see who complained. That is not going to eliminate all the issues that can arise from applications that people have forgotten are using MQ, but it is a start. The suggestion of weeks is serious; how many people have been caught by decommissioning something only to find an obscure job that only runs at month/quarter/year end will not complete because X is no longer available? While you may not be able to leave the queue manager in place for too long, at least a couple of weeks crossing a month end would be the least amount of time I'd recommend.
2) Set up RACF profiles to warn when anything local is connecting to te queue manager. If not using RACF, then the equivalent for the ESM you are using. Then look at the warnings received and repair the soon to be broken applications or subsystems. Once you have no warnings, then local applications are not trying to connect.
3) Is the queue manager part of a cluster? If so, remove it from the cluster and observe other member of the cluster for a while, See if anything becomes orphaned. Note - if the queue manager is a full repository, then you need to fix that first.
4) Is the queue manager part of a QSG? If so, remove it and again, see what if anything breaks.
I am sure others have more useful tips, these are just the things I think may cause grief. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 27, 2017 7:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| Vitor wrote: |
| ...So I took him into the machine room and pulled a CPU card out of the Dev machine while it was still running... |
You sure that wasn't the Coke machine standing next to it? |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 27, 2017 7:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Vitor wrote: |
| mqjeff wrote: |
| You could always just unplug the mainframe. |
It takes more than that to stop System z hardware. |
I might have meant "destroy all the mains coming into the building" by "unplug"...
|
At which point the backup power cuts in. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 27, 2017 7:35 am Post subject: Re: On the serious side |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| elkinsc wrote: |
If I were removing a queue manager from z/OS, some steps I would consider include:
1) Stop the CHIN for a few weeks and see who complained. That is not going to eliminate all the issues that can arise from applications that people have forgotten are using MQ, but it is a start. The suggestion of weeks is serious; how many people have been caught by decommissioning something only to find an obscure job that only runs at month/quarter/year end will not complete because X is no longer available? While you may not be able to leave the queue manager in place for too long, at least a couple of weeks crossing a month end would be the least amount of time I'd recommend.
2) Set up RACF profiles to warn when anything local is connecting to te queue manager. If not using RACF, then the equivalent for the ESM you are using. Then look at the warnings received and repair the soon to be broken applications or subsystems. Once you have no warnings, then local applications are not trying to connect.
3) Is the queue manager part of a cluster? If so, remove it from the cluster and observe other member of the cluster for a while, See if anything becomes orphaned. Note - if the queue manager is a full repository, then you need to fix that first.
4) Is the queue manager part of a QSG? If so, remove it and again, see what if anything breaks.
I am sure others have more useful tips, these are just the things I think may cause grief. |
The technical decommissioning of the queue manager is the easy part. Working out what is dependent on it is harder. If you have ENDEVOR or similar source code control, you may be able to proactively determine the applications that include MQ libraries and reach out to the owners to ensure they're not using the queue manager in question.
In addition to the excellent suggestions of my worthy associate.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Feb 27, 2017 8:47 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
[
He thought I was joking. So I took him into the machine room and pulled a CPU card out of the Dev machine while it was still running. He thought we'd be lynched but no-one noticed.
Like I said, a long time ago in a simpler age. |
I've seen a MF system get really sick when someone messed up a Storage system update. That was at a major bank and at month end. The Admin who auth'd the update was never seen again.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
