Les annonces de la TR1 de la 7.5 ou TR7 de la 7.4 sont sorties et disponibles ici https://www.ibm.com/support/pages/node/1119129/


• Voici selon nous 5 nouveautés à suivre dans cette Technology Refresh

• 1) La possibilité de faire des mises à jour sur des flux json avec la fonction JSON_UPDATE , ça fait longtemps que nos équipes râlaient, parce qu’elles devaient faire du bricolage quand on travaillait sur du flux json.


• 2) La possibilité d’exécuter des fonctions table remote, par exemple avec le service REMOTE TABLE, un object_statistics sur une partition distante. Ça peut avoir du sens pour automatiser des contrôles de cohérence.


• 3) Les nouvelles fonctions table, SYSTOOLS.AUDIT_JOURNAL_xx qui permettent de traiter les postes d’audit et plus globalement les nouveautés sur les audits comme la disponibilité d’IDS dans Navigator for i qui n’était pas présent dans la nouvelle interface.


• 4) SELF (SQL Error Logging Facility) qui va permettre de mettre au point les traitements SQL en attrapant de manière plus fine les erreurs et en pouvant les suivre dans le temps sans passer par un mode de debug parfois trop bavard en log.


• 5) Les nouveaux services pour administrer Object Connect (vous savez les commandes SAVRSTxxx, CHANGE_OBJECTCONNECT et OBJECTCONNECT_INFO), un petit rappel, Object Connect peut désormais fonctionner en IP. Disponible par PTF et c’est la dernière fonction SNA qui n’avait pas d’équivalent ip. Ces nouveaux services permettront d’administrer et d’avoir des informations sur ce qui s’exécute dans les échanges inter-machines.


• Rendez-vous en décembre pour les premiers tests.

, , Base64 en SQL avec les nouvelles fonctions de QSYS2 !

