gmane.network.mq.devel

Certification: WMQ System Admin v7.0

L R — 2013-06-18T15:00:03

Hello,

I would like to know if someone can suggest a website or a place where to
find documentation/information to set for this certification exam.
 I was researching in different sites and lately was hard to find anything
related to 7.0, even in the IBM website.

Thanks,
L.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

MQ Proxy

Huy Nguyen — 2013-06-17T19:41:22

Hi all,

We're looking for a way to forward MQ traffic in MQServer <--> Proxy <-->
MQServer fashion.  Besides MQIPT, just wondering if anyone here has used any
MQ-specify proxy service and can share their experience? Ideally we'd like
to use a proxy software that can understand MQ protocol instead of a normal
TCP proxy, but so far we find MQIPT limited in its ability to scale up.

Thanks,

Huy Nguyen.  

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Way to block port scanners?

Frost, Mark {BIS} — 2013-06-17T15:19:09

Hello.  We've an internal machine somewhere that is likely doing some kind of scanning for vulnerabilities.   I can't get any details about this particular machine, but it's regularly creating FDC files in our MQ instances due to the funky way it's hitting the port for the queue manager.

I suspect the answer is "no", but I don't suppose MQ provides some mechanism for me to block this particular connection?  I'm getting rather tired of cleaning up those FDC files.  (We get alerts whenever an FDC file is generated).

I'm running MQ 7.0.1.6 on HPUX.

Thanks

Mark


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

DataPower, Encoding and the OTMA Bridge

