Bonjour, dans ma documentation et sur le net, je ne trouve aucune description de la Commande Cobol ALTER !
Pourriez vous m'éclairer ?
Merci
Bonjour, dans ma documentation et sur le net, je ne trouve aucune description de la Commande Cobol ALTER !
Pourriez vous m'éclairer ?
Merci
« Ne me faites pas d'objections.
Les difficultés en feront assez d'elles-mêmes. »
sir Winston Churchill
Bonjour.
ALTER est la plus déconseillée des instructions Cobol.
Extrait de mon cours Cobol :
ALTER
Change le point de transfert d’un GO TO.
Proc1.
GO (TO) xxxx (la seule instruction)
Trait.
.../...
ALTER proc1 TO (PROCEED TO) proc2.
Avant le ALTER proc1 est exécutée normalement (branchement à xxxx), après le ALTER proc2 est exécutée à la place de xxxx à chaque fois que le contrôle passe par proc1.
Merci pour cette réponse, Effectivement, le GO TO étant déjà pas mal indigeste, l'ALTER en rajoute une belle couche d'incompréhension algorithmique !!!
Je vais faire avec !
« Ne me faites pas d'objections.
Les difficultés en feront assez d'elles-mêmes. »
sir Winston Churchill
Trouvé dans "COBOL Reference Manual" d'IBM (Mainframe) :
ALTER statement
"The ALTER statement encourages the use of unstructured programming practices; the EVALUATE statement provides the same function as the ALTER statement and helps to ensure that your program will be well-structured."
Cette instruction COBOL, héritée des temps anciens de l'informatique, a ceci d'original que c'est une instruction qui modifie une autre instruction !
Elle est bien sûr à bannir dans le cadre d'une bonne pratique de programmation et peut même poser des problèmes dans un contexte de multiprogrammation (conflit avec la réentrance notamment).
Effecitvement, ça fait peur. Sur du code qui a 25 ans d'âge et qui est déjà illisible(mon quotidien), ça serait le pompon.
Ils avaient des idées bizarres, les pionniers.....
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
+1.
L'instruction Alter Cobol est l'héritage de la technique d'aiguillage des premières générations de programmeurs assembleurs et est absolument à banir.
Se rappeler que l'apport essentiel de COBOL II sur COBOL 1 porte sur la structuration des programmes et leur réentrance. ALTER c'est le contraire de ces concepts. Avec les premières versions COBOL II IBM, les docs de migration COBOL II prévenaient qu'ALTER était appelé à disparaître. Curieusement ce n'a pas été le cas. C'est plus qu'étonnant et je cherche encore la justification d'une instruction qui semble injustifiable. Alors si quelqu'un peut avoir une idée de cette raison, je suis acheteur.
Effectivement au mieux un evaluate, au pire un go to depending on (je n'aime pas beaucoup plus) simplifierait bien la vie de quelqu'un qui serait confronté à un plantage dans un programme 'altérique'.
Quelques souvenirs (séquence émotion) :
Les premiers programmes étaient écrits en Assembleur. On travaillait à l'époque dans les années 70 avec des brouettes et donc avec des fourches !
Dans les années 70, vu la puissances des premiers 'mainframe' chaque instruction était choisie pour gagner du temps CPU. On codait donc en Assembleur des trucs comme ceci :
Vous avez dits réentrance structurée ? La seule justification de ceci était de limiter les tests pour gagner du temps machine (très cher).
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 DEBUT NOP TRAITEMENT OI DEBUT+1,X'FO' -> aiguillage de première fois, on va en séquence puis à TRAITEMENT les coups suivants (OI = ou inclusif) ou encore : XI TRAIT1+1,X'F0' TRAIT1 B TRAIT2 -> aiguillage dit de flip/flop. en séquence après TRAIT1 la première fois, pris Branch à TRAIT2, puis TRAIT1 etc... (XI = ou exclusif)
A décharge, il faut dire que la réentrance n'existait pas, les méthodes de structuration non plus, quant aux problèmes de maintenance, il n'y en avait pas encore tellement puisqu'il s'agissait des premiers programmes !
Puis est venu COBOL et des instructions transposées équivalentes.
Bon c'est un héritage révolu d'un temps ou parce que l'on travaillait avec des cartes perforées 'paquettées élastiquement', on reconnaissait un informaticien confirmé à sa dextérité au tir à l'élastique !
On peut donc encore code ALTER, mais merci de le faire sur cartes perforées.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager