Réécriture de l'assembleur IBM + COBOL en C ++

Je travaille comme agent / gestionnaire de location pour une entreprise de location de voitures qui fonctionne sur un système de location qui a été écrit en 1972. J'ai décidé qu'il était peut-être temps de faire une mise à jour. Pour un peu de contexte, voici un bref exemple de la folie que nous devons affronter quotidiennement avec ce programme:

Un agent de location doit se rappeler que l'impression sur un écran utilise "MXC" dans le champ ACT (tout est basé sur des codes courts), ce qui signifie perplexe pour "affichage MaXimum sur un contrat", tandis que sur un autre, il nécessite PR (pour PRint) dans le champ ACTION, mais plusieurs écrans utilisent un Y dans le champ PT (pour PrinT), encore un autre écran utilise Y dans le champ PRT (pour PRinT), un autre écran oblige l'utilisateur à appuyer sur Entrée (mais pas sur l'entrée à côté de la lettres, car il s'agit d'un nouveau caractère de ligne, ce doit être l'entrée sur le pavé numérique) puis F8, un écran différent mais lié nécessite simplement F8, certains écrans ont un champ étiqueté PRT, qui devrait être pour PRinT, mais le champ en fait ne fait rien et l'impression se fait automatiquement après avoir parcouru plusieurs invites, et encore plus d'écrans ont un champ intitulé IMPRIMER O / N,qui par défaut est insensé à Y pour les opérations dans lesquelles un autre emplacement fournit déjà des documents et à N pour les opérations dans lesquelles un autre concessionnaire aura besoin de documents.

J'ai décidé que je pouvais faire un meilleur travail que cela, alors j'ai décidé de contacter la personne dans l'entreprise qui prendrait la décision de mettre à jour cela. Je parviens finalement au VP de l'informatique, qui est en charge de ce programme. Je reçois un peu d'informations de lui et j'apprends que mon entreprise de location de voitures a son programme de location écrit dans l'assembleur d'IBM IBM avec un peu de COBOL mélangé. Il dit qu'il n'y a pas de postes ouverts en ce moment, mais que je devrais envoyez-lui mon curriculum vitae de toute façon (au cas où quelque chose s'ouvre).

Cela m'amène à mes questions.

Le premier est technique. Avec l'idée d'améliorer la maintenabilité à l'avenir, ma pensée est de la réécrire dans un langage de niveau supérieur au langage d'assemblage. Mon domaine d'expérience est en C ++, c'est donc le choix évident pour moi. La société a un besoin urgent d'un moyen plus facile de mettre à jour le programme, car j'ai récemment lu un article dans lequel l'homme à qui j'ai parlé aurait déclaré que l'équipe avait travaillé dur, et ils sont fiers d'annoncer que le programme prend désormais en charge 5 - codes de localisation à chiffres (au lieu de 4) et numéros de voiture à 8 chiffres (au lieu de 7). Ma philosophie sur les mises à jour, même dans des situations aussi dramatiques, est conforme à celle de Joel: http://www.joelonsoftware.com/articles/fog0000000069.html en bref, les réécritures devraient être incrémentielles, plutôt que de jeter tout ce qu'il y avait avant et recommencer à zéro.

Existe-t-il un moyen simple d'intégrer IBM Assembly à C ++, et si oui, comment dois-je procéder? Je connais vaguement le mot-clé asm, mais je ne sais pas s'il est préférable de l'utiliser ou de faire autre chose. Un tel plan est-il mal avisé? Je fais la plupart de mon travail sur Linux en utilisant g ++ et GNU make, donc les réponses spécifiques à cela sont les bienvenues, mais certainement pas requises (car je n'ai aucune idée de quel type de système de construction ils n'ont pas, mais je soupçonne presque aucun).

La deuxième question est plus politique. Comment dois-je faire pour persuader cette entreprise qu'elle doit faire le changement? Les économies théoriques sont énormes (sur la base de mes estimations, la société gaspille un million de dollars supplémentaires par an, juste sur l'augmentation des coûts de formation pour apprendre à interagir avec le programme), mais les changements que je propose mettraient probablement tous les les programmeurs actuels sans emploi, s'ils sont adoptés, il y a donc une grande résistance structurelle au changement.

