COBOL -COBOL

COBOL

O relatório COBOL 60 para CODASYL (abril de 1960)
Paradigma	Processual , imperativo , orientado a objetos , genérico
Projetado por	Howard Bromberg , Norman Discount , Vernon Reeves , Jean E. Sammet , William Selden , Gertrude Tierney , com influência indireta de Grace Hopper
Desenvolvedores	CODASYL , ANSI , ISO / IEC
Apareceu pela primeira vez	1959 ; 64 anos atrás ( 1959 )
Versão estável	ISO/IEC 1989:2023/2023
Disciplina de digitação	Fraco , estático
Extensões de nome de arquivo	.cbl, .cob,.cpy
Principais implementações
GnuCOBOL , IBM COBOL , Micro Focus Visual COBOL
Dialetos
COBOL/2, DEC COBOL-10, DEC PDP-11 COBOL, DEC PDP-11 COBOL-85, DEC VAX COBOL, DOSVS COBOL, Envyr ICOBOL, Fujitsu COBOL, Hitachi COBOL2002, HP3000 COBOL/II, IBM COBOL SAA, IBM COBOL /400, IBM COBOL/II, IBM Enterprise COBOL, IBM ILE COBOL, IBM OS/VS COBOL, ICL COBOL (VME), Micro Focus ACUCOBOL-GT, Micro Focus COBOL-IT, Micro Focus RM/COBOL, Micro Focus Visual COBOL , Microsoft COBOL, Raincode COBOL, Realia COBOL, Ryan McFarland RM/COBOL, Ryan McFarland RM/COBOL-85, Tandem (NonStop) COBOL, Tandem (NonStop) SCOBOL, UNIVAC COBOL, Unisys MCP COBOL74, Unisys MCP COBOL85, Unix COBOL X /Aberto, muito diferente de COBOL, Wang VS COBOL
Influenciado por
Inicial: AIMACO , COMTRAN , FACT , FLOW-MATIC COBOL 2002: C++ , Eiffel , Smalltalk
Influenciado
CobolScript , EGL , PL/I , PL/B
COBOL no Wikilivros

COBOL ( / ˈ k oʊ b ɒ l , - b ɔː l / ; um acrônimo para "common business-oriented language") é uma linguagem de programação de computador compilada semelhante ao inglês projetada para uso comercial. É uma linguagem imperativa , procedural e, desde 2002, orientada a objetos . COBOL é usado principalmente em negócios, finanças e sistemas administrativos para empresas e governos. O COBOL ainda é amplamente usado em aplicativos implantados em computadores mainframe , como lotes em grande escala e tarefas de processamento de transações . No entanto, devido ao declínio de sua popularidade e à aposentadoria de programadores COBOL experientes, os programas estão sendo migrados para novas plataformas, reescritos em linguagens modernas ou substituídos por pacotes de software. A maior parte da programação em COBOL agora é puramente para manter os aplicativos existentes; no entanto, muitas grandes instituições financeiras ainda estavam desenvolvendo novos sistemas em COBOL até 2006.

COBOL foi projetado em 1959 por CODASYL e foi parcialmente baseado na linguagem de programação FLOW-MATIC projetada por Grace Hopper . Foi criado como parte de um esforço do Departamento de Defesa dos EUA para criar uma linguagem de programação portátil para processamento de dados. Ele foi originalmente visto como um paliativo, mas o Departamento de Defesa prontamente forçou os fabricantes de computadores a fornecê-lo, resultando em sua ampla adoção. Foi padronizado em 1968 e desde então foi revisado quatro vezes. As expansões incluem suporte para programação estruturada e orientada a objetos . O padrão atual é ISO / IEC 1989:2014 .

As instruções COBOL têm uma sintaxe semelhante ao inglês, que foi projetada para ser autodocumentada e altamente legível. No entanto, é detalhado e usa mais de 300 palavras reservadas . Em contraste com a sintaxe moderna e sucinta como , COBOL tem uma sintaxe mais parecida com o inglês (neste caso, ). y = x;MOVE x TO y

O código COBOL é dividido em quatro divisões (identificação, ambiente, dados e procedimento) contendo uma hierarquia rígida de seções, parágrafos e sentenças. Na falta de uma grande biblioteca padrão , o padrão especifica 43 instruções, 87 funções e apenas uma classe.

Os cientistas da computação acadêmicos geralmente não se interessavam por aplicativos de negócios quando o COBOL foi criado e não estavam envolvidos em seu design; foi (efetivamente) projetado desde o início como uma linguagem de computador para negócios, com ênfase em entradas e saídas, cujos únicos tipos de dados eram números e strings de texto.

O COBOL foi criticado ao longo de sua vida por sua verbosidade, processo de design e suporte ruim para programação estruturada . Essas deficiências resultam em programas monolíticos e detalhados (pretendidos para serem parecidos com o inglês) que não são facilmente compreensíveis.

Durante anos, COBOL assumiu-se como uma linguagem de programação para operações de negócios em mainframes, embora nos últimos anos tenha surgido um interesse crescente na migração de operações COBOL para computação em nuvem .

Histórico e especificação

Fundo

No final da década de 1950, os usuários e fabricantes de computadores começaram a se preocupar com o aumento do custo da programação. Uma pesquisa de 1959 descobriu que, em qualquer instalação de processamento de dados, a programação custava US$ 800.000 em média e que a tradução de programas para rodar em um novo hardware custaria US$ 600.000. Em uma época em que novas linguagens de programação proliferavam a uma taxa cada vez maior, a mesma pesquisa sugeria que, se uma linguagem comum voltada para negócios fosse usada, a conversão seria muito mais barata e rápida.

Em 8 de abril de 1959, Mary K. Hawes , uma cientista da computação da Burroughs Corporation , convocou uma reunião de representantes da academia, usuários de computador e fabricantes na Universidade da Pensilvânia para organizar uma reunião formal sobre linguagens comerciais comuns. Os representantes incluíam Grace Hopper (inventora da linguagem de processamento de dados semelhante ao inglês FLOW-MATIC ), Jean Sammet e Saul Gorn .

Na reunião de abril, o grupo pediu ao Departamento de Defesa (DoD) que patrocinasse um esforço para criar uma linguagem comercial comum. A delegação impressionou Charles A. Phillips, diretor da equipe de pesquisa do sistema de dados do DoD, que pensou que eles "entendiam completamente" os problemas do DoD. O DoD operava 225 computadores, tinha mais 175 encomendados e gastou mais de $ 200 milhões na implementação de programas para rodar neles. Programas portáteis economizariam tempo, reduziriam custos e facilitariam a modernização.

Charles Phillips concordou em patrocinar a reunião e encarregou a delegação de redigir a agenda.

COBOL 60

Em 28 e 29 de maio de 1959 (exatamente um ano após a reunião Zürich ALGOL 58 ), foi realizada uma reunião no Pentágono para discutir a criação de uma linguagem de programação comum para negócios. Contou com a presença de 41 pessoas e foi presidida por Phillips. O Departamento de Defesa estava preocupado se poderia executar os mesmos programas de processamento de dados em diferentes computadores. FORTRAN , a única linguagem dominante na época, carecia dos recursos necessários para escrever tais programas.

Os representantes descreveram com entusiasmo uma linguagem que poderia funcionar em uma ampla variedade de ambientes, desde bancos e seguros até serviços públicos e controle de estoque. Eles concordaram unanimemente que mais pessoas deveriam ser capazes de programar e que a nova linguagem não deveria ser restringida pelas limitações da tecnologia contemporânea. A maioria concordou que o idioma deveria fazer uso máximo do inglês, ser capaz de mudar, ser independente da máquina e fácil de usar, mesmo à custa de poder.

A reunião resultou na criação de um comitê gestor e de comitês de curto, médio e longo prazo. O comitê de curto alcance recebeu até setembro (três meses) para produzir especificações para um idioma provisório, que seria então aprimorado pelos outros comitês. Sua missão oficial, no entanto, era identificar os pontos fortes e fracos das linguagens de programação existentes e não direcioná-los explicitamente para criar uma nova linguagem.

O prazo foi recebido com descrença pelo comitê de curto prazo. Um membro, Betty Holberton , descreveu o prazo de três meses como "otimismo grosseiro" e duvidou que a linguagem realmente fosse um paliativo.

O comitê diretivo se reuniu em 4 de junho e concordou em nomear toda a atividade como Comitê de Idiomas de Sistemas de Dados , ou CODASYL , e formar um comitê executivo.

Os membros do comitê de curto alcance representavam seis fabricantes de computadores e três agências governamentais. Os fabricantes de computadores foram Burroughs Corporation , IBM , Minneapolis-Honeywell (Honeywell Labs), RCA , Sperry Rand e Sylvania Electric Products . As agências governamentais eram a Força Aérea dos Estados Unidos , a Bacia Modelo David Taylor da Marinha e o National Bureau of Standards (atual Instituto Nacional de Padrões e Tecnologia). O comitê foi presidido por Joseph Wegstein, do US National Bureau of Standards. O trabalho começou investigando a descrição de dados, declarações, aplicativos existentes e experiências do usuário.

O comitê examinou principalmente as linguagens de programação FLOW-MATIC , AIMACO e COMTRAN . A linguagem FLOW-MATIC foi particularmente influente porque foi implementada e porque AIMACO era um derivado dela com apenas pequenas alterações. A inventora do FLOW-MATIC, Grace Hopper, também atuou como consultora técnica do comitê. As principais contribuições do FLOW-MATIC para o COBOL foram nomes longos de variáveis, palavras em inglês para comandos e a separação de descrições de dados e instruções.

Hopper às vezes é referido como "a mãe do COBOL" ou "a avó do COBOL", embora Jean Sammet , um designer-chefe do COBOL, tenha afirmado que Hopper "não era a mãe, criadora ou desenvolvedora do Cobol".

A linguagem COMTRAN da IBM, inventada por Bob Bemer , foi considerada uma concorrente do FLOW-MATIC por um comitê de curto alcance formado por colegas de Grace Hopper. Alguns de seus recursos não foram incorporados ao COBOL para que não parecesse que a IBM havia dominado o processo de design, e Jean Sammet disse em 1981 que havia um "forte viés anti-IBM" de alguns membros do comitê (incluindo ela). Em um caso, depois que Roy Goldfinger, autor do manual do COMTRAN e membro do comitê de médio alcance, compareceu a uma reunião do subcomitê para apoiar sua linguagem e encorajar o uso de expressões algébricas, Grace Hopper enviou um memorando ao comitê de curto alcance reiterando o argumento de Sperry Rand. esforços para criar uma linguagem baseada no inglês.

Em 1980, Grace Hopper comentou que "COBOL 60 é 95% FLOW-MATIC" e que COMTRAN teve uma influência "extremamente pequena". Além disso, ela disse que afirmaria que o trabalho foi influenciado por FLOW-MATIC e COMTRAN apenas para "manter outras pessoas felizes [para que elas] não tentassem nos derrubar".

Os recursos do COMTRAN incorporados ao COBOL incluíam fórmulas, a PICTUREcláusulaIF , uma instrução aprimorada , que evitou a necessidade de GO TOs e um sistema de gerenciamento de arquivos mais robusto.

A utilidade do trabalho do comitê foi objeto de grande debate. Enquanto alguns membros achavam que o idioma tinha muitos compromissos e era o resultado do design do comitê , outros achavam que era melhor do que os três idiomas examinados. Alguns acharam que a linguagem era muito complexa; outros, muito simples.

Recursos controversos incluíam aqueles considerados inúteis ou muito avançados para usuários de processamento de dados. Esses recursos incluíam expressões booleanas , fórmulas e subscritos de tabela (índices). Outro ponto de controvérsia era se as palavras-chave deveriam ser sensíveis ao contexto e o efeito que isso teria na legibilidade. Embora as palavras-chave contextuais tenham sido rejeitadas, a abordagem foi posteriormente usada em PL/I e parcialmente em COBOL a partir de 2002. Pouca consideração foi dada à interatividade , interação com sistemas operacionais (poucos existiam na época) e funções (pensadas como puramente matemáticas e sem uso no processamento de dados).

As especificações foram apresentadas ao comitê executivo em 4 de setembro. Eles ficaram aquém das expectativas: Joseph Wegstein observou que "contém pontos difíceis e requer algumas adições", e Bob Bemer mais tarde os descreveu como uma "mistura". O subcomitê teve até dezembro para melhorá-lo.

Em uma reunião em meados de setembro, o comitê discutiu o nome do novo idioma. As sugestões incluíram "BUSY" (sistema de negócios), "INFOSYL" (linguagem do sistema de informação) e "COCOSYL" (linguagem comum de sistemas de computador). Não está claro quem cunhou o nome "COBOL", embora Bob Bemer posteriormente afirme que foi sua sugestão.

Em outubro, o comitê de alcance intermediário recebeu cópias da especificação de linguagem FACT criada por Roy Nutt . Seus recursos impressionaram tanto o comitê que eles aprovaram uma resolução para basear o COBOL nele.

Isso foi um golpe para o comitê de curto prazo, que havia feito um bom progresso na especificação. Apesar de ser tecnicamente superior, o FACT não foi criado pensando na portabilidade ou por consenso entre fabricantes e usuários. Ele também carecia de uma implementação demonstrável, permitindo que os defensores de um COBOL baseado em FLOW-MATIC derrubassem a resolução. O representante da RCA, Howard Bromberg, também bloqueou o FACT, para que o trabalho da RCA em uma implementação COBOL não fosse desperdiçado.

Logo ficou claro que o comitê era muito grande para que qualquer progresso fosse feito rapidamente. Um frustrado Howard Bromberg comprou uma lápide de $ 15 com "COBOL" gravado nela e a enviou a Charles Phillips para demonstrar seu descontentamento.

Um subcomitê foi formado para analisar os idiomas existentes e era composto por seis pessoas:

• William Selden e Gertrude Tierney da IBM,
• Howard Bromberg e Howard Discount da RCA,
• Vernon Reeves e Jean E. Sammet da Sylvania Electric Products.

O subcomitê fez a maior parte do trabalho de criação da especificação, deixando o comitê de curto prazo revisar e modificar seu trabalho antes de produzir a especificação finalizada.

As especificações foram aprovadas pelo comitê executivo em 8 de janeiro de 1960 e enviadas à gráfica do governo, que as imprimiu como COBOL 60 . Os objetivos declarados da linguagem eram permitir que programas portáteis e eficientes fossem facilmente escritos, permitir que os usuários mudassem para novos sistemas com o mínimo de esforço e custo e fossem adequados para programadores inexperientes.

O Comitê Executivo CODASYL posteriormente criou o Comitê de Manutenção COBOL para responder a perguntas de usuários e fornecedores e para melhorar e expandir as especificações.

Durante 1960, a lista de fabricantes que planejavam construir compiladores COBOL cresceu. Em setembro, mais cinco fabricantes se juntaram à CODASYL ( Bendix , Control Data Corporation , General Electric (GE), National Cash Register e Philco ), e todos os fabricantes representados anunciaram compiladores COBOL. A GE e a IBM planejavam integrar o COBOL em suas próprias linguagens, GECOM e COMTRAN, respectivamente. Em contraste, a International Computers and Tabulators planejava substituir sua linguagem, CODEL, por COBOL.

Enquanto isso, a RCA e a Sperry Rand trabalhavam na criação de compiladores COBOL. O primeiro programa COBOL foi executado em 17 de agosto em um RCA 501. Em 6 e 7 de dezembro, o mesmo programa COBOL (embora com pequenas alterações) foi executado em um computador RCA e um computador Remington-Rand Univac, demonstrando que a compatibilidade pode ser alcançada .

As influências relativas de quais idiomas foram usados ​​continuam até hoje no aviso recomendado impresso em todos os manuais de referência COBOL:

COBOL é uma linguagem industrial e não é propriedade de nenhuma empresa ou grupo de empresas, nem de nenhuma organização ou grupo de organizações.

Nenhuma garantia, expressa ou implícita, é feita por qualquer contribuidor ou pelo Comitê CODASYL COBOL quanto à precisão e funcionamento do sistema de programação e linguagem. Além disso, nenhuma responsabilidade é assumida por qualquer colaborador, ou pelo comitê, em relação a isso. Os autores e detentores dos direitos autorais do material protegido por direitos autorais aqui utilizado são os seguintes:

FLOW-MATIC (marca registrada da Unisys Corporation ), Programação para UNIVAC (R) I e II, Data Automation Systems, com direitos autorais de 1958, 1959, da Unisys Corporation; IBM Commercial Translator Form No. F28-8013, copyright 1959 da IBM; FACT, DSI 27A5260-2760, registrado em 1960 por Minneapolis-Honeywell.

Eles autorizaram especificamente o uso deste material, no todo ou em parte, nas especificações COBOL. Tal autorização se estende à reprodução e uso de especificações COBOL em manuais de programação ou publicações similares.

COBOL-61 para COBOL-65

Muitas falhas lógicas foram encontradas no COBOL 60 , levando Charles Katz , da General Electric, a advertir que não poderia ser interpretado de forma inequívoca. Um relutante comitê de curto prazo decretou uma limpeza total e, em março de 1963, foi relatado que a sintaxe do COBOL era tão definível quanto a do ALGOL , embora as ambigüidades semânticas permanecessem.

COBOL é uma linguagem difícil de escrever um compilador, devido à grande sintaxe e muitos elementos opcionais nas construções sintáticas, bem como à necessidade de gerar código eficiente para uma linguagem com muitas representações de dados possíveis, conversões de tipo implícito e configurações necessárias. ups para operações de E/S. Os primeiros compiladores COBOL eram primitivos e lentos. Uma avaliação da Marinha dos EUA de 1962 encontrou velocidades de compilação de 3 a 11 declarações por minuto. Em meados de 1964, eles aumentaram para 11 a 1.000 declarações por minuto. Observou-se que o aumento da memória aumentaria drasticamente a velocidade e que os custos de compilação variavam muito: os custos por instrução variavam entre US$ 0,23 e US$ 18,91.

No final de 1962, a IBM anunciou que o COBOL seria sua principal linguagem de desenvolvimento e que o desenvolvimento do COMTRAN cessaria.

