Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. RPG et CL
  3. Le langage CL et les commandes
Extrait - RPG et CL Maîtrisez la programmation sur AS/400
Extraits du livre
RPG et CL Maîtrisez la programmation sur AS/400
1 avis
Revenir à la page d'achat du livre

Le langage CL et les commandes

Introduction

Il est temps de parler, un peu, de la programmation en général.

Au début des processeurs on ne parlait que l’assembleur, voire le langage machine. L’avantage de ces langages est que les temps de traitement sont extrêmement rapides. L’inconvénient c’est qu’ils sont également extrêmement longs à mettre au point, sans oublier que le langage machine ressemble à quelque chose comme cela : 10 0A F6. On ne parle que l’hexadécimal, chaque code correspond soit à une ou plusieurs instructions du microprocesseur, ou bien à une adresse mémoire et une instruction qui consiste à concaténer deux chaînes de caractères s’écrit en une bonne centaine d’instructions machine.

Le langage C est assez proche de cette façon de programmer, mais comme pour tous les langages évolués, une instruction sera traduite lors de la compilation par des dizaines, voire des centaines, d’instructions machines.

Il existe de nombreux langages structurés, comme le PASCAL, qui évitent au programmeur d’aller chercher aux tréfonds de la machine comment écrire un programme.

La plupart des langages utilisent la même façon de programmer.

Une partie déclarative, qui permet de définir des variables, des constantes, des accès fichier ou écran....

De l’utile à l’indispensable

Le langage de contrôle est très utilisé par l’ingénieur système, mais bon nombre de programmes ont également besoin du CL.

Le passage de paramètres, que ce soit entre un CL et un autre, ou entre un RPG et un CL est toujours assez délicat à réaliser. Il y a, au moment de l’exécution d’un CL, un contrôle du nombre de variables passées d’un programme à un autre, en revanche un programme RPG ne contrôle rien du tout. Il se plantera juste, en parlant d’un pointeur, si on fait une opération quelconque sur un paramètre oublié. D’autre part, et c’est plus subtil car il n’y a aucune erreur système, les variables de type numérique sont difficiles à transmettre entre les programmes étant donné qu’elles peuvent être définies de façon différente, binaire, condensé ou étendu, sans oublier les types horodatage. Il est nettement préférable, pour éviter des erreurs incompréhensibles, de passer tous les paramètres en alphanumérique en laissant aux programmes appelants et appelés le soin de convertir en numérique le moment venu.

Le dernier point est encore plus subtil au niveau des CL. Tant que la variable fait 32 octets au maximum, tout va pour...

Le CL de l’ingénieur système

L’ingénieur système qui connaît bien son AS/400 préférera taper PGMU01 plutôt que GO PGMU01. Cette remarque est également valable s’il doit saisir CALL PGM001CL, puis faire [F4]. L’AS/400 encourage la paresse mais oblige à réfléchir pour éviter tout effort inutile.

L’ingénieur système va donc commencer par écrire des CL pour se faciliter la vie, puis il créera des commandes pour exécuter les CL et enfin il créera un menu personnalisé appelé par une commande afin d’avoir tout sous la main avec un minimum d’efforts.

En fait, ces CL n’appellent pas vraiment de commentaires, ils ne sont là que pour montrer les diverses facettes de l’AS/400, du moins une infime partie.

Et cela permet également de se poser les bonnes questions avant de se lancer dans des développements hasardeux alors que la fonction existe déjà clés en main.

On aurait pu ajouter dans ces CL la commande pour démarrer et arrêter un sous-système, nettoyer périodiquement les spoules et autres.

On se contentera de ces quelques fonctions afin de s’habituer à parler couramment le CL.

1. Envoyer un message

Les commentaires du source permettent normalement de comprendre à quoi sont destinées les diverses...

Le CL du programmeur

Le programmeur, à qui on demande parfois les choses les plus invraisemblables, doit aussi répondre à des besoins précis. Et puis il faut bien de temps en temps se remettre au CL pour ne pas l’oublier.

Le but de ce CL est de recopier le contenu des fichiers d’une bibliothèque dans une autre, par exemple recopier des données de production afin de pouvoir tester les programmes dans un contexte sans risques.

Passons en revue les diverses étapes du CL. Nous utiliserons certaines de ces commandes dans un autre CL, et pour ces parties-là on se reportera au source complet si nécessaire.

La commande DSPOBJD peut être utilisée en interactif pour visualiser la description détaillée d’un objet. Si on ne précise rien, cette opération affichera un écran qui donne la liste des objets contenus dans une bibliothèque. Bien entendu, dans ce cas précis, et comme il est souhaitable que la copie se fasse en BATCH, on choisira l’option fichier ensuite on effectue la substitution puis la lecture du fichier.

