MQPUT Times question

[Dave Corbett]

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+***@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

[Tim Zielke]

Hi Dave,

I did a test with an amqsputc on server A (Linux) to a queue manager on server B (Solaris 10). I first confirmed that the system times on both servers were in-line to at least 1 second. Then, I started the CLNTCONN channel with amqsputc and had it PUT a message to the queue manager on server B which was successful. Then I went to server B's queue manager and sent a SIGSTOP to the amqzlaa0 channel process that amqsputc was connected to. I then did another PUT, waited about a minute, and then sent a SIGCONT to the amqzlaa0 process which then processed the PUT. The PutTime in the message was about a minute after the PUT was done on the client server. So it looks like it used the timestamp from the MCA, based on this test.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Dave Corbett
Sent: Wednesday, June 12, 2013 8:45 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: MQPUT Times question

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.


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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

[Ward Able, Grant]

I would have thought that it always the time of the PUT to the queue that the message is in when you read the MQPUT time. Nothing to base this on other than observation over the years.


Regards - Grant.
Telephone Internal: x1496 London
Telephone External: [phone]

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Tim Zielke
Sent: Wednesday, June 12, 2013 3:20 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: MQPUT Times question

Hi Dave,

I did a test with an amqsputc on server A (Linux) to a queue manager on server B (Solaris 10). I first confirmed that the system times on both servers were in-line to at least 1 second. Then, I started the CLNTCONN channel with amqsputc and had it PUT a message to the queue manager on server B which was successful. Then I went to server B's queue manager and sent a SIGSTOP to the amqzlaa0 channel process that amqsputc was connected to. I then did another PUT, waited about a minute, and then sent a SIGCONT to the amqzlaa0 process which then processed the PUT. The PutTime in the message was about a minute after the PUT was done on the client server. So it looks like it used the timestamp from the MCA, based on this test.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT]<mailto:[mailto:***@LISTSERV.MEDUNIWIEN.AC.AT]> On Behalf Of Dave Corbett
Sent: Wednesday, June 12, 2013 8:45 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: MQPUT Times question

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.


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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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


<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+***@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

[Bruce Lerner]

PUT date/time are GMT.

PUT time is the time a message is MQPUT to a local queue. If the app opens
a QRemote definition, the put is to a local transmission queue. The sending
MCA gets the message from the xmit queue, but does not change the time in
the MQMD. Similarly, ghe receiving MCA does not change the put time. So,
the put time is that of the producing application MQPUT.

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

[Jefferson Lowrey]

To put some framework around what bruce said, and open myself wide for
being corrected...

If the client app has timezone set to EST, but the clock is actually set
to GMT+7....
And the server has timezone set to EDT, and the clock is actually set to
EDT and the correct time and synched against NIST or etc...

When the client app issues it's PUT, the message is streamed over the
client channel as the raw data for an MQPUT command, which is processed by
the MCA hosting the SVRCONN into an MQPUT against the resolved queue
destination. In the case of a QCLUSTER or QALIAS that points to a
QCLUSTER or QREMOTE or etc, this is the relevant transmission queue.

The MQPUT is executed on the server, by the server-side MCA, to the QLOCAL
(again, this is likely a transmission queue). The PUTTIME is set now,
based on the server clock and represented in GMT. But, again, if the
server clock is set badly, such that a conversion of localtime to GMT
produces an inaccurate value, then the PUTTIME is still inaccurate. But
it's correct as far as the server knows.


Thank you,

Jeff Lowrey



From: Bruce Lerner <brucelerner-JUB/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/12/2013 08:39 AM
Subject: Re: [MQSERIES] MQPUT Times question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>



PUT date/time are GMT.

PUT time is the time a message is MQPUT to a local queue. If the app
opens
a QRemote definition, the put is to a local transmission queue. The
sending
MCA gets the message from the xmit queue, but does not change the time in
the MQMD. Similarly, ghe receiving MCA does not change the put time. So,
the put time is that of the producing application MQPUT.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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



To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

[Ward Able, Grant]

Well, live and learn! Thanks for that, Jeff. Just goes to show this old dog can learn a new trick...


Regards - Grant.
Telephone Internal: x1496 London
Telephone External: [phone]

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Wednesday, June 12, 2013 3:47 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: MQPUT Times question

To put some framework around what bruce said, and open myself wide for being corrected...

If the client app has timezone set to EST, but the clock is actually set to GMT+7....
And the server has timezone set to EDT, and the clock is actually set to EDT and the correct time and synched against NIST or etc...

When the client app issues it's PUT, the message is streamed over the client channel as the raw data for an MQPUT command, which is processed by the MCA hosting the SVRCONN into an MQPUT against the resolved queue destination. In the case of a QCLUSTER or QALIAS that points to a QCLUSTER or QREMOTE or etc, this is the relevant transmission queue.

The MQPUT is executed on the server, by the server-side MCA, to the QLOCAL (again, this is likely a transmission queue). The PUTTIME is set now, based on the server clock and represented in GMT. But, again, if the server clock is set badly, such that a conversion of localtime to GMT produces an inaccurate value, then the PUTTIME is still inaccurate. But it's correct as far as the server knows.


Thank you,

Jeff Lowrey



From: Bruce Lerner <***@CHARTER.NET<mailto:***@CHARTER.NET>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>,
Date: 06/12/2013 08:39 AM
Subject: Re: [MQSERIES] MQPUT Times question
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________



PUT date/time are GMT.

PUT time is the time a message is MQPUT to a local queue. If the app opens
a QRemote definition, the put is to a local transmission queue. The sending
MCA gets the message from the xmit queue, but does not change the time in
the MQMD. Similarly, ghe receiving MCA does not change the put time. So,
the put time is that of the producing application MQPUT.

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> 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<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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


<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+***@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

[Tim Zielke]

Thank you Jeff and Bruce, for the clarification. That was helpful.

It seems to me that it would be helpful to have a message flow time stamp in the message descriptor. Maybe an array of a limit of 10 that specifies the application name doing the PUT, the queue manager name (if applicable), the server it was done on, and the GMT time stamp. It would start with an entry for the original application for when it issued the MQPUT API with that application name, queue manager name (maybe if bindings mode), server name, and timestamp. The array would end with the MQ process name, queue manager name, server name, and GMT time stamp for the final resting place of the message. If you needed to record more than 10 hops, then you would probably want to keep the first 5 entries beginning with the application and keep the last 5 hops with the last entry being the last queue manager stop, and set some flag that says 10 hops was exceeded. I understand that not all servers in the flow may have a consistent system clock, but this could be helpful for identifying significant slowness in a hop and also just seeing the message path.

I think I might open up an RFE for this idea, unless people have reasons that it would not work, be feasible, etc.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Wednesday, June 12, 2013 9:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question

To put some framework around what bruce said, and open myself wide for being corrected...

If the client app has timezone set to EST, but the clock is actually set to GMT+7....
And the server has timezone set to EDT, and the clock is actually set to EDT and the correct time and synched against NIST or etc...

When the client app issues it's PUT, the message is streamed over the client channel as the raw data for an MQPUT command, which is processed by the MCA hosting the SVRCONN into an MQPUT against the resolved queue destination. In the case of a QCLUSTER or QALIAS that points to a QCLUSTER or QREMOTE or etc, this is the relevant transmission queue.

