Tim Zielke | 3 Sep 15:53 2015

Timestamp of cached SSL security information on distributed MQ

Hello,

 

Is anyone aware of a way where you can find out what is the current timestamp of the cached SSL security information on a distributed MQ queue manager?

 

For example, a distributed MQ queue manager has been running for 90 days.  30 days ago, someone issued a REFESH SECURITY TYPE(SSL).  The queue manager error logs only go back for one week.  There is no command event auditing for this queue manager.

 

Is there a way to query/inspect the queue manager to see that the cached SSL security information was built 30 days ago?

 

Thanks,

Tim

 

Tim Zielke | CICS/MQ Systems Programmer

Aon Service Corporation | Aon Technology | Foundational Technologies

4 Overlook Point, Lincolnshire, IL 60069 

t +1.847.295.5000

tim.zielke-VwKEKOxrCg4@public.gmane.org

 


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Costa, D. (Damian | 3 Sep 10:26 2015
Picon

MQ JMS 2007 error (msg too big for qmgr, channel or queue)

Hi all,
 A developer I was assisting got a MQJMS2007 error. And sent me an IBM link that said the qmgr or channel or
queue is not configured to handle the message being put to the queue.

Message is: 
2015-09-02 14:34:36,707 [asyncDelivery0] INFO  com.misys.liq.XXXXXX  - result: <Response success="true">
               <Result>
                              <RunXQueryResults version="1.0" queryResult="Script not found: Test"></RunXQueryResults></Result>
               <Messages></Messages></Response>

Error is:
2015-09-02 14:34:36,707 [asyncDelivery0] INFO  com.misys.liq.XxxxxXX  - Name: 1:XXXXXXX logon:
XXXXXXXX Ended
2015-09-02 14:34:36,739 [asyncDelivery0] ERROR com.misys.liq.ws.api.jms.XXXXXXXXJMSService  -
Exception receiving JMS message
javax.jms.JMSException: MQJMS2007: failed to send message to MQ queue
               at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:530)
               at com.ibm.mq.jms.MQQueueSender.sendInternal(MQQueueSender.java:816)
               at com.ibm.mq.jms.MQQueueSender.send(MQQueueSender.java:232)
               at com.ibm.mq.jms.MQQueueSender.send(MQQueueSender.java:265)
               at com.misys.liq.ws.api.jms.APIJMSService.onMessage(XXXXXAPIJMSService.java:127)
               at com.ibm.mq.jms.MQQueueReceiver.receiveAsync(MQQueueReceiver.java:86)
               at com.ibm.mq.jms.SessionAsyncHelper.run(SessionAsyncHelper.java:401)
               at java.lang.Thread.run(Unknown Source)

http://www-01.ibm.com/support/knowledgecenter/SSDKKW_6.1.1/com.ibm.wpg.entadv.doc/admin/wpgagmst275.html%23mqjms2007

the message as you can see is miniscule. The qmgr and channel and queue are defined using the default 4 meg
message limit.

Developer is using a self generated JMS bindings file , are their settings in the bindings file governing
payload characteristics?

Is there anything else I should be checking?

Thanks.

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Picon

certificate validation error 575010 - cert details are '????'

Hello fellow listers,

I hope someine can assist help me here.

I am getting error:
in an effort to help resolve a 575010 issue - but I do not have any certificate information:

The details of the certificate which could not be validated are '????'.
The certificate validation error was 575010.

How do I proceed from here to determine which certificate I am missing? Appreciate all your help.

David



===== Bloomberg LP --- Making Financial Markets Transparent =====
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Engineering
email: dawerbuch <at> bloomberg.net phone: + 1 646 324 2686
WMQ support: mq-support <at> bloomberg.com
-------------------------------------------------------------------
For all Trading Systems application and connectivity issues,
please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London +44-20-7330-7500
- Asia - Tokyo +81-3-3201-8900
- Singapore +65-6212-1000



List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Picon

certificate validation error 575010 - cert details are '????'

Hello fellow listers,

I hope someine can assist me here.

I am getting error:
AMQ9633: Bad SSL certificate for channel 'ME.TO.YOU'.

The error is not including any certificate information:
The details of the certificate which could not be validated are '????'.
The certificate validation error was 575010.

How do I proceed from here to determine which certificate I am missing? Appreciate any help.

wmq version 7.5.0.3
I have loaded all 3 certificate (root, primary intermediate, and secondary intermediate) sent to me by the connection partner.
I verified they are all valid.

David



===== Bloomberg LP --- Making Financial Markets Transparent =====
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Engineering
email: dawerbuch <at> bloomberg.net phone: + 1 646 324 2686
WMQ support: mq-support <at> bloomberg.com
-------------------------------------------------------------------
For all Trading Systems application and connectivity issues,
please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London +44-20-7330-7500
- Asia - Tokyo +81-3-3201-8900
- Singapore +65-6212-1000



