COBOL

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

O COBOL foi projetado em 1959 pela 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 y = x;, COBOL tem uma sintaxe mais parecida com o inglês (neste caso, 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.

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ócio em mainframes, embora nos últimos anos tenha surgido um interesse crescente na migração de operações COBOL para cloud computing.

Histórico e especificação

Fundo

No final da década de 1950, os usuários e fabricantes de computadores estavam ficando preocupados 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. Numa época em que novas linguagens de programação proliferavam a uma taxa cada vez maior, a mesma pesquisa sugeria que, se fosse usada uma linguagem comum voltada para negócios, 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 achou que eles "entendiam perfeitamente" 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

Nos dias 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. Ele contou com a presença de 41 pessoas e foi presidido 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 "grande otimismo" e duvidou que a linguagem realmente seria um paliativo.

O comitê diretor se reuniu em 4 de junho e concordou em nomear toda a atividade como Comitê de Linguagens 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 EUA, a Bacia Modelo David Taylor da Marinha e o National Bureau of Standards (agora o National Institute of Standards and Technology). 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 é chamado de "a mãe do COBOL" ou "a avó do COBOL", embora Jean Sammet, 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 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 Sperry Rand& #39;s esforços para criar um idioma baseado no inglês.

Em 1980, Grace Hopper comentou que "COBOL 60 é 95% FLOW-MATIC" e que o COMTRAN teve um "extremamente pequeno" influência. 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] não tentassem nos derrubar".

