ggv
Вот чего он такое и зачем я уже написал.

Вы писали, что это набор библиотек и несколько второстепенных бинарников. Насколько я понял - тут то же самое. Просто я думал, что если я слинковал свое приложение с этими библиотеками при компиляции, потом мне уже ничего и не надо для того, что бы приложение работало. Но кстати сейчас ставил сервер - он увидел, что на машине уже установлен клиент. Видимо эти библиотечки еще и регистрируются. В общем что такое клиент я, кажется, понял наконец! :)

Вот конкретный вопрос - если у меня установлен сервер. Могу ли я через MQSeries Explorer создать такую свою очередь, что бы туда попадали сообщения из какой-то удаленной очереди (я знаю ее адрес, порт, имя менеджера и имя очереди) и при этом делался browse (т.е. сообщения не удалялись) и как (и вообще - можно ли?) просто увидеть эту очередь в моем експлорере?

ggv
Лучше всего - слать С-шный структуры, ну а для межплатформенности - в XDR их (часть RPC, представляет данные в машино-независимом формате, если кто не знает)

Ну - с этим у нас "просто и легко" - такими проблемами глобальными голова не болит. :) Решение о функционировании очереди, доступе к ней, формате отдаваемых данных уже принято в одностороннем порядке. Так что нам осталось самое простое - сделать какой-то механизм выгребания оттуда данных и пользоваться.

Никак не могк понять - нафига мне нужен MTS и\или XA? На схеме New Year просто он был показан как некая среда, которая давала доступ к MQ из MS SQL. А так - для моих задач он не нужен особо.

NewYearно клиентской программой нельзя записать сообщения в sql server. т.к в зтом случае нет XA :(

В смысле - sql server ругнется, если я попробую в хранимой процедуре получить сообщения без транзакций (например - во временную таблицу), а потом открою транзакцию с mssql, закину данные в нужную мне таблицу и, если все без ошибок, подтвержу транзакцию? Он, вообще, может. :( До сих пор не могу понять, почему он считает, что нужно поднять распределенную транзакцию, если в одной и той же процедуре встречается обращение к линкованному серверу и открытие транзакции с уже полностью локальными участниками. Удивительно, что если обращение к удаленному серверу выполнить в динамическом запросе, то он прекрасно обходится без удаленных транзакций. :) В DB2, на мой взгляд, с этим еще ужаснее. Нетак давно решали проблему - нам на удаленном сервере дали права на запуск одной процедуры, которая возвращала нужные данные. Пришлось писать отдельный exe, который запускался из хранимой процедуры и через stdout передавал, полученные от процедуры данные. Процедура их парсила и уже после этого только они попадали в базу. А вот как сделать хранимую процедуру на Db2 так, что бы она коннектилась к удаленному серверу, запускала там процедуру и результат этой процедуры записывала в таблицу своего локального сервера мне никто не смог подсказать.

ggv
Ну и как верно сказал NewYear - нельзя использовать MQGET для удаленной очереди
MQOPEN может быть для удаленной очереди, но только на MQPUT
То есть - если вы даже и развернете свой qmgr, и сделаете MQOPEN удаленной очереди - вы не сможете просматривать сообщения (то есть делать MQGET в режиме browse)
Но это справедливо только для сервера? Клиент сможет открыть очередь для MQGET в режиме BROWSE?

NewYear>только на ЛОКАЛЬНОМ QMGR

ЛОКАЛЬНЫЙ QMGR это тот к которму был mqconn. это может быть удаленная машина.

ggvНу что такое локальный qmgr ф уже коротко упомянул выше :)
Как раз тот к которому был MQCONN :)

Я уж было напугался! :)

NewYearэто та же самая прога. просто тогда нужно перетащить ее на мейнфрейм.
ну а что делать?

А просто никто не даст нам ничего разворачивать на мэйнфрейме.


ну вот нафига, спрашивается, вообще этот browse и одна очередь для всех? нельзя что ли каждому дать свою очередь. а так в любом случае придется извращаться.
Конечно извращаться. В таком варианте нет ни гарантии доставки (сообщение может быть убито до того, как его прочтут ВСЕ кому оно нужно) и нет гарантии доставки в ЕДИНСТВЕННОМ экземпляре, потому что никто не мешает читать уже приходившие сообщения. Правильно? И в таком варианте только дополнительные мучения от очереди этой. Я ж и писал - как было бы здорово работать с федеративной табличкой или вьюшкой. А отличать, я надеюсь, будем по естественному ключу.

ggv
Мучения все из-за _неправильного_ использования MQ

Как выяснилось - все же будет правильное или почти правильное использование. Режим просмотра нужен только пока - именно нашей очереди нет еще и есть одна общая очередь из которой можно потренироваться читать и парсить, в нее положили несколько сообщений.
Реальная схема будет такая - есть выделенная (для нас) очередь расположенная на их менеджере (на OS/390). Наше приложение или сервер (насколько я понял с сервером так не получится) должны запросить сообщения, которые "ждут" нас, получить эти сообщения, поместить в БД, подтвердить их получение (что бы они удалились из очереди). Очевидно, тут транзакция была бы весьма кстати. А какие варианты есть у меня, кроме клиента перекладывающего сообщения в мою очередь (и в этом случае, насколько я понимаю, у меня все равно не будет транзакции между моим менеджером очереди и их, правильно?) ?

ggv
И никаких преимуществ и федеративной таблички нету - одни недостатки.
Ну сам подумай - MQ это некий специальный вид IPC - Inter Process Communication - обладающий свойствами транзакционности, асинхронности, и транспорта.
Никакая общая табличка и близко к таким возможностям не приблизится.

Если у Вас есть время, то я бы с удовольствием узнал бы недостатки такого способа (таблички) - пока я их не вижу. Вот смотрите по поводу свойств MQ:
1. Транзакционность - двухфазная транзакция в случае федеративной таблички не нужна, т.к. при неудачном завершении транзакции на стороне сервера-приемника всегда можно получить эти же данные повторно. Гарантию отсутствия дубликатов записей можно получить при наличии в таблице авто-инкрементального ключа.
2. Асинхронность - на полную катушку, поставщик данных обеспечивает гарантированное наличие необходимых данных в таблице, приемники читают те данные, которые еще ими не были прочитаны.
3. Транспорт - практически любой сервер БД поддерживает некоторые протоколы, которые позволяют получать информацию от удаленных систем с гарантией ее неизменности при передаче. Кроме этого - во многих БД есть встроенные производителем механизмы репликации, есть подозрение, что они могут быть достаточно эффективны.

Минусы MQ (на мой взгляд):
1. Дополнительные затраты (либо на написание своего клиента по работе с MQ, либо на покупку неких мостов, менеджеров)
2. Дополнительная головная боль (и потеря производительности) по стандартизации формата сообщения, организации парсинга этого сообщения.

Я ни в коем случае не ругаю MQ, мне просто хочется понять. Ну и в любом случае мне придется с ним работать.


ggv
Это только ораклисты способны делать IPC через oracle
Наверно еще MS SQL-ники ! ;)