Bienvenue...
Soumis par kacy le
...sur mon blog, j'utilise ce site pour noter les petites choses qui me sont utiles, que ça soit informatique ou autre :)
Blog
Il y a 13 années 2 mois
...sur mon blog, j'utilise ce site pour noter les petites choses qui me sont utiles, que ça soit informatique ou autre :)
Il y a 13 années 2 mois
Une bonne pratique est de nommer les XmitQ du nom du QM de destination.
Ok, mais encore, quel intérêt ? Cela permet en fait d'effectuer un routage des messages plus "fluide" en utilisant les champs ReplyTo des messages.
Lorsqu'on répond à un message MQ (en passant par l'API C ou la lib java spécifique WMQ - je n'ai pas regardé s'il existait un équivalent en JMS) le QM put en fait le message dans la XmitQ ayant le nom du QM spécifié dans le champ ReplyToQM du message MQ.
Le message remonte alors vers le QM de destination. Que se passe t il lorsque l'on est en architecture étoile (un QM central et n QM magasins rattachés à ce central) et qu'on essaye de répondre à un message envoyé à un magasin mais d'un QM connu uniquement du central ?
En effet, si vous m'avez suivi et que vous connaissez un peu le comportement d'un QM, la XmitQ étant inconnue du QM Magasin, le message échoue fatalement dans la Dead Letter Queue (la file des messages que le QM ne sait pas router).
Il faut donc positionner au niveau du QM Magasin une "Default XMITQ" pointant vers le central, le QM Magasin routera alors le message vers cette XmitQ et le QM Central, qui connait le ReplyToQMGR, saura dans laquelle de ses XmitQ il doit mettre le message.
Il y a 13 années 8 mois
Le principe étant que le sender fait un PUT dans la XmitQ et le receiver un GET, il faut par ailleurs que la XmitQ du channel soit la bonne (sinon ça marche pas :)
Il y a 13 années 8 mois
Il faut tout d'abord se procurer le Support Pack MS03 qui fourni l'executable "saveqmgr"
Une fois installé sur le serveur, taper la commande :
saveqmgr -o --noSystemObjects -f -m <NOM DU QM>
- -o pour écraser le fichier de destination s'il existe
- --noSystemObjects pour ne récupérer que le spécifique
- -f pour envoyer le résultat vers un fichier (par défaut <NOM DU QM>)
- -i si le script s'arrête suite à des erreurs (type objet MQ endommagé)
Cela génère un fichier de commande MQSC qu'il suffit ensuite de faire manger à un "runmqsc".
Il y a 13 années 8 mois
La fréquence de purge est fonction du transit des messages dans le QM.
Il faut installer le Support Pack IBM MS62 qui donne accès au script perl "cleanlogs".
Le script de purge à mettre en place :
# on vire les anciens log archivés
rm /var/mqm/log/<NOM DU QM>/*.gz
# on créé un snapshot
rcdmqimg -z -l -m <NOM DU QM> -t all \*
# on zippe les logs inutiles
cleanmqlogs -z <NOM DU QM>
La commande rcdmqimg est une commande standard MQ, elle permet de faire un snapshot des logs, l'option -z zip les archive de logs qui sont obsolètes, -l permet de ne conserver que les logs importants (qui permettront au QM de redémarrer même en cas de crash disque sévère).
> modifier éventuellement le fichier cleanmqlogs :
ligne 1 chemin vers perl
ligne 105 nom du gzip si pas dans le path