A especificação COBOL foi revisada três vezes nos cinco anos após sua publicação. O COBOL-60 foi substituído em 1961 pelo COBOL-61. Isso foi então substituído pelas especificações estendidas do COBOL-61 em 1963, que introduziu os recursos de classificação e criação de relatórios. As instalações adicionadas corrigiram as falhas identificadas pela Honeywell no final de 1959 em uma carta ao comitê de curto prazo. COBOL Edition 1965 trouxe mais esclarecimentos para as especificações e introduziu facilidades para manipulação de arquivos e tabelas de armazenamento em massa .

COBOL-68

Esforços começaram a padronizar o COBOL para superar as incompatibilidades entre as versões. No final de 1962, tanto a ISO quanto o United States of America Standards Institute (agora ANSI ) formaram grupos para criar padrões. ANSI produziu USA Standard COBOL X3.23 em agosto de 1968, que se tornou a pedra angular para versões posteriores. Esta versão era conhecida como American National Standard (ANS) COBOL e foi adotada pela ISO em 1972.

COBOL-74

Em 1970, o COBOL havia se tornado a linguagem de programação mais usada no mundo.

Independentemente do comitê ANSI, o CODASYL Programming Language Committee estava trabalhando para melhorar o idioma. Eles descreveram novas versões em 1968, 1969, 1970 e 1973, incluindo mudanças como novas comunicações entre programas, recursos de depuração e fusão de arquivos, bem como recursos aprimorados de manipulação de strings e inclusão de bibliotecas .

Embora o CODASYL fosse independente do comitê ANSI, o CODASYL Journal of Development foi usado pelo ANSI para identificar recursos que eram populares o suficiente para garantir a implementação. O Comitê de Linguagem de Programação também fez contato com a ECMA e o comitê do Padrão COBOL Japonês.

O Comitê de Linguagem de Programação não era muito conhecido, no entanto. O vice-presidente, William Rinehuls, reclamou que dois terços da comunidade COBOL não sabiam da existência do comitê. Também carecia de recursos para disponibilizar gratuitamente documentos públicos, como atas de reuniões e propostas de mudança.

Em 1974, a ANSI publicou uma versão revisada do (ANS) COBOL, contendo novos recursos, como organização de arquivos , DELETEinstrução e módulo de segmentação . Os recursos excluídos incluíam a NOTEinstrução, a EXAMINEinstrução (que foi substituída por INSPECT) e o módulo de acesso aleatório definido pelo implementador (que foi substituído pelos novos módulos de E/S sequencial e relativo). Foram 44 alterações que tornaram as declarações existentes incompatíveis com a nova norma. O redator do relatório estava programado para ser removido do COBOL, mas foi reintegrado antes da publicação do padrão. A ISO posteriormente adotou o padrão atualizado em 1978.

COBOL-85

Em junho de 1978, começou o trabalho de revisão do COBOL-74. O padrão proposto (comumente chamado de COBOL-80) diferia significativamente do anterior, causando preocupações sobre incompatibilidade e custos de conversão. Em janeiro de 1981, Joseph T. Brophy, vice-presidente sênior da Travellers Insurance, ameaçou processar o comitê padrão porque não era compatível com o COBOL-74. O Sr. Brophy descreveu as conversões anteriores de sua base de código de 40 milhões de linhas como "não produtivas" e um "completo desperdício de nossos recursos de programação". Mais tarde naquele ano, a Data Processing Management Association (DPMA) disse que se opunha "fortemente" ao novo padrão, citando custos de conversão "proibitivos" e melhorias que foram "impostas ao usuário".

Durante o primeiro período de revisão pública, o comitê recebeu 2.200 respostas, das quais 1.700 eram cartas modelo negativas. Outras respostas foram análises detalhadas do efeito que o COBOL-80 teria em seus sistemas; os custos de conversão foram previstos em pelo menos 50 centavos por linha de código. Menos de uma dúzia de respostas foram a favor do padrão proposto.

A ISO TC97-SC5 instalou em 1979 o COBOL Experts Group internacional, por iniciativa de Wim Ebbinkhuijsen . O grupo consistia de especialistas em COBOL de vários países, incluindo os Estados Unidos. Seu objetivo era alcançar entendimento e respeito mútuo entre ANSI e o resto do mundo com relação à necessidade de novos recursos COBOL. Após três anos, a ISO mudou o status do grupo para um Grupo de Trabalho formal: WG 4 COBOL . O grupo assumiu a propriedade primária e o desenvolvimento do padrão COBOL, onde o ANSI fez a maioria das propostas.

Em 1983, o DPMA retirou sua oposição ao padrão, citando a receptividade do comitê às preocupações do público. No mesmo ano, um estudo do National Bureau of Standards concluiu que o padrão proposto apresentaria poucos problemas. Um ano depois, a DEC lançou um VAX/VMS COBOL-80 e notou que a conversão de programas COBOL-74 apresentava poucos problemas. A nova EVALUATEinstrução e inline PERFORMforam particularmente bem recebidas e melhoraram a produtividade, graças ao fluxo de controle simplificado e à depuração .

A segunda revisão pública atraiu outras 1.000 respostas (principalmente negativas), enquanto a última atraiu apenas 25, quando muitas preocupações foram abordadas.

Em 1985, o ISO Working Group 4 aceitou a então versão do padrão ANSI proposto, fez várias alterações e o definiu como o novo padrão ISO COBOL 85. Foi publicado no final de 1985.

Sessenta recursos foram alterados ou obsoletos e 115 foram adicionados, como:

• Terminadores de escopo ( END-IF, END-PERFORM, END-READ, etc.)
• Subprogramas aninhados
• CONTINUE, uma declaração sem operação
• EVALUATE, uma declaração de troca
• INITIALIZE, uma instrução que pode definir grupos de dados para seus valores padrão
• Corpos de loop em linha PERFORM- anteriormente, os corpos de loop tinham que ser especificados em um procedimento separado
• Modificação de referência, que permite acesso a substrings
• Códigos de status de E/S.

O novo padrão foi adotado por todos os órgãos nacionais de padronização, incluindo o ANSI.

Duas emendas se seguiram em 1989 e 1993, a primeira introduzindo funções intrínsecas e a outra fornecendo correções.

COBOL 2002 e COBOL orientado a objetos

Em 1997, o Gartner Group estimou que existiam um total de 200 bilhões de linhas de COBOL, que executavam 80% de todos os programas de negócios.

No início da década de 1990, começou o trabalho de adicionar orientação a objetos na próxima revisão completa do COBOL. Recursos orientados a objetos foram retirados de C++ e Smalltalk .

A estimativa inicial era ter essa revisão concluída em 1997, e um Rascunho do Comitê ISO (CD) estava disponível em 1997. Alguns fornecedores (incluindo Micro Focus , Fujitsu e IBM ) introduziram a sintaxe orientada a objetos com base nos rascunhos da revisão completa. O padrão ISO aprovado final foi aprovado e publicado no final de 2002.

Fujitsu/GTSoftware, Micro Focus e RainCode introduziram compiladores COBOL orientados a objeto voltados para o .NET Framework .

Havia muitos outros novos recursos, muitos dos quais estavam no CODASYL COBOL Journal of Development desde 1978 e perderam a oportunidade de serem incluídos no COBOL-85. Esses outros recursos incluíam:

• Código de forma livre
• Funções definidas pelo usuário
• Recursão
• Processamento baseado em localidade
• Suporte para conjuntos de caracteres estendidos, como Unicode
• Tipos de dados de ponto flutuante e binários (até então, os itens binários eram truncados com base na especificação de base 10 de sua declaração )
• Resultados aritméticos portáteis
• Tipos de dados bit e booleanos
• Ponteiros e sintaxe para obter e liberar armazenamento
• O SCREEN SECTIONpara interfaces de usuário baseadas em texto
• A VALIDATEinstalação
• Interoperabilidade aprimorada com outras linguagens de programação e ambientes de estrutura , como .NET e Java .

Três retificações foram publicadas para o padrão: duas em 2006 e uma em 2009.

COBOL 2014

Entre 2003 e 2009, foram produzidos três relatórios técnicos descrevendo finalização de objetos , processamento de XML e classes de coleta para COBOL.

O COBOL 2002 sofria de suporte ruim: nenhum compilador suportava completamente o padrão. A Micro Focus descobriu que isso se devia à falta de demanda do usuário pelos novos recursos e à abolição do conjunto de testes NIST , que era usado para testar a conformidade do compilador. O processo de padronização também foi considerado lento e com poucos recursos.

COBOL 2014 inclui as seguintes alterações:

• Resultados aritméticos portáteis foram substituídos por tipos de dados IEEE 754
• Os principais recursos tornaram-se opcionais, como a VALIDATEinstalação, o redator de relatórios e a facilidade de manipulação de tela
• Sobrecarga de métodos
• Tabelas de capacidade dinâmica (um recurso retirado do rascunho do COBOL 2002)

Legado

Os programas COBOL são usados ​​globalmente em governos e empresas e são executados em diversos sistemas operacionais, como z/OS , z/VSE , VME , Unix , NonStop OS, OpenVMS e Windows . Em 1997, o Gartner Group informou que 80% dos negócios do mundo rodavam em COBOL com mais de 200 bilhões de linhas de código e 5 bilhões de linhas sendo escritas anualmente.