The MQPUT is executed on the server, by the server-side MCA, to the QLOCAL (again, this is likely a transmission queue). The PUTTIME is set now, based on the server clock and represented in GMT. But, again, if the server clock is set badly, such that a conversion of localtime to GMT produces an inaccurate value, then the PUTTIME is still inaccurate. But it's correct as far as the server knows.


Thank you,

Jeff Lowrey



From: Bruce Lerner <brucelerner-JUB/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/12/2013 08:39 AM
Subject: Re: [MQSERIES] MQPUT Times question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
________________________________



PUT date/time are GMT.

PUT time is the time a message is MQPUT to a local queue. If the app opens
a QRemote definition, the put is to a local transmission queue. The sending
MCA gets the message from the xmit queue, but does not change the time in
the MQMD. Similarly, ghe receiving MCA does not change the put time. So,
the put time is that of the producing application MQPUT.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

[Dominique Courtois]

Tim,
This is not a contradiction. The MQPUT, as far as WMQ is involved, is actually
executed on the server by the amqzlaa0 on behalf of the MCA on behalf of the
client application process and not on the client system itself. So the PUTTIME
must be the time of the MQPUT by the channel not by the client process.
Regards
Dominique

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

[Jefferson Lowrey]

So you want every message to include all of the information you can gather
from trace routing?
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/mo12620_.htm


Are you sure you want every message to include all of that information?
Including your 500byte IMS messages that need to be processed ASAP?


Thank you,

Jeff Lowrey



From: Tim Zielke <tim.zielke-RzW+Fo++***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/12/2013 10:03 AM
Subject: Re: [MQSERIES] MQPUT Times question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>



Thank you Jeff and Bruce, for the clarification. That was helpful.

It seems to me that it would be helpful to have a message flow time stamp
in the message descriptor. Maybe an array of a limit of 10 that specifies
the application name doing the PUT, the queue manager name (if
applicable), the server it was done on, and the GMT time stamp. It would
start with an entry for the original application for when it issued the
MQPUT API with that application name, queue manager name (maybe if
bindings mode), server name, and timestamp. The array would end with the
MQ process name, queue manager name, server name, and GMT time stamp for
the final resting place of the message. If you needed to record more than
10 hops, then you would probably want to keep the first 5 entries
beginning with the application and keep the last 5 hops with the last
entry being the last queue manager stop, and set some flag that says 10
hops was exceeded. I understand that not all servers in the flow may have
a consistent system clock, but this could be helpful for identifying
significant slowness in a hop and also just seeing the message path.

I think I might open up an RFE for this idea, unless people have reasons
that it would not work, be feasible, etc.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Jefferson Lowrey
Sent: Wednesday, June 12, 2013 9:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question

To put some framework around what bruce said, and open myself wide for
being corrected...

If the client app has timezone set to EST, but the clock is actually set
to GMT+7....
And the server has timezone set to EDT, and the clock is actually set to
EDT and the correct time and synched against NIST or etc...

When the client app issues it's PUT, the message is streamed over the
client channel as the raw data for an MQPUT command, which is processed by
the MCA hosting the SVRCONN into an MQPUT against the resolved queue
destination. In the case of a QCLUSTER or QALIAS that points to a
QCLUSTER or QREMOTE or etc, this is the relevant transmission queue.

The MQPUT is executed on the server, by the server-side MCA, to the QLOCAL
(again, this is likely a transmission queue). The PUTTIME is set now,
based on the server clock and represented in GMT. But, again, if the
server clock is set badly, such that a conversion of localtime to GMT
produces an inaccurate value, then the PUTTIME is still inaccurate. But
it's correct as far as the server knows.


Thank you,

Jeff Lowrey



From: Bruce Lerner <brucelerner-JUB/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/12/2013 08:39 AM
Subject: Re: [MQSERIES] MQPUT Times question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>




PUT date/time are GMT.

PUT time is the time a message is MQPUT to a local queue. If the app
opens
a QRemote definition, the put is to a local transmission queue. The
sending
MCA gets the message from the xmit queue, but does not change the time in
the MQMD. Similarly, ghe receiving MCA does not change the put time. So,
the put time is that of the producing application MQPUT.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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



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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

[Tim Zielke]

I wasn't aware of the MQ trace routing functionality. Looks like this idea already exists. Thanks for pointing that out!

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Wednesday, June 12, 2013 11:08 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question

So you want every message to include all of the information you can gather from trace routing? http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/mo12620_.htm

Are you sure you want every message to include all of that information? Including your 500byte IMS messages that need to be processed ASAP?


Thank you,

Jeff Lowrey



From: Tim Zielke <tim.zielke-RzW+Fo++***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/12/2013 10:03 AM
Subject: Re: [MQSERIES] MQPUT Times question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
________________________________



Thank you Jeff and Bruce, for the clarification. That was helpful.

It seems to me that it would be helpful to have a message flow time stamp in the message descriptor. Maybe an array of a limit of 10 that specifies the application name doing the PUT, the queue manager name (if applicable), the server it was done on, and the GMT time stamp. It would start with an entry for the original application for when it issued the MQPUT API with that application name, queue manager name (maybe if bindings mode), server name, and timestamp. The array would end with the MQ process name, queue manager name, server name, and GMT time stamp for the final resting place of the message. If you needed to record more than 10 hops, then you would probably want to keep the first 5 entries beginning with the application and keep the last 5 hops with the last entry being the last queue manager stop, and set some flag that says 10 hops was exceeded. I understand that not all servers in the flow may have a consistent system clock, but this could be helpful for identifying significant slowness in a hop and also just seeing the message path.

I think I might open up an RFE for this idea, unless people have reasons that it would not work, be feasible, etc.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Wednesday, June 12, 2013 9:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question

To put some framework around what bruce said, and open myself wide for being corrected...

If the client app has timezone set to EST, but the clock is actually set to GMT+7....
And the server has timezone set to EDT, and the clock is actually set to EDT and the correct time and synched against NIST or etc...

When the client app issues it's PUT, the message is streamed over the client channel as the raw data for an MQPUT command, which is processed by the MCA hosting the SVRCONN into an MQPUT against the resolved queue destination. In the case of a QCLUSTER or QALIAS that points to a QCLUSTER or QREMOTE or etc, this is the relevant transmission queue.

The MQPUT is executed on the server, by the server-side MCA, to the QLOCAL (again, this is likely a transmission queue). The PUTTIME is set now, based on the server clock and represented in GMT. But, again, if the server clock is set badly, such that a conversion of localtime to GMT produces an inaccurate value, then the PUTTIME is still inaccurate. But it's correct as far as the server knows.


Thank you,

Jeff Lowrey



From: Bruce Lerner <brucelerner-JUB/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/12/2013 08:39 AM
Subject: Re: [MQSERIES] MQPUT Times question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
________________________________




PUT date/time are GMT.

PUT time is the time a message is MQPUT to a local queue. If the app opens
a QRemote definition, the put is to a local transmission queue. The sending
MCA gets the message from the xmit queue, but does not change the time in
the MQMD. Similarly, ghe receiving MCA does not change the put time. So,
the put time is that of the producing application MQPUT.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