edit: je devrais expliquer pourquoi ma modification de ce que l'entreprise a déjà semble être la meilleure solution pour moi. Je suis toujours ouvert à d'autres suggestions, car il s'agit cependant d'un monstre de programme. Je n'ai jamais eu de travail de programmation auparavant, alors corrigez-moi toute analyse incorrecte que je pourrais donner.

Tout d'abord, il y a la solution standard.

D'après mes entretiens avec quelques gestionnaires de niveau intermédiaire à propos de ce genre de chose, l'une des principales préoccupations liées au passage à un nouveau système est le grand nombre d'employés fidèles qui travaillent dans l'entreprise depuis des décennies et qui sont à l'aise avec le système à l'heure actuelle. . Si j'ai la possibilité de modifier ce que nous avons, je pourrais maintenir l'interface actuelle dans une sorte de «mode de compatibilité». Les utilisateurs doivent déjà se connecter pour utiliser le système actuel, donc je pourrais ajouter la possibilité d'activer un paramètre lorsque les utilisateurs se connectent pour la première fois (après avoir effectué cette modification), où ils ont la possibilité d'utiliser soit le interface «classique» ou «nouvelle» interface. Il n'y a aucun moyen que je trouve une solution standard qui permet cela,

Mon entreprise possède également les logiciels que nous utilisons; nous ne l'autorisons pas. Cela signifie que la direction à laquelle je parle actuellement sont les mêmes personnes qui pourraient en fait m'autoriser à effectuer un changement. Avec une solution tierce, je devrais obtenir l'approbation de mon entreprise en plus d'obtenir tous les droits nécessaires de la société qui a développé le produit que nous utilisons, ce qui ajoute un obstacle supplémentaire. Cela nécessiterait également de convaincre la société de renoncer à «son» produit et de prendre un autre produit, ce qui semble être un obstacle plus important que d'essayer de mettre à jour ce que nous avons, mais je peux très bien me tromper sur cette question.

Enfin, en regardant vers l'avenir, je ne veux pas seulement améliorer l'interface utilisateur et corriger quelques bugs. Après avoir mis à jour ces problèmes «urgents», j'espérais mettre à jour le fonctionnement fondamental de l'entreprise en ce qui concerne la technologie. Après avoir passé un à deux ans sur ce genre de problèmes, mon plan était de revenir à la direction et de proposer des changements plus spectaculaires. Il existe de nombreuses façons dont l'entreprise fonctionne qui pourraient être fondamentalement améliorées par une technologie qu'elle n'utilise tout simplement pas en ce moment. Par exemple, chaque région fonctionne à peu près de la même manière. L'aéroport principal local est la plaque tournante centrale pour la distribution des voitures. Ils sont principalement envoyés au besoin. Cependant, l'aéroport est utilisé comme base d'attache pour toutes les opérations. Ils enverront deux personnes dans une voiture chez moi pour récupérer une voiture dont nous n'avons pas besoin, puis retournez à l'aéroport avec la voiture dans laquelle ils sont arrivés, plus ce qu'ils ramènent (nous sommes à 32 miles de l'aéroport). Ensuite, ils viendront à l'emplacement à 5 miles de nous dans deux voitures pour déposer l'un d'eux, puis retourneront dans leur autre voiture à l'aéroport. Ils le font même si la voiture que nous avons renvoyée est le même type de voiture dont ils ont besoin près de chez nous. Cela fait maintenant environ deux ans que je travaille dans l'entreprise, et il me semble qu'ils s'en écartent dans les situations d'urgence les plus extrêmes de la pénurie de voitures (donc environ trois fois). Je remplacerais les 4 personnes travaillant dans chaque région par un système de planification automatisé qui détermine quelles voitures vont où et j'essaie de trouver le chemin qui nécessite le moins de temps + miles + conducteurs pour livrer toutes les voitures là où elles doivent être, en tant que exemple des correctifs de niveau supérieur que j'espère ajouter un jour.

Cependant, avant de me sentir à l'aise de proposer tout cela, je pense qu'il serait utile de se familiariser avec l'entreprise et la base de code en effectuant des tâches plus petites, comme la mise à jour de l'interface. Des solutions comme l'externalisation ou autre supprimeraient cette possibilité.

Je me cantonne au front technique ...

