| Author |
Message
|
| bruce2359 |
 Posted: Fri Aug 09, 2013 6:13 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| JosephGramig wrote: |
Hmmm, I would not pick z/OS Qmgrs for Full Repositories unless I had no other choice. Surely, you can afford two Linux VMs... |
If your objective is the most reliable and robust configuration, why would you exclude (settle for anything less than) z/OS?
| JosephGramig wrote: |
| ... I'm saying z/OS will complicate the cluster channel configuration especially if it is in a SysPlex. |
I will agree that system admin on z/OS is more complicated than on the midrange platforms. HA on midrange platforms ups the complication factor, but offers significant benefits. z/OS Parallel Sysplex is the quintessential HA implementation. What exactly do you see as the problem with configuration if it is in a sysplex?
_________________
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 |
|
 |
| PeterPotkay |
| Posted: Fri Aug 09, 2013 6:34 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The design of having 2 full repositories is itself highly available. Its why IBM decided on having 2 and not 1 FRs in a best practices aligned MQ cluster.
2 virtual servers on separate ESX clusters is going to be plenty available, because you only need 1 of them for a 100% functional cluster than can run forever.
If none of your partial QMs are on z/OS I would argue strongly against putting just the FRs on z/OS due to the complications with exits (if you were to use them) and the added complexity.
I agree that any one QM on z/OS* is likely going to be more available than any one mid tier QM.
(The most stable platform in the hands of noobs is not going to be stable.)
But if you are comparing the availability of at least one of a pair of z/OS QMs to the availability of at least one of a pair of virtual QMs, then the margin closes significantly. And in my mind, it closes to the point of irrelevance. K.I.S.S. and put those FRs on mid tier servers.
If your expertise is z/OS, if the majority of your QMs are on z/OS and you still have all your ancient, wise, grizzled and so friendly MVS people around, then the discussion is back on for FRs on z/OS. But that's not something we can assume with any certainty nowadays is it? #MVS_RetirementCliff
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Aug 09, 2013 7:02 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
The concerns are:
1) People suspending, resuming and refreshing
2) Having more then two FRs in the cluster and not every Qmgr with an explicit CLUSSDR to every other FR also in the cluster (without which, you will end up with a fragmented cluster)
3) When the FRs are isolated, HA is not needed as it is inherent
So there! |
|
| Back to top |
|
|
| DaifaN |
| Posted: Sun Aug 11, 2013 11:26 pm Post subject: |
|
|
Newbie
Joined: 05 Aug 2013
Posts: 8
|
| gbaddeley wrote: |
| DaifaN wrote: |
| I also tried create the log file and change permission to 777, owner is mqm. Still no logs appeared. |
Check the MQ error logs, the MCA may not be able to load the exit module. The exit produces diagnostics on the system log if it cannot create or open the exit log file. See the user guide for details. |
yes, I find below error when starting CLUSSDER channel.
----- amqrmrsa.c : 565 --------------------------------------------------------
08/12/13 02:13:08 PM - Process(21273.55) User(mqm) Program(amqrmppa)
Host(mqserver2)
AMQ6175: The system could not dynamically load the shared library
'/var/mqm/exits64/wmqcml64.so'. The system returned error message 'ld.so.1:
amqrmppa: fatal: relocation error: file /var/mqm/exits64/wmqcml64.so: symbol
strerror_r: referenced symbol not found'.
EXPLANATION:
This message applies to UNIX systems. The shared library
'/var/mqm/exits64/wmqcml64.so' failed to load correctly due to a problem with
the library.
ACTION:
Check the file access permissions and that the file has not been corrupted. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Aug 12, 2013 3:39 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| DaifaN wrote: |
yes, I find below error when starting CLUSSDER channel.
----- amqrmrsa.c : 565 --------------------------------------------------------
08/12/13 02:13:08 PM - Process(21273.55) User(mqm) Program(amqrmppa)
Host(mqserver2)
AMQ6175: The system could not dynamically load the shared library
'/var/mqm/exits64/wmqcml64.so'. The system returned error message 'ld.so.1:
amqrmppa: fatal: relocation error: file /var/mqm/exits64/wmqcml64.so: symbol
strerror_r: referenced symbol not found'.
EXPLANATION:
This message applies to UNIX systems. The shared library
'/var/mqm/exits64/wmqcml64.so' failed to load correctly due to a problem with
the library.
ACTION:
Check the file access permissions and that the file has not been corrupted. |
The exit requires the standard C library function strerror_r, but it does not exist in the C runtime library on the server. What OS are you using?
_________________
Glenn |
|
| Back to top |
|
|
| DaifaN |
| Posted: Mon Aug 12, 2013 5:18 pm Post subject: |
|
|
Newbie
Joined: 05 Aug 2013
Posts: 8
|
Thanks Glenn.
SunOS 5.9 Generic_Virtual sun4u sparc SUNW,Sun-Fire-880
It is a sub zone created in Solaris10. |
|
| Back to top |
|
|
| vennela |
| Posted: Tue Aug 13, 2013 9:39 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| PeterPotkay wrote: |
The design of having 2 full repositories is itself highly available. Its why IBM decided on having 2 and not 1 FRs in a best practices aligned MQ cluster.
2 virtual servers on separate ESX clusters is going to be plenty available, because you only need 1 of them for a 100% functional cluster than can run forever.
If none of your partial QMs are on z/OS I would argue strongly against putting just the FRs on z/OS due to the complications with exits (if you were to use them) and the added complexity.
I agree that any one QM on z/OS* is likely going to be more available than any one mid tier QM.
(The most stable platform in the hands of noobs is not going to be stable.)
But if you are comparing the availability of at least one of a pair of z/OS QMs to the availability of at least one of a pair of virtual QMs, then the margin closes significantly. And in my mind, it closes to the point of irrelevance. K.I.S.S. and put those FRs on mid tier servers.
If your expertise is z/OS, if the majority of your QMs are on z/OS and you still have all your ancient, wise, grizzled and so friendly MVS people around, then the discussion is back on for FRs on z/OS. But that's not something we can assume with any certainty nowadays is it? #MVS_RetirementCliff |
I agree with the above arguments |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Aug 13, 2013 11:59 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
I agree that any one QM on z/OS* is likely going to be more available than any one mid tier QM.
But if you are comparing the availability of at least one of a pair of z/OS QMs to the availability of at least one of a pair of virtual QMs, then the margin closes significantly. And in my mind, it closes to the point of irrelevance. |
Since no one else disagreed with this, allow me.
If one qmgr on one z/OS is going to be more available than one midrange qmgr, then more than one z/OS qmgr will be more available than midrange equivalents.
WMQ in z/OS Parallel Sysplex can be thought of as MI, but with the possibility of dozens of MI-ish z/OS qmgrs - all seeing the same queues. With Parallel Sysplex, the availability margin increases dramatically over midrange MI.
I will not argue that system admin on z/OS is more complicated than on midrange. I will also not argue that z/OS systems programmers are an odd lot.
_________________
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 |
|
|
| gbaddeley |
| Posted: Tue Aug 13, 2013 3:06 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| DaifaN wrote: |
Thanks Glenn.
SunOS 5.9 Generic_Virtual sun4u sparc SUNW,Sun-Fire-880
It is a sub zone created in Solaris10. |
Apparently strerror_r() is not available on all versions of Solaris. The next version of the exit uses strerror() on Solaris rather than strerror_r(). Sorry, I can't provide any expectation on a release date.
_________________
Glenn |
|
| Back to top |
|
|
| DaifaN |
| Posted: Tue Aug 13, 2013 5:27 pm Post subject: |
|
|
Newbie
Joined: 05 Aug 2013
Posts: 8
|
| gbaddeley wrote: |
| DaifaN wrote: |
Thanks Glenn.
SunOS 5.9 Generic_Virtual sun4u sparc SUNW,Sun-Fire-880
It is a sub zone created in Solaris10. |
Apparently strerror_r() is not available on all versions of Solaris. The next version of the exit uses strerror() on Solaris rather than strerror_r(). Sorry, I can't provide any expectation on a release date. |
Thanks Glenn
I did the same testing between two solaris10 servers last night, the exit module works well, I also can get the logs.
Is this possible that solaris10 could use strerror_r() but solaris9 can't?
for solaris9, anything can be changed to make it use strerror_r() successful? |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Aug 14, 2013 5:31 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| DaifaN wrote: |
| ...anything can be changed to make it use strerror_r() successful? |
Like you writing a function with exactly that signature and calling stderr()? |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Aug 14, 2013 3:47 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| DaifaN wrote: |
Thanks Glenn
I did the same testing between two solaris10 servers last night, the exit module works well, I also can get the logs.
Is this possible that solaris10 could use strerror_r() but solaris9 can't?
for solaris9, anything can be changed to make it use strerror_r() successful? |
Yes, its possible. I don't know of any easy answer. These functions are in the Solaris standard C runtime library libc.so. Google "solaris strerror strerror_r" shows a legion of issues.
_________________
Glenn |
|
| Back to top |
|
|
| DaifaN |
| Posted: Sun Aug 18, 2013 6:18 pm Post subject: |
|
|
Newbie
Joined: 05 Aug 2013
Posts: 8
|
| gbaddeley wrote: |
| DaifaN wrote: |
Thanks Glenn
I did the same testing between two solaris10 servers last night, the exit module works well, I also can get the logs.
Is this possible that solaris10 could use strerror_r() but solaris9 can't?
for solaris9, anything can be changed to make it use strerror_r() successful? |
Yes, its possible. I don't know of any easy answer. These functions are in the Solaris standard C runtime library libc.so. Google "solaris strerror strerror_r" shows a legion of issues. |
Thanks all your help, I have report to my customer. |
|
| Back to top |
|
|
|
|