Recursos do COMTRAN incorporados ao COBOL incluíam fórmulas, a cláusula PICTURE, uma instrução IF 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. Tais recursos incluíam expressões booleanas, fórmulas e tabelas subscritos (í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 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 à comissão executiva no passado dia 4 de setembro. Eles ficaram aquém das expectativas: Joseph Wegstein observou que "contém pontos difíceis e requer alguns acréscimos", 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íam "OCUPADO" (Sistema de Negócios), "INFOSYL" (Linguagem do Sistema de Informação) e "COCOSYL" (Linguagem Comum de Sistemas Computacionais). 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 alcance, 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" gravou nele e o 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 Desconto de RCA,
• Vernon Reeves e Jean E. Sammet de 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 final.

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 eficientes fossem facilmente escritos, para permitir que os usuários mudassem para novos sistemas com o mínimo de esforço e custo e para ser adequado 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, RCA e 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:

A COBOL é uma língua da indústria e não é propriedade de qualquer empresa ou grupo de empresas, ou de qualquer organização ou grupo de organizações.

Nenhuma garantia, expressa ou implícita, é feita por qualquer colaborador ou pelo Comitê COBOL CODASYL quanto à precisão e funcionamento do sistema de programação e linguagem. Além disso, nenhuma responsabilidade é assumida por qualquer contribuinte, ou pelo comitê, em conexão com ele. Os autores e os titulares de direitos autorais do material protegido por direitos autorais usados neste documento são os seguintes:

FLOW-MATIC (marca comercial da Unisys Corporation), Programming for the UNIVAC (R) I and II, Data Automation Systems, copyrighted 1958, 1959, by Unisys Corporation; IBM Commercial Translator Form No. F28-8013, copyrighted 1959 by IBM; FACT, DSI 27A5260-2760, copyrighted 1960 by Minneapolis-Honeywell.

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

COBOL-61 para COBOL-65

Muitas falhas lógicas foram encontradas no COBOL 60, levando Charles Katz, da General Electric, a alertar 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 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. O COBOL Edition 1965 trouxe mais esclarecimentos às especificações e introduziu facilidades para lidar com 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. A 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 era 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.

No entanto, o Comitê de Linguagem de Programação não era muito conhecido. 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, o DELETE e o módulo de segmentação. Os recursos excluídos incluíam a instrução NOTE, a EXAMINE instrução (que foi substituída por INSPECT) e o módulo de acesso aleatório definido pelo implementador (que foi substituído pelo novo sequencial e módulos de E/S relativos). 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 programador". Mais tarde naquele ano, a Data Processing Management Association (DPMA) disse que era "fortemente contra" ao novo padrão, citando "proibitivo" custos de conversão e aprimoramentos que foram "forçados 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.

O 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 instrução EVALUATE e PERFORM embutido foram particularmente bem recebidos 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:

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

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 do 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 objetos 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 no local
• Suporte para conjuntos de caracteres estendidos como Unicode
• Tipos de dados de ponto flutuante e binário (até então, itens binários foram truncados com base na especificação base-10 da sua declaração)
• Resultados aritméticos portáteis
• Tipos de dados de bits e booleanos
• Ponteiros e sintaxe para obter e liberar armazenamento
• O SCREEN SECTION para interfaces de usuário baseadas em texto
• O VALIDATE facilidades
• Melhor interoperabilidade com outras linguagens de programação e ambientes-quadro, tais como. NET e Java.

Três correçõ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
• Principais características foram feitas opcionais, como o VALIDATE instalação, o escritor de relatórios e a instalação de manipulação de tela
• Sobrecarga de métodos
• Tabelas de capacidade dinâmica (uma característica retirada do rascunho de 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.

Próximo ao 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, pesquisas da Computerworld (de 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, COBOL era usado para a maioria de seu software interno. 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.

Recursos

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 x É MAIOR DO QUE y ou mais concisamente como x MAIOR y ou x > y. Condições mais complexas podem ser "abreviadas" removendo condições e variáveis repetidas. Por exemplo, a > b E a > c OU a = d pode ser abreviado para a > b E c OU = d. Para oferecer suporte a essa sintaxe semelhante ao inglês, o COBOL possui 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, IN e OF palavras-chave podem ser usadas alternadamente, assim como TIME e TIMES e VALOR e VALORES.

Cada programa COBOL é composto de quatro itens lexicais básicos: palavras, literais, sequências 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, 'Olá!'). 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 de 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 instrução ADD:

ADDNão. Não. (identificador-1literal-1?...... ANão. Não. (identificador-2Não.ROUNDONão. Não. ]?...... Não.|Vamos.SIZENão. Não. ERRONão. Não. declaração imperativo-1NÃONão. Não. Vamos.SIZENão. Não. ERRONão. Não. estado imperativo-2|]Não.END-ADDNão. Não. ]{displaystyle begin{array}{l}{underline {text{ADD}}},{begin{Bmatrix}{text{identifier-1}}\{text{literal-1}}end{Bmatrix}}dots ;{underline}}text{TO}},left,{underline} {text{NOT}}},{text{ON}},{underline {text{SIZE}}},{underline {text{ERROR}}},{text{imperative-statement-2}}\end{array}}right|right]quad left[,{underline {text{END-ADD}}},right]end{array}}}

Esta descrição permite as seguintes variantes:

ADD 1 A xADD 1, um, b) A x ROUNDO, Sim., zangão. ROUNDOADD um, b) A c Vamos. SIZE ERRO  DISPLICAÇÃO "Error"END-ADDADD um A b) NÃO SIZE ERRO  DISPLICAÇÃO "Não há erro" Vamos. SIZE ERRO  DISPLICAÇÃO "Error"

Formato de código

Convés de programa COBOL de cartões perfurados, dos anos 1970

O auge da popularidade do COBOL coincidiu com a era das máquinas perfuradoras e 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 livre. 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 pode ser colocado em qualquer lugar e também pode ser usado em código-fonte de formato fixo. As linhas de continuação não estão presentes e a diretiva >>PAGE 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: INVOKE declaração, que age de forma semelhante a CALL, ou por meio de inline chamada de método, que é análoga ao uso de funções.

* São equivalentes.INVOKE A minha classe "foo" RETURING varMOVIMENTO A minha classe:"foo" A var * Inline método invocation

