Les objets IBM® i tels que des modules, des fichiers , des programmes sont créés à partir de la source contenue dans votre projet. Chaque fichier source de votre projet peut être associé à un jeu de commandes pour le créer. L'association d'un jeu de commandes avec un jeu de membres source est définie dans un générateur.
D'autres types d'objets IBM i peuvent aussi être créés, comme des zones de données, des programmes de service et des listes d'autorisation. Ces types d'objets ne sont pas créés à partir de membres sources mais sont entièrement définis par des commandes. Vous pouvez utiliser des jeux de commandes pour définir également ces types d'objets.
Les jeux de commandes contiennent des commandes CL qui peuvent contenir des variables. Ces variables pouvant être définies au moment de l'exécution, les jeux de commandes peuvent être considérés comme étant des modèles pour la création d'objets ou pour l'exécution de diverses autres tâches devant prendre place lors de la création d'un projet.
Les jeux de commandes peuvent être définis dans la spécification de génération du projet qui les utilise ou ils peuvent être référencés en tant que jeux de commandes externes depuis d'autres projets en définissant d'abord une référence de projet puis en nommant le jeu de commandes à partir du projet que vous souhaitez utiliser. Vous pouvez utiliser cette fonction pour définir un jeu de commandes commun utilisé par tous les projets.
Il existe deux types de jeux de commandes : général et conditionnel. Les jeux de commandes généraux sont utilisés pour exécuter des tâches devant être exécutées sur chaque version. Cela fonctionne également pour la configuration, l'établissement de substitutions pour des compilations, le conditionnement et le nettoyage. Les jeux de commandes conditionnels peuvent être exécutés ou ne pas être basés sur l'état de la sortie du générateur qui l'utilise. Cela signifie que les commandes d'un jeux de commandes peuvent être exécutées si l'objet de sortie d'un générateur existe mais n'est pas à jour, ou si l'objet de sortie n'existe pas.
Les commandes d'un jeu de commandes sont regroupées en sections de traitement. Les jeux de commandes généraux peuvent n'ont qu'une seule section de traitement. Les jeux de commandes conditionnels effectuent leur traitement en fonction de l'état des objets générés définis pour les générateurs qui les utilisent. Les jeux de commandes conditionnels comportent deux sections, l'une d'elles s'exécute si un objet de sortie existe mais n'est pas à jour, l'autre s'exécute si l'objet de sortie n'existe pas. Un bon exemple de cas où cela peut s'avérer nécessaire est lorsque vous souhaitez créer un fichier physique à l'aide de CRTPF s'il n'existe pas et le modifier à l'aide de CHGPF s'il existe. Les zones de données et les autres objets contenant des données peuvent nécessiter un traitement spécial similaire. S'il n'est pas nécessaire que les deux sections soient différentes, vous pouvez définir la section qui "n'existe pas" pour qu'elle exécute les mêmes commandes que la section qui "existe mais n'est pas à jour".
Un générateur exécute un jeu de commandes en fonction du type de traitement d'entrée que vous avez spécifié dans le générateur qui l'utilise. Les commandes d'un jeu sont toujours exécutées dans l'ordre que vous spécifiez mais peuvent s'exécuter plusieurs fois selon le type d'entrée que vous lui avez associé dans le générateur.
Si vous ne spécifiez pas de liste d'objets source ou de membres, le jeu de commandes conditionnel s'exécutera une fois au plus si l'objet de sortie associé au générateur le requiert. Convient à l'exécution de commandes pouvant utiliser des listes d'objets comme paramètres, tels que CRTPGM.
Les jeux de commandes non-conditionnels peuvent n'avoir qu'une seule section de traitement. Ils conviennent aux commandes ou jeux de commandes qui ne créent pas d'objets mais peuvent être nécessaires en tant que partie intégrante de la configuration de génération pour établir des substitutions pour des compilations.
Voir Jazz.net pour plus d'informations.