List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Costa, D. (Damian | 1 Sep 12:20 2015
Picon

failover times for HA CMP , multiinstance and new MQ device

Hi,
 Does anyone have real world experience with the timings of failovers  in the case of HACMP, multi instance
and MQ device?
 Thanks.

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Voges, P. (Pieter | 25 Aug 17:44 2015
Picon

http://www.securitytracker.com/id/1032630

 

Hi Everyone

 

Thanks again for all the feedback around MQIPT. I have actually submitted a proposed design to use it in the DMZ, pointing to an internal “Hub” QMGR, instead of having a QMGR in the DMZ taking the data through Datapower.

 

So our security guys have lots of questions:

 

-          How does MQIPT prevent malware attacks

-          Hacking

 

Apparently Datapower can scan incoming messages which makes it safer.

 

I am sure however that MQIPT must be an equal alternative, as IBM states that only Datapower and MQIPT can do secure termination in the DMZ.

 

What can I take back to the Security Architects to set them at ease.  

 

By looking at the link I attached in the subject line, there was a reported vulnerability as recent as June 2015 with MQIPT.

 

T.Rob, just to make sure that I understand your post below correctly, what are the additional benefits of only allowing QMGR connections, and to keep away from Client Connections through MQIPT?

 

 

 

 

Thank you.

 

 

 

Pieter Voges

Technical Specialist (Multi Discipline) | Group Technology | Nedbank Limited

12 Olyfenbosch Close Protea-Heights Brackenfell Western-Cape 7560 South Africa |

t +27 (0)21 981 3733  c +27 (0)83 645 5300  <at> pietervo <at> nedbank.co.za

Website: nedbank.co.za

 

 

 

 

THINK BEFORE YOU PRINT - At Nedbank we are committed to minimising environmental impact and encourage the preservation of natural capital.

 

 

 

 

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: 22 August 2015 04:03 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: MQIPT

 

> To some people, it only means (right or wrong) its at rest only if it got written to a file (log, error, queue, trace, etc).

 

My whole point was that to decide policy based on the meaning of an arbitrary requirement is the wrong approach.  It doesn't matter what anyone thinks the term means if they design the security architecture based on a risk-based approach and a threat model.  The question is not whether data comes to rest in the DMZ because for any connection which terminates there *all* data comes to rest in the DMZ.  The question is to which specific threats is the data exposed while traversing the DMZ and are they adequately mitigated?

 

In any discussion where…

 

·         async data transport is secured using the same policies as synch data transport as if the two were equivalent,

·         MQ MCA and MQI channels are treated as if the threat model for these is equivalent,

·         the requirements are stated in terms of policy rather than specific threats and mitigations

 

…then there's a really good chance the end result won't be properly secured.  There's a  big difference between making a check mark next to "no data at rest" versus identifying and mitigating specific threats related to business requirements.

 

> Either way I think a Queue Manager will always allow for more data at rest compared to MQIPT.

 

Yup. No question.  And if "data at rest" fully describes the threat model, feel free to install MQIPT and make that check mark.  I'm sure it will make someone somewhere feel better.  Whether that person is sitting in the boardroom or a hostile country I can't tell you, but I'm sure it will make them feel better.

 

There are of course some threats for which managing data at rest is an appropriate mitigation and MQIPT a great way to do that.  But the choice of mitigation should be a requirement arrived at based on an evaluation of specific threats, not stated as if the mitigation *is* the requirement.  Data at rest is a security control.  It addresses a specific requirement that should be evaluated in the context of all the other specific threats to arrive at a security model that delivers the most effective mitigation. 

 

Kind regards,

-- T.Rob

 

T.Robert Wyatt, Managing partner

IoPT Consulting, LLC

+1 704-443-TROB (8762) Voice/Text

https://ioptconsulting.com

https://twitter.com/tdotrob

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Technology)
Sent: Friday, August 21, 2015 21:12 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: MQIPT

 

I suppose a definition of “data at rest” would be a good place to start.

 

To some people, it only means (right or wrong) its at rest only if it got written to a file (log, error, queue, trace, etc).

 

If you consider data in memory, however briefly, as “at rest”, then I guess its impossible to never have any data at rest in the DMZ.

 

Either way I think a Queue Manager will always allow for more data at rest compared to MQIPT.

 

 

 

Peter Potkay

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Friday, August 21, 2015 10:14 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: MQIPT

 

> Is there a top 10  list of things to do  to “lock it down “ further?

 

One of the things I considered a "must have" in the Redbook was a B2B chapter.  The team did a great job at testing it all out and we found a few MQIPT issues which have since been addressed by IBM.  Please see Chapter 10 of Secure Messaging Scenarios with WebSphere MQ:

http://www.redbooks.ibm.com/abstracts/sg248069.html

 

Missing from this thread so far is any mention of the difference in risk between allowing QMgr-to-QMgr connections versus allowing 3rd party client connections.  With a RCVR/RQSTR channel, the thing connecting to your QMgr is IBM's code, hosted by you, designed to only ever CONNECT and PUT on your QMgr.  When properly configured, the 3rd party cannot enumerate resources or commit a DOS attack.  Compare to an MQ client connection where the code talking to the QMgr is of unknown provenance, hosted by a 3rd party, and the best security possible when it is properly configured allows enumeration of resources and DOS attack.

 

Hopefully, it's obvious that this is not merely a difference in degree of risk, but a completely different category of risk.  Securing against 3rd party MQ client therefore requires a completely different security model than securing against a 3rd party QMgr.

 

For example, I don't have a problem routing several independent 3rd parties through the same QMgr is it accepts only QMgr-to-QMgr connections.  But if I have to accept MQ client connections I will strongly recommend dedicated QMgrs per 3rd party.  I'm also not allowing clients to connect without a certificate, even over VPN or dedicated encrypted circuit, whereas I might (reluctantly) allow that with a QMgr.

 

Regarding data at rest in the DMZ, I believe there's a misconception about what that means.  Consider the case of an SSL-terminating reverse proxy.  A message arrives on the proxy where it COMES TO REST while a copy of it is sent down the second link to the internal server.  With streaming protocols the amount of data at rest in the DMZ is limited to a single message, but that can be many megabytes worth of data.  For example, submitting a file of patient medical records using a browser to a terminating SSL proxy will result in substantial data at rest in the DMZ, however briefly.  Take the exact same file and transmit it as messages through a properly configured DMZ QMgr and it's possible to have even less data come to rest in the DMZ than with the HTTPS version, though it might be at rest a bit longer.  Furthermore, if the data is encrypted using AMS as it traverses the DMZ QMgr there is even less risk than plaintext data passing through an HTTPS proxy.

 

An inflexible rule stating "no QMgr in the DMZ" discards a whole host of possible valid solutions.  In the case of allowing MQ client connections, termination on a dedicated and properly configured DMZ QMgr is usually preferable to terminating clients from multiple business partners on the same QMgr inside the DMZ, even after passing through MQIPT.  The security model should be based on the degree of risk in the implementation, not on a blanket policy that fails to differentiate between the nature of synchronous vs. asynchronous protocols.

 

Kind regards,

-- T.Rob

 

T.Robert Wyatt, Managing partner

IoPT Consulting, LLC

+1 704-443-TROB (8762) Voice/Text

https://ioptconsulting.com

https://twitter.com/tdotrob

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Costa, D. (Damian)
Sent: Friday, August 21, 2015 7:50 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: MQIPT

 

In our case the DMZ has multiple firewall zones. Ie between our DMZ and the wide area network.  And between the DMZ and our trusted network.

 

We already have a dedicated “edge”  qmgr on our trusted network. However it has been poorly defined so there are some apps already using it from within the trusted network.

 

Is there a top 10  list of things to do  to “lock it down “ further?

Assume I am a  rank amateur at security….

Fyi Pieter Voges and I work at the same institution.

 

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Technology)
Sent: 21 August 2015 01:37 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: MQIPT

 