[Potkay, Peter M (CTO Architecture + Engineering)]

Suitably authorized (or unsuitably as the case may be) apps can set the
put time in the MQMD to whatever they want.

I set the put time to blanks on QM1 when I put to a remote queue that
aims at a local q on QM2. The message is sitting on QM2 with a blank put
time. This to me says the original put time value is carried during QM
to QM routing.

Don't forget there is a secondary MQMD with its own put time when a
message is sitting on an XMITQ

You can never be 100% sure the put time in the MQMD represents exactly
when the message was actually put.

Peter Potkay



-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Dominique Courtois
Sent: Wednesday, June 12, 2013 11:30 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question

Tim,
This is not a contradiction. The MQPUT, as far as WMQ is involved, is
actually executed on the server by the amqzlaa0 on behalf of the MCA on
behalf of the client application process and not on the client system
itself. So the PUTTIME must be the time of the MQPUT by the channel not
by the client process.
Regards
Dominique

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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
************************************************************
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+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Bruce Lerner]

Adding to the usual misunderstandings, the term 'client' has multiple
meanings here. Let's eliminate the client/server definition (a client app
requests a service from a serving app).

In MQ-speak, if the app uses 'client bindings,' the MQPUT call is shipped
across the network (from the client platform) to the SVRCONN channel, and
executes on the (queue manager) server to put the message on a local queue.
The timestamp is what, as Jeff points out, GMT as the server is configured
to believe.

Alternatively, if the app uses 'server bindings' the MQPUT executes
cross-memory to WMQ internals - no network involvement. In this instance,
the timestamp (still GMT) is that of the platform where the qmgr is running,
however GMT configured on that platform.

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

[Paul Clarke]

This is true with the slight exception of multicast. If you are using
multicast in your MQ client then messages don't flow through the server but
are transmitted directly from one client to another so, naturally, all
context fields are filled in by the client.

Cheers,
Paul.

Paul Clarke
www.mqgem.com
-----Original Message-----
From: Bruce Lerner
Sent: Wednesday, June 12, 2013 6:23 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question

Adding to the usual misunderstandings, the term 'client' has multiple
meanings here. Let's eliminate the client/server definition (a client app
requests a service from a serving app).

In MQ-speak, if the app uses 'client bindings,' the MQPUT call is shipped
across the network (from the client platform) to the SVRCONN channel, and
executes on the (queue manager) server to put the message on a local queue.
The timestamp is what, as Jeff points out, GMT as the server is configured
to believe.

Alternatively, if the app uses 'server bindings' the MQPUT executes
cross-memory to WMQ internals - no network involvement. In this instance,
the timestamp (still GMT) is that of the platform where the qmgr is running,
however GMT configured on that platform.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

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

[Glenn Baddeley]

Jeff wrote:
| The MQPUT is executed on the server, by the server-side MCA, to the
| QLOCAL (again, this is likely a transmission queue). The PUTTIME is set
| now, based on the server clock and represented in GMT. But, again, if the
| server clock is set badly, such that a conversion of localtime to GMT
| produces an inaccurate value, then the PUTTIME is still inaccurate.
| But it's correct as far as the server knows.

I was under the impression that system clocks normally run as GMT, and then
an adjustment is applied to generate local time, eg. the UNIX time() function
returns GMT, and localtime() converts the value to local time.

PUTTIME only has a resolution of 1/100 second so it is not particularly useful
for doing accurate latency measurements. MQ is capable of processing a *lot*
of messages in that time interval.

Its very unlikely that IBM will change the MQMD format to provide a
putdate/time history. Even going from v1 to v2 many moons ago was a big
step and created problems in some environments. IBM was even averse to
extending the MQMD to store Properties and other information, that found its
way into weird and wonderful header structures in the Message Data payload.

HTH, G.

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

[Dave Corbett]

Listers,

First of all - I want to thank everyone for commenting on the PUT time
question I posed. I am actually surprised by the fact that the original
message date/time is not maintained, and yet I understand (sort of) why
that is.

Regardless,

How about another question for SSL experts. We ran into some issues with
gskit7 / gskit8, etc. The short issue is that we need to rebuild our
keystore on a 7.0.1.6 QMGR on Windows. (this is a test environment).

After rebuilding the keystore, we are attempting to import a .pfx file
(our internal PKI has generated the keys for our keystore). However,
every time I try to import it, I receive the following error:
H:\>gsk7capicmd -cert -import -db <.pfx file path>\<pfx file>
" -target "<keystore path>\<keystore name>.kdb"
A password is required to access this key database
Please enter a password: **************
Error: 2

Please refer to the GSKCapiCmd User's Guide
for the meaning of the error.

Error id: GSKKM_ERR_ASN
Details: <<.pfx file path>\<pfx file>

I have taken the .cer and the .key file, and converted them into a .pfx
file with openssl. I have also tried the .pfx file that our PKI team
generated as part of their process

Nothing ever changes - I continually get this error - and when I try to
research it, all I find is some obscure link to something indicating that
there is a duplicate somewhere in my keystore, and yet all that is in the
keystore is the root certs created for the various CA's when we created
the keystore itself.

Has anyone else run into this error - and can explain what is happening?

Thanks,
David Corbett
Work: 612-973-7086
Pager: 612-280-6307
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0



From: "Potkay, Peter M (CTO Architecture + Engineering)"
<Peter.Potkay-***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Date: 06/12/2013 11:25 AM
Subject: Re: MQPUT Times question
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>



Suitably authorized (or unsuitably as the case may be) apps can set the
put time in the MQMD to whatever they want.

I set the put time to blanks on QM1 when I put to a remote queue that
aims at a local q on QM2. The message is sitting on QM2 with a blank put
time. This to me says the original put time value is carried during QM
to QM routing.

Don't forget there is a secondary MQMD with its own put time when a
message is sitting on an XMITQ

You can never be 100% sure the put time in the MQMD represents exactly
when the message was actually put.

Peter Potkay



-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Dominique Courtois
Sent: Wednesday, June 12, 2013 11:30 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question

Tim,
This is not a contradiction. The MQPUT, as far as WMQ is involved, is
actually executed on the server by the amqzlaa0 on behalf of the MCA on
behalf of the client application process and not on the client system
itself. So the PUTTIME must be the time of the MQPUT by the channel not
by the client process.
Regards
Dominique

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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
************************************************************
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+***@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


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+***@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

[Potkay, Peter M (CTO Architecture + Engineering)]

Dave,

I posted a reply that shows in my testing the original put time is
carried forward.



Suitably authorized (or unsuitably as the case may be) apps can set the
put time in the MQMD to whatever they want.



I set the put time to blanks on QM1 when I put to a remote queue that
aims at a local q on QM2. The message is sitting on QM2 with a blank put
time. This to me says the original put time value is carried during QM
to QM routing.



Don't forget there is a secondary MQMD with its own put time when a
message is sitting on an XMITQ



You can never be 100% sure the put time in the MQMD represents exactly
when the message was actually put.







Peter Potkay





