|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
decommission is mainframe queue manager |
« View previous topic :: View next topic » |
Author |
Message
|
Vitor |
Posted: Mon Feb 27, 2017 9:18 am Post subject: |
|
|
 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 |
|
 |
elkinsc |
Posted: Mon Feb 27, 2017 2:01 pm Post subject: Re: On the serious side |
|
|
 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 |
|
 |
bruce2359 |
Posted: Mon Feb 27, 2017 3:50 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 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 |
|
 |
|
|
|
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
|
|
|
|