Perto do final do século 20, o problema do ano 2000 (Y2K) foi o foco de um esforço significativo de programação COBOL, às vezes pelos mesmos programadores que projetaram os sistemas décadas antes. O nível específico de esforço necessário para corrigir o código COBOL foi atribuído à grande quantidade de COBOL orientado a negócios, pois os aplicativos de negócios usam datas pesadamente e a campos de dados de comprimento fixo. Alguns estudos atribuem até "24% dos custos de reparo de software Y2K ao Cobol". Após o esforço de limpeza colocado nesses programas para o Y2K, uma pesquisa de 2003 constatou que muitos permaneceram em uso. Os autores disseram que os dados da pesquisa sugerem "um declínio gradual na importância do COBOL no desenvolvimento de aplicativos nos [seguintes] 10 anos, a menos que ... a integração com outras linguagens e tecnologias possa ser adotada".

Em 2006 e 2012, as pesquisas da Computerworld (com 352 leitores) descobriram que mais de 60% das organizações usavam COBOL (mais do que C++ e Visual Basic .NET ) e que, para metade delas, o COBOL era usado na maioria de seus softwares internos. 36% dos gerentes disseram que planejam migrar do COBOL e 25% disseram que gostariam se fosse mais barato. Em vez disso, algumas empresas migraram seus sistemas de mainframes caros para sistemas mais baratos e modernos, mantendo seus programas COBOL.

Testemunho perante a Câmara dos Deputados em 2016 indicou que o COBOL ainda está em uso por muitas agências federais. A Reuters informou em 2017 que 43% dos sistemas bancários ainda usavam COBOL com mais de 220 bilhões de linhas de código COBOL em uso.

Em 2019, o número de programadores COBOL estava diminuindo rapidamente devido a aposentadorias, levando a uma lacuna iminente de habilidades em organizações empresariais e governamentais que ainda usam sistemas de mainframe para processamento de transações de alto volume. Esforços para reescrever sistemas em linguagens mais novas provaram ser caros e problemáticos, assim como a terceirização da manutenção de código, portanto, propostas para treinar mais pessoas em COBOL são defendidas.

Durante a pandemia de COVID-19 e o consequente aumento do desemprego, vários estados dos EUA relataram uma escassez de programadores COBOL qualificados para dar suporte aos sistemas legados usados ​​para gerenciamento de benefícios de desemprego. Muitos desses sistemas estavam em processo de conversão para linguagens de programação mais modernas antes da pandemia, mas o processo foi suspenso. Da mesma forma, o Internal Revenue Service dos EUA correu para corrigir seu arquivo mestre individual baseado em COBOL, a fim de desembolsar as dezenas de milhões de pagamentos exigidos pela Lei de Auxílio, Alívio e Segurança Econômica do Coronavírus .

Características

Sintaxe

COBOL tem uma sintaxe parecida com o inglês, que é usada para descrever quase tudo em um programa. Por exemplo, uma condição pode ser expressa como   ou mais concisamente como     ou   . Condições mais complexas podem ser "abreviadas" removendo condições e variáveis ​​repetidas. Por exemplo,     pode ser abreviado para . Para oferecer suporte a essa sintaxe semelhante ao inglês, o COBOL tem mais de 300 palavras-chave . Algumas das palavras-chave são alternativas simples ou grafias pluralizadas da mesma palavra, o que fornece declarações e cláusulas mais parecidas com o inglês; por exemplo, as palavras-chave e podem ser usadas de forma intercambiável, como can e , e e . x IS GREATER THAN yx GREATER yx > ya > b AND a > c OR a = da > b AND c OR = dINOFTIMETIMESVALUEVALUES

Cada programa COBOL é composto de quatro itens lexicais básicos : palavras, literais, cadeias de caracteres de imagem (consulte a cláusula PICTURE ) e separadores. As palavras incluem palavras reservadas e identificadores definidos pelo usuário. Eles têm até 31 caracteres e podem incluir letras, dígitos, hífens e sublinhados. Os literais incluem numerais (por exemplo, 12) e strings (por exemplo 'Hello!', ). Os separadores incluem o caractere de espaço e vírgulas e ponto e vírgula seguidos por um espaço.

Um programa COBOL é dividido em quatro divisões: a divisão de identificação, a divisão de ambiente, a divisão de dados e a divisão de procedimento. A divisão de identificação especifica o nome e o tipo do elemento de origem e é onde as classes e interfaces são especificadas. A divisão do ambiente especifica todos os recursos do programa que dependem do sistema que o executa, como arquivos e conjuntos de caracteres . A divisão de dados é usada para declarar variáveis ​​e parâmetros . A divisão do procedimento contém as instruções do programa . Cada divisão é subdividida em seções, que são compostas de parágrafos.

metalinguagem

A sintaxe do COBOL é geralmente descrita com uma metalinguagem única usando colchetes, colchetes, barras e sublinhado. A metalinguagem foi desenvolvida para as especificações originais do COBOL. Embora a forma Backus-Naur existisse na época, o comitê não tinha ouvido falar dela.

Como exemplo, considere a seguinte descrição de uma ADDdeclaração:

${\displaystyle {\begin{array}{l}{\underline {\text{ADD}}}\,{\begin{Bmatrix}{\text{identificador-1}}\\{\text{literal-1} }\end{Bmatrix}}\dots \;{\underline {\text{TO}}}\,\left\{{\text{identificador-2}}\,\left[\,{\underline {\text {ROUNDED}}}\,\right]\right\}\dots \\\quad \left[\left|{\begin{array}{l}{\text{ON}}\,{\sublinhado {\text {TAMANHO}}}\,{\sublinhado {\text{ERRO}}}\,{\text{declaração-imperativa-1}}\\{\sublinhado {\text{NÃO}}}\,{\text{ ON}}\,{\underline {\text{TAMANHO}}}\,{\underline {\text{ERRO}}}\,{\text{declaração-imperativa-2}}\\\end{array}} \right|\right]\\\quad \left[\,{\underline {\text{END-ADD}}}\,\right]\end{array}}}$

Esta descrição permite as seguintes variantes:

ADD 1 TO x
ADD 1, a, b TO x ROUNDED, y, z ROUNDED

ADD a, b TO c
    ON SIZE ERROR
        DISPLAY "Error"
END-ADD

ADD a TO b
    NOT SIZE ERROR
        DISPLAY "No error"
    ON SIZE ERROR
        DISPLAY "Error"

Formato de código

baralho programa COBOL de cartões perfurados, da década de 1970

O auge da popularidade do COBOL coincidiu com a era das máquinas perfuradoras e dos cartões perfurados . O programa em si era escrito em cartões perfurados, depois lido e compilado, e os dados inseridos no programa às vezes também estavam em cartões.

O COBOL pode ser escrito em dois formatos: fixo (o padrão) ou gratuito. No formato fixo, o código deve ser alinhado para caber em certas áreas (um resquício do uso de cartões perfurados). Até o COBOL 2002, eram:

No COBOL 2002, as Áreas A e B foram mescladas para formar a área de texto do programa, que agora termina em uma coluna definida pelo implementador.

O COBOL 2002 também introduziu o código de formato livre. O código de formato livre pode ser colocado em qualquer coluna do arquivo, como nas linguagens de programação mais recentes. Os comentários são especificados usando *>, que podem ser colocados em qualquer lugar e também podem ser usados ​​no código-fonte de formato fixo. As linhas de continuação não estão presentes e a >>PAGEdiretiva substitui o /indicador.

divisão de identificação

A divisão de identificação identifica a seguinte entidade de código e contém a definição de uma classe ou interface.

Programação Orientada a Objetos

As classes e interfaces estão em COBOL desde 2002. As classes têm objetos de fábrica, contendo métodos e variáveis ​​de classe, e objetos de instância, contendo métodos e variáveis ​​de instância. Herança e interfaces fornecem polimorfismo . O suporte para programação genérica é fornecido por meio de classes parametrizadas, que podem ser instanciadas para usar qualquer classe ou interface. Os objetos são armazenados como referências que podem ser restritas a um determinado tipo. Existem duas maneiras de chamar um método: a INVOKEinstrução, que age de maneira semelhante a CALL, ou por meio da invocação de método embutido, que é análoga ao uso de funções.

*> These are equivalent.
INVOKE my-class "foo" RETURNING var
MOVE my-class::"foo" TO var *> Inline method invocation

COBOL não fornece uma maneira de ocultar métodos. Os dados da classe podem ser ocultados, no entanto, declarando-os sem uma PROPERTYcláusula, o que deixa o usuário sem meios de acessá-los. A sobrecarga de método foi adicionada no COBOL 2014.

divisão de meio ambiente

A divisão do ambiente contém a seção de configuração e a seção de entrada-saída. A seção de configuração é usada para especificar recursos variáveis, como sinais de moeda, localidades e conjuntos de caracteres. A seção de entrada-saída contém informações relacionadas ao arquivo.

arquivos