From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Dave Corbett
Sent: Friday, June 14, 2013 3:44 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question (and now time for an SSL question)



Listers,

First of all - I want to thank everyone for commenting on the PUT time
question I posed. I am actually surprised by the fact that the original
message date/time is not maintained, and yet I understand (sort of) why
that is.

Regardless,

How about another question for SSL experts. We ran into some issues
with gskit7 / gskit8, etc. The short issue is that we need to rebuild
our keystore on a 7.0.1.6 QMGR on Windows. (this is a test
environment).

After rebuilding the keystore, we are attempting to import a .pfx file
(our internal PKI has generated the keys for our keystore). However,
every time I try to import it, I receive the following error:
H:\>gsk7capicmd -cert -import -db <.pfx file path>\<pfx file>
" -target "<keystore path>\<keystore name>.kdb"
A password is required to access this key database
Please enter a password: **************
Error: 2

Please refer to the GSKCapiCmd User's Guide
for the meaning of the error.

Error id: GSKKM_ERR_ASN
Details: <<.pfx file path>\<pfx file>

I have taken the .cer and the .key file, and converted them into a .pfx
file with openssl. I have also tried the .pfx file that our PKI team
generated as part of their process

Nothing ever changes - I continually get this error - and when I try to
research it, all I find is some obscure link to something indicating
that there is a duplicate somewhere in my keystore, and yet all that is
in the keystore is the root certs created for the various CA's when we
created the keystore itself.

Has anyone else run into this error - and can explain what is happening?


Thanks,
David Corbett
Work: 612-973-7086
Pager: 612-280-6307
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0



From: "Potkay, Peter M (CTO Architecture + Engineering)"
<Peter.Potkay-***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Date: 06/12/2013 11:25 AM
Subject: Re: MQPUT Times question
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>

________________________________




Suitably authorized (or unsuitably as the case may be) apps can set the
put time in the MQMD to whatever they want.

I set the put time to blanks on QM1 when I put to a remote queue that
aims at a local q on QM2. The message is sitting on QM2 with a blank put
time. This to me says the original put time value is carried during QM
to QM routing.

Don't forget there is a secondary MQMD with its own put time when a
message is sitting on an XMITQ

You can never be 100% sure the put time in the MQMD represents exactly
when the message was actually put.

Peter Potkay



-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> ] On
Behalf Of Dominique Courtois
Sent: Wednesday, June 12, 2013 11:30 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question

Tim,
This is not a contradiction. The MQPUT, as far as WMQ is involved, is
actually executed on the server by the amqzlaa0 on behalf of the MCA on
behalf of the client application process and not on the client system
itself. So the PUTTIME must be the time of the MQPUT by the channel not
by the client process.
Regards
Dominique

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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
<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
<http://listserv.meduniwien.ac.at/archives/mqser-l.html>
************************************************************
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+***@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
<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
<http://listserv.meduniwien.ac.at/archives/mqser-l.html>

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.


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



________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=sign
off%20mqseries>

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

************************************************************
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+***@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

[Tim Zielke]

Hi Peter,

I was curious about this, so I tried recreating your test and I am not able to get the behavior you were seeing.

I have a QM1 (Linux 7.1.0.2) with a remote queue that aims at a local queue on QM2 (Solaris 7.1.0.2).

I updated the amqsput program to change the md.PutTime to spaces before doing the PUT. However, when I look at the message on the local queue on QM2, it has been updated with a current PutTime. I tried changing the md.PutTime to a bogus time, and again the message on the local queue on QM2 has a current PutTime.

Maybe I am misunderstanding what you were saying.

Incidentally, I also did the test with the remote queue set up where I froze the RVCR channel process on QM2 with a STOP signal, did a PUT to the remote queue on QM1, and then unfroze the RCVR channel process on QM2 2 minutes later with a CONT signal. The message showed up on the local queue on QM2 with a PutTime that was 2 minutes old. So just more confirmation on what the experts have been saying on how this works (not that I was doubting anybody :-) ).

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Friday, June 14, 2013 3:14 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question (and now time for an SSL question)

Dave,
I posted a reply that shows in my testing the original put time is carried forward.


Suitably authorized (or unsuitably as the case may be) apps can set the put time in the MQMD to whatever they want.



I set the put time to blanks on QM1 when I put to a remote queue that aims at a local q on QM2. The message is sitting on QM2 with a blank put time. This to me says the original put time value is carried during QM to QM routing.



Don't forget there is a secondary MQMD with its own put time when a message is sitting on an XMITQ



You can never be 100% sure the put time in the MQMD represents exactly when the message was actually put.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Dave Corbett
Sent: Friday, June 14, 2013 3:44 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question (and now time for an SSL question)

Listers,

First of all - I want to thank everyone for commenting on the PUT time question I posed. I am actually surprised by the fact that the original message date/time is not maintained, and yet I understand (sort of) why that is.

Regardless,

How about another question for SSL experts. We ran into some issues with gskit7 / gskit8, etc. The short issue is that we need to rebuild our keystore on a 7.0.1.6 QMGR on Windows. (this is a test environment).

After rebuilding the keystore, we are attempting to import a .pfx file (our internal PKI has generated the keys for our keystore). However, every time I try to import it, I receive the following error:
H:\>gsk7capicmd -cert -import -db <.pfx file path>\<pfx file>
" -target "<keystore path>\<keystore name>.kdb"
A password is required to access this key database
Please enter a password: **************
Error: 2

Please refer to the GSKCapiCmd User's Guide
for the meaning of the error.

Error id: GSKKM_ERR_ASN
Details: <<.pfx file path>\<pfx file>

I have taken the .cer and the .key file, and converted them into a .pfx file with openssl. I have also tried the .pfx file that our PKI team generated as part of their process

Nothing ever changes - I continually get this error - and when I try to research it, all I find is some obscure link to something indicating that there is a duplicate somewhere in my keystore, and yet all that is in the keystore is the root certs created for the various CA's when we created the keystore itself.

Has anyone else run into this error - and can explain what is happening?

Thanks,
David Corbett
Work: 612-973-7086
Pager: 612-280-6307
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0



From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>
Date: 06/12/2013 11:25 AM
Subject: Re: MQPUT Times question
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________



Suitably authorized (or unsuitably as the case may be) apps can set the
put time in the MQMD to whatever they want.

I set the put time to blanks on QM1 when I put to a remote queue that
aims at a local q on QM2. The message is sitting on QM2 with a blank put
time. This to me says the original put time value is carried during QM
to QM routing.

Don't forget there is a secondary MQMD with its own put time when a
message is sitting on an XMITQ

You can never be 100% sure the put time in the MQMD represents exactly
when the message was actually put.

Peter Potkay



-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Dominique Courtois
Sent: Wednesday, June 12, 2013 11:30 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: MQPUT Times question

Tim,
This is not a contradiction. The MQPUT, as far as WMQ is involved, is
actually executed on the server by the amqzlaa0 on behalf of the MCA on
behalf of the client application process and not on the client system
itself. So the PUTTIME must be the time of the MQPUT by the channel not
by the client process.
Regards
Dominique

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> 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<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
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+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> 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<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

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.


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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

************************************************************
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<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

