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 Previous  1, 2
 decommission is mainframe queue manager « View previous topic :: View next topic » 
Author Message
Vitor
PostPosted: Mon Feb 27, 2017 9:18 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

smdavies99 wrote:
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.


Being fed to the card punch was a traditional punishment.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
elkinsc
PostPosted: Mon Feb 27, 2017 2:01 pm    Post subject: Re: On the serious side Reply with quote

Centurion

Joined: 29 Dec 2004
Posts: 138
Location: Indy

Vitor wrote:
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.


An excellent suggestion!

Another thing to do is to publicize the intent and proposed date for the final plug pulling. People with institutional knowledge (and there are still some of those rare and useful people around) might remember some occasional applications that might go unnoticed - especially if your company has not been terribly disciplined about source code on all platforms - and let you know about those.

Hopefully by combining these techniques when you do turn it off there will be little or no heartache caused, except to those of us who feel oddly loyal to the platform.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Feb 27, 2017 3:50 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

Alter (rename) the started task qmgr and chin procs so the qmgr cannot start. Do nothing else for several weeks or months until nobody complains.
Only then make pre-decom backups of all pieces and parts -in anticipation of having to restore it all.

Check for automation (job scheduler) for all references to the qmgr.
_________________
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
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 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.