| Author |
Message
|
| Rajiv |
 Posted: Wed Sep 08, 2004 10:24 pm Post subject: Packed Decimal (COMP-3) Fields |
 |
|
Newbie
Joined: 08 Sep 2004
Posts: 8
|
Hi,
We have a J2EE application running on WAS 5.x on Windows 2000 environment communicating with the HOST (IBM Mainframe) system using MQ Series.
The HOST system sends back reply messages containing Packed Decimal fields. When i browse through the reply message data on the MQ Explorer i see that PIC 9 (COBOL numeric) and PIC X (COBOL alpha) fields have been correctly converted from EBCDIC to ASCII but the Packed Decimal (COMP-3) fields have got garbled up and appear as junk.
The HOST team suggests that we should first get the reply message in EBCDIC, unpack the Packed Decimal fields and only then convert the message from EBCDIC to ASCII.
Since i have turned off the code that picks up the message from the queue, it is some setting at the MQ Server at my end or the HOST Application's PUT option that is responsible for the message being converted to ASCII.
How do i go about this...urgent help required!!
Thanks,
Rajiv. |
|
| Back to top |
|
 |
| kirani |
| Posted: Wed Sep 08, 2004 10:37 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
You will have to write a conversion exit/routine to handle binary fields (COMP-3, COMP, etc). Do you have WMQI available for your use? If so, WMQI can do this for you.
Convert options on MQGET call and Channel only converts "String data". COMP-3 fields are binary data.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| Rajiv |
| Posted: Wed Sep 08, 2004 10:45 pm Post subject: |
|
|
Newbie
Joined: 08 Sep 2004
Posts: 8
|
Thanks for the response Kiran.
This is the first time we are receiving data in this format (Packed Decimal) from the HOST systems (in all previous releases all data was translated into equivalent Nuimeric or Alpha fields by them) and do not have WMQI available and even convincing the client to go for it may be a problem.
In case WMQI is not an option, how do i go about writing a conversion/exit routine?
Also, do you know why i am seeing the reply message data in ASCII and not in EBCDIC?
Thanks a lot,
Rajiv. |
|
| Back to top |
|
|
| des |
| Posted: Wed Sep 08, 2004 11:44 pm Post subject: Packed Decimal (COMP-3) Fields |
|
|
Newbie
Joined: 08 Sep 2004
Posts: 2
|
There are 2 things here, one MQ is probably automatically translating your message, you need to set your environment variables to state that you are using a encoding and character set which is the same as the mainframe i.e.
MQMessage msg = new MQMessage();
msg.encoding = 785;
msg.format = "MQIMS "; //persuming you are using IMS
msg.characterSet = 37;
also you need to do an ebcdic to ascii conversion, and also a comp-3 conversion.
here is an example of a comp-3 to string conversion
public static String convertFromComp3(byte buffP[], int ele_len, int ele_aux_len, int total_len, int ele_type)
{
BigInteger i = new BigInteger(buffP);
String comp;
for(comp = i.toString(16); comp.length() < ele_len + 1; comp = "0" + comp);
comp = comp.toUpperCase();
if(comp.endsWith("D"))
comp = "-" + new String(comp.getBytes(), 0, comp.length() - 1);
else
comp = new String(comp.getBytes(), 0, comp.length() - 1);
if(ele_aux_len > 0)
{
BigDecimal d = new BigDecimal(comp);
d = d.movePointLeft(ele_aux_len);
comp = d.toString();
}
if(comp.length() < 1)
comp = " ";
return comp;
}
call it using the following:
String out = DataConvert.convertFromComp3(source, decBefore, decAfter, dataLength, isSigned); |
|
| Back to top |
|
|
| Rajiv |
| Posted: Thu Sep 09, 2004 12:56 am Post subject: |
|
|
Newbie
Joined: 08 Sep 2004
Posts: 8
|
Thanks Des...
I tried setting the characterSet and encoding attributes of the MQMessage before executing -
// Code Block Start
inMess= new MQMessage();
// getting a specified message
inMess.correlationId=messageId;
inMess.encoding = 785;
inMess.format = "MQIMS";
inMess.characterSet = 37;
gmo = new MQGetMessageOptions();
gmo.options |= 1;
queue.get(inMess, gmo);
// Code Block End
But the reply message data still has the Packed Decimal fields garbled up.
The Packed Decimal Field in this case should have a value of 3994 which should be '03994C' in Packed representation but appears as '..r<' both when i browse through the message data on the queue and after i get the message in my code as byte data.
The Reply message is definitely in ASCII and not EBCDIC as i can decipher the PIC X (Alpha) fields correctly.
Also, another thing i noted was that the characterSet and encoding had these values on the Request queue when i send the message -
Mesage Format : MQIMS
CCSID (Coded Charset ID) : 819
Encoding : 273
Doesn't that mean that these are the values i should use for setting the values in MQMessage() wrt the code snipper you had sent, i.e. -
MQMessage msg = new MQMessage();
msg.encoding = 273 (instead of 785);
msg.format = "MQIMS "; //persuming you are using IMS
msg.characterSet = 819 (instead of 37);
I tried that too but to no avail. Also since the message on the queue appears to already be in ASCII format , the Packed fields are already garbled, will i be able to restore it just by changing the attributes of the MQMessage?
Thanks a lot guys,
Rajiv. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Sep 09, 2004 5:33 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It sounds like, perhaps, the channel between your host queue manager and your local queue manager is set up to convert the message as it goes through the channel.
Can you browse your messages with something like MQExplorer, and confirm that the message string data is in ASCII on the local queue? If so, that tells you for sure that the channel is doing the data conversion.
If that is the case, you may be in trouble. At best, you will have to reverse the EBCDIC conversion that the channel has done on your packed fields. Then you will have to unpack it.
You will need to convince your MQ Administrators to change the channel definition so that it does not convert data. Or set up a new channel for this particular message flow, if everything else is significantly dependant on the channel doing the conversion.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 09, 2004 6:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
This subject has been discussed to death on the listserve. The consensus is that the thing that needs to change is the sending app to not send COMP-3 fields. Packed fields are a throwback from the day when storage was very expensive per byte. That is no longer true. Store your numerical fields in PIC 9 fields. Change the sending app to do the conversion of these packed fileds to PIC 9 fields before sending the message. It sounds hokey, but everyome agreeded that is the best solution.
If the message is going into the mainframe app thru a Bridge queue (OTMA), then you need to stick the IIH header in front of the data, and set the MQMD_FORMAT field to "MQIMS ". But nowhere does he say that he is going to IMS via OTMA. If not, MQMD_FORMAT needs to be "MQSTR " (eevn if he is going to IMS not thru the OTMA), so that conversion takes place.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Rajiv |
| Posted: Thu Sep 09, 2004 11:06 pm Post subject: |
|
|
Newbie
Joined: 08 Sep 2004
Posts: 8
|
Thanks again guys.
Just to clarify a couple of points -
1) We are going to the IMS via an OTMA bridge.
2) We are constructing an MQIIH header prefixing the Request Message data and the Format and ReplyToFormat field values are being set to 'MQIMSVS'.
Also, i have browsed the Reply Message data on the MQ Explorer and have confirmed that the data is in ASCII.
It seems like the Receiver Channel set up between the Remote Queue Manager and our Queue Manager is converting the Reply Message data from EBCDIC to ASCII.
I am speaking to the MQ Administrator on the HOST side to confirm the same.
Do correct me if i am wrong and/or if there is any other approach to solve this w/o turning off the conversion on the channel.
Thanks,
Rajiv. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Sep 10, 2004 4:55 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Rajiv wrote: |
Do correct me if i am wrong and/or if there is any other approach to solve this w/o turning off the conversion on the channel. |
Yes.
There is Peter's suggestion - Don't Send Packed Decimals!
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Rajiv |
| Posted: Fri Sep 10, 2004 5:04 am Post subject: |
|
|
Newbie
Joined: 08 Sep 2004
Posts: 8
|
How i wish...  .but the HOST application is based on old IVR's and are not willing to make this change.
I am following-up on the channel conversion solution.
Thanks a lot,
Rajiv. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 10, 2004 7:14 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Analyse your message and treat it as a bytesmessage
Then create your helper class to extract the meaning of your message:
extract the parts out of your byte array and transfer them as String or decode them as numbers...
Enjoy...  |
|
| Back to top |
|
|
| Rajiv |
| Posted: Fri Sep 24, 2004 4:31 am Post subject: |
|
|
Newbie
Joined: 08 Sep 2004
Posts: 8
|
Hi Guys,
'Des' had posted sample Java code for the conversion of COMP-3 fields (method name - convertFromComp3()).
We used that method and is converting the data correctly for most cases.
However we encountered a situation where the output string value does not comprise of only digits but characters also.
For ex - The program returned us a value '53F4' because F is a valid hex character and we are specifying the radix as 16(hex) while performing the following -
i.toString(16) // where i is the BigInteger
Under this scenario how can we extract the corresponding numeric value.
The expected value is '5814'.
Any help in this regard or any pointers to sample code of the similar kind is appreciated.
I am also following up with the Sender Channel (HOST) to check if the data is getting converted correctly at their end.
Regards,
Rajiv. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 24, 2004 12:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Rajiv,
53F4 is not a valid comp-3
a valid com-3 would be 53F4D or 53F4F or 53F4C.
The last byte is a sign indication : C/D/F +/-/unsigned (from bad memory).
Now if you look at these 5814 should give you
05814C or 05814F in hex
Enjoy  |
|
| Back to top |
|
|
|
|
