> Tech > Améliorer la sécurité avec les programmes points de sortie de commande CL – Part.2

Améliorer la sécurité avec les programmes points de sortie de commande CL – Part.2

Tech - Par Joel Wettern - Publié le 24 juin 2010
email

On voit que le programme de sortie reçoit les trois paramètres dont nous avons parlé plus haut. Le premier d’entre eux contient une structure de données qu’il convient d’analyser champ par champ. Ensuite l’on définit les champs qui seront utilisés pour stocker les données une fois analysées.Les données sont ensuite analysées au niveau de leurs composantes. Dans cet exemple, un travail supplémentaire consiste à analyser la chaîne de commande et à déterminer le décalage par rapport à la commande. Bien que l’exemple ne nécessite pas ou n’utilise pas cette information, le code est fourni comme un modèle pour écrire vos propres programmes de sortie.

Améliorer la sécurité avec les programmes points de sortie de commande CL – Part.2
Les données sont ensuite analysées au niveau de leurs composantes. Dans cet exemple, un travail supplémentaire consiste à analyser la chaîne de commande et à déterminer le décalage par rapport à la commande. Bien que l’exemple ne nécessite pas ou n’utilise pas cette information, le code est fourni comme un modèle pour écrire vos propres programmes de sortie. Le fait d’analyser la commande vous permet si nécessaire de modifier ses paramètres et de forcer d’autres paramètres dans la commande modifiée.

Ensuite, l’indicateur de changement est interrogé pour déterminer si la commande est modifiable par le programme de sortie. Si une commande est qualifiée en bibliothèque quand elle est transmise à l’analyseur de commandes – comme dans la commande QSYS/WRKJOB – elle n’est pas modifiable par le programme de sortie, et l’indicateur de changement aura une valeur de 0. C’est volontaire.

Une commande ne peut pas être modifiée dans certains autres cas.
Il en est ainsi des commandes qui

• ont un paramètre défini avec RTNVAL (*YES) comme dans toutes les commandes CL, retrieve (RTVxxx)
• ont des paramètres définis avec DSPINPUT (*NO) ou DSPINPUT (*PROMPT)
• s’exécutent dans un programme d’état système fourni par IBM Déjà en V4R5, IBM a introduit *SYSTEM comme nouvelle valeur de qualificateur. Ce qualificateur a pour but d’autoriser une sorte de référence qualifiée « non qualifiée » vis-à-vis d’un objet.

Par exemple, si une commande est spécifiée comme *SYSTEM/ WRKJOB, la commande WRK JOB dans la bibliothèque QSYS sera utilisée. Le qualificateur *SYSTEM obtient l’objet de QSYS, bien qu’il n’identifie pas explicitement QSYS. Si vous voulez qualifier des commandes dans vos applications et continuer à utiliser des programmes de sortie pour changer les commandes, vous pouvez utiliser le qualificateur *SYSTEM, lequel est, en coulisses, ni plus ni moins qu’une qualification vis-à-vis de la bibliothèque QSYS.

Dans le fragment de code suivant, la commande de remplacement est mise à QSYS/DSPJOB si l’utilisateur exécutant la commande WRKJOB a *USER comme classe utilisateur. Puis le programme de sortie se termine. Peut-être avez-vous constaté que les variables CL utilisées dans le programme de sortie pour stocker les chaînes de commandes ont une longueur de 2000 octets. Avant la V5R3, les variables caractères CL ne pouvaient pas dépasser 2000 octets. Mais la limite est maintenant de 9999.

Bien que 2000 octets suffisent certainement pour contenir la chaîne de commande WRKJOB de cet exemple, la longueur réelle d’une chaîne de commande qui peut être traitée par l’intermédiaire de l’interface du point de sortie est de 32 000 octets. Le programme exemple est écrit en CL afin que le programme de sortie soit simple à lire et à comprendre. En réalité, les programmes de sortie n’ont pas à être écrits dans un langage particulier, ni écrits pour ILE, mais bien sûr ils peuvent l’être.

Téléchargez gratuitement cette ressource

Guide de facturation électronique, voie royale pour le DAF et la digitalisation de la fonction finance

Guide de facturation électronique, voie royale pour le DAF et la digitalisation de la fonction finance

Ce livre blanc expose les problématiques auxquelles sont confrontés les DAF modernes et souligne les bénéfices de la facturation électronique pour la trésorerie. Il dévoile également le processus de déploiement de ce projet de transformation digitale que la réglementation rendra bientôt obligatoire.

Tech - Par Joel Wettern - Publié le 24 juin 2010