Restrictions

de sortie défini par l’utilisateur. Pour réduire le risque d’endommager le système, il faut bien comprendre les restrictions et les bons usages de cette fonction.

Conditions de programme. Le programme écrit par l’utilisateur n’est pas appelé si l’une des conditions suivantes se vérifie :

• Le programme n’a pas été ajouté à la fonction d’enregistrement pour le point de sortie QIBM_QWC_JOBITPPGM.

• Le job cible est en phase d’initialisation, en phase de terminaison, ou en route vers la phase de terminaison.

• Le job cible est un job système, un job de supervision de sous-système, un job lecteur de spool, ou un job d’écriture de spool.

• La valeur système QALWJOBITP est à 0.

• Le job cible est mis à l’état non interruptible quand il devient actif ou via l’API Change Job Interrupt Status (QWCCJITP).

Délai d’exécution du programme. L’API QWCJBITP n’attendra pas que le programme soit appelé dans le job cible, ce qui peut se traduire par un long délai entre le moment où l’API envoie la requête pour exécuter le programme dans le job cible et celui où le programme s’exécute vraiment. Un bon retour à partir de l’API ne garantit pas que le programme de sortie s’exécutera dans le job cible.

Programmes multiples. Si plusieurs programmes sont envoyés pour s’exécuter dans le même job cible, rien ne garantit qu’ils s’exécuteront dans le même ordre où ils ont été soumis, ni qu’un programme s’exécutera jusqu’à son terme avant qu’un autre programme ne commence.

Jobs multithreaded. D’autres threads dans le job cible sont encore en train de s’exécuter pendant qu’un programme fonctionne dans le thread initial du job cible. Le programme amené à s’exécuter dans le thread initial devrait être sécurisé contre le thread. Pour s’assurer qu’un programme s’exécute dans un job multithreaded, il faut enregistrer le programme comme Threadsafe *YES et Multithreaded Job action *RUN. Voir la commande ADDEXIT PGM (Add Exit Program) ou les API Add Exit Program (QUSADDEP, QusAddExitProgram) pour plus d’informations sur la manière d’ajouter correctement des programmes sécurisés contre le thread, à la fonction d’enregistrement.

Longueur du programme. Pour limiter le temps pendant lequel le job cible est interrompu, évitez d’utiliser un programme de longue exécution. Profil utilisateur. Le programme s’exécutera dans le job cible sous le même profil utilisateur que l’appelant de QWCJBITP. Conditions de réussite et d’erreur. Les conditions de réussite ou d’erreur signalées par le programme dans le job cible ne seront pas transmises au job source. Vous devez donc consulter le job log du job cible pour savoir si le programme a réussi ou échoué.

Jobs non interruptibles. Si le job cible dans la file d’attente est inactif ou indisponible, le job ne peut pas être interrompu. Le job cible n’est pas disponible s’il est en transition ou en cours de transfert.

Bibliothèque. Les programmes ne peuvent pas utiliser la commande SETASPGRP (Set ASP Group) pour changer l’espace du nom de bibliothèque du job. L’API ne peut appeler que les jobs qui résident dans *SYSBAS. La bibliothèque contenant le programme n’a pas besoin d’être dans la liste des bibliothèques du job ciblé.

Threads. Quand le programme de sortie se réfère aux objets modifiés par le job cible, les données peuvent être dans un état indéterminé. Les mécanismes de contrôle d’accès, comme les verrous d’objet, sont souvent étendus au job ou au thread. Le programme aura accès aux données modifiées par le thread interrompu par le programme.

Libérer les ressources système. Un programme de sortie qui interrompt un job doit libérer toutes les ressources système et job qu’il obtient. Cela inclut la libération des verrous éventuels obtenus par le programme, la levée de tout stockage éventuel alloué par le programme, et la fermeture des éventuels fichiers ouverts par le programme.

Changements de l’environnement. Les programmes de sortie qui interrompent un job ne devraient pas changer l’environnement du job cible, ni d’ailleurs l’environnement système. Vous ne devez pas changer la liste de bibliothèques du job cible, émettre une commande Change Job (CHGJOB) ou changer les variables d’environnement.

Utiliser un job séparé. N’utilisez pas un programme de sortie d’interruption de job pour tout ce qui peut être fait sur le job cible à partir d’un job séparé.

Programmer les limites de données. Les données du programme de sortie ne peuvent pas dépasser 2000 octets. Si le programme de sortie défini par l’utilisateur nécessite plus de 2000 octets de données, utilisez un socket pour envoyer les données au programme ou, alternativement, spécifiez un espace utilisateur ou une file d’attente de données servant à garder et envoyer les données au programme. Dans l’un ou l’autre cas, il faut écrire le programme pour accepter les données à partir de ces sources. Les données de pointeur ne peuvent pas être passées au programme.

Applications de messages. Si le job cible interrompu exécute une application qui envoie des messages, et si cette application ou une autre s’attend à des messages séquentiels, un programme de sortie défini par l’utilisateur perturbera l’interface en injectant des messages. Cette perturbation peut causer des défaillances applicatives si l’application s’attend à une certaine suite de messages ou s’attend à des messages dans un certain ordre.

Bibliothèque QTEMP. Vous pouvez autoriser les programmes de sortie à accéder à la bibliothèque QTEMP pour ajouter, renommer ou supprimer des objets, ou pour effacer QTEMP. Sachez toutefois que certaines de ces opérations peuvent perturber le système d’exploitation ou les applications qui utilisent des objets de QTEMP.

*EXT. Les programmes ajoutés au point de sortie peuvent envoyer un message de requête à *EXT. Le message de requête sera exécuté comme une commande si un écran d’entrée de commande est affiché dans un job batch ou interactif.

Programme de traitement des ruptures. Les programmes de sortie peuvent soit créer une nouvelle file d’attente de messages pour avoir un programme de traitement des ruptures, soit définir une file d’attente de messages existante vers un programme de traitement des ruptures. Une fois ce programme établi, les messages provenant d’autres jobs peuvent être envoyés à cette file d’attente de messages pour exécuter le programme de traitement des ruptures.

Mal effectuée, l’interruption d’un job peut endommager le système ou provoquer des résultats inattendus. Il ne faut donc interrompre un job que si c’est vraiment nécessaire.