Je vous suggère de commencer par déterminer l'environnement dans lequel l'application s'exécute. "Mainframe" peut signifier plusieurs choses différentes, étant donné l'âge de l'application, il peut s'agir de CICS ou IMS . Il est également possible que les auteurs originaux aient écrit leur propre tâche commencée.

Selon l'endroit où l'application s'exécute, elle utilisera probablement des API pour cet environnement, CICS utilise maintenant une interface nettement différente de ses débuts, je ne peux pas parler pour IMS. Si l'application est sa propre tâche démarrée, elle peut très bien avoir sa propre API interne - j'ai passé environ sept ans à soutenir une telle bête, écrite à la même époque.

Autre chose à considérer, étant donné l'âge de l'application, c'est que l'assembleur avec lequel vous souhaitez intégrer C ++ est antérieur à l'existence de Language Environment (LE). En tant que tel, à moins que l'assembleur n'ait été mis à jour pour être conforme à LE, vous aurez quelques difficultés car C et C ++ sont conformes à LE et exigeront que leurs appelants et leurs callees soient également conformes.

Un autre point à considérer, si cette application s'exécute sur un ordinateur central moribond, vous envisagez peut-être d'intégrer une application qui s'exécute sur du matériel et des logiciels non pris en charge. Ce ne serait pas différent d'essayer de l'intégrer avec une application écrite en 1989 qui fonctionne sous DOS 4.01 sur son matériel d'origine.

Vous sautez l'arme. D'après votre description, il semble que vous n'ayez pas entièrement compris l'environnement technique actuel (quel système d'exploitation exactement, où et comment sont stockées les données, existe-t-il des interfaces avec d'autres systèmes, etc.). Mais encore plus important: un plan sérieux devrait envisager des alternatives à une réécriture interne partielle ou complète du logiciel, à savoir un logiciel standard, une externalisation de la réécriture, un logiciel en tant que service, etc.

Quelle que soit la façon dont l'entreprise va finalement, elle a d'abord besoin d'une analyse solide de ce que fait le logiciel aujourd'hui et des exigences de la nouvelle solution.

Alors pourquoi ne proposez-vous pas de faire cette analyse?

Je suis surpris que vous ayez eu une réponse aussi polie!

Regardons cela de leur point de vue.

Ils ont réussi à gérer un système vieux de trente ans avec probablement des centaines de milliers de lignes de code, des interfaces avec peut-être vingt autres systèmes qui incarnent un processus métier qui a évolué sur quarante ans.

Ils sont probablement / espérons-le des experts dans leur domaine et, en tant que tels, considéreraient le C ++ comme un pas en avant du "langage de haut niveau de l'assembleur" d'IBM pour lui donner son titre complet. Le langage assembleur d'IBM est extrêmement puissant et le langage "MACRO" est la meilleure implémentation d'un langage de prétraitement / modèle.

Il aura été proposé de remplacer leur système tous les cinq ans environ depuis sa mise en œuvre. Certains auraient été rejetés après une étude de faisabilité, certains auraient atteint la phase de conception avant de perdre leur budget, certains auraient même pu entrer dans le code et peut-être en phase de test avant de rencontrer des problèmes de performances et de se mettre en conserve.

C ++ n'aiderait tout simplement pas. Il n'y a pas de bibliothèque graphique dans l'environnement où l'application s'exécute. (Il existe une bibliothèque graphique 3270, mais il est peu probable qu'elle soit prise en charge en C ++ car personne ne l'utilise et il existe une bibliothèque cliente "X" complète, mais vous devez être dans un environnement différent pour l'utiliser.)

Ils ont une interface utilisateur loin d'être parfaite mais bien connue et rapide. Un opérateur expérimenté remplira un formulaire environ trois fois plus rapidement en utilisant un écran vert plutôt qu'une interface graphique équivalente. De plus, ils peuvent prêter attention au client lorsqu'ils touchent le type.

Les opérateurs d'écran auront besoin de formation quelle que soit l'interface qu'ils utilisent, recycler tous les employés pour utiliser une nouvelle interface graphique inconnue serait un poste budgétaire énorme par rapport à la simple formation des nouveaux employés sur l'ancien système mondain.