COBOL suporta três formatos de arquivo, ou organizações : sequencial, indexado e relativo. Em arquivos sequenciais, os registros são contíguos e devem ser percorridos sequencialmente , de forma semelhante a uma lista encadeada . Arquivos indexados possuem um ou mais índices que permitem que os registros sejam acessados ​​aleatoriamente e que podem ser classificados neles. Cada registro deve ter uma chave exclusiva , mas outras chaves de registro alternativas não precisam ser exclusivas. As implementações de arquivos indexados variam entre os fornecedores, embora as implementações comuns, como C-ISAM e VSAM , sejam baseadas no ISAM da IBM . outras implementações são Record Management Services em OpenVMS e Enscribe em HPE NonStop (Tandem). Arquivos relativos, como arquivos indexados, possuem uma chave de registro exclusiva, mas não possuem chaves alternativas. A chave de um registro relativo é sua posição ordinal; por exemplo, o 10º registro tem uma chave de 10. Isso significa que a criação de um registro com uma chave de 5 pode exigir a criação de registros anteriores (vazios). Arquivos relativos também permitem acesso sequencial e aleatório.

Uma extensão não padrão comum é a organização sequencial de linha , usada para processar arquivos de texto. Os registros em um arquivo são finalizados por uma nova linha e podem ter tamanhos variados.

divisão de dados

A divisão de dados é dividida em seis seções que declaram diferentes itens: a seção de arquivo, para registros de arquivo; a seção de armazenamento de trabalho, para variáveis ​​estáticas ; a seção local-storage, para variáveis ​​automáticas ; a seção de ligação, para parâmetros e o valor de retorno; a seção de relatório e a seção de tela, para interfaces de usuário baseadas em texto .

dados agregados

Os itens de dados em COBOL são declarados hierarquicamente por meio do uso de números de nível que indicam se um item de dados faz parte de outro. Um item com um número de nível superior está subordinado a um item com um inferior. Itens de dados de nível superior, com número de nível 1, são chamados de registros . Os itens que possuem dados agregados subordinados são chamados de itens de grupo ; aqueles que não são chamados de itens elementares . Os números de nível usados ​​para descrever itens de dados padrão estão entre 1 e 49.

       01  some-record.                   *> Aggregate group record item
           05  num            PIC 9(10).  *> Elementary item
           05  the-date.                  *> Aggregate (sub)group record item
               10  the-year   PIC 9(4).   *> Elementary item
               10  the-month  PIC 99.     *> Elementary item
               10  the-day    PIC 99.     *> Elementary item

No exemplo acima, item elementar nume item de grupo the-dateestão subordinados ao registro some-record, enquanto itens elementares the-year, the-monthe the-dayfazem parte do item de grupo the-date.

Itens subordinados podem ser desambiguados com a palavra-chave IN(ou OF). Por exemplo, considere o código de exemplo acima junto com o exemplo a seguir:

       01  sale-date.
           05  the-year       PIC 9(4).
           05  the-month      PIC 99.
           05  the-day        PIC 99.

Os nomes the-year, the-monthe the-daysão ambíguos por si só, pois mais de um item de dados é definido com esses nomes. Para especificar um determinado item de dados, por exemplo, um dos itens contidos no sale-dategrupo, o programador usaria the-year IN sale-date(ou o equivalente the-year OF sale-date). Essa sintaxe é semelhante à "notação de ponto" suportada pela maioria das linguagens contemporâneas.

Outros níveis de dados

Um número de nível de 66 é usado para declarar um reagrupamento de itens previamente definidos, independentemente de como esses itens são estruturados. Esse nível de dados, também referido pela RENAMEScláusula associada , é raramente usado e, por volta de 1988, era geralmente encontrado em programas antigos. Sua capacidade de ignorar os dados da estrutura hierárquica e lógica fez com que seu uso não fosse recomendado e muitas instalações proibissem seu uso.

       01  customer-record.
           05  cust-key            PIC X(10).
           05  cust-name.
               10  cust-first-name PIC X(30).
               10  cust-last-name  PIC X(30).
           05  cust-dob            PIC 9(8).
           05  cust-balance        PIC 9(7)V99.
           
       66  cust-personal-details   RENAMES cust-name THRU cust-dob.
       66  cust-all-details        RENAMES cust-name THRU cust-balance.

Um número de nível 77 indica que o item é autônomo e, nessas situações, é equivalente ao número de nível 01. Por exemplo, o código a seguir declara dois itens de dados de nível 77 e , que são itens de dados não pertencentes ao property-namegrupo sales-regionque são independentes de (não subordinados a) quaisquer outros itens de dados:

       77  property-name      PIC X(80).
       77  sales-region       PIC 9(5).

Um número de nível 88 declara um nome de condição (o chamado nível 88) que é verdadeiro quando seu item de dados pai contém um dos valores especificados em sua VALUEcláusula. Por exemplo, o código a seguir define dois itens de nome de condição de 88 níveis que são verdadeiros ou falsos, dependendo do valor de dados de caractere atual do wage-typeitem de dados. Quando o item de dados contém um valor de 'H', o nome da condição wage-is-hourlyé verdadeiro, enquanto que quando contém um valor de 'S'ou 'Y', o nome da condição wage-is-yearlyé verdadeiro. Se o item de dados contiver algum outro valor, ambos os nomes de condição serão falsos.

       01  wage-type          PIC X.
           88  wage-is-hourly VALUE "H".
           88  wage-is-yearly VALUE "S", "Y".

Tipos de dados

O COBOL padrão fornece os seguintes tipos de dados:

A segurança de tipo é variável em COBOL. Os dados numéricos são convertidos entre diferentes representações e tamanhos silenciosamente e os dados alfanuméricos podem ser colocados em qualquer item de dados que possa ser armazenado como uma string, incluindo dados numéricos e de grupo. Em contraste, referências de objetos e ponteiros só podem ser atribuídos a partir de itens do mesmo tipo e seus valores podem ser restritos a um determinado tipo.

Cláusula IMAGEM

Uma cláusula PICTURE(ou PIC) é uma sequência de caracteres, cada um representando uma parte do item de dados e o que ele pode conter. Alguns caracteres de imagem especificam o tipo do item e quantos caracteres ou dígitos ele ocupa na memória. Por exemplo, a 9indica um dígito decimal e an Sindica que o item está assinado . Outros caracteres de imagem (chamados de caracteres de inserção e edição ) especificam como um item deve ser formatado. Por exemplo, uma série de +caracteres define as posições dos caracteres e também como um caractere de sinal inicial deve ser posicionado dentro dos dados finais do caractere; o caractere não numérico mais à direita conterá o sinal do item, enquanto outras posições de caracteres correspondentes a a +à esquerda dessa posição conterão um espaço. Os caracteres repetidos podem ser especificados de forma mais concisa, especificando um número entre parênteses após um caractere de imagem; por exemplo, 9(7)é equivalente a 9999999. As especificações de imagem contendo apenas caracteres de dígito ( 9) e sinal ( S) definem itens de dados puramente numéricos , enquanto as especificações de imagem contendo caracteres alfabéticos ( A) ou alfanuméricos ( ) definem itens de dados alfanuméricos . A presença de outros caracteres de formatação define itens de dados numéricos ou alfanuméricos editados . X

Cláusula de USO

A USAGEcláusula declara o formato no qual os dados são armazenados. Dependendo do tipo de dados, ele pode complementar ou ser usado no lugar de uma PICTUREcláusula. Embora possa ser usado para declarar ponteiros e referências de objetos, é mais voltado para a especificação de tipos numéricos. Esses formatos numéricos são:

• Binário, onde um tamanho mínimo é especificado pela PICTUREcláusula ou por uma USAGEcláusula comoBINARY-LONG
• USAGE COMPUTATIONAL, onde os dados podem ser armazenados em qualquer formato fornecido pela implementação; muitas vezes equivalente a  USAGE BINARY
• USAGE DISPLAY, o formato padrão, onde os dados são armazenados como uma string
• Ponto flutuante, em um formato dependente de implementação ou de acordo com IEEE 754
• USAGE NATIONAL, onde os dados são armazenados como uma string usando um conjunto de caracteres estendidos
• USAGE PACKED-DECIMAL, onde os dados são armazenados no menor formato decimal possível (normalmente empacotado decimal codificado em binário )

Redator de relatórios

O criador de relatórios é um recurso declarativo para a criação de relatórios. O programador precisa apenas especificar o layout do relatório e os dados necessários para produzi-lo, liberando-o de escrever código para lidar com coisas como quebras de página, formatação de dados e cabeçalhos e rodapés.

Os relatórios são associados a arquivos de relatório, que são arquivos que só podem ser gravados por meio de instruções do criador de relatórios.

       FD  report-out REPORT sales-report.

Cada relatório é definido na seção de relatório da divisão de dados. Um relatório é dividido em grupos de relatórios que definem os títulos, rodapés e detalhes do relatório. Os relatórios contornam as quebras de controle hierárquico . As quebras de controle ocorrem quando uma variável-chave altera seu valor; por exemplo, ao criar um relatório detalhando os pedidos dos clientes, pode ocorrer uma quebra de controle quando o programa atinge os pedidos de um cliente diferente. Aqui está um exemplo de descrição de relatório para um relatório que fornece as vendas de um vendedor e que avisa sobre quaisquer registros inválidos:

       RD  sales-report
           PAGE LIMITS 60 LINES
           FIRST DETAIL 3
           CONTROLS seller-name.

       01  TYPE PAGE HEADING.
           03  COL 1                    VALUE "Sales Report".
           03  COL 74                   VALUE "Page".
           03  COL 79                   PIC Z9 SOURCE PAGE-COUNTER.

       01  sales-on-day TYPE DETAIL, LINE + 1.
           03  COL 3                    VALUE "Sales on".
           03  COL 12                   PIC 99/99/9999 SOURCE sales-date.
           03  COL 21                   VALUE "were".
           03  COL 26                   PIC $$$$9.99 SOURCE sales-amount.

       01  invalid-sales TYPE DETAIL, LINE + 1.
           03  COL 3                    VALUE "INVALID RECORD:".
           03  COL 19                   PIC X(34) SOURCE sales-record.

       01  TYPE CONTROL HEADING seller-name, LINE + 2.
           03  COL 1                    VALUE "Seller:".
           03  COL 9                    PIC X(30) SOURCE seller-name.

