, , Débogage de grandes variables avec RDi

Le débogage avec RDi apporte confort et souplesse, mais il y a un point sur lequel il faut certainement faire un rappel : le débogage de grandes chaines de caractères.

Notre exemple

Simplissime :

Débogage avec RDi

Les variables et leur valeur apparaissent dans la vue dédiée « Variable »

Par contre, « seuls » 10.000 caractères sont affichés, impossible de voir la suite de la variable. De plus, impossible de modifier la variable :

La vue Moniteurs

Cette vue, qui sert déjà pour les variables des programmes CL, va également nous aider pour les variables RPG en permettant plus d’options. Il est possible d’utiliser dans cette vue toutes les syntaxes usuelles de STRDBG avec la commande EV (ou EVAL) qui supporte de compléments, des fonctions intégrées etc …

Vous pouvez ajouter une expression monitorée en faisant un click droit sur une variable puis « Contrôler une expression »

Vous pouvez également saisir manuellement des expression (vous reconnaîtrez les syntaxes du STRDBG) :

Vous pouvez alors utiliser %SUBSTR, DIGITS etc … Pour vous permettre de cibler une sous-chaîne spécifique par exemple.

Mais impossible de modifier une sous-chaîne par ce moyen :

Modification de variables

Vous devez utiliser cette syntaxe :

Attention : les chaines de caractères sont passées en majuscule ! Sauf à travailler en hexadécimal (est-ce réellement pratique ?)

Extension via APAR SE71579

L’APAR https://www.ibm.com/support/pages/apar/SE71579 permet d’augmenter les limites. Désormais :

Extend the string length limits to bigger values for            
fixed-length and variable-length string values in RDi debug.    
Maximum editable limit is now 4K (4096). Maximum display limit  
is now 30K (30720). The limits are 1K (1024) in the current    
driver.

Vous devez installer les PTF SI71302 (7.3) ou SI71314 (7.4). Après application on peut voir jusqu’à 30720 caractères dans notre cas :

La modification reste limitée à 4Ko.

, Client FTPS avec la nouvelle interface DCM

Pas encore habitué à la nouvelle interface de DCM ? Les options sont rangées différemment, voici donc un guide pour activer le FTPS client !

Informations nécessaires

Lorsque vous avez besoin d’initier une connexion FTP vers un serveur sécurisé par un certificat SSL, vous n’avez pas besoin d’importer le certificat serveur, mais de vous assurer de disposer des autorités de certification (CA) correspondantes.

Par exemple, pour le serveur jupiter.gaia.fr, voici le certificat lié au service FTP :

Ce certificat a été émis par une autorité Let’s Encrypt Authority X3, elle-même issue d’une autorité DST Root CA X3. Ce sont ces deux autorités de certification dont il faut disposer.

Connexion à DCM

La nouvelle interface est disponible ici : http://monIBMi:2006/dcm

Connectez-vous avec un profil fort :

Ouvrez le magasin *SYSTEM :

L’ensemble des certificats vous est proposé, nous allons filtrer pour n’afficher que les autorités de certifications :

Seuls les CA sont affichées désormais. En naviguant / cherchant, on retrouve nos 2 certificats racines :

Les options de recherches / tri :

Importation d’une autorité

Si un ou plusieurs CA racine ne sont pas trouvés, vous devez les importer. Pour cela, transférer le certificat sur l’IFS (via FTP, netserver etc …).

Définir les CA pour FTPS

Il ne reste maintenant plus qu’à indiquer au client FTP le ou les autorités de certification auxquelles faire confiance : tous les certificats serveurs issus de ces autorités seront autorisés.

Allez sur l’option « Manage Application Definition » :

Filtrer puis sélectionner FTP Client :

Par défaut, si aucun CA n’est indiqué, FTP fait confiance à l’ensemble des CA connu dans le magasin *SYSTEM. Sinon, uniquement aux CA indiqués :

Sélectionner les CA nécessaires puis Define :

Test

Renseigner profil et mot de passe lorsque demandé : la connexion est sécurisée, vos données et les commandes FTP seront cryptées lors de l’échange.

, , RSTLIB ou RSTOBJ et APYJRNCHG

Vous connaissez tous la journalisation base de donnés sur l’IBM i, qui permet d’avoir les images avant et après
de vos modifications base de données avec la possibilité de valider (APYJRNCHG) ou de les invalider par RMVJRNCHG

  • Je ne parle pas ici du controle de validation.

