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 » User Exits » MQ Client Receive Exit Agent Buffer question....

Post new topic  Reply to topic
 MQ Client Receive Exit Agent Buffer question.... « View previous topic :: View next topic » 
Author Message
TheAndroid
PostPosted: Fri Feb 13, 2015 2:34 pm    Post subject: MQ Client Receive Exit Agent Buffer question.... Reply with quote

Novice

Joined: 04 Dec 2007
Posts: 23

All,
I am writing a Receive Exit for Linux which is intended to do data conversion for application specific data. What I am up against is I have to use the MQClient for my connection. What this means is I must use a CLNTCONN channel on the client side and create SEND/RECEIVE exits for the messages.

The MQClient doesn't give me the clean MQXR_MSG reason with the just an MQXQH header and the message contents in the Agent Buffer.

Instead, I get the goofy MQXR_XMIT reason. The Agent Buffer contains an unmarked header which I don't understand or can find any reference for. Followed by a MQMD2 and an MQGMO. Here is a dump of the first 512 bytes where these headers come in.
Code:
00000000 00 00 00 00 00 00 00 00 01 95 30 00 00 00 00 00 ..........0.....
00000010 00 00 00 00 00 00 01 11 01 F4 00 00 00 00 11 FC ................
00000020 00 00 00 00 00 00 00 00 00 00 00 02 D4 C4 40 40 ..............@@
00000030 00 00 00 02 00 00 00 00 00 00 00 08 FF FF FF FF ................
00000040 00 00 00 00 00 00 01 11 00 00 01 F4 40 40 40 40 ............@@@@
00000050 40 40 40 40 00 00 00 00 00 00 00 00 C3 E2 D8 40 @@@@...........@
00000060 C3 E2 D8 F1 40 40 40 40 40 40 40 40 CE 80 C6 32 ....@@@@@@@@...2
00000070 46 80 10 00 00 00 00 00 00 00 00 00 00 00 00 00 F...............
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 @@@@@@@@@@@@@@@@
000000A0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 @@@@@@@@@@@@@@@@
000000B0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 @@@@@@@@@@@@@@@@
000000C0 C3 E2 D8 F1 40 40 40 40 40 40 40 40 40 40 40 40 ....@@@@@@@@@@@@
000000D0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 @@@@@@@@@@@@@@@@
000000E0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 @@@@@@@@@@@@@@@@
000000F0 C1 C1 C2 C1 E3 C5 40 40 40 40 40 40 1A 0F C3 E2 ......@@@@@@....
00000100 D8 F1 C3 C8 C9 D5 F1 F2 F0 C1 F3 C3 F3 F0 00 12 ................
00000110 0A 3C 30 00 00 00 00 00 00 00 00 00 40 40 40 40 .<0.........@@@@
00000120 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 @@@@@@@@@@@@@@@@
00000130 40 40 40 40 40 40 40 40 40 40 40 40 00 00 00 1C @@@@@@@@@@@@....
00000140 E6 85 82 E2 97 88 85 99 85 40 D4 D8 40 C3 93 89 .........@..@...
00000150 85 95 A3 40 86 96 99 40 D1 81 A5 81 F2 F0 F1 F5 ...@...@........
00000160 F0 F2 F1 F3 F1 F8 F0 F7 F0 F1 F1 F0 40 40 40 40 ............@@@@
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000180 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 ................
00000190 00 00 00 00 FF FF FF FF C7 D4 D6 40 00 00 00 03 ...........@....
000001A0 00 00 60 00 00 00 00 00 00 00 00 00 00 00 00 00 ..`.............
000001B0 F6 F4 C2 C9 E3 D5 C5 E2 E2 40 40 40 40 40 40 40 .........@@@@@@@
000001C0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 @@@@@@@@@@@@@@@@
000001D0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 @@@@@@@@@@@@@@@@
000001E0 00 00 00 03 40 40 40 00 00 00 00 00 00 00 00 00 ...@@@.........
000001F0 00 00 00 00 00 00 00 00 FF FF FF FF 00 00 0F FC ................


My data payload follows immediately. It is not really relevant to this question so I haven't included it.

Ok. This is what I know from the documentation. The first eight bytes of the buffer are untouchable. The tenth byte (0x95) is telling me this is a GET_REPLY. Then a bunch of stuff up until the MQMD2 starts at offset 0x2B. It is encoded in EBCDIC (the QMGR is on z/OS). I can identify everything starting at 0x2B. It's what is there before which giving me problems.

I'm concerned that my data payload will NOT always be at offset 0x200 in the message. The very end of the preamble area (my term) has a 00000002 in it. I suspect this is the number of headers following. Or, it is merely a coincidence? Does anyone know what this area contains information wise? The MQ Manuals say it is routing information. However, it does not have any of my MQ Object names embedded within. It looks like a pile of flags and indicators.

Thanks.
Back to top
View user's profile Send private message
RogerLacroix
PostPosted: Fri Feb 13, 2015 4:38 pm    Post subject: Re: MQ Client Receive Exit Agent Buffer question.... Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3252
Location: London, ON Canada

The first thing I must say is writing an exit requires expert knowledge of both C and MQ. (You have been warned.)

TheAndroid wrote:
I am writing a Receive Exit for Linux which is intended to do data conversion for application specific data.

Why? What is wrong with letting MQ do the conversion? Or write a data conversion exit? see here

TheAndroid wrote:
The MQClient doesn't give me the clean MQXR_MSG reason with the just an MQXQH header...

Nope. Never will. You are confusing QMgr to QMgr communication with client/server.

TheAndroid wrote:
I get the goofy MQXR_XMIT reason.

Not goofy (see my very 1st sentence). You get an Exit Reason of MQXR_XMIT for client/server communication.

TheAndroid wrote:
The Agent Buffer contains an unmarked header which I don't understand or can find any reference for.

The TSH and TSHM headers are not documented by IBM. If you want to beat your head against the wall and learn this stuff then go to WireShark and read their MQ code and then do a whole bunch of testing.

I can't wait for you to notice and then ask why the receive exit receives more MQXR_XMIT calls then the sender exit sent. Glorious pain awaits you.

Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
TheAndroid
PostPosted: Sun Feb 15, 2015 8:26 am    Post subject: Reply with quote

Novice

Joined: 04 Dec 2007
Posts: 23

I've written data conversion exits before. I have over 15 years of C development behind me. I do not fear Puny Exits.

The data is application specific so MQ can't do it. The Client does not allow a Data Exit to be defined in the CCDT. You can only define Send/Receive or Security Exits.

MQXR_XMIT is goofy in the fact that it apparently has some undocumented header on it. The only reference in the Intercommunication manual states the first 8 bytes are untouchable and byte 10 tells me what the XMIT "type" is. However, there is more information in there which apparently is super secret.

In decoding byte 10, I can clearly see that I am getting "internal" traffic to the MQClient itself. The only XMIT type I really care about is GET_REPLY. The rest are the Client's problem. It is handling them just fine as right now, all my Exit is doing is dumping the buffer area. I realize that the header information on the GET_REPLY message is in CCSID 500 with High Endian encoding (273). However, I can use the information within them to determine which payload message format with which I am dealing.

I hadn't thought of looking at it with Wire Shark mainly because I didn't think the undocumented header was thrown across the network. I thought it was internal. However, I will do as you say and study up on the TSH and TSHM formats.
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Sun Feb 15, 2015 1:36 pm    Post subject: Reply with quote

Grand Master

Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand

I would re-iterate Rogers words of warnings. If you need to do some data conversion, do it in a Conversion exit not in a Client Channel Receive exit.

The data format passed to a channel receive exit is not documented and is, as far as I know, still IBM Confidential. Even if you did find a way of finding out the format you should be aware of the following:

  • The formats have changed over the years particularly pre-V7 and post-V7
  • If the channel switches on compression your data will turn to mush
  • IBM are at liberty to change the format of the data any time they wish

Personally I would strongly advise against trying to decode the format of the data passed to a receive exit. And, since I was the person who designed the format in the first place, I do know what I am talking about.

Regards,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
gbaddeley
PostPosted: Sun Feb 15, 2015 3:55 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

Having written MQ Send / Receive exits (SupportPac MA0Z), I agree with Roger's and Paul's comments. The buffer format is IBM confidential and may change without notice. Its a series of data structures. Have fun trying to reverse engineer it. As a start, Google for "mq tsh" and "mq transmission segment header". The MQ Client protocol for connection management and MQI calls is very interesting and has many complexities for Java, shared conversations and read-ahead.
_________________
Glenn
Back to top
View user's profile Send private message
TheAndroid
PostPosted: Sun Feb 15, 2015 7:49 pm    Post subject: Reply with quote

Novice

Joined: 04 Dec 2007
Posts: 23

How do you define a Data Exit with the MQClient? Because when I define the channel in the CCDT locally using mqsc, it shows no provision for assigning a data exit. As I said, it only has Security, Send and Receive exits. Can't do what I'm not allowed.

Now, if I have to, I can look for the fingerprints for the MQMD and the MQGMO and work that way. I'd rather not as that solution seems "unclean" and inelegant. It also assumes that those header targets will ALWAYS be in my GET_RESPONSE Agent Buffer. There is no more guarantee of that than there is of IBM not changing the TSH area. So, I am in no more danger trying to figure out if the last fullword in the "TSH" area is the number of headers following than I am of the recognizable part of the Agent Buffer being different.

It's okay if you don't know if that is what that fullword means. IBM seems to think that it is some huge secret that protects them. Unfortunately, once they release a version, that secret is out for everyone to watch with WireShark or tcpdump unless they have some unusual self modifying algorithm encrypting their traffic. Not likely given what I've seen.

Furthermore, even if they did encrypt the traffic, they cannot change what is in that buffer within the same version when they call the exit. I get that post-receive. So I'm safe until an upgrade occurs. If my client upgrades, they will have to test with the new version. If things land in a different location, then I'll have to change my Exit because it won't work anymore. This is the nature of software.

So please tell me if you know if the last fullword is the number of headers following or not. And please stop trying to dissuade me from the SEND/RECEIVE exits. I do not fear the volatility of that area because I am not chasing versions. I do not fear converting data within the buffer because I already have the routines to do that from my Data Exits on previous engagements. I am not worried about client's upgrading underneath me because they have to go through a large test cycle in order to do that. Within that testing, the Exit will either succeed or fail.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sun Feb 15, 2015 7:49 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

Please explain why you can't perform the required conversion in an application at the sender or receiver end of the channel. Why must this be done in an exit?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sun Feb 15, 2015 7:54 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

bruce2359 wrote:
Please explain why you can't perform the required conversion in an application at the sender or receiver end of the channel. Why must this be done in an exit?

Or in a facade called by the application, that would place the transformation layer between the application and MQ.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
TheAndroid
PostPosted: Sun Feb 15, 2015 8:05 pm    Post subject: Reply with quote

Novice

Joined: 04 Dec 2007
Posts: 23

bruce2359 wrote:
Please explain why you can't perform the required conversion in an application at the sender or receiver end of the channel. Why must this be done in an exit?


I migrate mainframe software from z/OS to Open Systems platforms. In doing so, I have to minimize the amount of change introduced or there is little to no value for the client other than operating costs. Essentially, they will no longer recognize their own application and it then becomes unmaintainable by their personnel.

I have made a career out of lying to mainframe applications about the environment in which they are executing. Part of those lies involves presenting application specific data in the format the applicaiton will find acceptable on the target platform. If that platform is AIX, then I get to use High Endian. If it is Intel, I get to use Low Endian. In either, I will be working with a CCSID which is normally not EBCDIC.

These applications already contain calls to the MQ library to do normal boring MQ activities. As I strive to minimize the change to the application, I have to find a means for providing the payload transformation of the data. The data as it is placed on the queue is type NONE because it contains Binary, Packed Decimal and blob type data.

Most of the time, the application code is written in COBOL. Which adds yet another degree of confusion to all of this. Therefore, the cleanest and least intrusive way for me to do the payload translation is in an Exit. I would normally do it in a Data Exit, but those only appear to exist for Remote Queues. One cannot define a remote queue with the MQ Client so I am stuck with the channel exits.

I am not handshaking with the QMGR on the mainframe. After I get this Receive Exit working, I will then write a Send exit which does the reverse transformation before the payload hits the wire. Both exits will exist on the Client side and will therefore be working within the callback structure IBM dictates. I really don't care what hits the wire and what format it is. I care about what my actual payload looks like and where it is in the Agent Buffer.

Keep in mind, that the MQClient only allows me to open ONE channel. So not only will I have to convert the payload both ways, I will have to determine by which queue the payload originated, what the actual format is. This is another reason I would like to know about that last fullword.

If my client turns compression on, they will screw up more than my migrated application so I at least will know its coming. What I don't know is if I get the compressed data within the Receive exit or not. I can't find any reference in the documentation about that in regards to the MQ Client.
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Sun Feb 15, 2015 9:17 pm    Post subject: Reply with quote

Grand Master

Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand

TheAndroid,

I'm afraid that much of what you said makes no sense to me.


Quote:
If my client turns compression on, they will screw up more than my migrated application so I at least will know its coming.

What do you mean by this? The idea of channel compression is that you can switch it on or off without any of your applications even knowing it's happening. It should not 'screw up' anything.

Quote:
What I don't know is if I get the compressed data within the Receive exit or not. I can't find any reference in the documentation about that in regards to the MQ Client.

Yes you do, I just told you.

Quote:
Keep in mind, that the MQClient only allows me to open ONE channel.

I'm sorry but this sentence again makes no sense to me. Are you talking about a restriction in your application here. An MQ Client allows you to define (and use) as many Channels as you like.

Quote:
So not only will I have to convert the payload both ways, I will have to determine by which queue the payload originated, what the actual format is.

MQ is designed so that when you put a message you use the FORMAT field to specify what the format of the data is. It should not matter on which queue the data originated. Are you saying that if the application decided to put the data to a DLQ you would no longer be able to understand the data? This would not be a good thing.

Quote:
Therefore, the cleanest and least intrusive way for me to do the payload translation is in an Exit. I would normally do it in a Data Exit, but those only appear to exist for Remote Queues.

I don't understand this. What is a 'Data' exit? Secondly exits are not associated with Remote Queues

Quote:
I have made a career out of lying to mainframe applications about the environment in which they are executing. Part of those lies involves presenting application specific data in the format the application will find acceptable on the target platform. If that platform is AIX, then I get to use High Endian. If it is Intel, I get to use Low Endian. In either, I will be working with a CCSID which is normally not EBCDIC.

I don't understand what you are saying. Your application issues MQGET and asks for a certain CCDID and Encoding. Why is it not sufficient just to give them what they ask for? Secondly if you are migrating an application from z/OS to Linux why does it matter that everything that used to be in EBCDIC is now in ASCII?

Quote:
The data as it is placed on the queue is type NONE because it contains Binary, Packed Decimal and blob type data.

This is perhaps the crux of the problem. How hard would it be to give your format(s) a name? If you are not describing your data in some way then it just seems to me that you are making life awfully hard for yourself.

Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
TheAndroid
PostPosted: Mon Feb 16, 2015 7:31 am    Post subject: Reply with quote

Novice

Joined: 04 Dec 2007
Posts: 23

Paul,

Quote:
If my client turns compression on, they will screw up more than my migrated application so I at least will know its coming.
What do you mean by this? The idea of channel compression is that you can switch it on or off without any of your applications even knowing it's happening. It should not 'screw up' anything.


What I mean is I am not migrating ALL of the applications for this customer off of the other environments. They would have to turn compression on for the MQ Client connections everywhere and in order to do that, they would have to tell everyone their CCDT's will have to change. Therefore, it will not just magically happen without warning.

Quote:
What I don't know is if I get the compressed data within the Receive exit or not. I can't find any reference in the documentation about that in regards to the MQ Client.
Yes you do, I just told you.


Missed that. Even so, not worried about it because of above.

Quote:
Keep in mind, that the MQClient only allows me to open ONE channel.
I'm sorry but this sentence again makes no sense to me. Are you talking about a restriction in your application here. An MQ Client allows you to define (and use) as many Channels as you like.


I can define as many channels as I like, but if I connect to a QMGR using just a name with the MQClient through the CCDT (which is the only way to involve exits anyhow), I cannot direct traffic across a specific one. This is how the MQCONN calls are written in the migrating aplication. The MQClient basically uses the first one it finds or applies a heuristic to a group define to terminate at the same QMGR name.

Quote:
So not only will I have to convert the payload both ways, I will have to determine by which queue the payload originated, what the actual format is.

MQ is designed so that when you put a message you use the FORMAT field to specify what the format of the data is. It should not matter on which queue the data originated. Are you saying that if the application decided to put the data to a DLQ you would no longer be able to understand the data? This would not be a good thing.


Again, I do not have control over the entire environment. I cannot force all the other applications involved to modify their code. Since what I am dealing with is usually very vintage code, there is a likelihood that they are not nominating FORMAT's in all their PUTS. I wish I had that leeway. It would make my life much, much easier.

Quote:
Therefore, the cleanest and least intrusive way for me to do the payload translation is in an Exit. I would normally do it in a Data Exit, but those only appear to exist for Remote Queues.

I don't understand this. What is a 'Data' exit? Secondly exits are not associated with Remote Queues


In my experience, RECEIVEDATA and SENDDATA exits can only be usably defined with channels which are associated with XMIT queues. On the client, I would define a channel and associate it with an XMIT queue which is then associated with a Remote queue. As I would normally create the remote definition to use a specific XMIT queue and that would be configured to use a specific channel to haul the payload, I wouldn't necessarily HAVE to interrogate the source queue to figure out what format I'm using. Only one give format would be hauled across that channel.

However, the MQClient doesn't allow this. That is a mechanism reserved for a local QMGR to forward requests to a remote one.

Quote:
I have made a career out of lying to mainframe applications about the environment in which they are executing. Part of those lies involves presenting application specific data in the format the application will find acceptable on the target platform. If that platform is AIX, then I get to use High Endian. If it is Intel, I get to use Low Endian. In either, I will be working with a CCSID which is normally not EBCDIC.

I don't understand what you are saying. Your application issues MQGET and asks for a certain CCDID and Encoding. Why is it not sufficient just to give them what they ask for? Secondly if you are migrating an application from z/OS to Linux why does it matter that everything that used to be in EBCDIC is now in ASCII?

The data as it is placed on the queue is type NONE because it contains Binary, Packed Decimal and blob type data.

This is perhaps the crux of the problem. How hard would it be to give your format(s) a name? If you are not describing your data in some way then it just seems to me that you are making life awfully hard for yourself.
Cheers,
Paul.


Be that as it may, this is the task set upon me. I can't change the entire infrastructure for my customer. It includes Linux, AIX, z/TPF and z/OS. That's far too large a testing burden to force on them. Even making them change some definitions on the primary QMGR would require CCDT redistribution and testing. Right now, the primary QMGR for all of them is on z/OS. That is not likely to change anytime soon.

I can't spoof the MQ Client for COBOL without getting into an even uglier scenario (having to make the COBOL runtime understand what is going on). I have lost the argument that having a local QMGR would be infinitely easier because my customer sees it as a ongoing maintenance task as well as an additional hop and potential failure point for the data reaching the application. Even if I could squeeze a shim in between the MQI and COBOL, I still would have to interrogate the data to see what conversion to apply to it.

If this were brand new development, I would simply use the Java classes and have been finished already. I don't get to play in that arena. I get to make stuff "work like the mainframe" without major upheaval in the customer's application.
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Mon Feb 16, 2015 7:54 am    Post subject: Reply with quote

Grand Master

Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand

Ok, well, clearly I don't know your environment nor do I understand the restrictions you are working under. I can certainly understand the notion of wanting to make the change with as little interruption as possible. However, I see no benefit in coming up with a solution which does not fit in with the MQ Architecture. However, you seem hell bent on doing just that so at this point I think I'll just duck out and wish you good luck.

Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
hughson
PostPosted: Mon Feb 16, 2015 7:57 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

TheAndroid wrote:
I do not have control over the entire environment. I cannot force all the other applications involved to modify their code. Since what I am dealing with is usually very vintage code, there is a likelihood that they are not nominating FORMAT's in all their PUTS. I wish I had that leeway. It would make my life much, much easier.

Strikes me that you would be better then to use an API exit to insert the FORMAT field on all these clients, encourage those you can encourage to change over to use the best practice and then just write a Data Conversion exit for the format name you use.

Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Mon Feb 16, 2015 8:34 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

TheAndroid wrote:
The data is application specific so MQ can't do it. The Client does not allow a Data Exit to be defined in the CCDT. You can only define Send/Receive or Security Exits.

If by 'Data Exit' you mean a data conversion exit routine, you identify the name of the conversion exit in the MQMD format field. The exit is invoked by the consuming app specifying MQGMO_CONVERT.

If your application data is not of the MQ-supported types, then you are somewhat limited in your choices. I've written a few stand-alone apps when the data was telemetry/analog type. This type of app is far less complicated than creating send/receive exits.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
RogerLacroix
PostPosted: Tue Feb 17, 2015 3:01 pm    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3252
Location: London, ON Canada

Hey Android, your design/approach makes no sense unless you are a guy who uses a sledgehammer when a screwdriver is required.

You need to step back and look at the big picture - what you are describing is what a transform engine does. This is basic 101 Data Architecting.

There are 3 super easy solutions to your problem:

(1) Go get an open source transform engine and install it on your Unix/Linux/Windows server. Map your strings and integer/float fields and have it do the EBCDIC/ASCII conversion.

(2) Go buy IIB or DataStage and install it on your Unix/Linux/Windows server. Map your strings and integer/float fields and have it do the EBCDIC/ASCII conversion.

(3) Do a complete MQ only solution without using send/receive exits.
    (A) Install MQ Server on your Unix/Linux/Windows server.
    (B) Create a queue manager on your distributed platform
    (C) Create send/receive channels between your z/OS QMgr and your distributed QMgr
    (D) Create Data Conversion exit for the mainframe data called Z001
    (E) Create a simple program to read the messages from queue 'A', update the MQMD Format to 'Z001' and write the message to queue B but make ABSOLUTELY sure you do not change the CCSID and Encoding.
    (F) Have your distributed application perform a GET with Convert on queue B and BINGO, MQ will convert the data based on your mapping in your data conversion exit (Z001).

I have been doing z/OS (aka OS390, MVS) data transformation to/from distributed platforms for a very long time. You need to give your head a shake and stop using the wrong tool for the job.

I gave you 3 EASY solutions to your problem, please stop writing a send/receive exit. Also, please come to MQ Technical Conference and you will learn about many more solutions that use MQ.

Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » User Exits » MQ Client Receive Exit Agent Buffer question....
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.