[Neil Casey]

Hi Tim,

in order to set the PUTDATE (or other context fields) you have to correctly set the MQPMO options value, and you have to have opened the queue with the correct open options, and you have to be authorised.

See http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/fg12380_.htm

Regards,

Neil Casey.

Post by Tim Zielke
Hi Peter,
I was curious about this, so I tried recreating your test and I am not able to get the behavior you were seeing.
I have a QM1 (Linux 7.1.0.2) with a remote queue that aims at a local queue on QM2 (Solaris 7.1.0.2).
I updated the amqsput program to change the md.PutTime to spaces before doing the PUT. However, when I look at the message on the local queue on QM2, it has been updated with a current PutTime. I tried changing the md.PutTime to a bogus time, and again the message on the local queue on QM2 has a current PutTime.
Maybe I am misunderstanding what you were saying.
Incidentally, I also did the test with the remote queue set up where I froze the RVCR channel process on QM2 with a STOP signal, did a PUT to the remote queue on QM1, and then unfroze the RCVR channel process on QM2 2 minutes later with a CONT signal. The message showed up on the local queue on QM2 with a PutTime that was 2 minutes old. So just more confirmation on what the experts have been saying on how this works (not that I was doubting anybody :-) ).
Thanks,
Tim
Sent: Friday, June 14, 2013 3:14 PM
Subject: Re: MQPUT Times question (and now time for an SSL question)
Dave,
I posted a reply that shows in my testing the original put time is carried forward.
Suitably authorized (or unsuitably as the case may be) apps can set the put time in the MQMD to whatever they want.
I set the put time to blanks on QM1 when I put to a remote queue that aims at a local q on QM2. The message is sitting on QM2 with a blank put time. This to me says the original put time value is carried during QM to QM routing.
Don't forget there is a secondary MQMD with its own put time when a message is sitting on an XMITQ
You can never be 100% sure the put time in the MQMD represents exactly when the message was actually put.
Peter Potkay
Sent: Friday, June 14, 2013 3:44 PM
Subject: Re: MQPUT Times question (and now time for an SSL question)
Listers,
First of all - I want to thank everyone for commenting on the PUT time question I posed. I am actually surprised by the fact that the original message date/time is not maintained, and yet I understand (sort of) why that is.
Regardless,
How about another question for SSL experts. We ran into some issues with gskit7 / gskit8, etc. The short issue is that we need to rebuild our keystore on a 7.0.1.6 QMGR on Windows. (this is a test environment).
H:\>gsk7capicmd -cert -import -db <.pfx file path>\<pfx file>
" -target "<keystore path>\<keystore name>.kdb"
A password is required to access this key database
Please enter a password: **************
Error: 2
Please refer to the GSKCapiCmd User's Guide
for the meaning of the error.
Error id: GSKKM_ERR_ASN
Details: <<.pfx file path>\<pfx file>
I have taken the .cer and the .key file, and converted them into a .pfx file with openssl. I have also tried the .pfx file that our PKI team generated as part of their process
Nothing ever changes - I continually get this error - and when I try to research it, all I find is some obscure link to something indicating that there is a duplicate somewhere in my keystore, and yet all that is in the keystore is the root certs created for the various CA's when we created the keystore itself.
Has anyone else run into this error - and can explain what is happening?
Thanks,
David Corbett
Work: 612-973-7086
Pager: 612-280-6307
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0
Date: 06/12/2013 11:25 AM
Subject: Re: MQPUT Times question
Suitably authorized (or unsuitably as the case may be) apps can set the
put time in the MQMD to whatever they want.
I set the put time to blanks on QM1 when I put to a remote queue that
aims at a local q on QM2. The message is sitting on QM2 with a blank put
time. This to me says the original put time value is carried during QM
to QM routing.
Don't forget there is a secondary MQMD with its own put time when a
message is sitting on an XMITQ
You can never be 100% sure the put time in the MQMD represents exactly
when the message was actually put.
Peter Potkay
-----Original Message-----
Behalf Of Dominique Courtois
Sent: Wednesday, June 12, 2013 11:30 AM
Subject: Re: MQPUT Times question
Tim,
This is not a contradiction. The MQPUT, as far as WMQ is involved, is
actually executed on the server by the amqzlaa0 on behalf of the MCA on
behalf of the client application process and not on the client system
itself. So the PUTTIME must be the time of the MQPUT by the channel not
by the client process.
Regards
Dominique
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
************************************************************
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.
************************************************************
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
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.
---------------------------------------------------------------------
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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

[Tim Zielke]

Thanks, Neil. I made those adjustments and now the PutTime that the amqsput program is setting is getting preserved all the way to the message on the local queue on QM2.

So if the application is not requesting to update the origin context of a message (like PutTime) or is not authorized to perform this function, the PutTime will be the first time that an MQ queue manager PUT the message to a queue (i.e. XMITQ, SYSTEM.CLUSTER.TRANSMIT.QUEUE, etc.), regardless of how many queue manager hops the message goes through to its final queue destination.

If an authorized application requests to update the origin context of a message (like PutTime), the PutTime could represent anything that application is setting it to, perhaps the time right before the application issued the PUT API.

I can see now why Peter said "You can never be 100% sure the put time in the MQMD represents exactly when the message was actually put."

Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Friday, June 14, 2013 9:48 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question (and now time for an SSL question)

Hi Tim,

in order to set the PUTDATE (or other context fields) you have to correctly set the MQPMO options value, and you have to have opened the queue with the correct open options, and you have to be authorised.

See http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/fg12380_.htm

Regards,

Neil Casey.
On 15/06/2013, at 12:33 PM, Tim Zielke <tim.zielke-RzW+Fo++***@public.gmane.org<mailto:tim.zielke-RzW+Fo++***@public.gmane.org>> wrote:


Hi Peter,

I was curious about this, so I tried recreating your test and I am not able to get the behavior you were seeing.

I have a QM1 (Linux 7.1.0.2) with a remote queue that aims at a local queue on QM2 (Solaris 7.1.0.2).

I updated the amqsput program to change the md.PutTime to spaces before doing the PUT. However, when I look at the message on the local queue on QM2, it has been updated with a current PutTime. I tried changing the md.PutTime to a bogus time, and again the message on the local queue on QM2 has a current PutTime.

Maybe I am misunderstanding what you were saying.

Incidentally, I also did the test with the remote queue set up where I froze the RVCR channel process on QM2 with a STOP signal, did a PUT to the remote queue on QM1, and then unfroze the RCVR channel process on QM2 2 minutes later with a CONT signal. The message showed up on the local queue on QM2 with a PutTime that was 2 minutes old. So just more confirmation on what the experts have been saying on how this works (not that I was doubting anybody :-) ).

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Friday, June 14, 2013 3:14 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: MQPUT Times question (and now time for an SSL question)

Dave,
I posted a reply that shows in my testing the original put time is carried forward.

Suitably authorized (or unsuitably as the case may be) apps can set the put time in the MQMD to whatever they want.

I set the put time to blanks on QM1 when I put to a remote queue that aims at a local q on QM2. The message is sitting on QM2 with a blank put time. This to me says the original put time value is carried during QM to QM routing.

