боюсь что там не будет такой информации. напишите send-receive ехit и логируйте это раз вам нужно.

по такому-то каналу сообщение может пойти только в одно место -- по такому-то каналу на накой-то queue manager.
а там попасть либо в очередь назначения либо в dead letter queue либо в DEFXMITQ если удалённыё queue manager используется как транзитный.

ну есть конечно варианты что это клиенское соединение, нарпимер.
но обычно, в sender/reciver это вот так.

> либо в DEFXMITQ если удалённыё queue manager используется как транзитный.
и эта DEFXMITQ определена

zloy_boOblikя понял, но ет немного не то... я например в данный момент использую для этого FAR, но хотел что-бы это было более наглядно, тоесть какая либо програмка.

и что там в фаре видите? картинку можно?

zloy_boOblikL.EDISYSGUAA P.EDISYSGVCB GUAA 2009031709305786
отправитель, получатель, название очереди, время передачи.
остальной текст - скриптованое тело сообщения.

Не!!! это вы не правильно говорите!!! это то что вы видите это поля из message descriptor!!! которые конечно же есть в логе, как и тело сообщения!!! это же транзакшн лог а не лог кого куда отправили....

Смысл у этих полей них несколько иной...

но поскольку вы Железнодорожик, я знаю в РЖД есть что-то типа стандарта в поле ApplIdentityData пихать откуда сообщение взялось и куда преднозначено. вот наверно что красным цветом вы про то говорите!!!

ну замечательно.

вот "какие сообщения были отправлены на данном канале в промежуток времени" и информация "из дескриптора или ил тех полей что Вы указали" это разные вещи.

просто вы заявляете что хотите получить одно, а то что вы смотрите это совершенно другое.

вот то что вы заявляете что хотите получить -- "какие сообщения были отправлены на данном канале в промежуток времени" -- можно получить написав канальный send / receive exit.

с чего взяли-то что интересующая вас информация в логах есть?


Calculating the size of the log
After deciding whether the queue manager should use circular or linear logging, you need to estimate the size of the log that the queue manager needs. The size of the log is determined by the following log configuration parameters:

LogFilePages
The size of each primary and secondary log file in units of 4K pages
LogPrimaryFiles
The number of preallocated primary log files
LogSecondaryFiles
The number of secondary log files that can be created for use when the primary log files are full
Table 17 shows the amount of data the queue manager logs for various operations. Most queue manager operations need a minimal amount of log space. However, when a persistent message is put to a queue, all the message data must be written to the log to make it possible to recover the message. The size of the log depends, typically, on the number and size of the persistent messages the queue manager needs to handle.

Table 17. Log overhead sizes (all values are approximate) Operation Size
Put persistent message 750 bytes + message length
If the message is large, it is divided into segments of 15700 bytes, each with a 300-byte overhead.

Get message 260 bytes
Syncpoint, commit 750 bytes
Syncpoint, rollback 1000 bytes + 12 bytes for each get or put to be rolled back
Create object 1500 bytes
Delete object 300 bytes
Alter attributes 1024 bytes
Record media image 800 bytes + image
The image is divided into segments of 260 000 bytes, each having a 300-byte overhead.

Checkpoint 750 bytes + 200 bytes for each active unit of work
Additional data might be logged for any uncommitted puts or gets that have been buffered for performance reasons.


Notes:
You can change the number of primary and secondary log files each time the queue manager starts.
You cannot change the log file size; you must determine it before creating the queue manager.
The number of primary log files and the log file size determine the amount of log space that is preallocated when the queue manager is created.
The total number of primary and secondary log files cannot exceed 511 on UNIX systems, or 255 on Windows, which in the presence of long-running transactions, limits the maximum amount of log space available to the queue manager for restart recovery. The amount of log space the queue manager might need for media recovery does not share this limit.
When circular logging is being used, the queue manager reuses primary log space. This means that the queue manager's log can be smaller than the amount of data you have estimated that the queue manager needs to log. The queue manager will, up to a limit, allocate a secondary log file when a log file becomes full, and the next primary log file in the sequence is not available.
Primary log files are made available for reuse during a checkpoint. The queue manager takes both the primary and secondary log space into consideration before taking a checkpoint because the amount of log space is running low.
If you do not define more primary log files than secondary log files, the queue manager might allocate secondary log files before a checkpoint is taken. This makes the primary log files available for reuse.

Notices | Downloads | Library | Support | Feedback
amq5234