| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Format of a timestamp in MQ message is incorrect on read |
« View previous topic :: View next topic » |
| Author |
Message
|
| ccrandall |
 Posted: Fri Jul 09, 2010 1:36 pm Post subject: Format of a timestamp in MQ message is incorrect on read |
 |
|
Acolyte
Joined: 23 Oct 2008
Posts: 52
|
My application has a request and a reply flow. So, we use something called routing data to help correlate the reply to the request. To do this, we create a MQ message with the data and pop it on a queue.
I'm running a regression test suite and it looks like often, but not always, the date I'm putting into the MQ message is formatted correctly, but when read it's not.
The data is being created, in the request flow, with this statement:
SET OutputRoot.XMLNSC.RtgData.queueRtgDataMsgExpiry = OutputRoot.MQMD.Expiry + INTERVAL '600' SECOND;
In my user trace, I see this evaluates to '2010-07-09 19:58:20.243'.
Later, in my reply flow, I've got a trace node that prints out the Root.XMLNSC.RtgData and it's format has an extra 'T' in between the date and the time:
'2010-07-09T19:58:20.243'
When it hits this statement:
SET OutputRoot.MQMD.Expiry = CAST(Environment.Variables.RtgData.queueRtgDataMsgExpiry AS GMTTIMESTAMP);
I get the following error:
CastException BIP2461E: Error casting character string ''2010-07-09T19:58:20.243'' to a TIMESTAMP. State = '-1' ''S22007'' '0' ''
The character string must have a the form 'TIMESTAMP 'yyyy-mm-dd hh:mm:ss[.f+]'', or 'yyyy-mm-dd hh:mm:ss[.f+]' to be valid for casting to a timestamp.
Ensure that the string represents a valid time value.
This had been working fine under MB 6.0 and 6.1. However, I was also using the XML parser. Now that we've moved to MB 7.0, I'm using XMLNSC, but I'm not sure why that would cause this particular error.
I did have to create the Environment.Variables.RtgData node in the XMLNSC domain in the reply flow:
CREATE LASTCHILD OF Environment.Variables DOMAIN('XMLNSC') Name 'RtgData';
right before I assign the contents of that routing data to the Environment.Variables.RtgData node:
SET Environment.Variables.RtgData = Root.XMLNSC.RtgData;
I don't think this is related to the parser, but since that's the only thing that changed, it makes me wonder.
Does anyone know what might be happening here?
Thanks |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Jul 09, 2010 7:57 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Check out your standard xml timestamp formats and you'll notice that
'2010-07-09T19:58:20.243' complies with a standard XML timestamp format while '2010-07-09 19:58:20.243' would need a custom timestamp format for parsing. Yes I know it is how the broker represents a timestamp by default internally... So deal with it! 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Jul 10, 2010 6:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| Yes I know it is how the broker represents a timestamp by default internally... So deal with it! |
Now while agreeing with every word and accepting this is slightly off-topic, what methods have people used to deal with this? Aside from string manipulation to insert or remove the "T"?? 
Just trying to promote some discussion.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Jul 10, 2010 8:21 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The word 'OVERLAY' sort of comes into my mind when thinking about this sort of thing.
Then there is also casting with a FORMAT
Finally, if setting via a message set, setting the format in the field definition (or globally) also has its place.
The real answer AFAIC, is 'it depends'.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jul 10, 2010 8:30 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| kimbert |
| Posted: Sat Jul 10, 2010 1:49 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
From v6.1, the XMLNSC parser has complied with the XML Schema standard, so it must output an ESQL TIMESTAMP as a valid XML Schema xs:dateTime.
That means adding the 'T'. The change is documented here:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/topic/com.ibm.etools.mft.doc/ah20250_.htm
( and in the same topic in the v6.1 infocenter ).
As always in message broker, it is very important to distinguish between the logical representation of your message ( the message tree ) and its physical representation ( in your case, the XML document ). The Trace node shows you the ESQL logical value in the message tree - and that implies nothing about how the physical value will be serialized by the parser.
To put that another way, XML and XMLNS are not schema-compliant, so they don't exhibit this difference. You could choose to use XMLNS and live with the fact that your internal data formats are out of step with most XML processing tools. Or you can choose XMLNSC and change your internal data formats to match the published standard.
I have a question about this:
| Quote: |
When it hits this statement:
SET OutputRoot.MQMD.Expiry = CAST(Environment.Variables.RtgData.queueRtgDataMsgExpiry AS GMTTIMESTAMP);
I get the following error:
CastException BIP2461E: Error casting character string ''2010-07-09T19:58:20.243'' to a TIMESTAMP. State = '-1' ''S22007'' '0' ''
The character string must have a the form 'TIMESTAMP 'yyyy-mm-dd hh:mm:ss[.f+]'', or 'yyyy-mm-dd hh:mm:ss[.f+]' to be valid for casting to a timestamp.
Ensure that the string represents a valid time value.
This had been working fine under MB 6.0 and 6.1. However, I was also using the XML parser. Now that we've moved to MB 7.0, I'm using XMLNSC, but I'm not sure why that would cause this particular error. |
Why are you storing the *serialized* format in the Environment tree? I presume you must be doing that, otherwise the change in parser could not have affected the contents of the Environment tree. It is usually a bad idea for a message flow to know anything at all about the physical representation of the message - it should deal with the logical structure, and leave the rest to the parser+message set. |
|
| Back to top |
|
|
| ccrandall |
| Posted: Mon Jul 12, 2010 7:58 am Post subject: |
|
|
Acolyte
Joined: 23 Oct 2008
Posts: 52
|
@kimbert - Thanks again for the help. For completeness in this thread, I'll answer your question here. Basically, I have an already built framework that I'm converting from using XML to XMLNSC. In this particular case, we are storing routing data on a queue and one of the items we are storing is an expiry value. On the reply, we read the routing data that was created from the corresponding request and then use that expiry timestamp (or sometimes an integer) to set the expiry on the reply.
Yes, we probably could clean up this logic, but under the time constraints I have, the work around alluded to earlier in this thread seemed like the easiest fix.
@smdavies99 - yes I did use OVERLAY here. For expiry values, we may have a timestamp or an integer value. So, here's the logic I use to handle this situation:
SET queueRtgDataMsgExpiryStr = CAST(Environment.Variables.RtgData.queueRtgDataMsgExpiry AS CHAR);
IF LENGTH(queueRtgDataMsgExpiryStr) > 10 THEN
-- Kludge to get past a weird error where a 'T' is showing up between date and time
IF POSITION('T' IN queueRtgDataMsgExpiryStr) <> 0 THEN
SET OutputRoot.MQMD.Expiry = CAST(OVERLAY(queueRtgDataMsgExpiryStr PLACING ' ' FROM 11 FOR 1) AS GMTTIMESTAMP);
ELSE
SET OutputRoot.MQMD.Expiry = CAST(queueRtgDataMsgExpiryStr AS GMTTIMESTAMP);
END IF;
ELSE
SET OutputRoot.MQMD.Expiry = CAST(queueRtgDataMsgExpiryStr AS INT);
END IF;
Elegant? Maybe not. But hey, I'm a novice and this works and I'm just happy I was able to come up with a quick kludge so I could move on to more complicated problems!
Thank you everyone for your replies. They've all been very helpful!
Curt |
|
| Back to top |
|
|
| AndreasMartens |
| Posted: Thu Jul 15, 2010 8:10 am Post subject: Use FORMAT |
|
|
Acolyte
Joined: 30 Jan 2006
Posts: 65
Location: Hursley, UK
|
ESQL CAST with FORMAT supports ISO8601 datetimes:
DECLARE myString CHARACTER '2010-07-09T19:58:20.243';
DECLARE myDate GMTTIMESTAMP;
SET myDate = CAST(myString AS GMTTIMESTAMP FORMAT 'I');
--done!
cheers,
Andreas |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