Your partner does not need MQIPT.

Your partner can also be using MQIPT.

Your MQIPT configuration wouldn’t know or care if it was talking to your partner thru an MQIPT they have or don’t have.

 

Think long and hard about putting that QM in the DMZ – it means can have data at rest in the DMZ, which is typically not allowed. Consider moving that QM inside your firewall, and having only MQIPT in the DMZ. The QM can still act as a jump point from your internal MQ network to the partners. I call these types of queue managers “Edge Queue Managers” – they sit on the edge of your MQ topology, and their only purpose is a QM way of talking to other companies. Because their role in life is specific, you can lock them down more aggressively than you would a typical QM used by lots of your internal business apps. By having the Edge QM not in the DMZ, you mitigate MQ data at rest in the DMZ.

 

 

 

Peter Potkay

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Voges, P. (Pieter)
Sent: Friday, August 21, 2015 6:19 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: MQIPT

 

Regarding my mail below (I have done some reading in the meanwhile).

 

It seems that MQIPT runs as a Supportpac (ms81) – available for MQ V7 & V8 QMGR’s

 

So my remaining question is, and I think the answer is “yes” from what I read: Does it operate in an environment where one can deploy it (MQIPT) with your QMGR in the DMZ as a standalone solution, or does your external client also require an installation of MQIPT.

 

From what I read it can be used stand-alone as it supports external client connects, but I please need confirmation for this…

 

 

Thank you.

 

 

 

Pieter Voges

Technical Specialist (Multi Discipline) | Group Technology | Nedbank Limited

12 Olyfenbosch Close Protea-Heights Brackenfell Western-Cape 7560 South Africa |

t +27 (0)21 981 3733  c +27 (0)83 645 5300  <at> pietervo <at> nedbank.co.za

Website: nedbank.co.za

 

 

 

 

THINK BEFORE YOU PRINT - At Nedbank we are committed to minimising environmental impact and encourage the preservation of natural capital.

 

 

 

 

 