COBOL não fornece uma maneira de ocultar métodos. Os dados da classe podem ser ocultados, entretanto, declarando-os sem uma cláusula PROPERTY, 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 linha sequencial, 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:01 alguma gravação. * item de registro de grupo agregado  05:00 Não. PIC 9(10). * Artigo elementar  05:00 a data. * Aggregar (sub) item de registro de grupo  10. o ano PIC 9(4). * Artigo elementar  10. o mês PIC 99. * Artigo elementar  10. o dia PIC 99. * Artigo elementar

No exemplo acima, item elementar num e item de grupo the-date estão subordinados ao registro some-record, enquanto itens elementares o ano, o-mês e the-day fazem parte do item de grupo a-data.

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

  01:01 data de venda.  05:00 o ano PIC 9(4).  05:00 o mês PIC 99.  05:00 o dia PIC 99.

Os nomes o ano, o mês e the-day são ambíguos por si mesmos, pois mais de um item de dados é definido com esses nomes. Para especificar um item de dados específico, por exemplo, um dos itens contidos no venda-data, o programador usaria o -year IN sale-date (ou o equivalente o -ano da data de venda). 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. Este nível de dados, também referido pelo associado RENAMES cláusula, 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:01 registro do cliente.  05:00 cust-key PIC X(10).  05:00 cust-name.  10. cust-first-name PIC X(30).  10. cust-last-name PIC X(30).  05:00 O que foi? PIC 9(8).  05:00 equilíbrio de cust PIC 9(7)V99.    66 cust-personal-detalhes RENAMES cust-name VERDADE O que foi?.  66 cust-all-detalhes RENAMES cust-name VERDADE equilíbrio de cust.

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, nome da propriedade e sales-region, que são itens de dados não pertencentes ao grupo que são independentes de (não subordinados a) quaisquer outros itens de dados:

  77 nome de propriedade PIC X(80).  77 região de vendas 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 cláusula VALUE. 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 tipo de salário item de dados. Quando o item de dados contém um valor de 'H', o nome da condição salário-é-por-hora é verdadeiro, enquanto que quando contém um valor de & #39;S' ou 'Y', o nome da condição salário -is-yearly é verdadeiro. Se o item de dados contiver algum outro valor, ambos os nomes de condição serão falsos.

  01:01 Tipo de salário PIC X.  88 salário é hora VALORES "H".  88 salário é anual VALORES "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 IMAGEM (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, um 9 indica um dígito decimal e um S indica 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 + definem as posições dos caracteres bem como 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 um + à esquerda desta posição conterá 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. Especificações de imagem contendo apenas dígitos (9) e sinal (Os caracteres S) definem puramente itens de dados numéricos, enquanto especificações de imagem contendo alfabéticos (A) ou alfanumérico (X) definem itens de dados alfanuméricos. A presença de outros caracteres de formatação define itens de dados numéricos editados ou alfanuméricos editados.

Cláusula USAGE

A cláusula USAGE declara o formato no qual os dados são armazenados. Dependendo do tipo de dados, ele pode complementar ou ser usado no lugar de um PICTURE. 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 pelo PICTURE cláusula ou por uma USAGE cláusula como BINARY-LONG
• USAGE COMPUTATIONAL, onde os dados podem ser armazenados em qualquer formato que a implementação fornece; muitas vezes equivalente aUSAGE BINARY
• USAGE DISPLAY, o formato padrão, onde os dados são armazenados como uma string
• Ponto flutuante, em um formato dependente da implementação ou de acordo com o IEEE 754
• USAGE NATIONAL, onde os dados são armazenados como uma string usando um conjunto de caracteres estendido
• USAGE PACKED-DECIMAL, onde os dados são armazenados no menor formato decimal possível (tipicamente embalado decimal codificado binário)

