Há mesmo COBOL. in.NET?
[[1]}"Net Express é um ambiente de desenvolvimentoCOBOL para estender os processos de Negócio de base ao Framework.NET e outras plataformas distribuídas."Claro que segui o linke encontrei uma empresa que faz isto, mas ainda há lugares a usar o COBOL? Alguém usa mesmo o COBOL em. Net? frameworks?
editar: Obrigado a todos pela informação abaixo, eu definitivamente aprendi algo hoje!
6 answers
Micro Focus Crie um conjunto de desenvolvimento COBOL que tenha como objectivo essencial a manutenção das aplicações legacy mainframe. Ele fala algo como 20 dialetos de COBOL de várias plataformas e tem uma facilidade de emulação . A partir de 2004, recomendam-no para substituir as cargas de trabalho do mainframe até 400 MIPS mais ou menos. Tendo em mente que você ainda pode comprar sistemas mainframe classificados em 22 MIPS da Amdahl no início dos anos 90 400 MIPS em um mainframe é bastante uma carga de trabalho substancial.
Integrar o legado COBOL back-end nas front-end modernas é um grande negócio. Há uma substancial ecossistema de terminal emulação software, screen scrapers, a interface bibliotecas e RPC wrappers para vários protocolos, tais como CORBA e SABÃO.Há alguns anos, a Micro Focus trouxe um compilador COBOL.net que lhe permite executar aplicações COBOL num back-end CLR. Você pode compilar qualquer um dos dialetos suportados e irá executar todas as funções de emulação legadas. Isto permite - lhe colocar uma interface gráfica ou Web (ou uma camada de serviços web) numa aplicação COBOL existente, preservando o seu investimento na base de códigos existente. O front-end pode ser escrito com praticamente qualquer ferramenta de desenvolvimento que suporta o CLR. Você quer usar formulários C# / Windows, MS Workflow Foundation, SSIS, IronPython, ASP.NET ou integração CLR do servidor SQL com o seu COBOL back - end-knock saia.
Como tal, muitas vezes é uma alternativa muito atraente para uma reescrita completa e migração de uma aplicação legada. Este tipo de trabalho representa um pouco do seu negócio, mas ainda há nichos onde a COBOL faz um bom trabalho por si só. Para muitas tarefas em lote grandes abrir um arquivo orientado a registros e processá-lo de forma processual é um bom paradigma para obter uma aplicação que é simples, compreensível e rápido. Uma vez li um postando (no Slashdot IIRC) onde alguém estava falando sobre uma aplicação COBOL que lia em um arquivo 35GB de reembolso de cartão de crédito e processava-o a cada hora. Isso foi postado há muito tempo, em algum momento da década de 1990-em um momento em que 35GB era consideravelmente maior do que a capacidade de disco da maioria dos PCs. Obter um RDMBS para carga a granel e processar 35GB de dados (100-200 milhões de registros em um palpite) em uma hora não é necessariamente um trabalho trivial, mesmo em hardware moderno. Frequentemente, obter o desempenho do SQL requer que você tome uma abordagem um pouco oblíqua para o processamento, o que pode obscurecer o significado do código; SQL altamente sintonizado pode ser completamente 'escrever apenas.'A COBOL tem sido usada neste tipo de aplicação há cerca de 50 anos e é uma tecnologia madura, bem compreendida e fiável que realmente faz muito bem.
Pense nisto como uma locomotiva :-). No século XIX, todos costumavam viajar de trem porque era tudo o que tínhamos, mas para a maioria, isso foi substituído por carros e aviões. Para mover grandes quantidades de carga pesada ao redor, embora o sistema ferroviário ainda é o caminho a percorrer. Não se vêem muitas locomotivas no dia-a-dia, mas mantêm as centrais a funcionar com carvão.
É perceptível que Lisp ainda tem uma posição similar na IA. codificacao. O que eu acho interessante é que o outro membro do grupo das três línguas 'grandes' dos anos 60/70 - Fortran - diminuiu mais do que os outros, o que não é o que eu teria esperado na época. No entanto, ainda temos o básico de uma maneira grande, que é efetivamente o filho bastardo de Fortran, de modo que, sem dúvida, todos os três estão tão vivos e chutando como sempre.Rob, há umLote de lugares ainda fazendo COBOL embora não necessariamente para.NET; ainda fazemos um pouco de desenvolvimento mainframe e a grande maioria das aplicações financeiras ainda estão escritas em COBOL interfacing com CIC.
Além disso, você ainda pode obter Compiladores COBOL (por exemplo, Fujitsu) para as plataformas Windows.
Penso que o cenário mais comum é a interoperabilidade, por exemplo, O Windows e o Windows. ASP.NET aplicações que falam com aplicações COBOL / CIC e vice-versa.
Estive envolvido num projecto deste tipo há alguns anos para um grande banco no meu país, e imagino que seja bastante comum para qualquer banco que tenha mais de 40 anos de existência.O Artigo da Wikipédia surpreendeu-me:
Os programas COBOL são usados globalmente em agências governamentais e militares, em empresas comerciais, e em sistemas operacionais como o z/OS da IBM, O Windows da Microsoft e o POSIX famílias (Unix / Linux, etc.). Em 1997, o Grupo Gartner informou que 80% dos o negócio do mundo correu em COBOL com mais de 200 mil milhões de linhas de código em existência e com uma estimativa de 5 mil milhões de linhas de novo código anualmente.
Http://en.wikipedia.org/wiki/COBOL
Pensei que Cobol fosse madeira. Não é verdade. A propósito, a Fujitsu NetCOBOL for. net e A Micro Focus Net Express® com. net são implementações bastante abrangentes. Talvez devêssemos estudar esta língua e encontrar um bom emprego com um grande salário depois? :)