ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » XMNSC, Message Broker 8.0.0.2 and TIMESTAMP Failing

Post new topic  Reply to topic
 XMNSC, Message Broker 8.0.0.2 and TIMESTAMP Failing « View previous topic :: View next topic » 
Author Message
EricCox
PostPosted: Tue Sep 22, 2015 5:49 am    Post subject: XMNSC, Message Broker 8.0.0.2 and TIMESTAMP Failing Reply with quote

Master

Joined: 08 Apr 2011
Posts: 292

To all,

We had code using XMLNS parser and a TIMESTAMP field in XML content held in a STATE MSG Queue...this was all working.

We changed to the XMLNSC parser and store the TIMESTAMP in XML content. However, now the TIMESTAMP held in the STATE MSG Queue comes back with a T in it. Now when we try to CAST from the string coming out of the STATE MSG to the TIMESTAMP so we can do a calculation, adding up all elapsed time, the Broker throws a parsing error stating it can't convert a string, the T, to a TIMESTAMP. If we remove the T the CAST works and it cruises along.

Does anyone know why the T is now held inside the TIMESTAMP field, which got stored in the STATE MSG Queue?

Is this because the XMLNSC parser changes the way the TIMESTAMP data is output to XML Content? We did not experience this failure before changing to the XMLNSC parser.

I'll post more details as I learn more from the developers investigating.

Thanks,
E
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Sep 22, 2015 5:51 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

The XML standard defines a fixed string format for timestamp data.

If your field in the XML schema is a string, not a timestamp, then this doesn't apply.

The CAST you are using to turn a string into a timestamp is not using a format that matches the data in the string.
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
EricCox
PostPosted: Tue Sep 22, 2015 5:56 am    Post subject: with T it must be a string Reply with quote

Master

Joined: 08 Apr 2011
Posts: 292

The ESQL which puts the timestamp value in the STATE MSG for storage is producing a string. It has a T in the value so it must be handled as a string. A proper timestamp in XML or ESQL can only have characters.

The question is 'why are we now seeing the T in the timestamp value which is retrieved and stored in the XML via ESQL?'.

We did not see this T in this value prior to using XMLNSC.
Back to top
View user's profile Send private message
EricCox
PostPosted: Tue Sep 22, 2015 5:59 am    Post subject: Oops Reply with quote

Master

Joined: 08 Apr 2011
Posts: 292

Correction:
A proper timestamp in XML or ESQL can only have numbers. A single T inside the timestamp means it has to be handled as string characters.

Again, why and where is the T introduced?
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Sep 22, 2015 6:11 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

The T will be produced by whatever is creating the timestamp, and casting it to a string.

You should verify that this is in the raw message data before it gets to Broker. I'd be really surprised if it wasn't, particularly since you are treating it as a string.

Even if it is, again, the format of the cast from character to timestamp will allow you to deal with it.
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
mgk
PostPosted: Tue Sep 22, 2015 6:20 am    Post subject: Reply with quote

Padawan

Joined: 31 Jul 2003
Posts: 1642

The XMLNSC parser is XML schema compliant and XML Schema defines a timestamp with a 'T' Like Jeff said, you can deal with this using a FORMAT clause like this:

Code:
DECLARE input CHAR '2015-09-22T12:06:56.568+01:00';
DECLARE result TIMESTAMP CAST(input AS TIMESTAMP FORMAT 'I');
SET OutputRoot.XMLNSC.Result.Top.Input = input;
SET OutputRoot.XMLNSC.Result.Top.Result = result;


The above code works and produces a correct CAST. If you remove the FORMAT clause you will see it will fail with the error you see.

More docs here:
http://www-01.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/ak05610_.htm?lang=en

and here:
http://www-01.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/ak05616_.htm?lang=en

Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.
Back to top
View user's profile Send private message
EricCox
PostPosted: Tue Sep 22, 2015 6:30 am    Post subject: Finding Same Reply with quote

Master

Joined: 08 Apr 2011
Posts: 292

I'm finding the same in the docs.

Thanks guys. Switching to XMLNSC bites us again.

I appreciate confirming what I'm seeing.

E
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Sep 22, 2015 6:36 am    Post subject: Re: Finding Same Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

EricCox wrote:
Switching to XMLNSC bites us again.

Don't think of it like that. Think of it like

"Switching to XMLNSC demonstrates where our code had previously not been compliant with the XML standard."


_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
mgk
PostPosted: Tue Sep 22, 2015 6:37 am    Post subject: Reply with quote

Padawan

Joined: 31 Jul 2003
Posts: 1642

This page details the XML parsers available:

http://www-01.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/ad70530_.htm?lang=en

And it makes the point that XMLNSC is the fastest, schema compliant etc xml parser, but XMLNS is not deprecated and IIB does not force you to move to XMLNSC if you don't need to.

Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Sep 22, 2015 7:44 am    Post subject: Re: Oops Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

EricCox wrote:
A proper timestamp in XML or ESQL can only have numbers. A single T inside the timestamp means it has to be handled as string characters.


Not true. That's a valid timestamp value as defined by ISO8601
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Sep 22, 2015 7:44 am    Post subject: Re: Finding Same Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

mqjeff wrote:
EricCox wrote:
Switching to XMLNSC bites us again.

Don't think of it like that. Think of it like

"Switching to XMLNSC demonstrates where our code had previously not been compliant with the XML standard."




_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » XMNSC, Message Broker 8.0.0.2 and TIMESTAMP Failing
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.