Don't forget there is a secondary MQMD with its own put time when a message is sitting on an XMITQ

You can never be 100% sure the put time in the MQMD represents exactly when the message was actually put.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Dave Corbett
Sent: Friday, June 14, 2013 3:44 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: MQPUT Times question (and now time for an SSL question)

Listers,

First of all - I want to thank everyone for commenting on the PUT time question I posed. I am actually surprised by the fact that the original message date/time is not maintained, and yet I understand (sort of) why that is.

Regardless,

How about another question for SSL experts. We ran into some issues with gskit7 / gskit8, etc. The short issue is that we need to rebuild our keystore on a 7.0.1.6 QMGR on Windows. (this is a test environment).

After rebuilding the keystore, we are attempting to import a .pfx file (our internal PKI has generated the keys for our keystore). However, every time I try to import it, I receive the following error:
H:\>gsk7capicmd -cert -import -db <.pfx file path>\<pfx file>
" -target "<keystore path>\<keystore name>.kdb"
A password is required to access this key database
Please enter a password: **************
Error: 2

Please refer to the GSKCapiCmd User's Guide
for the meaning of the error.

Error id: GSKKM_ERR_ASN
Details: <<.pfx file path>\<pfx file>

I have taken the .cer and the .key file, and converted them into a .pfx file with openssl. I have also tried the .pfx file that our PKI team generated as part of their process

Nothing ever changes - I continually get this error - and when I try to research it, all I find is some obscure link to something indicating that there is a duplicate somewhere in my keystore, and yet all that is in the keystore is the root certs created for the various CA's when we created the keystore itself.

Has anyone else run into this error - and can explain what is happening?

Thanks,
David Corbett
Work: 612-973-7086
Pager: 612-280-6307
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0



From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>
Date: 06/12/2013 11:25 AM
Subject: Re: MQPUT Times question
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________



Suitably authorized (or unsuitably as the case may be) apps can set the
put time in the MQMD to whatever they want.

I set the put time to blanks on QM1 when I put to a remote queue that
aims at a local q on QM2. The message is sitting on QM2 with a blank put
time. This to me says the original put time value is carried during QM
to QM routing.

Don't forget there is a secondary MQMD with its own put time when a
message is sitting on an XMITQ

You can never be 100% sure the put time in the MQMD represents exactly
when the message was actually put.

Peter Potkay



-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Dominique Courtois
Sent: Wednesday, June 12, 2013 11:30 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: MQPUT Times question

Tim,
This is not a contradiction. The MQPUT, as far as WMQ is involved, is
actually executed on the server by the amqzlaa0 on behalf of the MCA on
behalf of the client application process and not on the client system
itself. So the PUTTIME must be the time of the MQPUT by the channel not
by the client process.
Regards
Dominique

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> 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<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
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+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> 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<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

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.


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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

************************************************************
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<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

[Bruce Lerner]

An application setting context fields in the MQMD takes additional
authority; however, suppressing context data (MQPMO_NO_CONTEXT) takes no
more authority than being able to MQPUT.

In practical terms, you can never be 100% certain about the application data
payload either - this, too, is under control of the application developer.

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

[Tim Zielke]

Hindsight is 20/20, but it is too bad there was not an extra 1-byte code added to the message descriptor to specify what parts of the context (i.e. identity, origin) were set by the queue manager or the application (i.e. code value of A = identity/origin both set by qmgr, B = identity/origin both set by application, etc.). That would help clear up some of the ambiguity with the PutTime.

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Bruce Lerner
Sent: Sunday, June 16, 2013 10:08 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question (and now time for an SSL question)

An application setting context fields in the MQMD takes additional
authority; however, suppressing context data (MQPMO_NO_CONTEXT) takes no
more authority than being able to MQPUT.

In practical terms, you can never be 100% certain about the application data
payload either - this, too, is under control of the application developer.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

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

[T.Rob]

Tim, it isn't as though you could rely on that. Remember that for
QMgr-to-QMgr connections, *every* MQMD field is set by the MCA on the way in
and it has to trust the MCA on the other side. We know of at least one case
where the thing on the other side not only wasn't an MCA but was a Python
program. Unless you control the other side, you have no reason to trust the
value in the MQMD, which is one reason the exit in the Redbook overwrites
the MQMD.UserID with the one from the local MCAUSER, which is a value you
*can* trust. Furthermore, any of those fields can be set by an exit, in
which case, what's the correct value for the flag and what's to enforce it?
And if the channel doesn't use SSL...

If such a flag were to exist, it would constrain honest users, but not
attackers. My issue with a lot of things presented as security controls are
that they make the user feel better but do not improve security. The result
is a security façade, which is bad enough, but a secondary result is that it
tends to suppress further investment in security - investment that might
actually accomplish something.

Prime example is using DNS names in exits as authenticators and now
[shudder] it looks like it will become a CHLAUTH option.

Hindsight is always 20/20? How about "looking back, it's still a bit
fuzzy"? (Yes, I'm paraphrasing Metallica. Extra points for those who
recognized that line.)

-- T.Rob

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Tim Zielke
Sent: Sunday, June 16, 2013 4:59 PM
Subject: Re: MQPUT Times question (and now time for an SSL question)
Hindsight is 20/20, but it is too bad there was not an extra 1-byte code

added to

Post by Potkay, Peter M (CTO Architecture + Engineering)
the message descriptor to specify what parts of the context (i.e.

identity, origin)

Post by Potkay, Peter M (CTO Architecture + Engineering)
were set by the queue manager or the application (i.e. code value of A =
identity/origin both set by qmgr, B = identity/origin both set by

application, etc.).

Post by Potkay, Peter M (CTO Architecture + Engineering)
That would help clear up some of the ambiguity with the PutTime.
Thanks,
Tim
-----Original Message-----
Behalf Of Bruce Lerner
Sent: Sunday, June 16, 2013 10:08 AM
Subject: Re: MQPUT Times question (and now time for an SSL question)
An application setting context fields in the MQMD takes additional

authority;

Post by Potkay, Peter M (CTO Architecture + Engineering)
however, suppressing context data (MQPMO_NO_CONTEXT) takes no more
authority than being able to MQPUT.
In practical terms, you can never be 100% certain about the application data
payload either - this, too, is under control of the application developer.
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv

General

Post by Potkay, Peter M (CTO Architecture + Engineering)
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv

General

Post by Potkay, Peter M (CTO Architecture + Engineering)
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

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

[Tim Zielke]

Thanks, T.Rob and Bruce, for the feedback. I can see after reading Bruce's follow on ponderings and your comments how this idea is probably not very feasible or practical. I think it might be time for this idea to "Fade to Black".

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Monday, June 17, 2013 6:14 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question (and now time for an SSL question)

Tim, it isn't as though you could rely on that. Remember that for
QMgr-to-QMgr connections, *every* MQMD field is set by the MCA on the way in
and it has to trust the MCA on the other side. We know of at least one case
where the thing on the other side not only wasn't an MCA but was a Python
program. Unless you control the other side, you have no reason to trust the
value in the MQMD, which is one reason the exit in the Redbook overwrites
the MQMD.UserID with the one from the local MCAUSER, which is a value you
*can* trust. Furthermore, any of those fields can be set by an exit, in
which case, what's the correct value for the flag and what's to enforce it?
And if the channel doesn't use SSL...

