ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » decommission is mainframe queue manager

Post new topic  Reply to topic Goto page 1, 2  Next
 decommission is mainframe queue manager « View previous topic :: View next topic » 
Author Message
bkiran2020
PostPosted: Mon Feb 27, 2017 4:27 am    Post subject: decommission is mainframe queue manager Reply with quote

Master

Joined: 20 Jan 2011
Posts: 243
Location: US

What are steps required to decommission the mainframe queue manager
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Feb 27, 2017 4:49 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
mqjeff
PostPosted: Mon Feb 27, 2017 5:35 am    Post subject: Reply with quote

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
View user's profile Send private message
bkiran2020
PostPosted: Mon Feb 27, 2017 5:39 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Mon Feb 27, 2017 5:56 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Mon Feb 27, 2017 6:11 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Mon Feb 27, 2017 6:26 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Mon Feb 27, 2017 6:45 am    Post subject: Reply with quote

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
View user's profile Send private message
elkinsc
PostPosted: Mon Feb 27, 2017 6:51 am    Post subject: And then your DR site takes over Reply with quote

Centurion

Joined: 29 Dec 2004
Posts: 138
Location: Indy

.....
Back to top
View user's profile Send private message
mqjeff
PostPosted: Mon Feb 27, 2017 7:13 am    Post subject: Re: And then your DR site takes over Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

elkinsc wrote:
.....

_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
elkinsc
PostPosted: Mon Feb 27, 2017 7:16 am    Post subject: On the serious side Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Mon Feb 27, 2017 7:32 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Mon Feb 27, 2017 7:33 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Mon Feb 27, 2017 7:35 am    Post subject: Re: On the serious side Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Mon Feb 27, 2017 8:47 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » decommission is mainframe queue manager
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.