Redator

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órios, que são arquivos que só podem ser gravados por meio de instruções do redator de relatórios.

  FED  relatório-out RELATÓRIO relatório de vendas.

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árquicas. As quebras de controle ocorrem quando uma variável-chave altera seu valor; por exemplo, ao criar um relatório detalhando os clientes' pedidos, 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  relatório de vendas  PAPEL LIMITOS 60 LIGAÇÃO  PRIMEIRA DETADOS 3 CONTROLOS nome do vendedor.  01:01 TYPE PAPEL HEADING.  03:03 COLOCAÇÃO 1 VALORES "Relatório de Vendas".  03:03 COLOCAÇÃO 74 VALORES "Página".  03:03 COLOCAÇÃO 79 PIC Z9 TRIBUNAL PAGE-COUNTER.  01:01 vendas no dia TYPE DETADOS, LINHA + 1.  03:03 COLOCAÇÃO 3 VALORES "Vendas em".  03:03 COLOCAÇÃO 12 PIC 99/99/9999 TRIBUNAL data de vendas.  03:03 COLOCAÇÃO 21 VALORES "estão".  03:03 COLOCAÇÃO 26 PIC $$$$9.99 TRIBUNAL vendas-montante.  01:01 vendas inválidas TYPE DETADOS, LINHA + 1.  03:03 COLOCAÇÃO 3 VALORES "Reconhecimento invulgar".  03:03 COLOCAÇÃO 19 PIC X(34) TRIBUNAL registro de vendas.  01:01 TYPE CONTROLO FITOSSANITÁRIO HEADING nome do vendedor, LINHA + 2.  03:03 COLOCAÇÃO 1 VALORES Vendedor:.  03:03 COLOCAÇÃO 9 PIC X(30) TRIBUNAL nome do vendedor.

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

Relatório de Vendas Página 1

Vendedor: Howard Bromberg
As vendas em 10/12/2008 foram $1000.00
As vendas em 12/12/2008 foram $0.00
As vendas em 13/12/2008 foram $31.47
RECORD INVALID: Howard Bromberg XXXXYY

Vendedor: Howard Discount
...
Relatório de Vendas Página 12

As vendas em 08/05/2014 foram $543.98
INVALID RECORD: William Selden 12O52014FOOOO
As vendas em 30/05/2014 foram $0.00

Quatro instruções controlam o redator do relatório: INICIAR, que prepara o redator do relatório para impressão; GERAR, 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:

  PARECER INP vendas, OUTROS relatório-out  INICIAÇÃO relatório de vendas   PERFORMAÇÃO UNIÃO EUROPEIA 1 < 1 LER vendas  EM FIM  EXPRESSO PERFORMAÇÃO  END-READ   VALIDO registro de vendas  IF registro válido  GERAL vendas no dia  ELSE  GERAL vendas inválidas  END-IF  END-PERFORM   TERMINAÇÃO relatório de vendas  CLOSE vendas, relatório-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 procedimentos

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 segue os procedimentos de um programa até que seja encerrado. Para usar procedimentos como sub-rotinas, o verbo PERFORM é usado.

Uma instrução PERFORM lembra um pouco uma chamada de procedimento em linguagens mais recentes no sentido de que a execução retorna ao código seguindo o PERFORM 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 chamada usando uma instrução simples como EXECUTAR sub-rotina, então o controle retorna no final do procedimento chamado. No entanto, PERFORM é incomum, pois pode ser usado para chamar um intervalo abrangendo uma sequência de vários procedimentos adjacentes. Isso é feito com o PERFORM sub-1 THRU sub-n construção:

PROCESSO Então.... PERFORMAÇÃO ALPHA PERFORMAÇÃO ALPHA VERDADE GAMMA POLÍTICA RECURSOS.ALPHA. DISPLICAÇÃO A '.BETA. DISPLICAÇÃO "B" '.GAMMA. DISPLICAÇÃO 'C'.

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