0020.00              DSPOBJD    OBJ(&BSRC/*ALL) OBJTYPE(*FILE) +
0021.00                           OUTPUT(*OUTFILE) OUTFILE(QTEMP/FTEMP)
0023.00              OVRDBF     FILE(QADSPOBJ) TOFILE(QTEMP/FTEMP)
0025.00  LECT:       RCVF       RCDFMT(QLIDOBJD)
0027.00              MONMSG     MSGID(CPF0864) EXEC(GOTO CMDLBL(CLOSE))
0029.00              IF         COND(&ODOBAT *NE 'PF') THEN(GOTO CMDLBL(LECT))
0031.00              CLRPFM     FILE(&BDST/&ODOBNM)...

Les CL utilisés dans les programmes

En dehors du routage des impressions qui sera étudié un peu plus loin, les programmes RPG qui seront écrits plus tard ont besoin de certaines fonctions qui sont plus simples à implémenter sous forme de CL. Il suffira ensuite de les appeler lorsque c’est nécessaire dans le programme.

1. Le fichier de travail

Nous n’utiliserons pas ce type de CL car les programmes réalisés sont relativement simples. Mais il y a parfois des cas assez complexes où un fichier de travail permet de s’en sortir sans trop de peine.

Les fichiers destinés à cet usage sont, le plus souvent, stockés dans une bibliothèque qui est commune à tous. Ces fichiers sont, par définition, toujours vides et ne sont utilisés que le temps d’un traitement.

Lire dans le chapitre Trucs, astuces et anecdotes pourquoi je n’aime guère les fichiers de travail.

2. Le CL des messages

Le premier CL utile permet d’envoyer un message à l’utilisateur afin de lui donner des indications sur la bonne ou mauvaise fin de telle ou telle action.

Là encore on utilisera largement la commande MONMSG que l’on aurait d’ailleurs pu positionner en début de programme, car il n’est pas utile quand on envoie un message d’en avoir un autre qui dit que le message a été envoyé.

0011.00...

Le CL et les transmissions

1. Récupérer un fichier sur un serveur FTP

Supposons que l’on veuille vérifier la présence d’un fichier sur un serveur FTP éloigné.

En interactif on tape STRTCPFTP puis [F4] afin de saisir les paramètres nécessaires à la connexion. L’exécution en BATCH est possible également, mais, dans ce cas, on mettra en dur dans le CL tous les paramètres nécessaires. Si cette opération ne se fait que sur un seul serveur avec toujours les mêmes paramètres, il est évident qu’un CL suffira.

Dans le cas où il faut accéder à différents serveurs avec des paramètres différents et un traitement identique, il est plus judicieux de n’écrire qu’un seul CL, dans le cas du FTP la mise au point est assez laborieuse, plutôt que d’en faire un par serveur avec l’obligation de recompiler le CL chaque fois qu’il y a une modification sur le serveur.

La commande STRTCPFTP fonctionne aussi bien en interactif qu’en BATCH. En BATCH il est nécessaire d’utiliser un fichier source pour indiquer à la commande les opérations à effectuer.

/* Substitution du source */
OVRDBF     FILE(INPUT) TOFILE(*LIBL/&FTPIN) MBR(&FTPIN)
/* Substitution du fichier de sortie */
OVRDBF     FILE(OUTPUT) TOFILE(QTEMP/FTPOUT) MBR(FTPOUT)
/* Démarrage...

Le CL et l’édition

Cette partie, même si elle semble relativement simple, doit être parfaitement maîtrisée. C’est le passage obligé de la plupart des éditions. Sur un AS/400 il n’est pas rare qu’il y ait une centaine d’imprimantes connectées, chaque utilisateur appréciera que le document qu’il vient d’éditer s’imprime sur l’imprimante qui est proche de lui. Bien sûr le document peut rester sagement assoupi au fond de son spoule jusqu’à ce qu’il décide de lui affecter l’imprimante qui lui convient en tapant WRKSPLF, en faisant 2 puis [F4] sur le document et voir s’afficher l’écran suivant.

08ep01.png

Il ne reste plus qu’à saisir le nom de la OUTQ (file d’attente en sortie) qui convient.

Si l’utilisateur édite une centaine de pages par jour, la crise de nerfs survient assez rapidement, surtout s’il est à Bordeaux et que ses éditions s’impriment à Lille.

1. Routage vers une imprimante

On pourrait, par facilité, saisir une fois pour toutes dans le fichier PRTF la bonne imprimante (nous verrons plus loin ce que c’est au juste). Mais ce ne serait qu’un palliatif qui, à l’instar des noms de bibliothèque saisis en dur ici ou là n’est pas viable.

La méthode la plus largement utilisée est celle que nous allons décrire maintenant.

Le programme PGMF2SCL est destiné au routage d’un spoule vers une OUTQ, c’est-à-dire une imprimante. Par défaut, l’AS/400, attribue QPRINT comme file d’attente d’impression. Cette file d’attente n’est jamais reliée à une imprimante sous peine de voir des centaines de documents, inutiles le plus souvent, s’imprimer à longueur de temps. Sans compter que les utilisateurs d’un AS/400 étant souvent disséminés aux quatre coins de l’hexagone, voire de l’Europe, il ne serait pas très raisonnable de tout imprimer à un seul endroit.

Pour router convenablement un document sur l’imprimante qui se trouve à proximité de l’utilisateur, on dispose d’un fichier FIO00P qui contient les profils utilisateurs, les noms de document et la OUTQ associée.

Le CL de routage utilise deux méthodes...

Exercice

Une variable de 10 de long contient un point (par exemple MAVAR.001), récupérer dans une autre variable ce qui se trouve avant le point.

Indices :

Créer deux variables de type *DEC, DEC et W1.

Utiliser la commande :

CHGVAR VAR(&P1) VALUE(%SST(&VAR &DEC &W1)

P1 fait un caractère, DE CET W1 sont initialisés à 1.

Normalement cela se termine par un GOTO… ou deux.

La morale du CL.

Quoi que l’on fasse, il y a toujours un moment ou un autre où l’on a besoin du CL. Même si le langage et la façon de programmer semblent antédiluviens, il faudra écrire du CL, et même, et ce n’est pas forcément le plus simple, arriver à comprendre les CL des autres, surtout s’ils refusent de fonctionner correctement.

Et puis il y a la joie de lancer un STRISDB, au moins une fois dans sa vie.