zip archive.zip analyse.csv adding: analyse.csv (deflated 84%) $
et par défaut si vous zippez sur une archive existante il ajoute
zip archive.zip xmlversion.txt adding: xmlversion.txt (stored 0%) $
pour voir le résultat
unzip -l archive.zip Archive: archive.zip Length Date Time Name ——— ———- —– —- 9934 2019-03-29 23:44 analyse.csv 17 2019-02-13 10:49 xmlversion.txt ——— ——- 9951 2 files $
Pour vous aider nous proposons une commande ADDTOARCF que vous pouvez retrouver ici https://github.com/Plberthoin/PLB/tree/master/GTOOLS/ un CLLE + un CMD
Remarque :
Vous pouvez ajouter une un fichier à un zip généré par CPYTOARCF Par défaut il créera la l’archive Vous pouvez indiquer des options si elles sont valides dans la commande Zip Vous avez un fichier stdout.log dans votre répertoire courant
https://www.gaia.fr/wp-content/uploads/2017/02/team3.png600600Pierre-Louis BERTHOIN/wp-content/uploads/2017/05/logogaia.pngPierre-Louis BERTHOIN2024-10-25 11:05:562024-10-25 11:07:21Ajouter des fichiers à une archive ZIP
Comment faire afficher un écran à un traitement batch ?
Les traitements 5250 sont faits pour tourner en interactif, mais pour différentes raisons vous pouvez vouloir les faire tourner en batch :
Pas de login sécurisation pas de attn request etc …
Voici un exemple, dans une société ou j’ai travaillé, les unités de productions pouvaient demander un mot de passe à l’astreinte, par exemple la nuit.
La solution la plus simple qu’on avait trouvée était de lui afficher un programme de changement sur son unité écran.
On lui demandait donc son profil utilisateur et son unité écran et on lançait le programme sur celle ci, il pouvait changer son mot de passe directement.
C’est cet exemple que j’ai simplifié qui est ci dessous
le DSPF source
A DSPSIZ(24 80 *DS3)
A CA03(03)
A INDARA
A R FMT01
A*%%TS SD 20240527 074541 PLB REL-V7R4M0 5770-WDS
A 4 20'Réinitialiser un mot de passe'
A 7 2'Utilisateur :'
A 8 2'Nouveau mot de passe :'
A 22 1'F3=Exit'
A USER 10A O 7 26
A PWD 32A B 8 26CHECK(LC)
A DEV 10A O 4 54
A TEXTE 30 O 14 3
Le CLP source
pgm (&dev &user)
/*----------------------------------------------------------*/
/* Ce programme permet de faire afficher un écran en batch */
/* vous devez acquérir l'unité écran */
/* pour réinitialiser un mot de passe */
/* sbmjob cmd(call initpwdr (&dev &user) job(QPADEV0001) */
/*----------------------------------------------------------*/
dcl &dev *char 10
dcl &user *char 10
/* Contrôles existence */
CHKOBJ OBJ(&DEV) OBJTYPE(*DEVD)
MONMSG MSGID(CPF9801) EXEC(DO)
SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) +
MSGDTA('L''unité écran doit exister') +
MSGTYPE(*ESCAPE)
enddo
ALCOBJ OBJ((&DEV *DEVD *EXCLRD)) WAIT(0)
monmsg CPF1002 exec(do)
SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) +
MSGDTA('Impossible d''allouer l''unité +
écran doit exister') MSGTYPE(*ESCAPE)
enddo
CHKOBJ OBJ(&user) OBJTYPE(*usrprf)
MONMSG MSGID(CPF9801) EXEC(DO)
SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Le +
profil utilisateur doit exister') +
MSGTYPE(*ESCAPE)
enddo
/* Lancement du programme sur l'écran remote */
SBMJOB CMD(CALL PGM(INITPWDR) PARM((&DEV) (&USER))) +
JOB(&DEV) JOBQ(QSYSNOMAX)
SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) +
MSGDTA('Travail, ' *bcat &dev *bcat +
'démarré') MSGTYPE(*comp)
endpgm
Le CLP cible
pgm (&dev &user)
/*----------------------------------------------------------*/
/* Ce programme réinitiliase un mot de passe */
/* Peut être envoyé sur un écran remote qui est sur la */
/* Mire */
/*----------------------------------------------------------*/
dcl &dev *char 10
dclf initpwdr
monmsg cpf0000 exec(goto erreur)
/* controles fait dans le programme appelant */
OVRDSPF FILE(INITPWDR) DEV(&DEV) OVRSCOPE(*JOB)
chgvar &pwd 'ici mot de passe'
dountil &in03
SNDRCVF RCDFMT(FMT01)
if cond(*not &in03) then(do)
if (&pwd *ne 'ici mot de passe') then(do)
CHGUSRPRF USRPRF(&USER) PASSWORD(&PWD) PWDEXP(*YES)
Chgvar &texte ('Mot de passe réinitialisé')
enddo
enddo
enddo
/* fin traitement */
DLTOVR FILE(INITPWD) LVL(*JOB)
MONMSG MSGID(CPF0000)
return
erreur:
SNDUSRMSG MSG('Réinitialisation de mot de passe pour' +
*BCAT &USER *BCAT ', actuellement +
impossible') MSGTYPE(*INFO)
MONMSG MSGID(CPF0000)
endpgm
La seule spécificité est de choisir l’unité écran d’affichage, pour qu’elle soit éligible elle doit être à la mire de connexion.
Sur un changement de mot de passe, il peut être important d’avoir un suivi ?
Bien sur, vous pouvez ajouter des contrôles …
Le job cible qui tourne en batch !
Donc pas de possibilité d’ATTN Request , et messages d’erreurs dans QSYSOPR
Remarques :
Vous pouvez choisir l’utilisateur de lancement, mais QSECOFR est interdit dans un SBMJOB Simple mais efficace, mais difficilement généralisable, on doit avoir un OVRDBF par DSPF
Intéressant pour des demandes ponctuelles
Dans les CLP vous pouvez indiquer directement l’unité sur la commande SNDRCVF
Contrôler le nombre de paramètres passés à un programme CL – %PARMS() / CEETSTA
Il arrive parfois d’avoir moins de paramètres passés à un programme CL que le nombre attendu, par exemple si on ajoute un paramètre à ce dernier mais que pour diverses raisons on ne souhaite pas modifier et recompiler tous les programmes qui y font appel.
Il existe deux solutions relativement simples à implémenter pour contrôler le nombre de paramètres transmis afin d’adapter en conséquence le comportement du programme : La fonction intégrée %PARMS et l’API CEETSTA.
%PARMS() – V7R4 et ultérieures
À partir de la V7R4, rien de plus simple, il suffit d’utiliser la fonction intégrée %PARMS(), qui retourne le nombre de paramètres :
PGM PARM(&PARAM1 &PARAM2)
/* Paramètres */
DCL VAR(&PARAM1) TYPE(*CHAR) LEN(10)
DCL VAR(&PARAM2) TYPE(*CHAR) LEN(10)
/* Corps du programme en fonction du passage du paramètre */
IF COND(%PARMS() *EQ 2) THEN(DO)
SNDPGMMSG MSG('Le paramètre &PARAM2 est renseigné')
ENDDO
ELSE CMD(DO)
SNDPGMMSG MSG('Le paramètre &PARAM2 n''est pas renseigné')
ENDDO
ENDPGM
Malheureusement, si on est confrontés à une contrainte de version, %PARMS ne descend pas en dessous de la V7R4 :
CEETSTA – V7R3 et antérieures
Dans ce cas, la solution la plus propre (je ne parlerai donc pas de monitoring sur un CHGVAR) est l’utilisation de l’API CEETSTA. Il suffit de lui passer en paramètre : – Une variable qui contiendra la valeur de retour, 1 si le paramètre est transmis, 0 s’il n’est pas transmis – Une variable indiquant la position du paramètre à contrôler
presence_flag
Sortie
*INT
Variable de retour : 1 ou 0
arg_num
Entrée
*INT
Position de la variable à tester
PGM PARM(&PARAM1 &PARAM2)
/* Paramètres */
DCL VAR(&PARAM1) TYPE(*CHAR) LEN(10)
DCL VAR(&PARAM2) TYPE(*CHAR) LEN(10)
/* Déclaration des variables nécessaires à l'utilisation de l'API */
DCL VAR(&PRESENCE) TYPE(*INT) /* Variable de retour : 1 ou 0 */
DCL VAR(&ARG_NUM) TYPE(*INT) VALUE(2) /* Position de la variable à tester */
/* Appel de l'API */
CALLPRC PRC('CEETSTA') PARM((&PRESENCE) (&ARG_NUM))
/* Corps du programme en fonction du passage du paramètre */
IF COND(&PRESENCE *EQ 1) THEN(DO)
SNDPGMMSG MSG('Le paramètre &PARAM2 est renseigné')
ENDDO
ELSE CMD(DO)
SNDPGMMSG MSG('Le paramètre &PARAM2 n''est pas renseigné')
ENDDO
ENDPGM
Remarques
Le compte des paramètres pour la arg_num commence à 1 La valeur de retour est un *INT pas un *LGL
https://www.gaia.fr/wp-content/uploads/2023/08/Openssh.gif191194Julien/wp-content/uploads/2017/05/logogaia.pngJulien2023-12-24 01:41:132023-12-24 01:41:15Contrôler le nombre de paramètres passés à un programme CL – %PARMS() / CEETSTA
Vous voulez utiliser la souris dans un dspf sur dans un de vos programmes voici un exemple en CLLE:
DSPF :
A DSPSIZ(24 80 *DS3)
A CA03(03)
A* EVENNEMENT SOURIS
A* UNSHIFT / LEFT / PRESS
A R FMT01
A*%%TS SD 20231025 171347 QSECOFR REL-V7R4M0 5770-WDS
A MOUBTN(*ULP ENTER)
A RTNCSRLOC(*MOUSE &L1 &C1 &L2 &C2)
A* RÉCUPÉRATION DU CURSEUR
A L1 3S 0H
A C1 3S 0H
A L2 3S 0H
A C2 3S 0H
A 3 13'Tester la position de la souris'
A 5 13'En faisant un clic Gauche.'
A* BOUTON BAS DE PAGE
A F1B 2Y 0B 23 2PSHBTNFLD
A PSHBTNCHC(1 'F3=>Exit' CA03)
https://www.gaia.fr/wp-content/uploads/2017/02/team3.png600600Pierre-Louis BERTHOIN/wp-content/uploads/2017/05/logogaia.pngPierre-Louis BERTHOIN2023-10-25 20:47:252023-10-27 19:46:40Utilisation de la souris dans un DSPF
C’est la possibilité d’avoir plusieurs messages d’erreur et de pouvoir paginer dessus
Vous pouvez programmer un sous fichier message, mais ca peut être un peu compliqué à réaliser.
Voici une solution simple, il suffit de mettre le mot clé ERRSFL au niveau fichier écran
Ci dessous un exemple avec son programme en CLLE
DSPF
A* Exemple sous fichier d'erreurs
A DSPSIZ(24 80 *DS3)
A ERRSFL
A CA03(03)
A R FMT01
A ZONE1 10A B 11 20
A 41 ERRMSG('Erreur ZONE 1' 41)
A ZONE2 10A B 12 20
A 42 ERRMSG('Erreur ZONE 2' 42)
A ZONE3 10A B 13 20
A 43 ERRMSG('Erreur ZONE 3' 43)
A 6 8'Sous fichier d''erreur'
A DSPATR(HI)
A 11 8'Zone 1 :'
A 12 8'Zone 2 :'
A 13 8'Zone 3 :'
CLLE
/* Exemple sous fichier message d'erreur */
PGM
DCLF ERREUR
dountil &in03
SNDRCVF RCDFMT(FMT01)
IF COND(*NOT &IN03) THEN(DO)
/* activation des indicateurs d'erreur */
CHGVAR &IN41 '1'
CHGVAR &IN42 '1'
CHGVAR &IN43 '1'
enddo
enddo
ENDPGM
Remarque:
La seule limitation, c’est une seule erreur par zone, mais ca suffit dans 90 % des cas
https://www.gaia.fr/wp-content/uploads/2017/02/team3.png600600Pierre-Louis BERTHOIN/wp-content/uploads/2017/05/logogaia.pngPierre-Louis BERTHOIN2023-10-25 09:23:442023-10-25 15:49:20Utiliser un SFL d’erreurs
Administration, Non classé, Open source, SecuritéSe connecter à un serveur SSH exécuté sous Windows à partir d’un IBM i (Comment obtenir la log pour débuguer les problèmes éventuels)
Se connecter à un serveur SSH exécuté sous Windows à partir d’un IBM i (Comment obtenir la log pour débuguer les problèmes éventuels)
Mise en place d’OpenSSH Server sur Windows
Pour mettre en place OpenSSH Server sur Windows, la méthode « standard » consiste à passer par les Paramètres > Applications et fonctionnalités > fonctionnalités facultatives :
Il est recommandé de redémarrer Windows une fois la fonctionnalité ajoutée.
Il suffit ensuite de démarrer le serveur via le gestionnaire de Services Windows :
Il est également souhaitable de configurer le démarrage automatique du serveur :
Remarque
Il est également possible d’installer OpenSSH sur Windows via d’autres sources (GitHub par exemple) ce qui permet, entre autres, de choisir plus facilement sa version d’OpenSSH, voir section Détail.
Création d’un jeu de clefs SSH via ssh-keygen
Pour plus de détails sur la création de clefs, vous pouvez vous référer à l’article de Guillaume Gestion des clefs SSH.
Dans cet article je vais tout réaliser sur l’IBM i via QSH :
$ ssh-keygen -t ecdsa -f ~/.ssh/ssh_key
Mise en place de la clef privée et configuration côté IBM i (client)
On a généré la clef privée dans le répertoire .ssh de l’utilisateur, donc elle est déjà bien en place. Il suffit donc de créer un fichier config dans le répertoire .ssh de l’utilisateur afin de simplifier nos commandes pour la suite. Voici un exemple de fichier config :
[~/.ssh/config]
Host windows
Hostname sshd_server.lan
User jl
IdentityFile ~/.ssh/key
StrictHostKeyChecking accept-new
Host
Nom de la configuration, utilisé à la place des différentes informations à la connexion
Hostname
Adresse ou nom du serveur à atteindre
User
Nom de l’utilisateur
IdentityFile
Chemin vers la clef privée
StrictHostKeyChecking accept-new
Permet d’ajouter automatiquement la signature du serveur distant au known_hosts
Mise en place de la clef privée et configuration côté Windows (serveur)
Il faut transférer la clef ssh_key.pub vers Windows et l’ajouter soit au fichier %UserProfile%.ssh\authorized_keys pour un utilisateur lambda, soit au fichier C:\ProgramData\ssh\administrators_authorized_keys pour un utilisateur ayant des droits d’administrateur local.
Attention à ce niveau, les droits des fichiers sont un peu particulières, il faut comme toujours avec le SSH réduire au maximum les utilisateurs ayant accès au fichier et, particularité de Windows, ajouter le droit de lecture au profil de service local Système :
Activation du fichier de log – Configuration sshd_config
Afin de pouvoir analyser d’éventuels problèmes ou simplement vouloir observer un peu plus en détail les différentes étapes de la mise en relation d’un flux ssh il est possible d’activer la log du serveur.
Par défaut celle-ci est redirigée vers les journaux d’évènements Windows et est seulement en « info ». On les retrouver via l’Observateur d’événements Windows :
Le mieux à mon avis est de repasser par un système plus standard, soit un vrai fichier de logs.
Pour ce faire, il faut aller modifier le fichier de configuration du serveur SSH, généralement il se trouve ici :
C:\ProgramData\ssh\sshd_config
ou
%ProgramData%\ssh\sshd_config
Il faut rechercher les lignes suivantes :
[sshd_config]
# Logging
#SyslogFacility AUTH
#LogLevel INFO
Les décommenter et indiquer les valeurs suivantes :
Une fois la configuration modifiée et le serveur redémarré, il suffit de retenter une connexion puis d’aller consulter le fichier de log :
C:\ProgramData\ssh\logs\sshd.log
ou
%ProgramData%\ssh\logs\sshd.log
Remarque
Les problèmes courants se passent généralement autour des lignes liées au fichier authorized_keys ou administrators_authorized_keys, problèmes de droits ou chemin du fichier utilisé…
Test de SSH IBM i vers Windows
On peut maintenant tester le tout via QSH ou CALL QP2TERM. Grâce au fichier config la commande est simple : (l’option -T permet de désactiver l’allocation d’un pseudo terminal)
$ ssh -T windows
Microsoft Windows [version 10.0.19045.3208]
(c) Microsoft Corporation. Tous droits r
Il est maintenant possible d’exécuter des commandes Shell Windows à partir de cette connexion.
Si on voulait obtenir les mêmes niveaux de log côté client (IBM i) que l’on a activé côté Windows, on pourrait utiliser la commande suivante :
$ ssh -T -vvv windows
OpenSSH_8.0p1, OpenSSL 1.1.1t 7 Feb 2023
debug1: Reading configuration data /home/jl/.ssh/config
debug1: /home/jl/.ssh/config line 1: Applying options for *
debug1: /home/jl/.ssh/config line 4: Applying options for laptop
debug1: Reading configuration data /QOpenSys/QIBM/ProdData/SC1/OpenSSH/etc/ssh_config
...
Microsoft Windows [version 10.0.19045.3208]
(c) Microsoft Corporation. Tous droits r
https://www.gaia.fr/wp-content/uploads/2023/08/Openssh.gif191194Julien/wp-content/uploads/2017/05/logogaia.pngJulien2023-08-02 19:21:092023-08-11 16:00:34Se connecter à un serveur SSH exécuté sous Windows à partir d’un IBM i (Comment obtenir la log pour débuguer les problèmes éventuels)
Cependant pour des raisons d’organisation des traitements, on peut ne pas souhaiter débrancher la commande QSH, en la soumettant, du reste de notre programme. Dans ce cas l’appel à QSH se fait dans le CLLE. Le log SHELL ne se retrouve pas dans les spools du job. On peut néanmoins les récupérer par l’intermédiaire de variable d’environnements.
Les variables d’environnement et l’exécution de script SHELL
Je profite de cet article pour rappeler l’usage de quelques variables d’environnement pour l’exécution d’un script SHELL dans un CLLE. Ce ne sont que des exemples, il y en a beaucoup d’autres de possible !
QIBM_MULTI_THREADED
Cette variable d’environnement est essentielle pour le fonctionnement des scripts SHELL. Il faut être multi-threadé pour que la commande s’exécute. Par exemple, dans l’image ci-dessous, j’ai lancé via la commande SHELL, un script SFTP. En dernière ligne nous trouvons le job lançant la commande shell, et au dessus 3 jobs de type BCI, « Batch immediate jobs », qui sont activés pour l’exécution d’un job multi-threadé.
ADDENVVAR ENVVAR(QIBM_MULTI_THREADED) VALUE(Y)
QIBM_QSH_CMD_ESCAPE_MSG
L’exécution de la commande QSH dans un programme entraine un message QSH0005, QSH0006 ou QSH0007. Le message QSH0005 contient un code statut, allant de 0 à 255. 0 pour une exécution complète, les autres codes pour renvoyer un avertissement ou une erreur.
Par défaut, ces messages sont envoyés avec un type d’achèvement complétion (*COMP), circulez, y’a rien à voir ! Seule une lecture du log du job, pour trouver le statut du message QSH0005, permettra de dire si l’exécution de la commande QSH s’est bien passée.
En ajoutant la variable d’environnement avec la valeur Y, le type d’achèvement dépendra du statut du message QSH0005.
Si le statut est 0 : message en complétion
Autre valeur du statut, message en *ESCAPE. Ca veut dire qu’il faudra monitorer les messages QSH dans votre CL et gérer ces erreurs, sinon votre programme plantera.
Cette variable définit le mode de sortie lors de l’exécution du script SHELL. NONE : exécution du script en mode silencieux STDOUT : affiche le terminal C avec le déroulé du script. En interactif, possibilité de répondre à une question en cours de script. FILE : génération d’un fichier log dans l’IFS. Si le fichier existe déjà, il sera remplacé. FILEAPPEND : génération d’un fichier dans l’IFS en ajout. Le fichier sera créé, s’il n’existe pas.
Attention : Pour les options « File » et « Fileappend », si le chemin IFS n’existe pas ou s’il n’est pas atteignable, problème de droit par exemple, le terminal C s’affichera.
Attention : Entre le « = « et le début du chemin pour le fichier log, il n’y a pas d’espace.
Dans votre programme, vous pouvez générer un nom de fichier log en dynamique, avant de générer votre variable d’environnement. Pour cela, il faudra que votre variable contienne ‘FILE=’ suivi du nom de votre fichier log, et passer la variable dans le paramètre VALUE de la commande.
Récupération du log
La variable d’environnement QIBM_QSH_CMD_ESCAPE_MSG permet de dissocier les fins OK des fins KO de QSH. Mais sans la moindre information sur ce qui s’est passé. Par la récupération du log dans l’IFS, vous pourrez interroger par SQL le fichier et gérer les problèmes. Au moins les cas les plus fréquents, et laisser les cas rares en gestion humaine. La génération d’une log, peut aussi avoir de l’intérêt en cas de création de script en dynamique dans votre programme, pour garder une trace de ce qui a été exécuté… Pensez à la maintenance, et aux recherches en cas d’anomalie…
Prenons un exemple : Un asynchrone qui scrute, via SFTP dans un répertoire réseau, la présence de fichier xml. Télécharger ces fichiers dans l’IFS et laisser un traitement d’intégration dans l’ERP. Ce traitement se lance à intervalle régulier, temporisation de 15 secondes. Il peut ne pas y avoir de fichier à récupérer, répertoire distant vide. C’est un cas classique d’interface asynchrone entre un logiciel externe à l’IBM i et la partie legacy de l’applicatif.
Dans cette exemple, je fais le choix d’effectuer directement un mget /repertoiredistant/*.xml, sans passer par un listing du répertoire suivi d’une lecture de ce listing pour charger fichier par fichier. Je récupère directement tous les fichiers xml présents. Problème, s’il n’y a aucun fichier xml dans le répertoire, le script SFTP renvoie une erreur, via le message QSH0005 qui a un statut 1. Pour moi ce n’est pas une erreur. C’est ce qu’on pourrait appeler un faux positif !
Pour déterminer si le message d’échappement reçu est une « vrai » erreur, ou l’absence de fichier à récupérer, je dois pouvoir récupérer la log.
Via la variable d’environnement, QIBM_QSH_CMD_OUPUT, en ‘FILE=’, je génère mes logs dans l’IFS, sans mode verbose sur le SFTP.
Quand tout se passe bien j’ai le log ci-dessous :
Le fichier contient la liste des commandes passées. Toutes les commandes de mon script se retrouvent dans la log.
Quand le mget ne trouve aucun fichier à ramener, j’ai le log :
À la suite du mget, je reçois un message d’erreur, pour fichier not found. Le script n’est pas allé plus loin, la commande « exit » n’a pas été passée.
Autre exemple, j’ai généré un problème de connexion, voici le log que j’ai reçu :
Aucune commande SFTP n’a été passée, normal, la connexion a été interrompu pendant la phase d’authentification. Ce log n’est bien entendue qu’un exemple parmi beaucoup de problèmes de connexion.
Lecture du fichier par SQL
Je dispose de log dans l’IFS, je peux donc par SQL lire ces fichiers via la fonction table IFS_READ.
Voici ce que ça donne pour les 3 logs :
Le log ne disposant pas de code erreur ou de statut de fin, si je veux exploiter ces fichiers, je dois utiliser des recherches textuelles dans le champ LINE. Ce n’est pas l’ideal, mais faute de mieux…
Je peux par exemple rechercher « exit », pour savoir si mon script est allé au bout :
Je peux au contraire rechercher le problème de connexion interrompue :
Je peux aussi rechercher le « not found » pour détecter la fausse anomalie :
Dans notre programme, suite à l’exécution du script SHELL, plusieurs possibilités :
Avec la variable d’environnement QIBM_QSH_CMD_ESCAPE_MSG, monitorer les messages QSH0000 et donc en cas de problème lire les fichiers log. Dans ce cas la chaîne « exit » n’a pas besoin d’être testée, dans ce cas le message de retour est en complétion.
Sans la variable d’environnement QIBM_QSH_CMD_ESCAPE_MSG. Dans ce cas, je dois lire le log systématiquement et si je trouve « exit » ou « not found », la fin est normale, sinon il y a une erreur.
Les fichiers log, surtout sans mode verbose, comportent très peu de ligne, les SQL utilisés même s’ils sont « gourmands » par l’utilisation de like sur un fichier IFS, restent rapide. Mais attention à ne pas utiliser sur un fichier IFS contenant un log en cumul sur un mois !
L’idée est de gérer en automatique les retours les plus simples qui ne nécessitent pas d’intervention humaine. Encore une fois, ce n’est pas l’idéal, mais si on peut alléger les alertes pour les équipes de maintenance, surtout pour un traitement lancé plusieurs fois par minute, il ne faut pas hésiter.
En cas de récupération des logs dans l’IFS, si vous générez un fichier distinct par appel, n’oubliez pas la base : durée de rétention des fichiers, script d’épuration des log obsolètes. Par SHELL, vous avez les outils pour gérer votre stratégie facilement. Ca évitera un IFS qui enfle. Pour rappel, la volumétrie de données n’est pas la seule responsable des temps de sauvegarde / restauration de l’IFS, le nombre de fichiers aussi. Il vaut mieux un seul fichier de 1 Mo que 1000 fichiers de 1 ko
/wp-content/uploads/2017/05/logogaia.png00Damien Trijasson/wp-content/uploads/2017/05/logogaia.pngDamien Trijasson2023-08-02 16:57:352023-08-21 15:31:15Gestion des logs SHELL dans un CLLE
Il est difficile de déboguer un watcher parce qu’on ne maitrise pas son lancement.
Voici une méthode en utilisant RDI, qui va vous permet de le faire :
Trouver le nom du programme à analyser :
WRKWCH WCH(*ALL) :
5 pour le détail
Dans RDI, clic droit sur le programme à déboguer => débogage ou couverture de code (entrée de service) => définir un point d’entrée de service
Le message d’affiche :
Pour tester, on peut simuler un traitement qui va planter. Dans notre cas, on fait un call d’un programme qui n’existe pas, et donc ça va faire un plantage dans QSYSOPR.
SBMJOB CMD(CALL PGM(GAIA/ERREURA))
JOB(ERREURA)
JOBQ(QSYSNOMAX)
Une fois le programme a été lancé, sur RDI s’affichera le message suivant :
Cliquer sur « Afficher *LISTING »
Pour avancer d’un pas on peut utiliser la touche F5 ou en cliquant sur la flèche :
Pour afficher les valeurs des variables il suffit de passer la souris sur le nom de la variable :
Conclusion : c’est une solution simple pour déboguer un watcher ou un programme dont vous ne maitrisez pas le lancement.
Le programme doit être compilé avec le source.
Vous devrez avoir le droit pour faire ce type d’opération. Soit au niveau de profil, soit par les fonctions usages.
On se demande souvent comment gérer les paramètres de compile sur les PRTF et les DSPF, il existe plusieurs solutions comme créer des CL de compile par exemple, ou utiliser des ALM qui intègrent cette possibilité. Mais comment faire pour que ca marche tout le temps sans avoir à modifier les commandes de compile
Voici une solution qui a été mise au point pour nos clients du centre de service.
On va utiliser le programme d’exit QIBM_QCA_CHG_COMMAND qui, à chaque fois qu’il verra un CRTPRTF l’interceptera.
Pour éviter que cela ne boucle on devra dupliquer la commande CRTPRTF dans une autre bibliothèque et renvoyer sur celle de QSYS quand on aura fait le paramétrage complémentaire.
Cette bibliothèque devra donc être devant QSYS dans la liste des bibliothèques, imaginons que cette bibliothèque s’appelle GDDS.
CHGSYSLIBL LIB(GDDS)
soit DSPLIBL
dans le source de votre PRTF vous allez indiquer des lignes commençant par A*<COMP> et terminées par </COMP>
+ votre mot clé exempleSAVE(*YES) Vous pouvez indiquer plusieurs paramètres sur une seule ligne.
Nous avons 2 programmes que vous pouvez retrouver ici, il vous suffit des les compiler et de les ajouter à la bibliothèque GDDS que vous avez placée en tête de liste
Vous avez donc dans votre bibliothèque 2 programmes et une duplication de la commande CRTPRTF et (du CRTDSPF si vous l’ajoutez)
RTVMBRSRC qui va retrouver à partir de la commande le membre source à compiler GDDS qui prendra la commande et qui lui ajoutera les informations lues dans le fichier source c’est ce programme qu’on devra ajouter au programme d’exit comme ceci : ADDEXITPGM EXITPNT(QIBM_QCA_CHG_COMMAND) FORMAT(CHGC0100) PGMNBR(92) PGM(GDDS/GDDS) TEXT(‘Paramétrage GDDS’) PGMDTA(*JOB 20 ‘CRTPRTF GDDS ‘)
Attention au paramètre PGMDTA, la commande fois faire 10 de long pour que le système la trouve
Vous avez un programme CLLE INITGDDS qui peut vous aider dans le répertoire CLP
==>WRKREGINF QIBM_QCA_CHG_COMMAND puis option 8
Avec cette commande, on prendra en compte désormais les CRTPRTF. A partir de ce moment là, quand vous passerez la commande CRTPRTF, vos paramètres indiqués dans le sources seront ajoutés à la commande.
Par exemple en demandant l’invite sur la commande : CRTPRTF FILE(GDATA/PRTF198) SRCFILE(GDATA/QDDSSRC) SRCMBR(*FILE) Vous aurez vos paramètres
Remarque : Vous pouvez indiquer un programme d’exit pour les DSPF (CRTDSPF), et même si vous avez encore quelque PF (CRTPF), les LF (CRTLF) Bien sûr, tous les mots clés que vous indiquez doivent syntaxiquement être justes et correspondre au type de fichier que vous créez. Cette solution marche en interactif, en batch, par RDI et par Vs Code, dans vos CL de compile etc …
https://www.gaia.fr/wp-content/uploads/2017/02/team3.png600600Pierre-Louis BERTHOIN/wp-content/uploads/2017/05/logogaia.pngPierre-Louis BERTHOIN2023-03-07 05:34:002023-03-07 14:28:16Comment gérer les options de compile des PRTF