From: Voges, P. (Pieter)
Sent: 21 August 2015 10:57 AM
To: 'Harish T.D.'; MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: RE: MQ Device

 

Thanks you everyone for the valuable feedback.

 

I DO understand that the IBM statement is clear, only 2 ways of terminating safely in the DMZ

 

1)      Datapower

2)      MQIPT

 

-          So in my setup I have 2 HUB QMGR’s proposed, I on the LAN, and one in the DMZ

-          I also have a Datapower component on LAN and in DMZ

 

I am frantically trying to read about MQIPT as I have no prior experience of it.

 

Question as a quick win:

 

1)      In scenario 1, external customers with Datapower can talk HTTPS to my Datapower in the DMZ – safe termination

2)      For scenario 2 (MQ traffic), if I put a copy of MQIPT in the DMZ on a Linux partition, would external clients with QMGR and Client connects be able to connect to it, and can we route it from there into the internal network

a)      Would this use of MQIPT be considered safe termination

b)      Can it be done with MQIPT on my side only – or would the external customer require it as well?

 

 

 

Thank you.

 

 

 

Pieter Voges

Technical Specialist (Multi Discipline) | Group Technology | Nedbank Limited

12 Olyfenbosch Close Protea-Heights Brackenfell Western-Cape 7560 South Africa |

t +27 (0)21 981 3733  c +27 (0)83 645 5300  <at> pietervo <at> nedbank.co.za

Website: nedbank.co.za

 

 

 

 

THINK BEFORE YOU PRINT - At Nedbank we are committed to minimising environmental impact and encourage the preservation of natural capital.

 

 

 

 

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Harish T.D.
Sent: 21 August 2015 10:30 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: MQ Device

 

Hi Jeff,

 

Scenario - 1

Let us assume a MQ Client on the internet (Clearing houses, ATMs, Stock exchanges), directly connecting to the MQ Gateway Appliance without needing a MQIPT instance.  

 

The proposed approach is to have both MQ appliance as well as the DP appliance in the DMZ. One for MQ clients, the other for web service clients.

 

MQ messages will be stored in the DMZ - albeit for a brief period of time while waiting for DP to come and pick the message. Doesn't this go against the grain of having no data storage in the DMZ? How are you convincing the security teams in your respective customer locations that this is the "new normal"?

 

Scenario - 2

A MQ client connects to an instance of MQIPT running on a conventional Linux server placed in the DMZ. The message now gets routed to the MQ appliance QM. DP now makes a connection from the DMZ to the MQ appliance - examines the message and then accepts or rejects this message.

 

How are you addressing the "all our messages must be handled by the hardened appliance. why do we need a new MQIPT server?" question?

 

Thanks,

Harish

 

 

 

 

 

On Thursday, August 20, 2015 9:08 PM, Jefferson Lowrey <jlowrey <at> US.IBM.COM> wrote:

 

I'm not sure what you mean by "MQ Client talking to MQ Client"?  The MQ Appliance implements queue managers, so the DataPower multi-protocol gateway would be an MQ Client talking to a QueueManager...

And there wouldn't be data stored in the DMZ, except in memory on the DP box as it works its way through the MPG.


Thank you,

Jeff Lowrey




From:        "Harish T.D." <0000001a074ebb44-dmarc-request <at> LISTSERV.MEDUNIWIEN.AC.AT>
To:        MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Date:        08/20/2015 09:51 AM
Subject:        Re: [MQSERIES] MQ Device
Sent by:        MQSeries List <MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT>




MQIPT needs another conventional server to be placed in the DMZ. Customers would rather have the MQ Gateway appliance rather than have a server that only runs MQIPT.

DataPower is a MQ client - so a MQ client talking to a MQ client does not work. How else can MQ Clients that are outside an organization connect securely to the MQ Appliance?



On Wednesday, August 19, 2015 2:29 AM, "Potkay, Peter M (CTO Technology)" <Peter.Potkay <at> THEHARTFORD.COM> wrote:


Peter,
The problem is if you put the MQ appliance (or any queue manager) in the DMZ, you open the possibility for data at rest in the DMZ (messages in queues and/or transaction logs and/or your friendly MQ Admin leaving a trace behind). Data at rest in the DMZ is generally a no no.
 
Peter Potkay
 
From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Voges, P. (Pieter)
Sent: Tuesday, August 18, 2015 10:15 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: MQ Device

 
Thank you very much T.Rob –  real proper answer – exactly what I was looking for.
 
According to IBM documentation, there are only two ways of terminating securely in the DMZ, one is MQIPT, the other is Datapower.
 
We have a Datapower device in the in the DMZ for external customers with Datapower, so the two devices can talk https.
 
I was hoping that the MQ Device could get DMZ certification in future for the external MQ connections. Funny that it can’t, as its build on Datapower hardware…  
 
 
Thank you.
 

 

 

