Я тут некоторое время назад выспрашивал какие-то начальные основы про MQ Series и огромное спасибо, особенно господам ggv и New Year, народу за помощь. А теперь вот у меня снова вопрос.

Получение сообщений мы подняли, получаем, разбираем, все классно, пока все работает. Однако стоит произойти элементарному сбою (например - подвис маршрутизатор, да и на сервере нашем, бывает, БД подвиснет), который приводит к тому, что сообщения не могут быть доставлены, как эти сообщения тут же начинают с неимоверной быстротой накапливаться и, в конечном итоге, уже через несколько часов начинают ощутимо замедлять работу мэйнфрейма.

Вопрос состоит в следующем - возможно ли сделать таким образом, что бы при 5 или там 100 неудачных попытках сообщение просто удалялось? Или что бы оно это делало по достижении определенного числа сообщений в трансмишшн очереди (удаляя наиболее старые)? Можно ли это реализовать на майнфрейме под управлением OS/390? Не посылайте только меня читать огромную кучу книг по OS/390 в целом и реализации MQ Series для этой ОС в частности, т.к. у меня нет доступа ни к мэйнфрейму, ни к их MQ серверу. Просто ответьте - можно или нет. И можно ли сделать это без программирования. А уж если кто напишет не просто возможно или нет, а и как (а то и пример реализации кинет) - сильно буду благодарен.

Новый Годв Message Descriptor есть поле Expirity (время жизни сообщения). может это поможет.

Спасибо, почитаю. Может он будет удалять в этом случае, по истечении времени, мы могли бы, пожалуй, привязаться ко времени.

Новый Год
>что бы при 5 или там 100 неудачных попытках
счетчик попыток это поле BackoutCount. в дескрипторе сообщения. т.е. написать программульку, которая удаляет сообщения, для которых BackoutCount > 5 конечно можно. на мой взгляд это извращение. сам МСА естественно сообщения никогда не удаляет.
В общем-то, конечно, при такой постановке страдает сама идея ГАРАНТИРОВАННОЙ доставки, однако в жизни бывает всякое и на практике иной раз лучше, что бы удаленный (наш :( ) сервер недополучил часть сообщений, чем лег основной. А как Вы решаете подобную проблему, ведь не могла же она никогда не возникать? Ломаются маршрутизаторы, рвутся, окисляются, кабели, выходят из строя сервера и т.д. Или все под жестким контролем просто, продублировано и с запасом производительности большим?

Почитал документацию, нашел вот такое решение, насколько оно правильно:
для канала отправителя задать значения MsqRetryCount и MsgRetryInterval, после которых сервер будет перекладывать письма в dead-letter queue, а для процессинга dead-letter queue в MQS для OS/390 есть batch утилитка CSQUDLQH, которую можно периодически запускать для процессинга нужной dead-letter queue и там, в зависимости от reason, убивать сообщения, которые не могут доставиться.

Max queue depth тоже спасибо. Кстати почему-то на MQS 5.3 под винду не работает этот параметр. Смотрю параметры очереди стоит = 2000 (сам выставлял), а показывает текущую depth > 5000. При этом иногда работает как-то, т.к. партнеры говорят, что бывает им приходят репорты о том, что целевая очередь переполнена... странно в общем.

Про Expirity я что-то не смог найти ничего в pdf-ах (искал в Application Programming Guide\Reference и Intercommunication). Нашел описание заголовка сообщения - никакого Expirity или там TTL не нашел, еще нашел упоминание о short live letter и long live letter и что их нужно на разные странички размещать, но, насколько я понял, термины short\long live letter (или message) относятся не к каким-то системным установкам, а скорее к планируемому администратором\разработчиком времени жизни сообщения (например, что до одного сервера сообщения могут быть отправлены раз в три часа, а на другой шлются сразу и постоянно). Где про него прочесть?

НГ>Где про него прочесть?
вроде в wmq system adm. for 390. нет книжки с собой.
Имелось ввиду - где прочитать про long\short letters? Такая книжка у меня есть в pdf, там и прочел про них. Понял, что это просто понятия при проектировании системы очередей сообщений. Книгу про ОС 390 читаю иногда для "проверки" своих коллег, т.к. иногда, есть подозрение, отвечают, что сделать нельзя, а на самом деле просто какому-то начальнику-посреднику не хочется брать на себя ответственность и проще ответить "нет", чем разбираться "как". А сам я к OS/390, к огромному моему сожалению, доступа не имею, да и MQ у нас всего одна очередь в одном менеджере на одном сервере. :)
Вопрос относился к тому, где прочитать про Expiry - большое спасибо, прочел. Просто я пробовал искать Expirity и в формате заголовка - а тут Expiry и в API.

Огромное спасибо Вам - как минимум два варианта, которые должны сработать, уже есть, будем теперь вести переговоры.

Ну я и думал, что всего два - но этого мне будет, надеюсь, достаточно. Про решение, с dead letter queue я подумал потому, что когда я еще в самом начале пытался совать мессаджи сразу в трансмишн очередь (и о чем оно мне ругалось, что формат не тот), то оно, насколько я помню, перекидывало сообщения в dead letter queue. Я думал, что оно может поступать так же, если очередь будет переполнена или будет првышено количество попыток отравки. Я этого не проверял повторно - не было выделено времени, а дома не установлен MQ Series (попробую на досуге). Впрочем у меня нет оснований не верить господину New Year - если он говорит, что эти параметры влияют только для ресивера, то веростно так и есть, а с SSL я, увы, помочь ничем не могу - не пытались даже настраивать аутентификацию (особенно при том, что у нас даже поле userID приходит вообще пустое). Мы удовлетворились тем, что на продакшн сервере настроим доступ к нужному порту только определенному адресу интранета.