La 7.4 TR5 (et 7.3 TR11) ont apporté de nouvelles fonctions http dans QSYS2 en remplacement de celles fournies dans SYSTOOLS (cf https://www.volubis.fr/Pausecaf/PAUSECAF88.html).

Dans le même temps, nous avons droit à un refresh des fonctions utilitaires.

Parlons donc de l’encodage/décodage base64 !

Différences entre les fonctions fournies :

Les fonctions n’ont pas le même nom pour éviter toute ambiguïté :

Dans SYSTOOLS : BASE64ENCODE et BASE64DECODE

Dans QSYS2 : BASE64_ENCODE et BASE64_DECODE

L’implémentation des nouvelles fonctions (QSYS2) est basée sur Axis (en C natif), contrairement aux fonctions historiques de SYSTOOLS en Java. L’empreinte mémoire est donc bien meilleure avec les fonctions de QSYS2.

Surtout, les paramètres diffèrent : dans la version SYSTOOLS, la taille des paramètres est très limitée, et nous sommes donc sur du VARCHAR jusqu’à 4Ko maximum encodé. Les nouvelles versions utilisent des CLOB et BLOB jusqu’à 2Go !

Usages

Données caractères

On utilise régulièrement l’encodage base64 pour transmettre une authentification par profil/mot de passe, par exemple une authentification http basic.

Les deux fonctions renvoient bien sur le même résultat :

Si vous utilisez un convertisseur en ligne, vous n’obtenez pas le même résultat :

Par exemple sur https://simplycalc.com/base64-encode.php :

La raison est simple : l’encodage base64 a pour objectif d’exprimer sous forme de caractères une donnée binaire. Le paramètre en entrée des fonctions QSYS2.BASE64_ENCODE et SYSTOOLS.BASE64ENCODE sont donc un BLOB (Binary Large Object) ou un VARCHAR avec CCSID 65535 (signifie pas de conversion).

La chaine de caractères ‘toto’ est donc transmise ici en EBCDIC et c’est la valeur binaire correspondante qui est encodée en base64.

Pour être conforme au standard : convertissez les chaines de caractères en UTF-8 :

Pour décoder des données, on utilise SYSTOOLS.BASE64DECODE et QSYS2.BASE64_DECODE :

Le résultat affiché diffère.

La aussi c’est un effet de bord du changement de type de paramètre, ET de la configuration de ACS :

La fonction de SYSTOOLS étant en VARCHAR, elle est interprétée dans le CCSID du travail. La fonction de QSYS2 renvoyant un BLOB, il n’y a pas de conversion directe possible en caractères.

La valeur binaire renvoyée est bien la même. Si l’on teste en passant par un fichier :

Données binaires

L’objectif premier est tout de même de pouvoir travailler sur des valeurs binaires.

On utilise une image sur l’IFS en tant que donnée binaire à encoder. L’image fait 158Ko, une valeur très raisonnable.

Pour faciliter la démonstration, on travaille étape par étape avec des variables SQL.

Pour lire le fichier image en binaire :

Script de test :

Les résultats semblent concordants :

Mais :

C’est le problème de la longueur des paramètres des fonctions de SYSTOOLS !

Dans l’historique :

On a un SqlCode à 0 mais un SqlState en classe ‘01’ !

On décode notre image :

Les fichiers d’origine et le fichier encodé/décodé sont bien identiques !

Les nouvelles fonctions, au-delà de l’implémentation en C, nous apportent la possibilité d’encoder et décoder des « documents » (image, pdf …à) en base64. Très utile pour faire transiter des informations binaires dans nos web services par exemple !

Et la limite à 2Go semble raisonnable.

, , , , Utiliser ACS pour produire des fichiers Excel depuis l’IBM i

Access Client Solutions (ACS)

Pour rappel, ACS est le successeur de Client Access et permet toujours les exports de données.

ACS est également un produit entièrement Java, et utilisable en mode ligne de commande.

Il est donc possible de le piloter sur l’IBM i. Pour cela il vous faut :

  • Avoir le produit sous licence 5770JV1 (Java) version 8 ou supérieur
  • Access Client Solutions sur l’IFS (désormais installé via PTF (7.4: SI71900 / 7.3: SI71934 / 7.2: SI71935) dans /QIBM/ProdData/Access/ACS/Base

Exemples

Il est alors possible de provoquer le transfert de données de deux façons :

  • le fichier complet
  • une requête SQL permettant la sélection, transformation, jointure …

Syntaxe :

/PLUGIN=cldownload /system=<system>
                          [/userid=<userid>]
                          {/hostfile=<library/filename> | /sql="statement"}
                          {/clientfile=<path><filename>.<extension> | /display}
                          [/<options>]

    /userid     - user id to use when connecting to the target system
    /hostfile   - Source library and file on the IBM i system for the download
                  e.g. /hostfile=QIWS/QCUSTCDT
    /sql        - specify an SQL statement
                  e.g. /sql="select CUSNUM,LSTNAM,INIT,ZIPCOD from QIWS/QCUSTCDT"
    /clientfile - Target file location for the download.
                  The format of this file will be determined by the specified
                  extension (for example, .csv .ods .xlsx .xlsx)
                  If the file extension is not specified or is of a type
                  not supported, the data will be formatted as a .csv file
    /display    - write the output to the terminal
    
    Valid options are:
       /colheadings=<1/0> - Include column headings as the first row. When specified, the column names will be the heading.
       /usecollabels      - Use column labels for the heading.

Puisque ACS est directement sur votre IBM i, on peut utiliser localhost pour la valeur /system. Cela permet également la portabilité de la commande d’une machine à l’autre.

Pour transférer tout un fichier on utilisera le paramètre /hostfile. Ici sous QSH :

cd /QIBM/ProdData/Access/ACS/Base

java -jar acsbundle.jar
/PLUGIN=cldownload /system=localhost
/hostfile=sqlsample/employee
/clientfile=/home/nb/export/employe.xlsx

Cela produit :

Remarquer le nom de l’onglet.

Pour transférer par une requête SQL :

cd /QIBM/ProdData/Access/ACS/Base

java -jar acsbundle.jar
/PLUGIN=cldownload /system=localhost
/sql="select trim(firstnme) concat ' ' concat trim(lastname), hiredate, current date - hiredate as \"Ancienneté\" from sqlsample.employee" /clientfile=/home/nb/export/employesql.xlsx

Attention à l’échappement des caractères spéciaux …

On obtient :

Des options supplémentaires vous permettent d’affiner la sortie :

  • /colheadings=<1/0> – Inclure ou non l’entête
  • /usecollabels – Utiliser les labels au lieu des noms de colonne

Ces fonctions nécessitent une version de ACS > 1.1.8.6 pour fonctionner correctement.

Comment automatiser ?

Il est relativement simple d’intégrer cette commande Java dans un programme CL. Ici en utilisant /clientfile.

Par exemple avec RUNJVA :

Ou par QSH :

Ici on a paramétré plus d’éléments pour avoir une base de programme plus générique.

Avantages ?

Access Client Solutions permet facilement d’automatiser vos conversions depuis l’IBM i, et non depuis un poste client. Cela rend beaucoup plus naturel l’intégration de ces traitements dans vos chaines, la maitrise des transferts par l’IT et non par les utilisateurs, la maitrise des flux, des versions de produits utilisées etc …

, ACS sous Chromebook

Vous nous avez demandé plusieurs fois, si on pouvait installer et faire fonctionner ACS sur un Chromebook.

Donc nous avons fait une RFE chez IBM qui a été refusée .

Nous avons donc décider de faire un test par nous même :

Prérequis avoir un Chromebook à jour avec un processeur x86 en 64 bits

Installer Linux, vous pouvez laisser tout les paramètres par défaut
Après l’installation, lancer l’explorateur de fichier
Aller dans l’onglet ‘Linux fichiers’
Vous devez y extraire le fichier ZIP d’ACS
Vous devez maintenant installer Java
Par exemple ‘sudo apt install openjdk-11-jre’
Aller dans Linux_Application (‘cd Linux_Application’)
Exécuter la commande : ‘./install_acs_64’
Suivre le processus classique de setup (sélectionner les options nécessaires)
Une fois l’installation terminée, quitter le terminal
Chercher IBM dans les applications
Si il est présent, tout est bon
Sinon redémarrer le ChromeBook

Ca peux paraitre compliqué comme ca, mais c’est relativement simple en réalité et ça prend moins d’une heure.

Nous avons donc testé pendant une demi-journée le travail sur ce terminal.

Voici ce qu’on a constaté


Le lancement est un peu long
Pas de touche Fx sur le clavier vous devrez les mettre en incrusté dans votre session
Pas de clic droit
Des comportements d’affichage assez particuliers en cas de perte de focus.


Ma ca reste tout à fait utilisable.

Conclusion :


Ca fonctionne et sur un poste pour une utilisation occasionnelle c’est tout à fait acceptable

Merci à Clément pour ces tests.

, , 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 des 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 expressions (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 la 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ées 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 contrôle de validation.

Que se 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 se 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 là, mais il est à l’état partiel.

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

La plus part du temps ce n’est pas grave, mais si vouliez invalider des modifications en appliquant 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, de détacher le récepteur 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 trouvé 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 est 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. SPLUNK est aussi une solution très connue.

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

Pour échanger avec votre concentrateur, vous devrez 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 erreurs de login 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 heure

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 intéressant si par exemple vous utilisez des logiciels 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 CCSID819 et avoir *LF comme délimiteur.
Dans ce fichier vous indiquerez votre fichier de sortie.
Vous démarrez 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 cet ajustement automatique la différence étant un ajustement à 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 ajustés.
Vous devez faire le ménage sur les récepteurs de journaux que vous créez.
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é est le bon par la commande suivante :

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é 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 œuvre .

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)  

/*Substitution 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 Substitution  */

DLTOVR FILE(QATADOF)

Cette méthode est un peu plus lourde, à utiliser plutôt 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 simplifié au maximum

En résumé :

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

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 une 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