Que ce passe t’il quand on restaure une bibliothèque suite à un sinistre ou sur autre système pour des tests par exemple ?

Par défaut quand vous sauvegardez un récepteur attaché vous avez ce message

CPF7080 Récepteur RCV de TSTJRN1 sauvegardé alors qu’il était attaché

Que ce passe t’il quand on restaure la bibliothèque qui contient le récepteur et le journal ?

Le système créée un nouveau récepteur qu’il attache au journal , votre ancien récepteur est la, mais il est à l’état partiel.

Les recepteurs à l’état partiel ne sont pas utlisables, vous pouvez voir ce qu’il y a dedans en indiquant la plage de récepteur sur la commande DSPJRN, mais pas les utiliser.

La plus part du temps ce n’est pas grave, mais si vouliez invalider des modifications en applicant un filtre c’est impossible.

Vous devez lire les données et les reporter à la main.

La solution est, avant de sauvegarder votre bibliothèque, il faut détacher le recepteur en cours.

==>CHGJRN JRN(votrebib/votreJRN) JRNRCV(*GEN)

A la restauration vous aurez 3 récepteurs
1 sauvegardé
1 partiel
1 attaché

Vous avez toujours le récepteur partiel qui est inutilisable, mais il n’a plus de modification de données à l’intérieur

Si vous choisissez d’invalider une partie des transactions en attente, vous pouvez utiliser le récepteur sauvegardé

RMVJRNCHG JRN(votrebib/votreJRN)
FILE((votrebib/*ALL))
RCVRNG(votrebib/RCVsauvegardé votrebib/RCVsauvegardé)

vous aurez un message de ce type

x postes retirés pour x objets.
Certains postes n’ont pas été appliqués ou retirés pour au moins un
objet.

Le deuxième message indique que votre demande a trouver des postes autres que R ( modifications de données)

Conclusion :

Il peut être intéressant de détacher vos récepteurs avant de faire vos opérations de savlib au moins pour vos bibliothèques importantes, on ne sait jamais !

Il peut être intéressant de regarder, si vous avez des récepteurs à l’état partiel, ça peut révéler un vrai problème

J’ai des outils sur GITHUB qui traitent des journaux

https://github.com/Plberthoin/PLB/tree/master/GJOURN

, Utiliser SYSLOG sur IBMi

Les nouvelles organisations informatiques imposent parfois la mise en place d’un Siem.

Chez IBM on vous proposera QRADAR, PLUNK est aussi une solution très

connue.

https://fr.wikipedia.org/wiki/Security_information_management_system

Pour échanger avec votre concentrateur, vous devrer utiliser un format spécifique qui se nomme SYSLOG.

https://fr.wikipedia.org/wiki/Syslog

Comment produire du format syslog sur L’IBMi?

Il y a principalement 3 manières d’en produire.

SQL as a service à prévu des passerelles pour produire ces fichiers.

1) Sur les sorties d’audit journal QAUDJRN

Exemple :

SELECT
SYSLOG_EVENT ,
SYSLOG_FACILITY ,
SYSLOG_SEVERITY ,
SYSLOG_PRIORITY
FROM TABLE(QSYS2.DISPLAY_JOURNAL(‘QSYS’, ‘QAUDJRN’,
STARTING_RECEIVER_NAME => ‘*CURCHAIN’,
JOURNAL_ENTRY_TYPES => ‘PW’,
STARTING_TIMESTAMP => CURRENT TIMESTAMP -24 HOURS,
GENERATE_SYSLOG => ‘RFC5424’
)) AS X

Cette requête produira une liste des erreur de mot de passe sur les dernières 24 heures

2) sur la log du système

SELECT
SYSLOG_EVENT ,
SYSLOG_FACILITY ,
SYSLOG_SEVERITY ,
SYSLOG_PRIORITY
FROM TABLE(QSYS2.HISTORY_LOG_INFO(
START_TIME=> NOW() – 1 HOURS,
GENERATE_SYSLOG => ‘RFC3164’
)) AS X

cette requête extrait la liste des commandes du dsplog sur 1 heures

La fonction table ne prévoit pas de filtre vous serez surement obliger de rajouter une clause WHERE pour par exemple, choisir des messages.

Il y a 2 formats de sortie :

https://tools.ietf.org/html/rfc3164

https://tools.ietf.org/html/RFC5424

3) en utilisant SYSLOG

Syslog n’est pas qu’un formatage de données c’est aussi un logiciel unix de remontée d’alerte.
Ca peut être interessant si par exemple vous utilisez des logiciel open source sur votre partition.

https://fr.wikipedia.org/wiki/Syslog

l’installation est très classique :

Vous avez un executable qui se trouve ici, /QOpenSys/usr/sbin/syslogd.
Vous devrez avoir un fichier de conf ici,
/QOpenSys/etc/syslog.conf
Ce fichier doit être en ccsid 819 et avoir *LF comme délimiteur.
Dans ce fichier vous indiquerez votre fichier de sortie.
Vous démarrer SYSLOG
SBMJOB CMD( CALL QP2SHELL PARM(‘/QOpenSys/usr/sbin/syslogd’) ) JOB(SYSLOGD)

Par convention on l’appelle SYSLOGD du nom du deamon UNIX.
Si vous n’avez pas de sous système dédié à ce type d’opération mettez le dans la jobq QSYSNOMAX , il tournera alors dans le sous système QSYSWRK.

Une fois que vous avez produit vos fichiers, il suffira de les envoyer en CSV par exemple à votre concentrateur SIEM.

vous devrez faire attention au ccsid à produire

Le logs peuvent prendre beaucoup de place , n’oubliez pas de les extraire pour les consolider et de faire le ménage.

Une fréquence journalière peut être adaptée à ce type de traitement.

Il existe des solutions plus ou moins packagées, que vous pouvez trouver chez des éditeurs.

, , Comment suivre l’évolution des pools mémoire ?

Rappel


Les pools partagés sont des espaces mémoire dans lequel les sous systèmes place des travaux.
*MACHINE Utilisé par les fonctions internes du pool machine
liste des pools
*BASE Pool système par défaut
*INTERACT Travail interactif
*SPOOL Impression
*SHRPOOL1 à *SHRPOOL60 pools spécifiques
et sur ces pools il y a 2 valeurs importantes à ajuster, la taille et le niveau d’activité.

Ajustement

Il existe une valeur système pour ajuster automatiquement ces pools
La valeur systéme QPFRADJ à 2 ou à 3 permet de mettre en place cette ajustement automatique la différence étant un ajustementant à l’IPL avec la valeur 2.
Ce mécanisme fonctionne très bien …
l’ajustement par défaut est fait toutes les 60 secondes ce qui la plupart temps convient bien.
Si vous voulez ajuster ce temps vous pouvez créer une dtaara :
CRTDTAARA DTAARA(QUSRSYS/QPFRADJWT) TYPE(*DEC) LEN(3 0) VALUE(60) vous pouvez indiquer une valeur en seconde de 20 à 120.

Mais on a aucune visibilité sur l’ajustement sur une période données , exemple mon pool de base une journée.

Voici comment on peut faire :


il faut créer un récepteur de journal, il peut être dans une bibliothèque privée, et vous pouvez choisir son nom
CRTJRNRCV JRNRCV(QUSRSYS/QPFRADJ)
il faut créer le journal QPFRADJ qui pointe sur votre récepteur
CRTJRN JRN(QSYS/QPFRADJ) JRNRCV(QUSRSYS/QPFRADJ)
Il vous faut un fichier pour faire votre analyse le fichier qui contient la structure est QAWCTPJE
CRTDUPOBJ OBJ(QAWCTPJE) FROMLIB(QSYS) OBJTYPE(FILE) TOLIB(votrebib) NEWOBJ(QPFRADJ) récupérer les informations du journal DSPJRN JRN(QSYS/QPFRADJ) ENTTYP(TP) OUTPUT(OUTFILE) OUTFILE(votrebib/votrefic)
Créer un fichier à exporter.
create table qtemp/analyse as(
SELECT TPTIME as heure , TPCSIZ as taille
FROM votrebib/votrefic WHERE
TPPNAM = ‘*BASE ‘ and tpdate = ‘070320’
) with data
dans notre cas le pool de base, le 7 mars 2020
vous devez ensuite exporter ce fichier pour faire un diagramme, par exemple sous excel .

Remarque :

il ne faut pas utiliser des pools privés qui ne seront pas ajuster.
Vous devez faire le ménage sur les récepteurs de journaux que vous créer.
Et règle fondamentale, si on fait de l’ajustement, on fait une mesure avant et une mesure après sur des périodes significatives

, , Comment retrouver le label de bande ?

Vous voulez connaitre le label qui est actuellement monté sur une unité de bande !

Rappel

Pourquoi c’est très important de gérer les noms de labels ?


D’abord pour des questions d’organisation c’est mieux d’avoir LUNDI, MARDI, MERCRE etc.. ou HEBDO1 , MOIS1 que XXXXX1.
Mais l’autre raison est qu’en faisant correspondre le volume à une bande physique? on peut avoir des statistiques, qui peuvent par exemple vous indiquer qu’une bande est altérée !
C’est en utilisant la commande PRTERRLOG ou par SST que vous pouvez avoir ces informations

exemple dans un scripte SQL

cl:PRTERRLOG TYPE(VOLSTAT) OUTPUT(OUTFILE)
OUTFILE(QTEMP/ERRLOG)
VOLTYPE(3580) — a trouver sur l’unité
VOLSTATTYP(*SESSION) ;

SELECT SPHMSR, SPSNAM, SPLDAT, SPLTIM, substr(SPKVID, 1, 6) as vol ,
SPVOPR, SPVOPW, SPVOTR, SPVOTW FROM qtemp/ERRLOG

Vous pouvez tester pour savoir si le volume montée est le bon
par la commande

CHKTAP DEV(nomdevice) VOL(nomvolume)
monmsg (CPF6720 CPF6772)

CPF6720 Volume &2 incorrect sur unité &1.
CPF6772 Le volume chargé sur l’unité &1 ne peut pas être traité.

Mais vous ne connaissez pas le volume qui est monté à cet instant

Voici 3 méthodes pour connaitre le volume montée sur une bande

La première méthode, consiste à lire le message envoyé par le chktap

         CHKTAP     DEV(&DEV)                                 
         RCVMSG     MSGTYPE(*COMP) RMV(*YES) MSGDTA(&MSGDTA) +
                      MSGID(&MSGID) 
if cond(&msgid = 'CPC6778') then(do)                              
               chgvar &vol %sst(&msgdta 11 6)  
 enddo                           

C’est la plus simple des méthodes à mettre à en oeuvre .

La deuxième méthode, consiste à lire la sortie d’une dsptap

/* declaration du fichier système pour la compile / 
dclf qsys/QATADOF 
/ génération du fichier avec un enreg  /
 DSPTAP DEV(&dev )            + 
        SEQNBR(FIRST ONLY)  + 
        OUTPUT(OUTFILE)      + 
OUTFILE(QTEMP/WATADOF)
/*Subtitution pour lire le fichier généré */
OVRDBF FILE(QATADOF) +
TOFILE(QTEMP/WATADOF) +
LVLCHK(NO) / lecture du fichier / RCVF / traitement des informations / chgvar &vol %sst(&RDVOLL 5 6) /Arret de la Subtitution */
DLTOVR FILE(QATADOF)

Cette méthode est un peu plus lourde, a utiliser plutot si on veut d’autres informations, voir description du fichier qsys/QATADOF

Le DSPTAP peut être également utilisé, pour connaitre le contenu d’une bande , pour effectuer des recherches

La Troisième solution c’est par l’api QTARTLBL

/* déclarations nécessaires l’appel de QTARTLBL */

         DCL        VAR(&RCV) TYPE(*CHAR) LEN(220)              
         DCL        VAR(&RCVLEN) TYPE(*CHAR) LEN(4) +           
                      VALUE(X'000000DC')                        
         DCL        VAR(&FORMAT) TYPE(*CHAR) LEN(8) +           
                      VALUE('RLBL0100')                         
         DCL        VAR(&DEV) TYPE(*CHAR) LEN(10)               
         DCL        VAR(&REQQUAL) TYPE(*CHAR) LEN(44) +         
                      VALUE('      *ALL             *FIRST    + 
                      *ONLY     0')                             
         DCL        VAR(&REQQUALLEN) TYPE(*CHAR) LEN(4) +       
                      VALUE(X'0000002C')                        
         DCL        VAR(&ERR) TYPE(*CHAR) LEN(256)              
/* appel de l'api QTARTLBL /
CALL       PGM(QTARTLBL) PARM(&RCV &RCVLEN &FORMAT +
             &DEV    &REQQUAL &REQQUALLEN &ERR)
/ lecture du volume ou en cas d'erreur envoi du message CPFXXXX */
if cond(%sst(&err 09 7) *eq ' ') then(do)
chgvar &vol %sst(&rcv 29 6)
SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Le +
volume sur l''unité, ' *BCAT &DEV *BCAT +
'est' BCAT &VOL) MSGTYPE(COMP)
return
enddo
else do
SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Erreur +
sur l''unité, ' *BCAT &DEV *BCAT 'MSGID:' +
BCAT %SST(&ERR 09 7)) MSGTYPE(COMP)
chgvar &vol 'ERREUR'
return
enddo

C’est une bonne méthode, mais elle peut être un plus compliquée à mettre en oeuvre dans mon cas j’ai simplifier au maximum

En résumé :

Voila, vous savez maintenant lire le nom du volume montée sur votre bande, après il faut prendre la decision en cas de volume érronée.

La règle restant « il vaut mieux une sauvegarde sur le mauvais volume, que pas de sauvegarde du tout !

La deuxième règle, c’est un bande qui comporte des erreurs doit être automatiquement retirée des bandes actives.

Si vous avez des structures plus grosses vous utiliseriez BRMS qui vous simplifiera votre gestion

La version 1.1.8.3 d’Access Client Solutions apporte une fonctionnalité attendue : complétion SQL !

L’outil cherche pour vous les noms des tables et des colonnes :

  • Gain de temps
  • Plus de faute de frappe (en tout cas sur les noms des tables et colonnes)
  • Pas besoin de connaitre tout votre modèle de donnée par cœur

Regardez notre courte vidéo pour vous faire une idée !

Vous êtes nombreux à nous solliciter sur une difficulté récurrente liée au débogage : comment déboguer un programme pour lequel le source n’est pas sur la machine, et qui n’a pas été compilé avec la vue *LISTING

Pour RPG : CRTBNDRPG/CRTRPGMOD … DBGVIEW(*ALL ou *LISTING)

Pour rappel :

  • DBGVIEW(*SOURCE) : le source n’est pas inclus dans l’objet compilé, i lest recherché sur le système lors du débogage
  • DBGVIEW(*LISTING) : le source est inclus dans l’objet compilé. Si le membre source est présent lors du débogage, il est affiché, sinon c’est le source inclus dans l’objet compilé qui est affiché

Il est évidemment bien plus pratique d’indiquer DBGVIEW(*ALL ou *LISTING) pour permettre le débogage.

Vous distribuez vos objets programmes et ne souhaitez pas que vos clients puissent accéder au source ? Il est possible de crypter le source embarqué : lors du débogage, vous devez saisir la clé correspondante pour afficher le source !

Pour changer de vue source (équivalent F15 dans STRDBG), clique droit dans le source, changer la vue …

 

Revenons maintenant à notre cas : vous compilez avec DBGVIEW(*SOURCE) et vous envoyez vos programmes sur un autre système (production, recette/UAT …). Lorsque vous souhaitez déboguer vos programmes en production, impossible d’avoir le source, et donc de faire quoi que ce soit d’intelligent !

Vous pouvez bien sur envoyer le source ….

 

Mais RDi vous permet de déboguer un programme sur une machine de production, tout en accédant au source sur la machine de développement, voir sur votre machine Windows (Linux/Max pour ceux qui souhaitent) !

 

C’est assez simple :

–          Dans RDi, assurez-vous de disposer d’une connexion RSE au système de production et d’une autre connexion au système de développement

–          Evidemment, vous devez savoir où (bibliothèque, fichier …) se trouve le source

Lancez le débogage sur votre machine de production. L’écran suivant s’affiche, le membre source étant introuvable sur ce système :

Cliquez sur « Editer le chemin de recherche des fichiers source … », puis sur « Ajouter… » :

Puis « Fichier source IBM i » :

Sélectionner la connexion RSE correspondant à la machine de développement, puis dérouler les bibliothèques pour sélectionner la bibliothèque/fichier source correspondant, puis OK :

Le source s’affiche, vous pouvez déboguer normalement !

 

La technique peut s’appliquer également si lors de votre process de développement les membres source sont déplacés d’une bibliothèque (développement/version) à une autre (référentiel).

 

Vous avez le source sous forme de fichier texte sur votre machine ? Pas de soucis, vous pouvez également l’indiquer :

 

On peut alors déboguer :

 

Limitations :

–          Impossible d’indiquer le nom du membre source : ne fonctionne pas avec les renommages

–          les includes/copy, coloration, etc …

, Mise en place d’un PRA ?

Quand on discute avec les clients on se rend compte qu’il y a une grande confusion entre haute disponibilité est PRA, PCA etc …

Prenons la définition de WIKIPEDIA .

Un plan de reprise d’activité (PRA) est un ensemble de procédures (techniques, organisationnelles, sécurité) qui permet à une entreprise de prévoir par anticipation, les mécanismes pour reconstruire et remettre en route un système d’information en cas de sinistre important ou d’incident critique.

En gros pour moi c’est le temps dont on a besoin suite à gros un crash pour rendre un service acceptable à la production.

Comment faire le point dans votre entreprise ?

il y a une technique assez simple c’est de se dire voila, on est planté maintenant qu’est ce qui ce passe ?

1) Il va vous falloir Reconstruire une machine.