A descrição do relatório acima descreve o seguinte layout:

Sales Report                                                             Page  1

Seller: Howard Bromberg
  Sales on 10/12/2008 were $1000.00
  Sales on 12/12/2008 were    $0.00
  Sales on 13/12/2008 were   $31.47
  INVALID RECORD: Howard Bromberg             XXXXYY

Seller: Howard Discount
...
Sales Report                                                            Page 12

  Sales on 08/05/2014 were  $543.98
  INVALID RECORD: William Selden      12O52014FOOFOO
  Sales on 30/05/2014 were    $0.00

Quatro instruções controlam o redator do relatório: INITIATE, que prepara o redator do relatório para impressão; GENERATE, que imprime um grupo de relatórios; SUPPRESS, que suprime a impressão de um grupo de relatórios; e TERMINATE, que encerra o processamento do relatório. Para o exemplo de relatório de vendas acima, a divisão do procedimento pode ter esta aparência:

           OPEN INPUT sales, OUTPUT report-out
           INITIATE sales-report
 
           PERFORM UNTIL 1 <> 1
               READ sales
                   AT END
                       EXIT PERFORM
               END-READ
 
               VALIDATE sales-record
               IF valid-record
                   GENERATE sales-on-day
               ELSE
                   GENERATE invalid-sales
               END-IF
           END-PERFORM
 
           TERMINATE sales-report
           CLOSE sales, report-out
           .

O uso do recurso Report Writer tende a variar consideravelmente; algumas organizações o utilizam extensivamente e outras não. Além disso, as implementações do Report Writer variavam em qualidade, com aquelas na extremidade inferior às vezes usando quantidades excessivas de memória em tempo de execução.

Divisão de procedimento

Procedimentos

As seções e parágrafos na divisão do procedimento (chamados coletivamente de procedimentos) podem ser usados ​​como rótulos e como sub-rotinas simples . Ao contrário de outras divisões, os parágrafos não precisam estar em seções.

A execução desce através dos procedimentos de um programa até que seja encerrado. Para usar procedimentos como sub-rotinas, o PERFORMverbo é usado.

Uma PERFORMinstrução lembra um pouco uma chamada de procedimento em linguagens mais recentes no sentido de que a execução retorna ao código seguinte à PERFORMinstrução no final do código chamado; no entanto, ele não fornece um mecanismo para passagem de parâmetro ou para retornar um valor de resultado. Se uma sub-rotina for invocada usando uma instrução simples como , o controle retornará no final do procedimento chamado. No entanto, é incomum porque pode ser usado para chamar um intervalo abrangendo uma sequência de vários procedimentos adjacentes. Isso é feito com a construção: PERFORM subroutinePERFORMPERFORM sub-1 THRU sub-n

PROCEDURE so-and-so.
    PERFORM ALPHA
    PERFORM ALPHA THRU GAMMA
    STOP RUN.
ALPHA.
    DISPLAY 'A'.
BETA.
    DISPLAY 'B'.
GAMMA.
    DISPLAY 'C'.

A saída deste programa será: "AAB C".

