Commande ALTER en cobol

Bonjour, dans ma documentation et sur le net, je ne trouve aucune description de la Commande Cobol ALTER !

Pourriez vous m'éclairer ?

Merci

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 !

Moi, le GO TO il me plaît bien et en trente ans de carrière je n'ai jamais utilisé l'ALTER.

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

Ouuais, ils nous faisaient faire de l'ALTERophélie. :) mais ils ont fait avancer les choses. Et dire que j'ai vu et vécu un peu de ça.

+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'.

Citation:

---

Envoyé par Homer-ac

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

---

J'en ai pas mais si j'en trouve je te la ferais à 0 centime (je dirais plutôt millime).

ALTER est toujours dans la doc technique de tous les nouveaux compilateurs Cobol. A part quelques conseils pour ne pas l'utiliser, nada sur la réentrance.

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 :

Code:

---

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)

---

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).
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.