PERFORM também difere das chamadas de procedimento convencionais em que não existe, 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 um PERFORM declaração em si), mas requerem 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 um PERFORM que foi chamado anteriormente, mas ainda não foi concluído, o padrão COBOL 2002 estipula que o comportamento é indefinido.

O motivo é 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 não houver PERFORM instruções acontecem, o controle flui de cima para baixo através do programa. Mas quando uma instrução PERFORM é executada, ela modifica a continuação endereço do procedimento chamado (ou o último procedimento do intervalo chamado, se PERFORM THRU), de forma que o controle retornará ao site da chamada ao final. O valor original é salvo e restaurado posteriormente, mas há apenas uma posição de armazenamento. Se duas invocações aninhadas operarem 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. DISPLICAÇÃO ' ' PERFORMAÇÃO LABEL2 VERDADE LABEL3 POLÍTICA RECURSOS.LABEL2. DISPLICAÇÃO 2 ' PERFORMAÇÃO LABEL3 VERDADE LABEL4.LABEL3. DISPLICAÇÃO 3 '.LABEL4. DISPLICAÇÃO 4 '.

Alguém pode esperar que a saída deste programa seja "1 2 3 4 3": Após exibir "2", o segundo PERFORM causa "3" e "4" a ser exibido e, em seguida, a primeira chamada continua com "3". Em implementações COBOL tradicionais, esse não é o caso. Em vez disso, a primeira instrução PERFORM define o endereço de continuação em o final de LABEL3 para que volte para o site da chamada dentro de LABEL1. A segunda instrução PERFORM define o retorno no final de LABEL4 mas 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 chegar ao final de LABEL3, ele volta para a instrução PERFORM 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, os dois PERFORM não interferem entre si 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 EXECUTAR não pode ser usado para escrever código recursivo. Outro exemplo simples para ilustrar isso (ligeiramente simplificado de Veerman & Verhoeven 2006):

 MOVIMENTO 1 A A PERFORMAÇÃO LABEL  POLÍTICA RECURSOS.LABEL. DISPLICAÇÃO A IF A < 3 ADD 1 A A PERFORMAÇÃO LABEL  END-IF  DISPLICAÇÃO "Erro" '.

Pode-se esperar que a saída seja "1 2 3 END END END" e, na verdade, é 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

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 relatório escritor. As declarações do redator do relatório são abordadas na seção do redator do relatório.

Fluxo de controle

As declarações condicionais do COBOL são IF e AVALIAR. AVALIAR é uma declaraçã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:

AVALIAÇÃO TRÊS ALSO velocidade desejada ALSO velocidade atual QUANDO tampa fechada ALSO velocidade mínima VERDADE velocidade máxima ALSO LEI Obrigado. velocidade desejada PERFORMAÇÃO speed-up-máquina QUANDO tampa fechada ALSO velocidade mínima VERDADE velocidade máxima ALSO GREATER Obrigado. velocidade desejada PERFORMAÇÃO máquina lenta QUANDO lid-open ALSO Qualquer ALSO NÃO ZERO  PERFORMAÇÃO parada de emergência QUANDO OUTROS  CONTEÚDOEND-EVALUIAÇÃO

A instrução PERFORM é usada para definir loops que são executados até que uma condição seja verdadeira (não enquanto verdadeira, 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). CALL e INVOKE chama 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). CANCELAR descarrega subprogramas da memória. GO TO faz com que o programa pule para um procedimento especificado.

A instrução GOBACK é uma instrução de retorno e a instrução STOP interrompe o programa. A instrução EXIT tem seis formatos diferentes: pode ser usado 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 geradas por uma instrução RAISE e capturado com um manipulador, ou declarativo, definido no DECLARATIVOS parte da divisão do procedimento. Declarativos são seções que começam com uma instrução USE que especifica o erros para lidar. As exceções podem ser nomes ou objetos. RESUME é usado em um declarativo para pular para a instrução após aquele que levantou a exceção ou para um procedimento fora do DECLARATIVOS. 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 pelo autodescritivo OPEN , CLOSE, LER e WRITE declarações junto com mais três: REWRITE, que atualiza um registro; START, que seleciona os registros subsequentes para acessar encontrando um gravar com uma determinada chave; e UNLOCK, que libera um bloqueio no último registro acessado.

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