Pieter Voges
Technical Specialist (Multi Discipline) | Group Technology | Nedbank Limited
12 Olyfenbosch Close Protea-Heights Brackenfell Western-Cape 7560 South Africa |
t +27 (0)21 981 3733  c +27 (0)83 645 5300   <at> pietervo <at> nedbank.co.za
Website: nedbank.co.za

 

 

 

 
THINK BEFORE YOU PRINT - At Nedbank we are committed to minimising environmental impact and encourage the preservation of natural capital.

 

 


 
 
 
From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: 18 August 2015 03:54 PM
To:
MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject:
Re: MQ Device
 
Hi Pieter,
 
I asked the same question about use in the DMZ and was told that MQIPT is IBM's strategic solution there.  I'm not sure why that is since the MQ Appliance is built on a DataPower platform but my response at the time was that answer would be a lot easier to take if MQIPT had all the features of a modern QMgr - like multi-instance CONNAME, for example.
 
I do at least have good news about the external storage, and from an authoritative source.  Please see http://iopt.us/1E0yzgZ
Under "Statement of general direction" they write:
IBM intends to deliver fibre channel capability in IBM MQ Appliance M2000
The IBM MQ Appliance includes a fibre channel card.
IBM intends to support fibre channel connectivity to connect the IBM MQ Appliance to external storage. This connectivity will enable greater queue depth and support disaster recovery configurations where the IBM MQ Appliance can failover to another MQ configuration in a remote data center.
Can we have a timeline?  Doesn't work that way.  For accounting and legal reasons IBM will not announce dates for release until the date is known and it is within a calendar quarter.  Instead they provide statements of general direction which omit dates and timelines intentionally.  However this one appears to be very direct.  If you bought the M2000 version then you will get SAN connectivity in a future update, possibly even the *next* update.
 
 
Kind regards,
-- T.Rob
 
T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
https://ioptconsulting.com
https://twitter.com/tdotrob
 
From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Voges, P. (Pieter)
Sent: Tuesday, August 18, 2015 5:16 AM
To:
MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject:
MQ Device
 
Good day everyone.
 
We have been working towards the creation of a “HUB QMGR” design for more than 18 months to decrease our QMGR footprint as it was getting out of hand in the distributed environment and it became quite a task to patch and upgrade all of these servers.
 
Our proposed solution was for two of these HUB QMGR’s, one on the LAN, and one for external customers to terminate in the DMZ.
 
So the announcement of the MQ device was great news for us.
 
Unfortunately, it (The MQ Device), is totally unusable for us for both applications which leads to quite a lot of frustrations, and I am sure there must be more customers feeling the same.
 
1)      The device has ample disk-space on board – but no ability to store data off-site, making data replication for Disaster Recovery sites non-existent, so it is unusable for the Internal Hub
2)      The device is not certified for use in the DMZ – which makes it unusable for our “External Hub”
 
My question is simple – for those few insiders that might know:
 
a)      Are there any plans to address either of these issues
b)      If so, can we have a timeline please
 
The announcement of the device brought along great excitement, but if these issues are both not on the radar to be resolved soon, I better start looking for different ways going forward.
 
Therefore I would really appreciate a honest, straight-forward, technical (not sales driven) answer to the 2 questions…  
 
 
Thank you.
 

 

 