il va falloir vous pencher sur les contrats de maintenance de votre partenaire matériel . Ne pas hésiter à ce faire confirmer les choses.
La vrai durée qui doit vous intéresser c’est combien de temps pour avoir une machine opérationnelle.

une prise en compte de l’incident au 1/4 heure s’il ne se passe rien derrière ne sert à rien !

2) Reconstruire le contexte opérationnel

On limitera ici à la restauration complète de la machine.

Ça veut dire ou sont la ou les bandes :

A) du système (on parle de savsys)

pour restaurer l’os, les configurations, les utilisateurs.
première remarque, tout ce qui a évolué sur votre système dans le lapse de temps est perdu (nouveau profils , changement de mot de passe)

la bonne fréquence , si on le peut sauvegarde complète tous les soirs, ça simplifie les opérations de reprise
sinon 1 fois par semaine est un bon compromis, une fois par mois est un minimum.
mais attention sachez précisément ou est cette bande, quand vous la chercherez le compteur tournera.

B) des données

Les bibliothèques
Les dossiers partagés (à remplacer au plus vite)
Le reste de l’ifs

Pour avoir une idée de vos temps de restauration compter vos temps de sauvegarde que vous multipliez par environ 1,5.

1 client sur trois ne saurait pas remonter sont système sans perte d’informations, 9 clients sur 10 sauvegardent bien leurs bibliothèques de données mais néglige le reste.