If such a flag were to exist, it would constrain honest users, but not
attackers. My issue with a lot of things presented as security controls are
that they make the user feel better but do not improve security. The result
is a security façade, which is bad enough, but a secondary result is that it
tends to suppress further investment in security - investment that might
actually accomplish something.

Prime example is using DNS names in exits as authenticators and now
[shudder] it looks like it will become a CHLAUTH option.

Hindsight is always 20/20? How about "looking back, it's still a bit
fuzzy"? (Yes, I'm paraphrasing Metallica. Extra points for those who
recognized that line.)

-- T.Rob

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Tim Zielke
Sent: Sunday, June 16, 2013 4:59 PM
Subject: Re: MQPUT Times question (and now time for an SSL question)
Hindsight is 20/20, but it is too bad there was not an extra 1-byte code

added to

Post by Potkay, Peter M (CTO Architecture + Engineering)
the message descriptor to specify what parts of the context (i.e.

identity, origin)

Post by Potkay, Peter M (CTO Architecture + Engineering)
were set by the queue manager or the application (i.e. code value of A =
identity/origin both set by qmgr, B = identity/origin both set by

application, etc.).

Post by Potkay, Peter M (CTO Architecture + Engineering)
That would help clear up some of the ambiguity with the PutTime.
Thanks,
Tim
-----Original Message-----
Behalf Of Bruce Lerner
Sent: Sunday, June 16, 2013 10:08 AM
Subject: Re: MQPUT Times question (and now time for an SSL question)
An application setting context fields in the MQMD takes additional

authority;

Post by Potkay, Peter M (CTO Architecture + Engineering)
however, suppressing context data (MQPMO_NO_CONTEXT) takes no more
authority than being able to MQPUT.
In practical terms, you can never be 100% certain about the application data
payload either - this, too, is under control of the application developer.
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv

General

Post by Potkay, Peter M (CTO Architecture + Engineering)
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv

General

Post by Potkay, Peter M (CTO Architecture + Engineering)
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

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

[T.Rob]

Curt pointed out (off list too - what a gentleman!) that I *said* Metallica
but really *meant* Megadeth. That's NEVER happened to anyone before. ;-)

Couldn't come up with a good title for this idea from the Megadeth catalog,
except possibly Countdown to Extinction. Or else install AMS. The MQMD
identity will be irrelevant and we can quote from the Cryptic Writings CD.

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Tim Zielke
Sent: Monday, June 17, 2013 5:01 PM
Subject: Re: MQPUT Times question (and now time for an SSL question)
Thanks, T.Rob and Bruce, for the feedback. I can see after reading

Bruce's

Post by Potkay, Peter M (CTO Architecture + Engineering)
follow on ponderings and your comments how this idea is probably not very
feasible or practical. I think it might be time for this idea to "Fade to

Black".

Post by Potkay, Peter M (CTO Architecture + Engineering)
Thanks,
Tim
-----Original Message-----
Behalf Of T.Rob
Sent: Monday, June 17, 2013 6:14 AM
Subject: Re: MQPUT Times question (and now time for an SSL question)
Tim, it isn't as though you could rely on that. Remember that for

QMgr-to-QMgr

Post by Potkay, Peter M (CTO Architecture + Engineering)
connections, *every* MQMD field is set by the MCA on the way in and it has

to

Post by Potkay, Peter M (CTO Architecture + Engineering)
trust the MCA on the other side. We know of at least one case where the

thing

Post by Potkay, Peter M (CTO Architecture + Engineering)
on the other side not only wasn't an MCA but was a Python program. Unless
you control the other side, you have no reason to trust the value in the

MQMD,

Post by Potkay, Peter M (CTO Architecture + Engineering)
which is one reason the exit in the Redbook overwrites the MQMD.UserID

with

Post by Potkay, Peter M (CTO Architecture + Engineering)
the one from the local MCAUSER, which is a value you
*can* trust. Furthermore, any of those fields can be set by an exit, in

which

Post by Potkay, Peter M (CTO Architecture + Engineering)
case, what's the correct value for the flag and what's to enforce it?
And if the channel doesn't use SSL...
If such a flag were to exist, it would constrain honest users, but not

attackers.

Post by Potkay, Peter M (CTO Architecture + Engineering)
My issue with a lot of things presented as security controls are that they

make

Post by Potkay, Peter M (CTO Architecture + Engineering)
the user feel better but do not improve security. The result is a

security façade,

Post by Potkay, Peter M (CTO Architecture + Engineering)
which is bad enough, but a secondary result is that it tends to suppress

further

Post by Potkay, Peter M (CTO Architecture + Engineering)
investment in security - investment that might actually accomplish

something.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Prime example is using DNS names in exits as authenticators and now

[shudder]

Post by Potkay, Peter M (CTO Architecture + Engineering)
it looks like it will become a CHLAUTH option.
Hindsight is always 20/20? How about "looking back, it's still a bit

fuzzy"? (Yes,

Post by Potkay, Peter M (CTO Architecture + Engineering)
I'm paraphrasing Metallica. Extra points for those who recognized that

line.)

Post by Potkay, Peter M (CTO Architecture + Engineering)
-- T.Rob

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Tim Zielke
Sent: Sunday, June 16, 2013 4:59 PM
Subject: Re: MQPUT Times question (and now time for an SSL question)
Hindsight is 20/20, but it is too bad there was not an extra 1-byte code

added to

Post by Potkay, Peter M (CTO Architecture + Engineering)
the message descriptor to specify what parts of the context (i.e.

identity, origin)

Post by Potkay, Peter M (CTO Architecture + Engineering)
were set by the queue manager or the application (i.e. code value of A
= identity/origin both set by qmgr, B = identity/origin both set by

application, etc.).

Post by Potkay, Peter M (CTO Architecture + Engineering)
That would help clear up some of the ambiguity with the PutTime.
Thanks,
Tim
-----Original Message-----
Behalf Of Bruce Lerner
Sent: Sunday, June 16, 2013 10:08 AM
Subject: Re: MQPUT Times question (and now time for an SSL question)
An application setting context fields in the MQMD takes additional

authority;

Post by Potkay, Peter M (CTO Architecture + Engineering)
however, suppressing context data (MQPMO_NO_CONTEXT) takes no more
authority than being able to MQPUT.
In practical terms, you can never be 100% certain about the
application

data

Post by Potkay, Peter M (CTO Architecture + Engineering)
payload either - this, too, is under control of the application developer.

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

[Bruce Lerner]

If the application has neither MQOO_SET_IDENTITY_CONTEXT nor
MQOO_SET_ALL_CONTEXT authority, then there is no ambiguity.

These authorities should only be granted to 'special' applications, like
MCAs or apps that must mask the true identity of the message source. These
authorities should not be routinely granted to any other application.

A few follow-on ponderings...

Would you also like to know which application set these fields? What if
different apps set different fields in the message along its journey?

Would you also want to know at what date/time these each of these fields
were set by the application, if the date/time differed from the qmgr's
date/time?

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

[Dave Corbett]

All,

Setting Put time is apparently a confusing thing - and I can relate to the
issues around allowing an app to do it. It seems that we get 3rd party
vendor apps in and we attempt to restrict the SET (or SETID - I can't
remember exactly which on as I am writing this e-mail) options on their
user ids, but then their app fails because they are trying to set the
date/time on the MQMD and we end up granting a little more access than we
would like. I think there is something in JMS that wants to do this - I
just can't remember the specifics.

Regardless, you can ignore my second item on this thread regarding the
importing of a .pfx file. I got that fixed and things are functioning
fine now. It was just an issue typing in the correct passwords at the
correct time during the import - I am slightly embarrassed now - again....
(-:

Thanks to all for the input - I tend to save off some of these discussions
for future reference.

Thanks,
David Corbett
Work: 612-973-7086
Pager: 612-280-6307
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0



From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Date: 06/15/2013 11:35 AM
Subject: Re: MQPUT Times question (and now time for an SSL
question)
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>



Thanks, Neil. I made those adjustments and now the PutTime that the
amqsput program is setting is getting preserved all the way to the message
on the local queue on QM2.

So if the application is not requesting to update the origin context of a
message (like PutTime) or is not authorized to perform this function, the
PutTime will be the first time that an MQ queue manager PUT the message to
a queue (i.e. XMITQ, SYSTEM.CLUSTER.TRANSMIT.QUEUE, etc.), regardless of
how many queue manager hops the message goes through to its final queue
destination.

If an authorized application requests to update the origin context of a
message (like PutTime), the PutTime could represent anything that
application is setting it to, perhaps the time right before the
application issued the PUT API.

I can see now why Peter said "You can never be 100% sure the put time in
the MQMD represents exactly when the message was actually put."

Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Neil Casey
Sent: Friday, June 14, 2013 9:48 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question (and now time for an SSL question)

Hi Tim,

in order to set the PUTDATE (or other context fields) you have to
correctly set the MQPMO options value, and you have to have opened the
queue with the correct open options, and you have to be authorised.

See
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/fg12380_.htm

Regards,

Neil Casey.
On 15/06/2013, at 12:33 PM, Tim Zielke <tim.zielke-RzW+Fo++***@public.gmane.org> wrote:


Hi Peter,

I was curious about this, so I tried recreating your test and I am not
able to get the behavior you were seeing.

I have a QM1 (Linux 7.1.0.2) with a remote queue that aims at a local
queue on QM2 (Solaris 7.1.0.2).

I updated the amqsput program to change the md.PutTime to spaces before
doing the PUT. However, when I look at the message on the local queue on
QM2, it has been updated with a current PutTime. I tried changing the
md.PutTime to a bogus time, and again the message on the local queue on
QM2 has a current PutTime.

Maybe I am misunderstanding what you were saying.

Incidentally, I also did the test with the remote queue set up where I
froze the RVCR channel process on QM2 with a STOP signal, did a PUT to the
remote queue on QM1, and then unfroze the RCVR channel process on QM2 2
minutes later with a CONT signal. The message showed up on the local
queue on QM2 with a PutTime that was 2 minutes old. So just more
confirmation on what the experts have been saying on how this works (not
that I was doubting anybody :-) ).

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Friday, June 14, 2013 3:14 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question (and now time for an SSL question)

Dave,
I posted a reply that shows in my testing the original put time is carried
forward.

Suitably authorized (or unsuitably as the case may be) apps can set the
put time in the MQMD to whatever they want.

I set the put time to blanks on QM1 when I put to a remote queue that aims
at a local q on QM2. The message is sitting on QM2 with a blank put time.
This to me says the original put time value is carried during QM to QM
routing.

Don't forget there is a secondary MQMD with its own put time when a
message is sitting on an XMITQ

You can never be 100% sure the put time in the MQMD represents exactly
when the message was actually put.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Dave Corbett
Sent: Friday, June 14, 2013 3:44 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question (and now time for an SSL question)

Listers,

First of all - I want to thank everyone for commenting on the PUT time
question I posed. I am actually surprised by the fact that the original
message date/time is not maintained, and yet I understand (sort of) why
that is.

Regardless,

How about another question for SSL experts. We ran into some issues with
gskit7 / gskit8, etc. The short issue is that we need to rebuild our
keystore on a 7.0.1.6 QMGR on Windows. (this is a test environment).

After rebuilding the keystore, we are attempting to import a .pfx file
(our internal PKI has generated the keys for our keystore). However,
every time I try to import it, I receive the following error:
H:\>gsk7capicmd -cert -import -db <.pfx file path>\<pfx file>
" -target "<keystore path>\<keystore name>.kdb"
A password is required to access this key database
Please enter a password: **************
Error: 2

Please refer to the GSKCapiCmd User's Guide
for the meaning of the error.

Error id: GSKKM_ERR_ASN
Details: <<.pfx file path>\<pfx file>

I have taken the .cer and the .key file, and converted them into a .pfx
file with openssl. I have also tried the .pfx file that our PKI team
generated as part of their process

Nothing ever changes - I continually get this error - and when I try to
research it, all I find is some obscure link to something indicating that
there is a duplicate somewhere in my keystore, and yet all that is in the
keystore is the root certs created for the various CA's when we created
the keystore itself.

Has anyone else run into this error - and can explain what is happening?

Thanks,
David Corbett
Work: 612-973-7086
Pager: 612-280-6307
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0



From: "Potkay, Peter M (CTO Architecture + Engineering)" <
Peter.Potkay-***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Date: 06/12/2013 11:25 AM
Subject: Re: MQPUT Times question
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>




Suitably authorized (or unsuitably as the case may be) apps can set the
put time in the MQMD to whatever they want.

I set the put time to blanks on QM1 when I put to a remote queue that
aims at a local q on QM2. The message is sitting on QM2 with a blank put
time. This to me says the original put time value is carried during QM
to QM routing.

Don't forget there is a secondary MQMD with its own put time when a
message is sitting on an XMITQ

You can never be 100% sure the put time in the MQMD represents exactly
when the message was actually put.

Peter Potkay



-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Dominique Courtois
Sent: Wednesday, June 12, 2013 11:30 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQPUT Times question

Tim,
This is not a contradiction. The MQPUT, as far as WMQ is involved, is
actually executed on the server by the amqzlaa0 on behalf of the MCA on
behalf of the client application process and not on the client system
itself. So the PUTTIME must be the time of the MQPUT by the channel not
by the client process.
Regards
Dominique

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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
************************************************************
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+***@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
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.


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


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

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+***@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

[Glenn Baddeley]

Interesting discussion. It seems to reinforce my belief that apps should not be
allowed to set any of the MQMD context fields, unless they have a "trusted"
role to play in MQ operations, as suggested to T-Rob's post.

If apps need to convey some information with a message it should be set in a
non-privileged MQMD field, or even better, part of the Message Data payload
or in Message Properties.

A requirement to set context fields generally indicates a weakness in the
messaging design, compromises security, and is asking for trouble. It also
makes it harder for the MQ support folks, as they may see unexpected values
in context fields and go off on a tangent investigating irrelevant information. :-
/

Glenn.

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