L’exploitation des chaînes Control-M entraîne parfois, certains problèmes quand à la gestion des jobs. Cet article a pour but de détailler les différentes solution mises en œuvres pour remédier à ces problèmes.
Lors des actions de de suppressions de job, il peut arriver que celles-ci ne fonctionnent pas sur l’Enterprise Manager. En effet, certains jobs dans un état instable peuvent apparaître :
- En jaune : Le processus associé sur le serveur cible ne tourne pas.
- En blanc : Aucune opération n’est possible sur le job.
Remarque : Dans les deux cas, il s’agit d’une désynchronisation entre la base et le serveur Control-M.
Méthode de résolution
- Récupération Order_ID :
Se connecter avec un compte administrateur (ex : emuser) au serveur Control-M. Se positionner sur le job qui pose problème et effectuer les actions suivantes :
- Faire un clic droit sur le job
- Sélectionner Hold
- Se positionner dans l’onglet Active
- Récupérer l’Order ID de ce job.
Sur le serveur Control-M, sous le user root, effectuer les opérations suivantes :
1 |
controlm@basmut:/controlm/srv_6.4.01 $ p_36 ORDERID |
Remarque : Où ORDERID est le numéro récupéré dans l’onglet Active du job.
Exemple d’utilisation du script :
1 2 |
controlm@basmut:/controlm/srv_6.4.01 $ p_36 00a3g result = 398310 |
- Vérification du job bloqué :
Vérifier que le numéro retourné correspond bien au job bloqué, via les commandes suivantes :
1 |
controlm@basmut:/controlm/srv_6.4.01 $ sql |
1 |
SQL> SELECT jobname, memname FROM cmr_ajf WHERE orderno = RESULT; |
Remarque : Où RESULT est le résultat de la commande p_36
Exemple d’utilisation du script :
1 |
controlm@basmut:/controlm/srv_6.4.01 $ sql |
1 |
SQL> SELECT jobname, memname FROM cmr_ajf WHERE orderno = 398310 ; |
1 2 3 |
JOBNAME MEMNAME ----------------------------- ----------------------- X-AGT Purge_Proclog |
- Mise à jour du statut du job :
Modifier l’information stockée dans la base de données via les commandes suivantes :
1 |
controlm@basmut:/controlm/srv_6.4.01 $ sql |
1 2 |
SQL> UPDATE cmr_ajf set state ='5', oscompstat = 1, status = 'N' WHERE orderno = RESULT; SQL> commit; |
Remarque : Où RESULT est le résultat de la commande p_36.
Une fois cette mise à jour effectuée, le job passera en status « NOK », et il peut maintenant être dé-planifié via les commandes adéquates.
Bonjour,
Ces jobs ne résultent pas d’une désynchronisation entre la base et le CTM/Server. Ils sont le résultat d’une interprétation du control-M/Server en l’absence d’informations venant du CTM/Agent. Un arrêt/relance de l’agent ou parfois un simple hold/free peut résoudre le problème.
Même si la méthode expliqué dans cette article est largement utilisée sur les sites Control-M, attention aux écritures dans la base ! Elles ne sont pas autorisée par l’éditeur sans validation par le support. En effet, le job modifié pourrait verrouiller une ressource que la mise à jour faite ici ne libèrera pas.
Cdlt.
Bonjour,
Merci pour ce retour d’expérience, j’essaierai de redémarrer un agent si cela se reproduit à nouveau, toutefois, un simple hold/free n’a pas suffit à résoudre mon problème lorsque celui-ci s’est produit (déjà testé plusieurs fois sur des agents en blanc). Certes, la méthode utilisée est un peu violente puisque l’on altère la base de données, mais ces opérations ne sont pas effectuées par tout le monde, seulement par les administrateurs en charge de l’infrastructure Control-M.