J'ai eu un problème similaire il y a quelques années chez BellSouth. J'ai simplement écrit du code COBOL pour analyser les programmes de langage assembleur octet par octet, séparer les opcodes et opérandes, convertir les instructions de branchement en tos et convertir les instructions de comparaison en IF. Ce programme a converti les instructions DC en code COBOL Data Division équivalent et converti les mouvements, zaps, etc., selon le cas.

Une fois cela fait, j'ai écrit un deuxième programme pour convertir les IF et les GOTO en IF-THEN, avec des mouvements et autres dans les lignes entre ces clusters (ce n'était pas vraiment si difficile à faire - le secret est d'insérer les IF et ELSE pendant que vous relisez le cobol "pidgin" de la première phase de l'arrière vers l'avant).

IF-THEN-ELSER a recherché des situations où il a trouvé une référence GOTO à proximité d'une étiquette, qui pourrait être supprimée en toute sécurité (décrémentant son nombre de références de 1). Vous exécutez ce programme IF-THEN-ELSER de manière itérative (c'est-à-dire que vous l'exécutez encore et encore, en vous arrêtant uniquement lorsque votre dernier passage ne peut pas trouver un moyen d'apporter d'autres modifications). La plupart du travail critique est effectué par ce si-alors-elser, dont le produit COBOL doit être soigneusement examiné et vérifié par un programmeur expérimenté et compétent en langage assembleur (à savoir, moi). D'après mon expérience, mon "if-then-elser" a pu éliminer plus de 90% des GO TO résultant des instructions de branchement d'origine.

Je suppose qu'il est possible d'aller de l'avant à partir de ce point avec une conversion simple en C (ou C ++) - langages avec lesquels je suis également familier. Cependant, chez BellSouth, notre langue cible de choix était COBOL / II. Il y a toujours un peu de complexité qui découle des situations où une étiquette restante a plusieurs références GO TO (plusieurs fois, ces situations sont gérées par COBOL PERFORMs, mais peuvent parfois être simplement représentées par des constructions OR et AND).

Je pense qu'il est agréable de produire du code en COBOL / II élégamment structuré en blocs, avec EVALUATEs (constructions de cas) et 88 noms de condition de niveau. L'ajout de ces touches finales a conduit à une autre paire de programmes, qui s'est avérée pratique pour les programmes COBOL ne provenant pas de programmes convertis à partir de l'assembleur.

Je ne sais pas si cela aide.

Comme d'autres l'ont indiqué ci-dessus, vous devez mener ce processus avec soin. Il est utile d'avoir 10 à 12 ans d'expérience en codage d'assembleur pour éclairer vos processus de prise de décision. Nous qui avons cette expérience sont difficiles à trouver.

Pour terminer: nous n'avions écrit dans l'assembleur à l'époque que parce que les compilateurs pour les langages de haut niveau produisaient un code objet lourd et inefficace. Les compilateurs COBOL «optimisants» d'aujourd'hui n'ont pas les mêmes mauvaises habitudes. ----------

Les conseils de Joel sont généralement judicieux, mais dans ce cas, une réécriture complète est attendue. Idéalement, une réécriture avec une hampe de bataille, car ce que vous traitez ici est un monstre.

Je ne sais pas exactement quoi ajouter, car vous avez déjà fait un très bon argument pour cette réécriture vous-même. Ma seule recommandation serait de sauter complètement C ++ et d'aller directement à une interface Web pour le système de location, car cela sera probablement encore plus facile pour former les travailleurs et vous fera économiser beaucoup de travail sur l'interface utilisateur (ainsi que faire il est beaucoup plus facile d'obtenir du sang neuf dans le projet, ou même d'externaliser le tout).

Quant aux programmeurs COBOL existants, ils peuvent peut-être aider à documenter le système existant et au processus de migration.

Quant à l'aspect technique, beaucoup dépendra de la qualité - la modularité - du code assembleur. Certains programmeurs ont compris l'importance de créer des modules avec une fonction spécifique et limitée et une interface paramétrée claire et simple, en utilisant les conventions de liaison de sous-programme IBM standard. Cependant, la grande majorité a eu tendance à créer des monstruosités monolithiques.

