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 » Broker V5 -> V6 migration issue

Post new topic  Reply to topic
 Broker V5 -> V6 migration issue « View previous topic :: View next topic » 
Author Message
smeunier
PostPosted: Wed Jul 08, 2009 1:32 pm    Post subject: Broker V5 -> V6 migration issue Reply with quote

Partisan

Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont

While migrating from V5 to V6, a few anomalies have occurred, which have required minor message flow or message set changes. The last one we are struggling with is a dropped <LF> from the output message in V6, which is ok in V5. The legacy application on the back end has dependencies on the <LF>. Te out put data between V5 and V6 is identical, the only difference is the absence of the <LF> on the the last node in the XML output record.

I'm wondering how I can force this (<LF>) either through the message set or the ESQL. I have tried numerous tests but all have failed. Ay tips would be helpful.

The inbound message arrives via the mySAP.com adapter in XML format. The message is then parsed and a new message structure is created from elements of the original message. The final output message as shown below is missing the <LF> x'0A' at the end of the data withing the CDATA tag. I inserted the text "missing" for illustaration purpose, whereas the "." in bold represents the previous good tag.



Code:

[CDATA[           5B434441 54415B20 20202020 20202020
00001472                   20202020 20202020 20202020 20202020
00001488       20 080521   20202020 20203230 30383035 32312020
00001504                43 20202020 20202020 20202020 20203433
00001520 78924737 62743243 37383932 34373337 36323734 33323433
00001536                   20202020 20202020 20202020 20202020
00001552                   20202020 20202020 20202020 20202020
00001568 00306678 06[b].[/b]      30303330 36363738 30360A20 20202020
00001584                   20202020 20202020 20202020 20202020
00001600            200805 20202020 20202020 20203230 30383035
00001616 21                32312020 20202020 20202020 20202020
00001632   743864 27648732 20203734 33383634 32373634 38373332
00001648                   20202020 20202020 20202020 20202020
00001664                   20202020 20202020 20202020 20202020
00001680     0030 667807[b]missing[/b]] 20202020 30303330 36363738 30375D5D


What I'm failing to understand, due to experience, is what is forcing the first <LF> and how can I affect the insertion of a <LF> into the last(other) data groups.

Any help would be appreciated.
Back to top
View user's profile Send private message
kimbert
PostPosted: Thu Jul 09, 2009 12:41 am    Post subject: Reply with quote

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

Check the TDS properties for the outermost complex type. If it does not already have its Group Terminator set to '<LF>' then make it so.
Back to top
View user's profile Send private message
smeunier
PostPosted: Mon Jul 13, 2009 12:14 pm    Post subject: Reply with quote

Partisan

Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont

The suggestion of adding a Group Terminator <LF> worked in terms of forcing a <LF> for each group of data. However it added extra <LF> to records which already had one on the end. You can see this in the CDATA section snippet below. (depicted by "." characters). In the message
set I have the Data Element Separation=Fixed Length and the Group Indicator=(nothing specified) and Group Separator = <LF>
Code:

00001456 [CDATA[           5B434441 54415B20 20202020 20202020
00001472                   20202020 20202020 20202020 20202020
00001488       20 080521   20202020 20203230 30383035 32312020
00001504                43 20202020 20202020 20202020 20203433
00001520 78924737 62743243 37383932 34373337 36323734 33323433
00001536                   20202020 20202020 20202020 20202020
00001552                   20202020 20202020 20202020 20202020
00001568 00306678 06..     30303330 36363738 30360A0A 20202020
00001584                   20202020 20202020 20202020 20202020
00001600             20080 20202020 20202020 20202032 30303830
00001616 521               35323120 20202020 20202020 20202020
00001632    74386 42764873 20202037 34333836 34323736 34383733
00001648 2                 32202020 20202020 20202020 20202020
00001664                   20202020 20202020 20202020 20202020
00001680      003 0667807. 20202020 20303033 30363637 3830370A
Back to top
View user's profile Send private message
kimbert
PostPosted: Mon Jul 13, 2009 12:50 pm    Post subject: Reply with quote

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

Bad news, I'm afraid. If the simple fix didn't work the only solution is to read the model and understand how it works. I can't make any more suggestions without very detailed knowledge of the message set. Before posting loads of detail, please take a close look and see if you can see how it all works.
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 » Broker V5 -> V6 migration issue
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.