Une fois votre système n’oubliez pas de ré-appliquer les droit privés !

3) Conclusion

Vous devez pouvoir répondre à votre directeur combien de temps prendrait un crash du système

reconstruction de la machine    xx heures
reconstruction du système         xx heures
refresh des dernières données  xx heures

exemple :

36 heures
1 heures
3 heures

Ne négligez pas les temps de prise de décision, que vous ne rattraperez jamais.

Vous pouvez mettre en place des choses simples , pour pouvoir travailler à minima en cas de problèmes.

Par exemple , j’avais un client qui descendait tous les soirs les commandes à préparer le lendemain dans csv sur un PC de L’entrepôt

Vous devez également vérifier que vos sauvegardes sont lisibles …

 

Vous ne pourrez pas dire je ne savais pas !

, Mettre en place une alerte qui vous avertisse en cas de dépassement de seuil limite de votre ASP.

Voici comment être alerté en cas de disques pleins , en mettant en place une solution simple

Vous avez une valeur limite système qui s’appelle QSTGLOWLMT qui indique la valeur minimum qui doit rester et qui est exprimée en % souvent 15 % ou 10 %.

Vous avez une deuxième valeur système QSTGLOWACN qui indique l’action à effectuer quand vous aurez dépassé ce seuil
par défaut *MSG enverra un message dans QSYSOPR
Vous pouvez changer cette valeur en *REGFAC cette notion veut dire déclenche le programme associé au programme d’exit QIBM_QWC_QSTGLOWACN

le programme que vous devez lancer ne reçoit pas de paramètre

 

ADDEXITPGM EXITPNT(QIBM_QWC_QSTGLOWACN)
FORMAT(STGL0100)
PGMNBR(1)
PGM(MABIB/MONPGM)

exemple de programme :

PGM

/* MONPGM */
SNDSMTPEMM RCP((‘admin@votresociété.fr’)) +

SUBJECT(‘Limite espace disque’) +

NOTE(‘Attention vous avez dépassé le seuil de mémoire requise’)

ENDPGM

Bien sur il faut que votre partition soit relais de messagerie .

Attention, si vous utilisez le mail, QPGMR devra avoir le droit d’en emettre, utilisez la commande ADDSMTPLE.

Vous pouvez faire un programme beaucoup plus évolué, même en RPGLE,  si vous le désirez .

Attention :

La petite subtilité est donc au redémarrage :

Quand on démarre le système (IPL) ou qu’on lance le qstruppgm ou qu’on démarre le sous système qctl avec moins de la valeur  QSTGLOWLMT, Il ne peut pas soumettre le Programme d’exit et le système reste en restreint un peu comme la valeur *ENDSYS qui mettrait directement le sous système en restreint. et pour redémarrer vous devrez faire du ménage ….