Dans quelle langue voulez-vous ports programmes COBOL et pourquoi?

Question

Lors de la sélection d'une langue à des programmes COBOL ports de langue choisiriez-vous et pourquoi? Je ne cherche pas la réponse « parce que je suis familier avec le langage X ».

Je cherche des fonctionnalités dans une langue qui cartographient bien à la conception de COBOL.

Mise à jour:. Les programmes courraient le gammit aux services publics, de traitement des données, écrans, etc

Answer 1

Je les port ... euh ... COBOL. Oui c'est ça. COBOL.

Désolé, n'a pas pu résister.

Sérieusement, il y a des compilateurs COBOL pour les plates-formes actuelles là-bas et, à moins que nous en savons un peu plus sur pourquoi le code a pour être portés, nous ne pouvons pas être en mesure d'aider.

La plate-forme sur laquelle il court obsolète? La direction est juste pousser pour une solution plus « moderne »? Devez-vous passer des choses de System z vers Windows (ugh!)?

COBOL (dans sa forme la plus pure, pas que les déchets OO-COBOL) est le plus souvent d'un simple langage procédural (ReportWriter nonobstant) se traduira donc à l'un des autres languges procédure assez bien:

• C.
• C ++ sans les classes
• Java, bien que vous ne pouvez pas éviter les classes, sauf si vous avez un grand honkin' singleton.
• Pascal (échange d'une langue 'morte' pour une autre).
• même Python, Perl et al peut être fait pour travailler.

Answer 2

Eh bien, vous devriez considérer quels apports des programmes COBOL obtiennent habituellement.

COBOL a été conçu pour traiter de grandes quantités de texte formaté à largeur fixe comme entrée, à la sortie de la même manière. Cela ressemble plus à un processus ETL pour moi que toute autre chose.

Alors je ne voudrais pas les programmes COBOL portuaires simplement une autre de langue; J'avais le port à des technologies ETL appropriées telles que SQL Server Integration Services (SSIS) ou au moins ses predeccesor DTS - Data Transformation Services SQL. SSIS implique l'utilisation VB.NET (au moins dans SQL Server 2005), mais cela ne devrait pas être un problème.

Answer 3

Je ne sais pas grand-chose COBOL, mais je ne pense pas qu'il y ait un langage courant qui est un droit de celui-ci surensemble (donc, il est difficile de cartographier directement COBOL à la langue). Je vois plusieurs problèmes:

1. Prise en charge intégrée pour l'arithmétique décimale -. Ce qui exclut toute langue moderne sans surcharge d'opérateur

2. Un meilleur soutien pour les dossiers structurés -. On pourrait utiliser combo struct / union comme en C, mais je pense que ce serait des identifiants très long parfois (au moins pour les programmes que j'ai vu)

3. GOTO -. Sans elle, il faudrait analyser complètement la logique du programme lors de la réécriture, il

Il peut y avoir d'autres fonctions qui ne sont pas faciles à la carte.

Answer 4

J'exécuter personnellement cette décision fondée sur la conception destinée, plutôt que sa mise en œuvre actuelle du programme. Si vous voulez un port ligne pour ligne droite dehors, cependant, je dirais probablement c / c ++.

Answer 5

Peut-être au lieu de regarder immédiatement à une nouvelle langue que vous pourriez envisager une partie de votre transition code dans un cadre contemporain comme .Net - vous trouverez peut-être qu'une bonne solution intermediatery, jusqu'à ce que vous êtes prêt à aller tout le porc.

Il y a quelques compilateurs Cobol pour .NET disponibles tels que Fujitsu NetCOBOL .

Answer 6

Une fois, je participais le portage des choses COBOL à C (1989 environ.) Le COBOL en question était code pour surveiller les systèmes d'alarme, les alarmes d'incendie, etc. Il était le genre de programme qui est adapté à un plus en temps réel type d'environnement. Sondage ces appareils de terrain client gazillion tant de fois par minute, etc. Vous cherchez « pour les fonctions dans une langue qui cartographient bien à la conception de COBOL » ne tient pas compte du fait qu'il ya beaucoup de programmes COBOL là-bas qui ne tiennent pas la conception de COBOL.

Answer 7

Je garderais le cœur COBOL, mais développer autour des bords.

Microfocus fournissent un outil appelé Enterprise Server qui permet COBOL d'interagir avec les services Web.

Si vous avez un programme COBOL A et un autre programme COBOL B et A B appels via la section d'interface, l'outil vous permet d'exposer la section d'interface de B en tant que service Web.

Pour le programme A, est alors créé un proxy client et A peut maintenant appeler B via un service Web.

Bien sûr, parce que B a maintenant un service Web tout autre type de programme (ligne de commande, application Windows, Java, ASP, etc.) peuvent désormais appeler aussi.

En outre, ils ont un produit appelé COBOL.NET qui fonctionne dans Visual Studio et se traduit par COBOL à MSIL. Cela signifie que vous pouvez relier à tous les composants .NET.

Ainsi, l'approche est de garder le noyau de COBOL, mais l'interface via des services web et faire de nouveaux développements dans toutes les langues compatible CLR (C #, VB, etc.)

Answer 8

• Je dois dire que vous ne devriez pas COBOL port.
  • Si vous voulez dire Ressaisissez , alors oui, choisissez une langue. Je suggère une interface web, java ou .Net, réécrire dans.
  • Si le code doit exécuter exactement comme il fonctionne maintenant, toute conversion "portage" ne fera que faire du mal.
• Si vous devez modifier les plates-formes pour une raison quelconque, vous pouvez utiliser COBOL sur une autre plate-forme.
• Qu'est-ce qui a le mieux dans mon expérience est d'essayer de séparer les composants ou les services de l'autre, et soit la conversion de petits morceaux d'écriture individuellement ou tout nouveau code dans une langue préférée, en gardant le COBOL en cours d'exécution dans le back-end.

Answer 9

D'abord on a comme pourquoi COBOL doit être portée? COBOL est un moment puissant honoré la langue qui a très probablement encore plus de lignes de code en cours d'exécution paie, la comptabilité, etc. dans la production que toute autre langue.

Le port de moins douloureux serait Synergy DBL. Ceci est une mise à jour de style VM très portable de DIBOL (langue Business Oriented numérique).

http://www.synergex.com/synergy-dbl/

DIBOL utilisé tous les bons morceaux de BASIC, FORTRAN et COBOL en laissant de côté la plupart des mauvaises.

Si vous suivant le lien ci-dessus, vous verrez qu'ils ont une interface graphique, .NET et d'autres outils d'amélioration. Juste être certain qu'il est une machine virtuelle pour tout système d'exploitation cible que vous exécuterez sur.

IBM Mainframe COBOL faisant un usage intensif de CICS, TCAM, IDMS, etc. sera un port vraiment difficile à rien d'autre.

OpenVMS COBOL fait usage de DECForms ou peut-être même FMS sera un port difficile sans un paquet de manipulation de l'écran. Très vieux COBOL de ces magasins utilisera copieuses des services système et exécuter des programmes de bibliothèque de temps fournis par le système d'exploitation qui ne seront pas disponibles sur la plupart des autres plates-formes. Vous devrez également lire sur Logicals et comprendre comment mettre en œuvre quelque chose un peu-sorta-gros assez sur votre cible.

Ce que vous trouverez la plupart mainframe et COBOL milieu de gamme est que vous n'êtes pas migrez juste COBOL. Il y aura des tonnes de services système qui fait usage de COBOL plus.