Manipulação de dados

Os seguintes verbos manipulam dados:

• INITIALIZE, que define itens de dados para seus valores padrão.
• MOVE, que atribui valores aos itens de dados; CIRCULAÇÃO atribui campos semelhantes correspondentes.
• SET, que tem 15 formatos: pode modificar índices, atribuir referências de objetos e alterar capacidades de tabela, entre outras funções.
• ADD, SUBTRACT, MULTIPLY, DIVIDEe COMPUTE, que lida com aritmética (com COMPUTE atribuindo o resultado de uma fórmula a uma variável).
• ALLOCATE e FREE, que lida com memória dinâmica.
• VALIDATE, que valida e distribui dados conforme especificado na descrição de um item na divisão de dados.
• STRING e UNSTRING, que concatenar e dividir cordas, respectivamente.
• INSPECT, que alta ou substitui instâncias de substrings especificados dentro de uma string.
• SEARCH, que procura uma tabela para a primeira entrada satisfazendo uma condição.

Arquivos e tabelas são classificados usando SORT e o verbo MERGE mescla e classifica arquivos. O verbo RELEASE fornece registros para classificar e RETURN recupera registros classificados em ordem.

Rescisão do escopo

Algumas declarações, como IF e LER, podem conter declarações. Tais declarações podem ser encerradas de duas maneiras: por um ponto (rescisão implícita), que encerra todas as declarações não encerradas contidas, ou por um terminador de escopo, que encerra a instrução open correspondente mais próxima.

* Período de terminação ("exterminação implícita")IF inválido. IF No-more-records TEXTO SENTÊNCIA  ELSE  LER arquivo de registro EM FIM SESSÃO No-more-records A TRÊS.* Terminadores de escopo ("exterminação explícita")IF inválido. IF No-more-records CONTEÚDO  ELSE  LER arquivo de registro EM FIM SESSÃO No-more-records A TRÊS  END-READ  END-IFEND-IF

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

IF x DISPLICAÇÃO Sim.. DISPLICAÇÃO zangão..

Aqui, a intenção é exibir y e z se a condição x for verdadeira. No entanto, z será exibido qualquer que seja o valor de x porque a instrução IF é encerrada por um ponto errado após DISPLAY y.

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

IF x IF Sim. DISPLICAÇÃO umELSE  DISPLICAÇÃO b).

No fragmento acima, ELSE associa-se ao diretório IF y em vez de o SE x, causando um bug. Antes da introdução de terminadores de escopo explícitos, impedi-los exigiria SENÃO PRÓXIMO SENTENÇA para ser colocado após o IF interno.

Código automodificável

A especificação COBOL original (1959) suportava o infame ALTER X PARA PROSSEGUIR TO Y, para a qual muitos compiladores geraram código. X e Y são rótulos de procedimento e o estilo GO TO instrução no procedimento X executada após tal ALTER significa VÁ PARA S em vez disso. Muitos compiladores ainda o suportam, mas foi considerado obsoleto no padrão COBOL 1985 e excluído em 2002.

A instrução ALTER foi mal vista porque minou a "localidade do contexto" e tornou a lógica geral de um programa difícil de compreender. Como escreveu o autor do livro didático Daniel D. McCracken 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 uma instrução GO TO 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 "Olá, mundo" programa em COBOL:

  Identificação DIVISÃO.  PROGRAMA-ID. Olá, mundo.  PROCESSO DIVISÃO.  DISPLICAÇÃO "Olá, mundo!"  .

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 uma DIVISÃO DE DADOS vazia, 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.

//COBULG JOB (001),'COBOL BASE TEST ', 000 milhões de euros// CLASSIFICAÇÃO= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =A,MSGCLASS= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =A,VENDA= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =(1,1) 000 milhões de euros//BASE EXECUÇÃO COBULG 000 milhões de euros//COBRA.SYSIN DD * 000 milhões de euros ?* VALIDAÇÃO DE BASE COBOL INSTÂNCIA 000 milhões de euros 01000 Identificação DIVISÃO. 000 milhões de euros 01100 PROGRAMA-ID. HELLO '. 000 milhões de euros 0 AMBIENTE DIVISÃO. 000 milhões de euros 02100 CONFIGURAÇÃO SECÇÃO. 000 milhões de euros 02110 TRIBUNAL DE CONTACTO. GNULINUX. Facilidade 02120 OBJECT-COMPUTER. HERCULTURAS. 00110000 02200 ESPECIAL-NAMES. 00120000 02210 CONSELHO É. CONSELHO. 00130000 03000 DADOS DIVISÃO. 00140000 04000 PROCESSO DIVISÃO. 00150000 04100 00- Não.MAIOR. 00160000 0410 DISPLICAÇÃO Olá, mundo. ' UP CONSELHO. 00170000 04900 POLÍTICA RECURSOS. 00180000//LKED.SYSLIB DD DSNAME= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =SYS1.COBLIBIL,DISP= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =SHR 00190000// DD DSNAME= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =SYS1.LINKLIB,DISP= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =SHR 00200000//Vai..SYSPRINT DD SYSOUT= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =A 00210000// 00220000

Depois de enviar o JCL, o console MVS exibiu:

 19.52.48 JOB 3 $HASP100 COBUCLG EM READER1 COBOL BASE TEST
19.52.48 JOB 3 IEF677I WARNING MESSAGE(S) PARA 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 ESTADO MISSÃO
19.52.48 JOB 3 IEC130I SYSLIB DD ESTADO MISSÃO
19.52.48 JOB 3 IEC130I SYSPUNCH DD ESTADO MISSÃO
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, MUNDO
 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 discordância publicada às observações de Dijkstra, o cientista da computação Howard E. Tompkins afirmou que o COBOL não estruturado tende 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 era o IR PARA declaração. No entanto, tentativas de remover GO TOs do código COBOL, resultou em programas complicados e qualidade de código reduzida. GO TOs foram amplamente substituídos pela classe PERFORM declaração e procedimentos, que promoveu a programação modular e deu fácil acesso a poderosas instalações de looping. No entanto, PERFORM pode ser usado apenas com procedimentos de loop os corpos não foram 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 considerou o maior erro da comissão.

Outra complicação surgiu da capacidade de PERFORM THRU uma sequência especificada 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 conforme 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 impossível de manter. 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 criado para ser uma ferramenta "comum" linguagem. 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 autodocumentado, facilitando a manutenção do programa. O COBOL também foi projetado para ser fácil para os programadores aprenderem e usarem, enquanto ainda é legível para a equipe não técnica, 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 problemas "incompreensíveis" código 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" 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" 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 de Backus-Naur, que o comitê desconhecia. Isso resultou em "grave" crítica.

Posteriormente, o COBOL sofreu com a escassez de material que o cobrisse; 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 ensinavam linguagens e técnicas mais modernas e de ponta, em vez de COBOL, que diziam ter uma "escola profissional" natureza. 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 'odiado COBOL' perfurado 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, sugerindo 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 sobre o processo de design

Dúvidas foram levantadas sobre a competência do comitê de padrões. Howard Bromberg, membro do comitê de curto prazo, disse que havia "pouco controle" sobre o processo de desenvolvimento e que foi "afetado 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 repetidamente atrasos: 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 atrasos, o comitê de padronização permitiu a criação de adendos opcionais que adicionariam recursos mais rapidamente do que esperar pela próxima revisão de padronizaçã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 outros idiomas

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 cláusula REDEFINES 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.