Avec le premier, la réutilisation est possible, et il ne devrait pas être si difficile de trouver la «colle» entre C ++ et l'assembleur, en supposant que vos modules d'assembleur utilisent des séquences d'appel standard (ou au moins cohérentes). Selon toute vraisemblance, cependant, le code assembleur sera un gâchis. Bien qu'il ait été possible d'écrire un assembleur structuré, très peu de personnes l'ont fait, et il sera presque impossible de discerner un "design" à partir duquel commencer la réécriture.

D'un autre côté, l'assembleur 360/370 est assez haut niveau par rapport aux microprocesseurs d'aujourd'hui, et beaucoup plus simple, et C est parfois considéré comme "assembleur de haut niveau". J'ai travaillé pour une société de SGBD dont le produit était entièrement 370 assembleur, et notre architecte principal pensait qu'il pourrait être possible de traduire automatiquement le code assembleur en C (pour une future portabilité). Je suis sceptique, mais le fait est que la distance n'est pas aussi grande qu'on pourrait le penser.

Je ne sais pas si tout cela est utile. Comme je l'ai dit, je pense que cela dépend fortement de la qualité et de la taille du code d'origine.

Je ne peux pas dire si c'est une blague ou non - votre entreprise exécute sérieusement du code écrit il y a 39 ans? S'il fonctionne sur un système / 360, vous devrez compiler g ++ à partir des sources ...

Honnêtement, je ne penserais même pas à utiliser l'ancien code; vous devez adopter une nouvelle approche, vous asseoir et réfléchir à ce qui doit entrer dans la conception, et le faire à partir de zéro. Oui, cela impliquera un peu de planification, mais je ne pense pas que même Joel dirait que c'est un cas pour des changements progressifs.

En ce qui concerne la persuasion de la société que vous devez changer, vous devez indiquer des raisons spécifiques qui amélioreront l'efficacité, entraîneront une baisse des coûts et / ou montreront que ce que vous utilisez maintenant nuit actuellement au résultat net.

Un autre commentaire - j'imagine que d'autres sociétés de location de voitures ont rejoint le reste d'entre nous au 21e siècle; Je ferais un peu de reconnaissance pour voir comment ils le font (sur le Web, j'imagine), et éventuellement le modéliser d'après l'un de ces systèmes (c'est-à-dire, ne pas réinventer la roue).

Bonne chance!

En théorie, il ne devrait pas être difficile de convaincre la haute direction de remplacer l'ancien système si vous pouvez leur montrer que cela leur fera économiser des mégabucks. Et ce sera le cas. Il deviendra de plus en plus difficile de trouver des programmeurs pour maintenir ce système, et ces programmeurs deviendront de plus en plus chers. Ce n'est pas une question de «si», c'est une question de «quand». Il faut vraiment le mettre à jour.

Cependant, la question est de savoir si vous pouvez les convaincre non seulement qu'il a besoin d'une mise à jour (et ils le savent probablement de toute façon), mais que ce devrait être un projet interne. Surtout si l'équipe n'est que vous. Très souvent, un tel remplacement majeur est externalisé. Il peut même y avoir des logiciels disponibles sur le marché pour examen. Ces options doivent être étudiées et vos gestionnaires insisteront pour que cela se produise s'ils sont raisonnables.

Quant à la tâche, si vous deviez le faire, je pense en fait qu'une réécriture au bulldozer peut être appropriée dans ce cas. L'argument de Joel ne s'applique pas dans tous les cas. Mais je ne pouvais pas vraiment savoir sans le voir.

1. Un changement progressif est hors de question.

2. Il est probable qu'une solution standard soit disponible. Il existe de nombreuses entreprises de location de voitures.

3. Si, en dernier recours, vous avez besoin de le réécrire, passez d'abord un peu de temps à réfléchir au fonctionnement du nouveau système.
   Après avoir identifié les fonctionnalités et les interfaces, vous pouvez alors choisir les outils de développement qui correspondent le mieux aux besoins (et à vos compétences).

Une stratégie pour minimiser le stress pour les utilisateurs finaux consiste à commencer à émuler l'ancienne interface laide que les utilisateurs connaissent, avec quelques subtilités comme des listes déroulantes pour les mnémoniques laides, puis à ajouter progressivement des fonctionnalités d'interface utilisateur et à les sevrer dans une interface utilisateur moderne.

Vous ne voudrez probablement pas conserver le même format de fichier de données, il n'y aura donc pas de retour possible une fois qu'ils auront changé.