Pieter Voges
Technical Specialist (Multi Discipline) | Group Technology | Nedbank Limited
12 Olyfenbosch Close Protea-Heights Brackenfell Western-Cape 7560 South Africa |
t +27 (0)21 981 3733  c +27 (0)83 645 5300   <at> pietervo <at> nedbank.co.za
Website: nedbank.co.za

 

 

 

 
THINK BEFORE YOU PRINT - At Nedbank we are committed to minimising environmental impact and encourage the preservation of natural capital.

 

 


 
 

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[
http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[
http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

 


List Archive
- Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


 


List Archive
- Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com



********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[
http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[
http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

 


List Archive
- Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


************************************************************
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.


************************************************************

 

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

************************************************************
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.
************************************************************

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

************************************************************
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.
************************************************************

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

T.Rob | 25 Aug 17:07 2015

Re: best approach for mq client connected apps and local user accounts on qmgr svrs

Hi Damian,

First thing is do *not* let MQ check account credentials at all unless at
least one of the following is true...

* The QMgr and client are both v8.0
* The channel is encrypted
* The channel runs an exit that encrypts the credentials with a per-session
key such as that offered by Capitalware.

The last thing you want is for user credentials to be flowing over the
network unencrypted.  If you use the v8.0 client, make sure the server is
configured to block credentials delivered over a plaintext channel from a <
v8.0 client.

With those requirements stipulated, most shops that I have experience with
either are very small and manage the passwords on the MQ servers, or else
use AD or LDAP to validate against a centrally managed credential database.

Since many shops will not have an all v8.0 client base or the MQAUSX exit,
encrypting the channels has been a frequent requirement to keep credentials
safe from network sniffers.  Although this can be done with no cert on the
client side, once you have anonymous TLS it's only a short distance to
mutually authenticated TLS and use of certs to authenticate the connection
rather than ID and password.  In many cases the effort to deploy per-user
certs is less than that required to set up password checking against a
central database.  Since cert authentication is done completely in the QMgr
with no external calls, it's also a lot faster.  This is the option I've
used most often, but I expect as v8.0 clients get rolled out we'll see more
ID/password auth.

On a related note...I have from time to time tried to get various vendors
interested in some cert management tools.  IBM's MQ product management
didn't want to encroach on functions provided by the various Tivoli
products, including Tivoli Key Lifecycle Manager.  Other vendors I
approached backed away due to it not being compatible with their core
offerings, or due to the complexity.  So choices for cert management are
either the stone knives and bearskins approach of scripting GSKit commands,
or the Enterprise-grade tools like ITKLM and Venafi that are overkill if all
you want is to manage MQ certs.  The market space between those is a barren
wasteland.

Eventually I came to the conclusion that the only way to get some cert
management tools in that barren middle-market space was to just do it.  I
hope to have something to announce about that in time for MQTC.  

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
https://ioptconsulting.com
https://twitter.com/tdotrob

> -----Original Message-----
> From: MQSeries List
[mailto:MQSERIES@...] On
> Behalf Of Costa, D. (Damian)
> Sent: Tuesday, August 25, 2015 5:26 AM
> To: MQSERIES@...
> Subject: best approahc for mq client connected apps and local user
> accounts on qmgr svrs
> 
> HI all,
>  How do all you people handle the accounts management for access into
> central /hub qmgrs for multiple apps connecting via MQ clients?
> Especially qmgrs on unix servers....
> 
> We have formal systems in place to create the local accounts  but that
> becomes a password maintenance  mission and our mq admin team certainly
> do not want to be maintaining user account passwords.
> 
> Should we be looking at an LDAP option so the qmgr can interrogate the
> domain controllers for the user account credentials?  Can MQ managers do
> that ? Or should we just use the channel auth user mapping capability
> for this component and leave the account maintenance with the
> application support teams.....
> 
> Are there any other options?
> Thanks.
> 
> 
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
> 
> To unsubscribe, write to
LISTSERV@... 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

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Costa, D. (Damian | 25 Aug 11:53 2015
Picon

Encountering a java error when genreating a JNDI bindings file.

Hi all,
On  Qmgr version 7.1.0.3 on AIX v 7*   , java 6:
 When I invoke the JMSAdmin app in /usr/mqm/java/bin I keep getting :

Exception in thread "main" java.lang.NoClassDefFoundError: com.ibm.mq.jms.admin.                                                                                                                     JMSAdmin
Caused by: java.lang.ClassNotFoundException: com.ibm.mq.jms.admin.JMSAdmin
        at java.net.URLClassLoader.findClass(URLClassLoader.java:434)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:677)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:358)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:643)
Could not find the main class: com.ibm.mq.jms.admin.JMSAdmin.  Program will exit   

I ran the setjmsenv script enve added the java bin folder for java v 6.

 So where are the java classes stored for JMSAdmin?

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Costa, D. (Damian | 25 Aug 11:25 2015
Picon

best approahc for mq client connected apps and local user accounts on qmgr svrs

HI all,
 How do all you people handle the accounts management for access into central /hub qmgrs for multiple apps
connecting via MQ clients? Especially qmgrs on unix servers....

We have formal systems in place to create the local accounts  but that becomes a password maintenance 
mission and our mq admin team certainly do not want to be maintaining user account passwords.

Should we be looking at an LDAP option so the qmgr can interrogate the domain controllers for the user
account credentials?  Can MQ managers do that ? Or should we just use the channel auth user mapping
capability for this component and leave the account maintenance with the application support teams.....

Are there any other options?
Thanks.

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES
T.Rob | 21 Aug 19:02 2015

Bats of a Feather

> I forgot T.Rob's sessions

 

I get that all the time, Roger. :-P

 

Also, no mention of the Bats of a Feather session in your list below so I hope you don't mind if I announce it. 

 

Bats of a Feather: 18:00 - 19:00 in the Vendor Pavilion

 

Bats of a Feather is conceived as a cross between Lightning Talks and the Birds of a Feather sessions that you remember from IMPACT and other conferences.  The idea is that you get a microphone and 3 minutes to tell your worst (best?) MQ horror story.  The crowd votes with a prize for the winner(s).  We do not yet know what the prize(s) will be but Roger said there would be at least one premium prize to give out.  More on that as it develops.

 

Anyone attending MQTC who wants to participate should come up with a 1 or 2 sentence talk title that you can fit into a Tweet with hashtag #MQTCBATS.  (I will also have a web page to submit these in case you do not use Twitter.)  Event organizers will collect all the titles and set up a Survey Monkey poll to vote for the talks people most want to hear.  During the event the MC will go down the list starting with the top vote-getter and working down.  If you are in the room when your talk is called up, you get to speak and a shot at the prize.  After the talks conclude, we'll have a judging to pick the winners.

 

Rules:

·       NO ACTUAL COMPANY OR PERSONAL NAMES, BRANDS, OR OTHER IDENTIFYING INFORMATION IS PERMITTED!  You are required to change the names to protect the guilty (and keep us all out of court).

·       Cutoff for topic submissions will be Tuesday September 22nd. That's one week before the event.

·       Talks will begin no earlier than 18:10 and end by 18:45.  We will keep going until we run out of speakers or time, whichever comes first.

·       You must be in the room to be eligible, and "on deck" ready to go when it's your turn to speak.

·       You get 3 minutes and will be timed.  If you go over, the next speaker might be tempted to tackle you and take the mic because you will be cutting into their time.

·       If more than one is submitted by the same person, your *last* submission before the cutoff will be used.  (So feel free to refine and revise your ideas.)

·       Vendors, sponsors and staff are ineligible to present or win prizes.  (They are however encouraged to donate prizes.)

 

Follow my blog at https://t-rob.net or the MQTC page for more details.  Feel free to begin tweeting talk titles now.  Over the weekend I will set up a web page where you can submit talk topics and check to see what's been submitted so far.  The survey page to vote for which talks you want to hear will go live on September 22nd.

 

Sound like fun?  I Hope so!

 

Kind regards,

-- T.Rob

 

T.Robert Wyatt, Managing partner

IoPT Consulting, LLC

+1 704-443-TROB (8762) Voice/Text

https://ioptconsulting.com

https://twitter.com/tdotrob

 

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org] On Behalf Of Roger Lacroix
Sent: Friday, August 21, 2015 12:17 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org
Subject: Re: MQ Technical Conference Final Schedule

 

Oops, copy & paste error.  I forgot T.Rob's sessions.


T.Rob Wyatt of IoPT Consulting
- Managing CA Certificates for MQ
- Beyond Intrusion Prevention

Roger Lacroix
Capitalware Inc.

On 8/21/2015 11:54 AM, Roger Lacroix wrote:

All,

The final schedule has been posted to http://www.mqtechconference.com/schedule.html

A session list by topics can be found at http://www.mqtechconference.com/sessions_v2015.html

A session list by tracks can be found at http://www.mqtechconference.com/tracks.html

Here is the list of sessions by speaker:

Technical Sessions:

Mark Taylor of IBM:
- What’s New in IBM Messaging
- MQ Integration with Directory Services
- PCF Programming
- Where is my Message?

Dave Ware of IBM:
- An introduction to MQ publish/subscribe
- Using publish/subscribe in an MQ network
- What can you achieve with MQ clusters?
- MQ Appliance

Matthew Whitehead of IBM:
- An Introduction to MQ Light, MQ's beta support for AMQP & Bluemix
- Deploying MQ Light applications against MQ
- An Introduction to JMS 2.0 in MQ V8

Chris Frank of IBM:
- Mysteries of the Distributed MQ Logger
- Flexible MQ Topologies in IBM Integration Bus V10
- MQ Appliance Administration Using the IBM MQ Console

Lyn Elkins of IBM:
- MQ for z/OS – Taking advantage of the platform
- MQ for z/OS – An introduction to tuning and queue manager management
- MQ for z/OS – An introduction to tuning applications for performance
- MQ for z/OS – The V8 SMF data

Jeff Lowrey of IBM:
- Advanced MQTT for Developers
- IOTF, MessageSight and Bluemix

Suganya Rane of Prolifics:
- Architecting & Tuning IIB / eXtreme Scale for Maximum Performance and Reliability
- Top Ten ways to improve your MQ/IIB environment

Sandeep Chellingi of Prolifics:
- Pure pattern for MQ & IIB components
- The new MQ Appliance as a “Messaging in a Box” and “MQ/MFT Hub” solution

Glen Brumbaugh of TxMQ:
- SOA, APIs, and MQ
- MQ Performance Tuning
- SSL/TLS: Using and Managing Certificates

Art Rodriguez of TxMQ:
- MQ for Administrators
- MQ Internet Pass Through

Allan Bartleywood of TxMQ:
- Can your App keep up with MQ

Gary Dischner of TxMQ:
- MQ Telemetry

Roger Lacroix of Capitalware:
- Introduction to MQ

Tim Zielke of AON:
- MQ Problem Determination With Tracing

Barry Lamkin of IBM:
- The top ten issues in IBM MQ and WebSphere MB

Greg Brown of CACI:
- Enabling Auto-Segmentation of Messages Having Defined Properties

Richard Nikula of Nastel Technologies:
- Leveraging WBI (Broker) Monitoring

Vendor Sessions:

Roger Lacroix of Capitalware:
- Capitalware's Commercial & Open Source Products Explained
- Application API Tracking
- Authentication with MQAUSX

Peter D'Agosta of Avada Software:
- Productivity through smart self service for IBM MQ/IIB
- An not allowed deep dive-little known secrets
- How to build a PLUG-IN to the IR360 framework

Richard Nikula of Nastel Technologies:
- 3 Things That Nobody Tells You About MQ Monitoring
- When Good Flows Go Bad...

Barry Lamkin of IBM:
- What is new in OMEGAMON XE for Messaging v7.3
- What happened to my Transaction

T.Rob Wyatt of IoPT Consulting:
- Advanced Scripting with MQSCX by T.Rob Wyatt

Allan Bartleywood of TxMQ:
- MQ Capacity Planner by Allan Bartleywood
- TxMQ Virtual MQ by Allan Bartleywood

Krista Valentine & Steve Lokam of OpenLogic:
- 7 Tips to Successful Engagements with your Business Partners

For more information about MQTC, please go to: http://www.mqtechconference.com

So, hopefully there is lots of MQ content that will keep attendees busy for 3 days.

Regards,
Roger Lacroix
Capitalware Inc.

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Roger Lacroix | 21 Aug 17:54 2015

MQ Technical Conference Final Schedule

All,

The final schedule has been posted to http://www.mqtechconference.com/schedule.html

A session list by topics can be found at http://www.mqtechconference.com/sessions_v2015.html

A session list by tracks can be found at http://www.mqtechconference.com/tracks.html

Here is the list of sessions by speaker:

Technical Sessions:

Mark Taylor of IBM:
- What’s New in IBM Messaging
- MQ Integration with Directory Services
- PCF Programming
- Where is my Message?

Dave Ware of IBM:
- An introduction to MQ publish/subscribe
- Using publish/subscribe in an MQ network
- What can you achieve with MQ clusters?
- MQ Appliance

Matthew Whitehead of IBM:
- An Introduction to MQ Light, MQ's beta support for AMQP & Bluemix
- Deploying MQ Light applications against MQ
- An Introduction to JMS 2.0 in MQ V8

Chris Frank of IBM:
- Mysteries of the Distributed MQ Logger
- Flexible MQ Topologies in IBM Integration Bus V10
- MQ Appliance Administration Using the IBM MQ Console

Lyn Elkins of IBM:
- MQ for z/OS – Taking advantage of the platform
- MQ for z/OS – An introduction to tuning and queue manager management
- MQ for z/OS – An introduction to tuning applications for performance
- MQ for z/OS – The V8 SMF data

Jeff Lowrey of IBM:
- Advanced MQTT for Developers
- IOTF, MessageSight and Bluemix

Suganya Rane of Prolifics:
- Architecting & Tuning IIB / eXtreme Scale for Maximum Performance and Reliability
- Top Ten ways to improve your MQ/IIB environment

Sandeep Chellingi of Prolifics:
- Pure pattern for MQ & IIB components
- The new MQ Appliance as a “Messaging in a Box” and “MQ/MFT Hub” solution

Glen Brumbaugh of TxMQ:
- SOA, APIs, and MQ
- MQ Performance Tuning
- SSL/TLS: Using and Managing Certificates

Art Rodriguez of TxMQ:
- MQ for Administrators
- MQ Internet Pass Through

Allan Bartleywood of TxMQ:
- Can your App keep up with MQ

Gary Dischner of TxMQ:
- MQ Telemetry

Roger Lacroix of Capitalware:
- Introduction to MQ

Tim Zielke of AON:
- MQ Problem Determination With Tracing

Barry Lamkin of IBM:
- The top ten issues in IBM MQ and WebSphere MB

Greg Brown of CACI:
- Enabling Auto-Segmentation of Messages Having Defined Properties

Richard Nikula of Nastel Technologies:
- Leveraging WBI (Broker) Monitoring

Vendor Sessions:

Roger Lacroix of Capitalware:
- Capitalware's Commercial & Open Source Products Explained
- Application API Tracking
- Authentication with MQAUSX

Peter D'Agosta of Avada Software:
- Productivity through smart self service for IBM MQ/IIB
- An not allowed deep dive-little known secrets
- How to build a PLUG-IN to the IR360 framework

Richard Nikula of Nastel Technologies:
- 3 Things That Nobody Tells You About MQ Monitoring
- When Good Flows Go Bad...

Barry Lamkin of IBM:
- What is new in OMEGAMON XE for Messaging v7.3
- What happened to my Transaction

T.Rob Wyatt of IoPT Consulting:
- Advanced Scripting with MQSCX by T.Rob Wyatt

Allan Bartleywood of TxMQ:
- MQ Capacity Planner by Allan Bartleywood
- TxMQ Virtual MQ by Allan Bartleywood

Krista Valentine & Steve Lokam of OpenLogic:
- 7 Tips to Successful Engagements with your Business Partners

For more information about MQTC, please go to: http://www.mqtechconference.com

So, hopefully there is lots of MQ content that will keep attendees busy for 3 days.

Regards,
Roger Lacroix
Capitalware Inc.


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


Gmane