Potkay, Peter M (CTO Architecture + Engineering — 2013-06-14T20:12:13

We have an issue where an MQ message being sent thru the OTMA Bridge was
causing IMS to abend. DataPower was producing the message including the
IIH header. IMS kept complaining about the lenght of some fields.

Eventually we started comparing the MQMD, MQIIH and data payload between
what DataPower was producing and what a Java app was producing. The Java
app was producing request messages that were not causing an issue.

We noticed that the MQMD's Encoding field was different between the
DataPower message that abended and the Java message that worked. Also,
when viewed in Hex the MQIIH's Version field and StrucLength field were
different.

DataPower produced messages:
MQMD CCSID = 819
MQMD Encoding = 546
MQIIH Version Field (in hex) = 01000000
MQIIH StrucLength Field (in hex) = 54000000

Java Client produced messages:
MQMD CCSID = 819
MQMD Encoding = 273
MQIIH Version Field (in hex) = 00000001
MQIIH StrucLength Field (in hex) = 00000054

So, we asked the DataPower dude what he was setting the MQMD Encoding to
inside DataPower. He was not setting it to anything at all. He then
coded in DataPower to set the MQMD Encoding value to 273. The next
message he put now looked like the Java produced one - it had 273 for
the MQMD Encoding and the MQIIH Version and StrucLength hex bytes
flipped themselves around.

We let the message go into the OTMA bridge and success - no abend on the
mainframe and the reply came back. High fives all around! But wait a
minute, did we fix the root cause, or did we implement a work around
that's gonna break when the real problem is fixed?

Why does the mainframe deal with this OK:
MQMD Encoding = 273
MQIIH Version Field (in hex) = 00000001
MQIIH StrucLength Field (in hex) = 00000054

But abends on this:
MQMD Encoding = 546
MQIIH Version Field (in hex) = 01000000
MQIIH StrucLength Field (in hex) = 54000000

Does 546 correctly describe 01000000 and 54000000 in the MQIIH?
If yes, shouldn't the mainframe be able to deal with it correctly? If it
can't is there a bug on the mainframe side?

If 546 does not correctly describe the data, why does DataPower produce
a 546 message by default - is that the bug?

This is the first time we are using DataPower to send to the IMS Bridge.
But more importantly, I bet this is the first time we are using
DataPower to send MQ messages with something other than plain character
data in it, and thus the first time that the MQMD Encoding field is
relevant.

Peter Potkay

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

SSL peer matching

Oddo, Fred — 2013-06-14T18:49:24

Can anyone shed some light on "how to" configure SSL peer matching and possibly matching for source IP address. 
I'm pretty familiar with the configuring certs the channel attributes to specify. What  we're looking for a way to associate 
an SSL certificate to a user Id (linux) so we can restrict qmgr/object access based on the user id defined on the server. 
We're just getting started so I'd appreciate any assistance. 



Thanks,

Fred Oddo
Transaction and Messaging Technologies
DTCC Dallas
foddo< at >dtcc.com
DTCC Non Confidential (White)



<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>

MQMD.Expiry and JMSExpiration

Tom Pullar — 2013-06-14T01:22:27

Hi all,

 

One of our key developers is having development difficulty setting MQ expire
properties from JMS configurations.   I am wondering if others have
encountered this and worked through it.  The relevant text from the manual
discussed the caveats around JMSExpiration storing time to expire.  We are
setting the JMSExpiration, but it does not appear to be persisting to the
MQMD.Expiry as it travels to Z/OS.  Thanks.

 

 

Tom

 

Thomas G. Pullar, Certified TOGAF Enterprise Architect

Technical Architect

Advanced Systems, Integration Enterprise Services
IT Technology Division 

100 Erie Insurance Place

Erie, PA 16530

 <mailto:Linda.Sylvester-gaR6cFh0+tJvgq9H/jF5PwC/G2K4zDHf< at >public.gmane.org> thomas.pullar-WrL+EPVQPdoMEFOSxmVQkAC/G2K4zDHf< at >public.gmane.org

 

 

 <http://www.erieinsurance.com/> cid:image001.png-+rCVOepiJ/FWE+InZOgmszRmByFHzeGd< at >public.gmane.org

 

This e-mail and any attachments thereto, is intended only for the use of the
addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is strictly prohibited.
If you have received this email in error, please notify me via return e-mail
and via telephone at (814) 870-4322 and permanently delete the original and
any copy of any e-mail and any printout thereof.

 

 


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Issue with an exit routine not loading correctly.

Doug Clark — 2013-06-13T18:29:35

Need some help figuring out how I can get this exit utility resolved; The
vendor supporting the product is not being very helpful.

06/13/13 12:59:46 - Process(15663302.1) User(mqm) Program(qpmon)
                    Host(twausxmqmapp04)
AMQ6175: The system could not dynamically load the shared library
'/var/mqm/exits64/mirrorq'. The system returned error number '8' and error
message '       0509-022 Cannot load module /var/mqm/exits64/mirrorq.
        0509-026
System error: Cannot run a file that does not have a valid format.'.

EXPLANATION:
This message applies to AIX systems. The shared library
'/var/mqm/exits64/mirrorq' 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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

v7.5 MQ Managed File Transfer stand-alone file logger

Larry Parsons - IT — 2013-06-12T17:47:23

Is it possible to force the v7.5 MQ Managed File Transfer stand-alone file logger to close the current file and start a new one?  We would like to copy the file and process it for archive and trouble shooting purposes.

Here is the command I used to create the file logger:

fteCreateLogger -loggerType FILE -fileLoggerMode CIRCULAR -fileSize 1d -fileCount 10 qmgr.file.logger1

Thanks,
Larry Parsons

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Broker processes list?

T.Rob — 2013-06-12T17:05:12

Is there an authoritative list of the broker process names posted anywhere?
The word "process" is so overloaded, particularly in a product that does
business process stuff, that searching in the Infocenter or Google turns up
all the wrong references.  It's hard to tell if the info is simply not there
or if my search terms are bad.

 

Thanks - T.Rob


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

MQPUT Times question

Dave Corbett — 2013-06-12T13:45:23

Listers,

This is just a very basic question - but I have a pressing need to know 
for SURE.  The MQPUT time on a message should be the time that the client 
application actually issued the MQPUT.  If that PUT was to a remote queue, 
that then traversed two QMGR hops to reach its final destination, is the 
timestamp still that of when the client issued the MQPUT, or that of the 
MCA when it physically put the message into the local queue?

Tried to research the manuals, but questions like this seem to be hard to 
pin down and am looking for an "Expert" opinion.

Thanks,
David Corbett
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0
U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.



---------------------------------------------------------------------


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Only two weeks left of MQSCX Beta

Paul Clarke — 2013-06-12T09:56:03

There is now only about two weeks left of the MQSCX Beta so if you haven't already done so why not download it and have a play. 

Feedback your comments to me and you could help improve the first version. 

MQSCX is free to download and will run on Windows, Linux x86, Power Linux, AIX and now z/Linux. It can connect either locally or over a client so you can connect and view any of your Queue Managers, including z/OS!

So give it a try and tell me your thoughts.

Cheers,
Paul.


Paul Clarke 
www.mqgem.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

MQ 7.1/LDAP and existing security suddenly missing

Tim Zielke — 2013-06-11T14:31:59

Hello,

Today we had 3 distributed partial-repository queue managers (running 7.1.0.1 or 7.1.0.2 and each on a separate Solaris 10 server) all report the following error when the full repository servers tried to start a channel to these 3 servers.

================================================================

06/11/13 07:14:37 AM - Process(8694.371) User(mqm) Program(amqzlaa0)
                    Host(lzxxxx15) Installation(Installation1)
                    VRMF(7.1.0.1) QMgr(LZXXXX15.MQTEST1)

AMQ8077: Entity 'isxxxyyy    ' has insufficient authority to access object
'LZXXXX15.MQTEST1'.

EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: connect
ACTION:
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
group.

==================================================================

The id isxxxyyy is in a group xxxyyy which has connect access to the queue manager on the applicable server, and this security was working before the issue.  All 3 of the affected servers use LDAP.  When I logged onto the 3 servers around 8:30 am CT and did an "id isxxxyyy", LDAP showed that the id isxxxyyy was in the xxxyyy group.  I did a REFRESH SECURITY on all 3 queue managers and then the full repositories were able to start up their channels to these 3 servers.  I was going to chalk this up as a distributed LDAP issue (we have had numerous issues with LDAP flakiness since we moved to LDAP), but I did a google search and found someone reporting a very similar issue with MQ 7.1 and LDAP -> http://www.mqseries.net/phpBB2/viewtopic.php?t=61871&sid=7d88e7d0b97e685981c23eca8078c38c.

So just curious if anyone else has seen this type of similar issue with MQ 7.1 and LDAP.

Thanks,
Tim

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

LINUX and dspmqaut (for a z/OS guy!)

Ward Able, Grant — 2013-06-11T13:07:56

Hello MQers,
For my sins I have to start doing the OAM stuff as well as RACF stuff for our qmgrs. Reading the InfoCentre has not really helped me. Perhaps the info is there, but hidden from me! I am finding that there are things I am ignorant of, such as:

*         Is there a way to list the defined groups?

*         Is there a way to view what access rights a particular group has?

*         Is there a way to list the defined profiles?

Any help on these would be greatly appreciated!


Regards - Grant.
Telephone Internal: 201496 (London)
Telephone External: +44 (0)207 650 1496


<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

WMQ TOFU - it's not just for vegetarians anymore

T.Rob — 2013-06-10T23:09:40

Hi Listers,

 

I wanted to toss around some hypothetical ideas about cert management.  It's
probably the biggest impediment I see to enabling TLS channels across the
board so I'd like to start mapping the territory by kicking off a dialog
about where the gaps are and in what form they might be filled.

 

One of the MQ enhancements I've been lobbying for is TOFU - Trust On First
Use.  An example of this is the warning you get when using SSH or SCP when
it says something along the lines of "Hey, this is a new certificate. Here
are the details.  Do you want to trust it?"  

 

Of course, with WMQ there's no trusting the certificate without putting it
into the KDB and running REFRESH SECURITY TYPE(SSL) so I would not expect
that this process would be automatic for existing queue managers.  It might
instead store the certificate in a temporary queue and an Explorer plug-in
or command-line utility would interrogate the queue to tell the admin what
certs are pending.

 

There are a few problems I'm trying to solve here.  One is that deployment
of a new cluster should be easy to do with TLS enabled.  WAS ND creates a
lightweight CA, generates certificates and distributes keys throughout the
cluster, all without user involvement.  I'd like that level of simplicity in
WMQ clusters.  For a new QMgr, it would be fairly easy to do since the cert
would be generated prior to the QMgr starting up - so no REFRESH SECURITY in
most cases.  If the repository was also the CA, it would not need a REFRESH
SECURITY since it would not need the cluster member's cert, but rather just
the static signer.  The certs would include the cluster name and the
repository's signer.  If you had taken the trouble to provision a non-admin
user ID for the MCAUSER, the appropriate CHLAUTH rules and SSLPEER would be
added as well.

 

The other problem I'd like to solve is where you have a 3rd party interface.
The business partner can usually tell you their cert is Verisign (or
whatever) but not necessarily *which* signer chain and root cert.  Then it's
up to you to hunt around for the right signer on the CA's web site.  Good
luck with that.  On the other hand, it would be possible to capture the
signer cert from the inbound connection and either display its attributes or
even load it directly to the KDB.  There are, of course, a few issues with
loading whatever cert is presented.  The first issue being that the root CA
certs are distributed with GSKit (and Windows, and Mozilla, and Safari,
etc.) for a reason.  I could create a root CA signer cert with a
DN="VeriSign Class 3 Public Primary Certification Authority - G5" and a
signer with the appropriate DN.  If I could get my QMgr between you and your
business partner, and if all you checked was the DN and not the fingerprint
or serial number, then you might trust *my* cert thinking it's Verisign.
Not good.  If the cert you are accepting is expected to have been signed by
a commercial CA it would be best to fetch the signer chain from the source.
Or maybe to compare the one received to the ones distributed with GSKit so
you know you have a good one before loading it. After verifying that the
cert received is signed by a "known good" cert, the only thing left is to
make sure the Distinguished Name is the one you are expecting.  

 

Finally, we are probably all familiar by now with the issue where the remote
site's certificate expires and the channels die.  It's pretty tough to
diagnose this remotely and you get no warning.  On the other hand, it's
possible to inspect the other side's cert during the TLS handshake and parse
the expiration date.  With that information it would be possible to write an
error log entry, send a PCF event message, send an email or whatever,
notifying the local admin "hey the cert on the other side of channel X.Y.Z
expires soon!"  This might avert an occasional outage, yes?

 

All of this can be automated to some degree or another.  I'm curious how
useful people think it would be to do this.  Assuming it is considered
useful, then what type of security controls would you need before, for
example, adding the remote cert signer chain to your KDB?  Would you want
the information about the remote side's signer chain so you could manually
download and add the appropriate certs from the commercial CA?  Would you
want the typical TOFU message (hey, I'm being presented with an unknown
certificate do you want to trust it?) followed by the utility adding the
cert signer chain for you?  If so does that require an Explorer dialog,
command line utility or both?

 

All of this is hypothetical.  There may or may not be similar functionality
planned for a future release, frankly I don't know.  What I'm more
interested in is to map out the missing function and then flesh it out a bit
in terms of how it might be implemented.  Then I'd like to stand up a
prototype that we could build on and which would get us even further down
the road.  Anyone interested?

Reply-to QMGR and Reply-to Q question

Yagudayeva, Irina — 2013-06-10T19:28:22

Hello,

We are running Reply-to Q/Reply-to QMGR process with one of our
customers.

Currently our Application which Gets request messages and Puts responses
messages is connected to the Queue Manager Q1.

There are 3 Xmit queues(X1, X2 and X3) and 3 Pairs of Channels defined
in Q1 to Receive a request message and Send a response message back to
the customer according Reply-to Q and Reply-to QMGR values he put into
the header of his request.

We're moving our Application to a new environment where it will be
connected to queue manager Q2.

We want this move to be seamless to the customer.

Here is what we plan to do.

1. Make a request queue Remote in Q1 to route messages to queue
manager Q2 and trigger their the Application.

2. Define QMGR Aliases in queue manager Q2:

Remote Q "X1" (Xmit Q = Q1, Remote Queue Manager Name = X1, Remote Queue
name - blank)

Remote Q "X2" (Xmit Q = Q1, Remote Queue Manager Name = X2, Remote Queue
name - blank)

Remote Q "X3" (Xmit Q = Q1, Remote Queue Manager Name = X3, Remote Queue
name - blank)

3. Leave XMIT queues X1, X2 and X3 and corresponding channels in
queue manager Q1 the way they are currently defined.

Q1 and Q2 are already interconnected and have channels and XMIT queues
defined.

Please, advise whether this configuration should work.

Thank you.

Irina Yagudayeva

Insurance Services Office

Infrastructure Engineering

(201)469-3648

This email is intended for the recipient only. If you are not the intended recipient please disregard, and do not use the information for any purpose.

Using a simple benchmark to understand your queue managers

Charley Rich — 2013-06-07T14:48:58

Nastel is a Sponsor for the New York / New Jersey WebSphere MQ & Application 
Integration User Group

Tuesday, June 11
ISO Building
Jersey City, New Jersey

Seminar: Using a simple benchmark to understand your queue managers

Presenter: Richard Nikula, VP Product Development and Support, Nastel 
Technologies

In this session, we will demonstrate how a simple benchmark can provide 
insight into the behavior of your queue managers. How do you know the 
answers to questions like:

- Do the queue managers perform worse at one time of day compared to 
another?
- What impact do different options have on message behavior?
- How do the channels perform between different queue managers.

These and other answers will be explored as well as a round table discussion on 
other benchmark usage.
More information will be up shortly at the NY/NJ WebSphere MQ User Group. 
http://www.nastel.com/company/news-and-events/events.html#wug

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Pub/Sub enhancement - Message Distribution - RFE-Vote request

Michael Dag — 2013-06-07T11:51:26

I would like to draw your attention and ask you to vote for the following
RFE by Neil Casey:

 

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe
<http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=35062>
&CR_ID=35062

 

every now and then the topic of message distribution, splitting, copy-ing,
etc... comes up and 

either you have to switch to using distribution lists (program changes!) or
implement your own message splitter, copy-er etc 

(which many have done already!) or use the pub/sub feature, except with
pub/sub the original message descriptor is NOT preserved so you don't get an
exact copy of the original message.

 

This RFE is meant to allow message descriptor preservation and when
implemented should allow you to use pub/sub to implement message
distribution without having to write your own message splitter or you can
even decommission some of your existing message splitters copy-ers...

 

needless to say... your vote is welcome to raise awareness!

 

Thank you!

 

Michael Dag

www.mqsystems.com 

 


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

SVRCONN in Binding status

Pasha, Mir Musthafa Ali - Contractor {BIS} — 2013-06-04T17:29:21

Hello All,
Hope this email finds you in peace. I am looking at a SVRCONN channel which is accessed by several clients connections. Some of the instances of the SVRCONN are in Binding status and some are in Running status.
The status gets resolved automatically for some instances (meaning changes into Running state) and stays as Binding for others. All these connections are from different client i/p addresses.

My questions are:

1. When does a SVRCONN channel go into a Binding status?

2. Where does it log the reason for switching to a Binding status?

a. I have looked at the /var/mqm/errors and /var/mqm/<qmgr>/errors on the server and did not find anything related to this SVRCONN.

b. I don't have access to the client machines, so cant check the client error logs.

3. Some users have complained about data loss in the past and have opened a ticket for analysis. Does this issue cause any data on the channel to be lost? [I check the system queues and did not find anything in it, so I am assuming data was lost even before it hit MQ or after it was consumed from MQ].

a. Searching Bing reveals only one conversation thread in mqseries.net site regarding this issue but it does not have any solution.

Any pointers in the right direction will be appreciated.

Sincerely,
Mir Musthafa Ali Pasha
PepsiCo, Inc. | BIS

MQSCX Beta - New version

Paul Clarke — 2013-06-03T09:34:40

Hi,



Thank-you to all the people who tried out  my MQSCX Beta program and a special thank-you to those of you who took the time and trouble to feedback your comments. 



This is a quick note to let you know that a new Beta version, incorporating your comments,  is now available on www.mqgem.com.



The main changes are:



  a.. Make it clearer that any MQ installation can be managed including z/OS with QSG. 
  b.. Fixed the =where(usage = xmitq) filter 
  c.. Added the ability to specify the client connection values directly 
  d.. Fixed SSL cipher spec tabbing 
  e.. Add -w0 for single line output 
  f.. Added an AIX version 
  g.. Linux x86 has been rebuilt on an older version of Linux


Please have a play with the new versions and, of course, let me have your comments or suggestions.



Cheers,

Paul.



Paul Clarke 
www.mqgem.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

What?!? FREE MQ??!!?!?

T.Rob — 2013-06-01T02:04:26

Well, yes, if you download Broker along with it.  

 

For several of my years at IBM I lobbied hard to get a free and unexpiring
version of WebSphere MQ.  We were finally able to get WebSphere MQ Advanced
for Developers V7.5 which is a per-seat license, including support, at a
relatively low price.  I would have preferred a no-cost license since
competing async messaging products are available at no cost for development.
However, this was a start and I was happy to get it.

 

So imagine my surprise when I stumbled across this announcement for
WebSphere Message Broker Version 8.0.0.1 Developer Edition:

http://www-01.ibm.com/support/docview.wss?uid=swg21614492 

 

The announcement cuts right to the chase:

 

"WebSphere Message Broker V8.0.0.1 Developer Edition is a full-function
version of the product, which you can use for evaluative purposes. You can
download the Developer Edition at no charge and you are free to use it for
as long as you require, within the terms of the license."

 

Then later in the same announcement:

 

"Message Broker V8.0.0.1 Developer Edition is available on Windows 64-bit
operating systems and Linux on x86-64 . All product prerequisites are
included in the download package. The Developer Edition includes WebSphere
MQ Version 7.5, rather than WebSphere MQ Version 7.0.1, which is included
with the full edition of Message Broker Version 8.0.0.1."

 

I don't know about you but when I read this, it was like finding out that Q
had changed the coefficient of gravity and nobody noticed.

 

Because it was so hard to believe this made it out the door with little to
no fanfare, I went to the link and downloaded it.  I just now opened the zip
file with the Windows components and sure enough, there's a WMQ v7.5 in
there.  I haven't tried to install yet because I'm too busy pinching myself
and waiting to wake up.

 

So buy the WMQ Advanced for Developers if you need support, or download the
broker, including the WMQ Advanced component, for no cost if you do not need
support.

 

And as long as you have Broker on your desk to play with anyway. go learn
all about WMB development and admin!

CHLAUTH question

Ward Able, Grant — 2013-05-31T13:17:18

Hi MQLIST-ers,
We are slowly getting ready to implement V7.1 and this will allow us to use the CHLAUTH feature. We may also begin using the MQ Explorer, however I am a little confused as to what to specify in the SET CHLAUTH commands, mainly because most of the MQ Explorer connections will be done over dynamic IP addresses.

Setting up the backstop rule is easy:
SET CHLAUTH('SYSTEM.*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS)

Now the problem is - how do I cater for dynamic IP addresses, in oerder to allow them access?

Surely this is something that has been solved by some people out there in the big, wide MQ world. I'd like to hear from you, if you'd care to share you wisdom.

Regards - Grant.
Telephone Internal: 201496 (London)
Telephone External: +44 (0)207 650 1496


<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw< at >public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES