| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Changing MQ system default objects |
« View previous topic :: View next topic » |
| Author |
Message
|
| krypton |
 Posted: Fri Jun 23, 2017 7:55 am Post subject: Changing MQ system default objects |
 |
|
Disciple
Joined: 14 Mar 2010
Posts: 186
|
Can we change the System objects of MQ? like adding CIPHERSPEC in "SYSTEM.DEF.SVRCONN', would it impact the normal functioning of MQ?
_________________
Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Jun 23, 2017 8:20 am Post subject: Re: Changing MQ system default objects |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| krypton wrote: |
| Can we change the System objects of MQ? like adding CIPHERSPEC in "SYSTEM.DEF.SVRCONN', would it impact the normal functioning of MQ? |
You are not to use any SYSTEM objects and certainly not any SYSTEM.*.SVRCONN channels. Apply channel auth soonest.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Fri Jun 23, 2017 9:11 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
The SYSTEM.DEF objects are templates for object definitions. You can change them in any way you see fit if you are fairly certain that the majority of objects created should have those values. However, as is mentioned before you shouldn't really use the objects in anger. ie. you should not actually be running the SYSTEM.DEF.SVRCONN channel.
So, by all means add a cipherspec to SYSTEM.DEF.SVRCONN but bear in mind it will have no effect of already created SVRCONN channels.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| hughson |
| Posted: Fri Jun 23, 2017 4:03 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Mostly SYSTEM objects should be left alone.
SYSTEM.DEF* objects however, are designed for you to change. The reason for this is to change the defaults you get when issuing a command to make a new object.
For example, if you alter the SYSTEM.DEFAULT.LOCAL.QUEUE to have MAXDEPTH of 5, then all QLOCALs you defined from then on will have a MAXDEPTH of 5 unless you explicitly state a different MAXDEPTH on the DEFINE command.
So, if you alter the SYSTEM.DEF.SVRCONN to have a value in SSLCIPH, then all SVRCONN channels you defined from then on would have that value in SSLCIPH unless you explicitly stated a different one on the DEFINE command.
In many cases the SYSTEM.DEF* objects are not actually valid usable objects as they stand, for example the SYSTEM.DEF.SENDER doesn't have a transmission queue. However, some are, and unfortunately the SYSTEM.DEF.SVRCONN is one that is a fully functioning channel.
Default CHLAUTH rules block the SYSTEM.* channels from being used.
If your intention of setting an SSLCIPH in the SYSTEM.DEF.SVRCONN is so that you can use it as a real operating SVRCONN I urge you to reconsider and make your own SVRCONN with a name appropriate to the application that is to use it.
If your intention of setting an SSLCIPH in the SYSTEM.DEF.SVRCONN is so that you can avoid remembering to set the SSLCIPH in all new defines of SVRCONNs going forward, then that is the exact purpose of the SYSTEM.DEF* objects.
As Paul notes, remember that this only affects new DEFINEs of objects subsequent to you making the change to the SYSTEM.DEF* object. It is not retrospectively added to existing objects.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Jun 25, 2017 7:12 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Quote: |
| Morag: If your intention of setting an SSLCIPH in the SYSTEM.DEF.SVRCONN is so that you can avoid remembering to set the SSLCIPH in all new defines of SVRCONNs going forward, then that is the exact purpose of the SYSTEM.DEF* objects. |
Another approach is to set critical attributes to invalid values to render the default object unusable. This enforce all new define object commands to specify these attributes, to reinforce that the correct design / configuration decisions are being made.
Too often we see application objects that take default values (particularly maxdepth, maxmsgl, defpsist) that are (luckily) OK for initial deployment, but down the track when message size / volume changes, or a real DR occurs, the app breaks.
_________________
Glenn |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
