Проблема с преобразованием данных MQ EBCDIC (25), которое интерпретируется как перевод строки и преобразуется в 15

У нас возникла интересная проблема.

У нас есть интеграция между системой AS400, которая отправляет сообщения MQ в формате EBCDIC, принимается плагином TIBCO BW MQ и обрабатывается. Это финансовые операции.

Проблема заключается в том, что когда элемент данных (упакованный десятичный) содержит нечетные цифры, такие как 251-259 или 25001-25999 и т. д., элемент данных интерпретируется плагином TIBCO BW MQ как 151-159 и т. д.

Таким образом, у нас была сумма 25125, интерпретируемая как 15125, что привело к отсутствию подсчета транзакции в размере 100 долларов США (суммы в центах). Плагин TIBCO BW MQ использует Java внизу, поэтому, вероятно, это проблема Java. AS400 может отправлять и получать как 25125. Но когда мы просматриваем сообщение из проводника MQ, мы видим, что значение элемента данных также отображается как 15125.

Команда AS400 указывает, что, поскольку они могут отправлять и получать как 25125, проблема не на их стороне. Кто-нибудь сталкивался с подобной проблемой раньше? Если да, то как вы ее решили? Это проблема с клиентом MQ или проблема с доставкой сообщения AS400 MQ?


java ibm-mq mq tibco ibm-midrange
person Karthik    schedule 15.09.2015    source источник
comment
Числа PackedDecimal должны содержать нечетное количество цифр, поскольку знак (последний полубайт) занимает 1 цифру (последний полубайт). Если MQ Explorer неправильно интерпретирует число, маловероятно, что это проблема клиента. Старшая цифра всегда уменьшается на 1 или сдвигается вправо? Попробуйте 501 и 401. Они оба станут 201? или 401 и 301?   -  person JustinDanielson    schedule 16.09.2015
comment
Это происходит только для 25 серии, остальные все в порядке. По-видимому, 25 является символом новой строки и заменяется на 15 при анализе данных.   -  person Karthik    schedule 16.09.2015
comment
Мы обратились в службу поддержки TIBCO по инженерным сборкам, и оказалось, что это проблема с клиентом MQ. Кто-нибудь знает, есть ли у клиента MQ поддержка или он с открытым исходным кодом.   -  person Karthik    schedule 18.09.2015

Ответы (3)


arrow_upward
1
arrow_downward

Я не знаком с TIBCO...

Но вообще говоря, передавать упакованные данные через MQ — плохая идея.

MQ, будучи мультиплатформенным, имеет только два способа отправки сообщения. В виде строки и в виде необработанных байтов. Когда вы отправляете его в виде строки, он будет обрабатывать преобразование из одной кодировки в другую в зависимости от задействованных платформ.

Как видите, обработка упакованного десятичного числа как строки не работает.

TIBCO может иметь функциональность для обработки необработанного сообщения, где-то в TIBCO (или в вашем Java-приложении?) вам нужно настроить преобразование EBCDIC в ASCII (Unicode) вместе с распаковкой упакованного десятичного поля. Вам также нужно будет настроить MQ для отправки этого сообщения в необработанном виде.

В противном случае вам потребуется, чтобы сторона IBM i распаковала данные перед их отправкой в ​​виде строкового сообщения MQ.

person Charles    schedule 16.09.2015
comment
данные отправляются и принимаются в виде байтов, а не в виде строки. Когда байты анализируются, байты, начинающиеся с 25, заменяются на 15. - person Karthik; 16.09.2015
comment
Если MQ отправляет необработанные байты, клиент получает необработанные байты, поэтому проблема заключается либо в TIBCO, либо в вашем приложении Java; тот, кто занимается разбором. - person Charles; 16.09.2015

arrow_upward
1
arrow_downward

Один из способов получить числовые данные от машины EBCDIC — это представление, которое преобразует числа в символы.

Например

CREATE TABLE DSYLVESTER/ZDAN1 (X1 decimal(3,2) NOT NULL WITH 
DEFAULT)                                                     

select * from dsylvester/zdan1 

3.22

create view qtemp/z3 as (            
SELECT cast( X1 as char(5)) as x1    
 FROM dsylvester/zdan1               

)                                    

select * from qtemp/z3  
3.22

Примечания: позвоните в IBM, они не знают, как это сделать. Позвоните в TIBCO, они тратят больше на рекламу и продажи, чем на разработку. TIBCO не сможет помочь.

person danny117    schedule 24.09.2015
comment
Спасибо Дэнни, но система MQ Core не захотела вносить для этого никаких изменений. Итак, мы закончили отладку и выяснение проблемы. Я опубликую ответ в ближайшее время - person Karthik; 02.10.2015

arrow_upward
0
arrow_downward

Спасибо всем за разные указатели.

Это оказалось проблемой с java jar, предоставленными вместе с клиентом MQ. Оказывается, этот конкретный байт '0x25' обладает любопытным свойством: при обработке JVM таким образом и обработке его как символа, закодированного в схеме CCSID 37, выходной байт будет '0x15'.

Например, используя фрагмент кода следующего вида:

byte[] bytesRepresentation = {(byte)0x25};
String dataAsString = new String(bytesRepresentation, "IBM-037");
byte[] newBytesRepresentation =
dataAsString.getBytes(Charset.forName("IBM-037"));
System.out.println(byteArrayToHexString(bytesRepresentation));
System.out.println(byteArrayToHexString(newBytesRepresentation));

вывод:

25 15

т.е. последовательность байтов была изменена обработкой byte[]->String->byte[].

Служба поддержки MQ рекомендовала отправляющей стороне изменить свойство сообщения, определяющее формат сообщения как MQSTR, на значение по умолчанию (пустое). После этого клиент MQ не пытается выполнить преобразование, и TIBCO правильно получает это от клиента MQ.

person Karthik    schedule 02.10.2015