PERFORMtambém difere das chamadas de procedimento convencionais porque não há, pelo menos tradicionalmente, noção de pilha de chamadas. Como consequência, invocações aninhadas são possíveis (uma sequência de código sendo PERFORM'ed pode executar uma PERFORMinstrução em si), mas requer cuidado extra se partes do mesmo código forem executadas por ambas as invocações. O problema surge quando o código na invocação interna atinge o ponto de saída da invocação externa. Mais formalmente, se o controle passar pelo ponto de saída de uma PERFORMchamada que foi chamada anteriormente, mas ainda não foi concluída, o padrão COBOL 2002 estipula que o comportamento é indefinido .

A razão é que o COBOL, em vez de um "endereço de retorno", opera com o que pode ser chamado de endereço de continuação. Quando o fluxo de controle chega ao final de qualquer procedimento, o endereço de continuação é procurado e o controle é transferido para esse endereço. Antes da execução do programa, o endereço de continuação de cada procedimento é inicializado com o endereço inicial do procedimento que vem a seguir no texto do programa, de modo que, se nenhuma PERFORMinstrução ocorrer, o controle fluirá de cima para baixo no programa. Mas quando uma PERFORMinstrução é executada, ela modifica o endereço de continuação do procedimento chamado (ou o último procedimento do intervalo chamado, se PERFORM THRUfoi usado), para que o controle retorne ao local da chamada ao final. O valor original é salvo e restaurado posteriormente, mas há apenas uma posição de armazenamento. Se duas invocações aninhadas operam em código sobreposto, elas podem interferir no gerenciamento uma da outra do endereço de continuação de várias maneiras.

O exemplo a seguir (retirado de Veerman & Verhoeven 2006 ) ilustra o problema:

LABEL1.
    DISPLAY '1'
    PERFORM LABEL2 THRU LABEL3
    STOP RUN.
LABEL2.
    DISPLAY '2'
    PERFORM LABEL3 THRU LABEL4.
LABEL3.
    DISPLAY '3'.
LABEL4.
    DISPLAY '4'.

Pode-se esperar que a saída deste programa seja "1 2 3 4 3": Depois de exibir "2", o segundo PERFORMfaz com que "3" e "4" sejam exibidos e, em seguida, a primeira invocação continua com "3" . Em implementações COBOL tradicionais, esse não é o caso. Em vez disso, a primeira PERFORMinstrução define o endereço de continuação no final de LABEL3para que ele volte ao local de chamada dentro de LABEL1. A segunda PERFORMinstrução define o retorno no final de, LABEL4mas não modifica o endereço de continuação de LABEL3, esperando que seja a continuação padrão. Assim, quando a invocação interna chega ao final de LABEL3, ela pula de volta para a PERFORMinstrução externa, e o programa deixa de imprimir apenas "1 2 3". Por outro lado, em algumas implementações COBOL como o compilador TinyCOBOL de código aberto, as duas PERFORMinstruções não interferem uma na outra e a saída é de fato "1 2 3 4 3". Portanto, o comportamento nesses casos não é apenas (talvez) surpreendente, mas também não é portátil.

Uma consequência especial dessa limitação é que PERFORMnão pode ser usado para escrever código recursivo. Outro exemplo simples para ilustrar isso (ligeiramente simplificado de Veerman & Verhoeven 2006 ):

    MOVE 1 TO A
    PERFORM LABEL
    STOP RUN.
LABEL.
    DISPLAY A
    IF A < 3
        ADD 1 TO A
        PERFORM LABEL
    END-IF
    DISPLAY 'END'.

Pode-se esperar que a saída seja "1 2 3 END END END" e, de fato, é isso que alguns compiladores COBOL produzirão. Mas outros compiladores, como o IBM COBOL, produzirão código que imprime "1 2 3 END END END END ..." e assim por diante, imprimindo "END" repetidamente em um loop infinito. Como há espaço limitado para armazenar endereços de continuação de backup, os backups são substituídos durante as invocações recursivas e tudo o que pode ser restaurado é o salto de volta para DISPLAY 'END'.

Declarações

O COBOL 2014 tem 47 instruções (também chamadas de verbos ), que podem ser agrupadas nas seguintes categorias amplas: fluxo de controle, E/S, manipulação de dados e criador de relatórios. As declarações do redator do relatório são abordadas na seção do redator do relatório .

Controle de fluxo

As instruções condicionais do COBOL são IFe EVALUATE. EVALUATEé uma instrução do tipo switch com a capacidade adicional de avaliar vários valores e condições. Isso pode ser usado para implementar tabelas de decisão . Por exemplo, o seguinte pode ser usado para controlar um torno CNC :

EVALUATE TRUE ALSO desired-speed ALSO current-speed
    WHEN lid-closed ALSO min-speed THRU max-speed ALSO LESS THAN desired-speed
        PERFORM speed-up-machine
    WHEN lid-closed ALSO min-speed THRU max-speed ALSO GREATER THAN desired-speed
        PERFORM slow-down-machine
    WHEN lid-open ALSO ANY ALSO NOT ZERO
        PERFORM emergency-stop
    WHEN OTHER
        CONTINUE
END-EVALUATE

A PERFORMinstrução é usada para definir loops que são executados até que uma condição seja verdadeira (não enquanto verdadeira, o que é mais comum em outras linguagens). Também é usado para chamar procedimentos ou intervalos de procedimentos (consulte a seção de procedimentos para obter mais detalhes). CALLe INVOKEchamar subprogramas e métodos, respectivamente. O nome do subprograma/método está contido em uma string que pode ser um literal ou um item de dados. Os parâmetros podem ser passados ​​por referência , por conteúdo (onde uma cópia é passada por referência) ou por valor (mas somente se um protótipo estiver disponível). CANCELdescarrega subprogramas da memória. GO TOfaz com que o programa pule para um procedimento especificado.

A GOBACKinstrução é uma instrução de retorno e a STOPinstrução interrompe o programa. A EXITinstrução tem seis formatos diferentes: pode ser usada como uma instrução return, uma instrução break , uma instrução continue , um marcador de fim ou para sair de um procedimento.

As exceções são levantadas por uma RAISEinstrução e capturadas com um manipulador, ou declarativo , definido na DECLARATIVESparte da divisão do procedimento. Declarativos são seções que começam com uma USEinstrução que especifica os erros a serem tratados. As exceções podem ser nomes ou objetos. RESUMEé usado em um declarativo para pular para a instrução após aquela que gerou a exceção ou para um procedimento fora do DECLARATIVES. Ao contrário de outras linguagens, as exceções não detectadas podem não encerrar o programa e o programa pode continuar sem ser afetado.

E/S

A E/S de arquivo é tratada pelas instruções autodescritivas OPEN, CLOSE, READ, e WRITEjunto com outras três: REWRITE, que atualiza um registro; START, que seleciona registros subseqüentes para acessar encontrando um registro com uma determinada chave; e UNLOCK, que libera o bloqueio do último registro acessado.

A interação do usuário é feita usando ACCEPTe DISPLAY.

Manipulação de dados

Os seguintes verbos manipulam dados:

• INITIALIZE, que define os itens de dados com seus valores padrão.
• MOVE, que atribui valores a itens de dados; MOVE CORRESPONDING atribui campos com nomes semelhantes correspondentes .
• SET, que possui 15 formatos: pode modificar índices, atribuir referências de objetos e alterar capacidades de tabelas, entre outras funções.
• ADD, SUBTRACT, MULTIPLY, DIVIDEe COMPUTE, que lidam com aritmética (com COMPUTEa atribuição do resultado de uma fórmula a uma variável).
• ALLOCATEe FREE, que tratam da memória dinâmica .
• VALIDATE, que valida e distribui dados conforme especificado na descrição de um item na divisão de dados.
• STRINGe UNSTRING, que concatenam e dividem strings , respectivamente.
• INSPECT, que registra ou substitui instâncias de substrings especificadas em uma string.
• SEARCH, que procura em uma tabela a primeira entrada que satisfaça uma condição.

Arquivos e tabelas são classificados usando SORTe o MERGEverbo mescla e classifica arquivos. O RELEASEverbo fornece registros para classificar e RETURNrecupera os registros classificados em ordem.

Encerramento do escopo

Algumas instruções, como IFe READ, podem conter instruções. Essas instruções podem ser encerradas de duas maneiras: por um ponto ( finalização implícita ), que encerra todas as instruções não encerradas contidas, ou por um terminador de escopo, que encerra a instrução aberta correspondente mais próxima.

*> Terminator period ("implicit termination")
IF invalid-record
    IF no-more-records
        NEXT SENTENCE
    ELSE
        READ record-file
            AT END SET no-more-records TO TRUE.

*> Scope terminators ("explicit termination")
IF invalid-record
    IF no-more-records
        CONTINUE
    ELSE
        READ record-file
            AT END SET no-more-records TO TRUE
        END-READ
    END-IF
END-IF

Instruções aninhadas terminadas com um ponto são uma fonte comum de bugs. Por exemplo, examine o seguinte código:

IF x
    DISPLAY y.
    DISPLAY z.

Aqui, a intenção é exibir ye zse a condição xfor verdadeira. No entanto, zserá exibido qualquer que seja o valor de xporque a IFinstrução é encerrada por um ponto errado após . DISPLAY y

Outro bug é resultado do problema do else pendente , quando duas IFinstruções podem ser associadas a um ELSE.

IF x
    IF y
        DISPLAY a
ELSE
    DISPLAY b.

No fragmento acima, o ELSEassocia com a     instrução em vez da     instrução, causando um bug. Antes da introdução de terminadores de escopo explícitos, impedi-los exigiria     que fossem colocados após o . IF yIF xELSE NEXT SENTENCEIF

Código automodificável

A especificação COBOL original (1959) suportava a     declaração infame, para a qual muitos compiladores geravam código automodificável . e são rótulos de procedimento, e a única     instrução no procedimento executada após tal instrução significa     em vez disso. Muitos compiladores ainda o suportam, mas foi considerado obsoleto no padrão COBOL 1985 e excluído em 2002. ALTER X TO PROCEED TO YXYGO TOXALTERGO TO Y

A ALTERdeclaração foi mal vista porque prejudicava a "localidade do contexto" e tornava difícil a compreensão da lógica geral de um programa. Como o autor do livro didático Daniel D. McCracken escreveu em 1976, quando "alguém que nunca viu o programa antes deve se familiarizar com ele o mais rápido possível, às vezes sob pressão crítica de tempo porque o programa falhou ... a visão de um GO TO declaração em um parágrafo por si só, sinalizando a existência de um número desconhecido de instruções ALTER em locais desconhecidos ao longo do programa, causa medo no coração do programador mais corajoso."

Olá Mundo

Um programa " Olá, mundo " em COBOL:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. hello-world.
       PROCEDURE DIVISION.
           DISPLAY "Hello, world!"
           .

Quando o – agora famoso – "Hello, World!" exemplo de programa em A linguagem de programação C foi publicado pela primeira vez em 1978, uma amostra de programa COBOL de mainframe semelhante teria sido enviada por meio de JCL , muito provavelmente usando um leitor de cartão perfurado e cartões perfurados de 80 colunas. A listagem abaixo, com um DATA DIVISION vazio , foi testada usando Linux e o emulador System/370 Hercules executando MVS 3.8J. O JCL, escrito em julho de 2015, é derivado dos tutoriais e amostras do Hercules hospedados por Jay Moseley. De acordo com a programação COBOL daquela época, HELLO, WORLD é exibido em letras maiúsculas.

//COBUCLG  JOB (001),'COBOL BASE TEST',                                 00010000
//             CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)                        00020000
//BASETEST EXEC COBUCLG                                                 00030000
//COB.SYSIN DD *                                                        00040000
 00000* VALIDATION OF BASE COBOL INSTALL                                00050000
 01000 IDENTIFICATION DIVISION.                                         00060000
 01100 PROGRAM-ID. 'HELLO'.                                             00070000
 02000 ENVIRONMENT DIVISION.                                            00080000
 02100 CONFIGURATION SECTION.                                           00090000
 02110 SOURCE-COMPUTER.  GNULINUX.                                      00100000
 02120 OBJECT-COMPUTER.  HERCULES.                                      00110000
 02200 SPECIAL-NAMES.                                                   00120000
 02210     CONSOLE IS CONSL.                                            00130000
 03000 DATA DIVISION.                                                   00140000
 04000 PROCEDURE DIVISION.                                              00150000
 04100 00-MAIN.                                                         00160000
 04110     DISPLAY 'HELLO, WORLD' UPON CONSL.                           00170000
 04900     STOP RUN.                                                    00180000
//LKED.SYSLIB DD DSNAME=SYS1.COBLIB,DISP=SHR                            00190000
//            DD DSNAME=SYS1.LINKLIB,DISP=SHR                           00200000
//GO.SYSPRINT DD SYSOUT=A                                               00210000
//                                                                      00220000

Depois de enviar o JCL, o console MVS exibiu:

    19.52.48 JOB    3  $HASP100 COBUCLG  ON READER1     COBOL BASE TEST
    19.52.48 JOB    3  IEF677I WARNING MESSAGE(S) FOR JOB COBUCLG  ISSUED
    19.52.48 JOB    3  $HASP373 COBUCLG  STARTED - INIT 1 - CLASS A - SYS BSP1
    19.52.48 JOB    3  IEC130I SYSPUNCH DD STATEMENT MISSING
    19.52.48 JOB    3  IEC130I SYSLIB   DD STATEMENT MISSING
    19.52.48 JOB    3  IEC130I SYSPUNCH DD STATEMENT MISSING
    19.52.48 JOB    3  IEFACTRT - Stepname  Procstep  Program   Retcode
    19.52.48 JOB    3  COBUCLG    BASETEST  COB       IKFCBL00  RC= 0000
    19.52.48 JOB    3  COBUCLG    BASETEST  LKED      IEWL      RC= 0000
    19.52.48 JOB    3  +HELLO, WORLD
    19.52.48 JOB    3  COBUCLG    BASETEST  GO        PGM=*.DD  RC= 0000
    19.52.48 JOB    3  $HASP395 COBUCLG  ENDED

A linha 10 da listagem do console acima é destacada para efeito, o realce não faz parte da saída real do console .

A listagem do compilador associado gerou mais de quatro páginas de detalhes técnicos e informações de execução de tarefa, para a única linha de saída das 14 linhas de COBOL.

Recepção

falta de estrutura

Na década de 1970, a adoção do paradigma de programação estruturada estava se tornando cada vez mais difundida. Edsger Dijkstra , um proeminente cientista da computação, escreveu uma carta ao editor de Communications of the ACM , publicada em 1975, intitulada "Como dizemos verdades que podem machucar?", Na qual criticava o COBOL e várias outras linguagens contemporâneas; observando que "o uso de COBOL paralisa a mente".

Em uma dissidência publicada às observações de Dijkstra, o cientista da computação Howard E. Tompkins afirmou que o COBOL não estruturado tendia a ser "escrito por programadores que nunca tiveram o benefício do COBOL estruturado bem ensinado", argumentando que a questão era principalmente de treinamento.

Uma causa do código espaguete foi a GO TOdeclaração. Tentativas de remover GO TOs do código COBOL, no entanto, resultaram em programas complicados e qualidade de código reduzida. GO TOs foram amplamente substituídos por PERFORMinstruções e procedimentos, que promoviam a programação modular e davam acesso fácil a poderosos recursos de loop. No entanto, PERFORMpoderia ser usado apenas com procedimentos para que os corpos de loop não fossem localizados onde foram usados, tornando os programas mais difíceis de entender.

Os programas COBOL eram famosos por serem monolíticos e sem modularização. O código COBOL poderia ser modularizado apenas por meio de procedimentos, que foram considerados inadequados para grandes sistemas. Era impossível restringir o acesso aos dados, o que significa que um procedimento poderia acessar e modificar qualquer item de dados. Além disso, não havia como passar parâmetros a um procedimento, omissão que Jean Sammet considerava o maior erro da comissão.

Outra complicação decorreu da capacidade de PERFORM THRUuma sequência específica de procedimentos. Isso significava que o controle poderia ir e voltar de qualquer procedimento, criando um fluxo de controle complicado e permitindo que um programador quebrasse a regra de entrada única e saída única .

Essa situação melhorou à medida que o COBOL adotou mais recursos. O COBOL-74 adicionou subprogramas, dando aos programadores a capacidade de controlar os dados que cada parte do programa pode acessar. O COBOL-85 então adicionou subprogramas aninhados, permitindo aos programadores ocultar subprogramas. Mais controle sobre dados e código veio em 2002, quando a programação orientada a objetos, funções definidas pelo usuário e tipos de dados definidos pelo usuário foram incluídos.

No entanto, software COBOL herdado muito importante usa código não estruturado, que se tornou praticamente insustentável. Pode ser muito arriscado e caro modificar até mesmo uma simples seção de código, pois pode ser usado de lugares desconhecidos de maneiras desconhecidas.

Problemas de compatibilidade

O COBOL foi planejado para ser uma linguagem "comum" altamente portátil. No entanto, em 2001, cerca de 300 dialetos foram criados. Uma fonte de dialetos era o próprio padrão: o padrão de 1974 era composto por um núcleo obrigatório e onze módulos funcionais, cada um contendo dois ou três níveis de suporte. Isso permitiu 104.976 variantes possíveis.

O COBOL-85 não era totalmente compatível com as versões anteriores e seu desenvolvimento foi controverso. Joseph T. Brophy, o CIO da Travelers Insurance , liderou um esforço para informar os usuários de COBOL sobre os altos custos de reprogramação da implementação do novo padrão. Como resultado, o Comitê ANSI COBOL recebeu mais de 2.200 cartas do público, a maioria negativas, exigindo que o comitê fizesse alterações. Por outro lado, a conversão para COBOL-85 foi pensada para aumentar a produtividade nos próximos anos, justificando assim os custos de conversão.

Sintaxe detalhada

A sintaxe COBOL tem sido frequentemente criticada por sua verbosidade. Os proponentes dizem que isso pretendia tornar o código autodocumentável , facilitando a manutenção do programa. O COBOL também foi projetado para ser fácil para os programadores aprenderem e usarem, embora ainda seja legível para funcionários não técnicos, como gerentes.

O desejo de legibilidade levou ao uso de sintaxe e elementos estruturais semelhantes ao inglês, como substantivos, verbos, cláusulas, sentenças, seções e divisões. No entanto, em 1984, os mantenedores de programas COBOL estavam lutando para lidar com códigos "incompreensíveis" e as principais mudanças no COBOL-85 estavam lá para ajudar a facilitar a manutenção.

Jean Sammet, um membro do comitê de curto alcance, observou que "pouca tentativa foi feita para atender ao programador profissional, na verdade, as pessoas cujo principal interesse é a programação tendem a ficar muito insatisfeitas com o COBOL", o que ela atribuiu à sintaxe detalhada do COBOL.

Isolamento da comunidade de ciência da computação

A comunidade COBOL sempre esteve isolada da comunidade da ciência da computação. Nenhum cientista da computação acadêmico participou do projeto do COBOL: todos os membros do comitê vieram do comércio ou do governo. Os cientistas da computação na época estavam mais interessados ​​em campos como análise numérica, física e programação de sistemas do que nos problemas comerciais de processamento de arquivos que o desenvolvimento do COBOL abordou. Jean Sammet atribuiu a impopularidade do COBOL a uma "reação esnobe" inicial devido à sua falta de elegância, à falta de cientistas da computação influentes participando do processo de design e ao desdém pelo processamento de dados comerciais. A especificação COBOL usou uma "notação" única, ou metalinguagem , para definir sua sintaxe em vez da nova forma Backus-Naur que o comitê não conhecia. Isso resultou em críticas "severas".

Mais tarde, o COBOL sofreu com a escassez de material que o cobria; demorou até 1963 para os livros introdutórios aparecerem (com Richard D. Irwin publicando um livro universitário sobre COBOL em 1966). Em 1985, havia o dobro de livros em FORTRAN e quatro vezes mais em BASIC do que em COBOL na Biblioteca do Congresso . Professores universitários ensinaram linguagens e técnicas mais modernas e de ponta, em vez de COBOL, que se dizia ter uma natureza de "escola profissional". Donald Nelson, presidente do comitê CODASYL COBOL, disse em 1984 que "acadêmicos ... odeiam COBOL" e que os graduados em ciência da computação "tinham 'ódio COBOL' cravado neles".

Em meados da década de 1980, havia também significativa condescendência em relação ao COBOL na comunidade empresarial por parte de usuários de outras linguagens, por exemplo, FORTRAN ou assembler , implicando que o COBOL poderia ser usado apenas para problemas não desafiadores.

Em 2003, COBOL estava presente em 80% dos currículos de sistemas de informação nos Estados Unidos, a mesma proporção que C++ e Java . Dez anos depois, uma pesquisa da Micro Focus descobriu que 20% dos acadêmicos universitários achavam que o COBOL estava desatualizado ou morto e que 55% acreditavam que seus alunos achavam que o COBOL estava desatualizado ou morto. A mesma pesquisa também descobriu que apenas 25% dos acadêmicos tinham programação COBOL em seu currículo, embora 60% pensassem que deveriam ensiná-la.

Preocupações com o processo de design

Dúvidas foram levantadas sobre a competência do comitê de normas. O membro do comitê de curto prazo, Howard Bromberg, disse que havia "pouco controle" sobre o processo de desenvolvimento e que era "atormentado pela descontinuidade de pessoal e ... falta de talento". Jean Sammet e Jerome Garfunkel também observaram que as mudanças introduzidas em uma revisão do padrão seriam revertidas na próxima, devido tanto a mudanças em quem estava no comitê de padrões quanto a evidências objetivas.

Os padrões COBOL sofreram atrasos repetidamente: o COBOL-85 chegou cinco anos depois do esperado, o COBOL 2002 estava cinco anos atrasado e o COBOL 2014 estava seis anos atrasado. Para combater os atrasos, o comitê de padrões permitiu a criação de adendos opcionais que adicionariam recursos mais rapidamente do que esperar pela próxima revisão do padrão. No entanto, alguns membros do comitê levantaram preocupações sobre incompatibilidades entre implementações e modificações frequentes do padrão.

Influências em outras línguas

As estruturas de dados do COBOL influenciaram as linguagens de programação subsequentes. Sua estrutura de registro e arquivo influenciou PL/I e Pascal , e a REDEFINEScláusula foi uma predecessora dos registros variantes de Pascal. As definições explícitas da estrutura de arquivos precederam o desenvolvimento de sistemas de gerenciamento de banco de dados e os dados agregados foram um avanço significativo em relação aos arrays do Fortran.

PICTUREas declarações de dados foram incorporadas ao PL/I, com pequenas alterações.

A facilidade do COBOL COPY, embora considerada "primitiva", influenciou o desenvolvimento das diretivas include .

O foco na portabilidade e padronização significava que os programas escritos em COBOL poderiam ser portáteis e facilitar a disseminação da linguagem para uma ampla variedade de plataformas de hardware e sistemas operacionais. Adicionalmente, a estrutura de divisão bem definida restringe a definição de referências externas à Divisão de Ambiente, o que simplifica em particular as mudanças de plataforma.

Veja também

• Lista alfabética de linguagens de programação
• BLIS/COBOL
• CODASIL
• Comparação de linguagens de programação
• Lista geracional de linguagens de programação § baseado em COBOL
• Lista de compiladores § compiladores COBOL

Notas

Referências

Citações

Fontes

links externos

• COBOL na Curlie
• Padrão de linguagem COBOL (1991; COBOL-85 com alteração 1), do The Open Group