As grandes mudanças do ISO COBOL 2002

As últimas revisões do COBOL publicadas em 2002 e 2014 pela International Standard Organization (ISO) introduziram algumas mudanças significativas na estrutura da linguagem.

Bom? Ruim? Feio? Ou desnecessário?

Como a ISO funciona

A ISO surgiu depois da Segunda Guerra Mundial com o objetivo de promover o desenvolvimento de normais internacionais para fabricação, comércio e comunicação em todos os segmentos, exceto engenharia elétrica e eletrônica.

Ela é formada por institutos nacionais de padronização de 146 países e está localizada em Genebra. O Brasil é representado na ISO pela Associação Brasileira de Normas Técnicas (ABNT) desde a sua fundação em 1940.

Quando uma determinada indústria percebe a necessidade de criação de um padrão, ela se comunica com o instituto nacional do país a que pertence, que por sua vez propõe à ISO um estudo sobre o tema. Se a solicitação for aceita, a ISO estabelece um subcomitê com técnicos indicados pelos institutos de cada país. Esse subcomitê elabora um Draft of International Standard (DIS)que posteriormente será submetido para comentários e votação dos membros permanentes. Se aprovado, esse documento é publicado como Final Draft of International Standard (FDIS) e se transforma numa norma ISO.

A palavra “recomendação” talvez seja mais apropriada do que “norma”. A ISO é um órgão não-governamental e não tem poder “normativo” sobre nenhum governo ou instituição privada. Em alguns casos, como por exemplo no padrão ISO 9000, suas recomendações são aceitas de maneira quase universal. Em outros não.

A ISO e o COBOL

A linguagem COBOL teve diversas especificações e revisões desde que foi criada, em 1959 pelo CODASYL. Algumas dessas revisões introduziram avanços significativos, e ficaram conhecidas pelo ano em que foram publicadas. Assim, é comum ouvirmos falar em COBOL/65, COBOL/74, COBOL/80, COBOL/85 e assim por diante.

Em 2002, a ISO publicou um FDIS revisando algumas regras do COBOL, buscando modernizá-las. Doze anos depois esse documento foi novamente revisto e deu origem ao padrão ISO/IEC 1989:2014. Apesar disso, essa última versão do COBOL ficou conhecida pelo ano da primeira publicação: COBOL/2002.

A recomendação da ISO não descreve como um compilador deve transformar um código fonte em código executável. Ela apenas sugere as regras sintáticas e semânticas que façam com que um programa escrito em COBOL para o equipamento X possa ser recompilado para ser executado no equipamento Y.

A ISO sugere que algumas dessas regras sejam mandatórias. Outras, ela deixa a critério de cada fabricante. Em teoria, um compilador só poderia ser chamado de “COBOL/2002” se implementasse todas as regras mandatórias.

Mudanças: Modernização ou descaracterização da linguagem?

A grande maioria dos compiladores COBOL continua suportando padrões anteriores. O IBM Enterprise COBOL 2002, por exemplo, permite que você compile sem alterações um programa codificado de acordo com as versões de 1965, ou 1974, ou 1985…

Por esse motivo, quem determina se as mudanças são relevantes e serão adotadas são as instalações, os clientes, os analistas de suporte e, em última análise, os próprios programadores. É possível ignorar totalmente qualquer “novidade” que não ofereça um benefício claro e objetivo.

Talvez por isso, acredito que muitas das alterações sugeridas na última revisão da ISO nunca venham a ser adotadas em grande escala. Não porque sejam ruins, mas porque poderiam “ferir” um dos princípios fundamentais da linguagem: a compatibilidade reversa. Qual outra linguagem de programação pode se orgulhar de dizer que tem programas com 50 anos de idade que ainda estão rodando em sistemas de missão crítica?

Vejamos algumas dessas alterações…

Comentários em linha

É possível incluir um comentário após uma instrução, usando “*>”.

IF WT-AC-SALDO > WL-DB-LIMITE         *> SE SALDO ACUMULADO FOR MAIOR QUE
   MOVE "NAO" TO WT-FL-PERMITIDO      *> O LIMITE INFORMADO VIA PARAMETRO
   PERFORM 15-BLOQUEIA-TRANSACAO      *> BLOQUEIA O PROCESSAMENTO
END-IF

Continuação de literais

Não é mais obrigatório que se coloque um hífen na coluna 7 para continuar um literal que não coube na linha anterior. Agora basta incluí-lo após o literal.

MOVE "ENDERECO INFORMADO PELO CLIENTE "-
     "NAO ESTA COMPLETO" TO WS-TX-MSG

Fim das áreas reservadas

A sequence number area (colunas 1 a 6), a indicator area (coluna 7) e a identifier area (colunas 73 a 80) não são mais obrigatórias. Da mesma forma, não precisamos mais nos preocupar com área A (colunas 8 a 11) e área B (colunas 12 a 72).

Um programador (ruim) poderia escrever um programa seguindo o modelo abaixo:

PARAGRAFO-A.
MOVE VARIAVEL-A TO VARIAVEL-B
ADD 1 TO VARIAVEL-C
PERFORM PARAGRAFO-B
UNTIL WT-FILE-STATUS NOT = "00".

Tamanho das linhas

Acaba a limitação de 80 caracteres por linha de código, resquício dos tempos do cartão perfurado. Agora os programas podem ter linhas com até 255 caracteres.

Classificação de tabelas internas

Passa a existir um comando específico para classificação de tabelas internas (arrays), como no exemplo abaixo:

01 WT-TABELA.
   03  WT-OCORRENCIAS OCCURS 10 TIMES
                      INDEXED BY INDICE
                      ASCENDING WT-ELEMENTO.
       05 WT-ELEMENTO PIC X(002).
       05 FILLER      PIC X(001).

...

MOVE "5A 1A 2B 1X 5C" TO WT-TABELA

SORT WT-TABELA

DISPLAY WT-TABELA

No exemplo acima, o comando DISPLAY exibiria “1A 1X 2B 5A 5C”. Também seria possível incluir várias cláusulas ASCENDING/DESCENDING na declaração da tabela para classificá-la por múltiplos itens elementares.

E pensar que quebramos a cabeça para aprender bubble sort, radix sort, selection sort e coisas semelhantes…

WRITE FROM literal

O padrão 2002 permite comandos como os mostrados abaixo:

WRITE REGISTRO FROM SPACES
WRITE REGISTRO FROM ALL "X"

Nome de parágrafo não obrigatório

Não é mais preciso colocar um parágrafo no início da PROCEDURE DIVISION ou de uma SECTION. O trecho abaixo é considerado válido:

PROCEDURE DIVISION.

    PERFORM A1-INICIO
    PERFORM A2-PROCESSO
    PERFORM A3-FIM

STOP RUN.

PROGRAM-ID literal

É possível usar um literal como PROGRAM-ID. Essa opção pode ser útil quando estamos num ambiente que permite nomes longos e/ou case sensitivos, como no exemplo abaixo:

IDENTIFICATION DIVISION.
PROGRAM-ID. "CalculaImpostoDeRenda".

Concatenação de literais

Lembra do comando STRING? Pois é… agora é possível codificar coisas assim:

MOVE "FAVOR ENTRAR EM CONTATO COM " & WT-NM-SUPORTE &
     " PELO TELEFONE " & WT-NR-TELEFONE TO WT-TX-MENSAGEM

Definição de constantes

Variáveis são variáveis; constantes são constantes:

WORKING-STORAGE SECTION.
01  WT-VARIAVEIS.
    03  WT-AC-SALDO  PIC S9(013)V9(002) COMP-3 VALUE ZEROS.
    03  WT-AC-DEBITO PIC S9(013)V9(002) COMP-3 VALUE ZEROS.

01  WT-CONSTANTES.
    03  WT-NM-SISTEMA  CONSTANT VALUE "FATURAMENTO".
    03  WT-NM-PROGRAMA CONSTANT VALUE "ABC0809".

EXIT agora sai

O EXIT era aquele comando que a gente usava como o comando único de um parágrafo que marcava o fim do parágrafo anterior. Agora ele ganhou uma utilidade prática: é possível sair de PERFORMs IN-LINE ou mesmo de parágrafos usando esse comando:

   PERFORM PARAGRAFO-A.

   ...

PARAGRAFO-A.

   IF A0101-NM-CLIENTE = SPACES
      MOVE "NOME DO CLIENTE NAO PREENCHIDO" TO WT-TX-MSG
      EXIT
   END-IF

   IF A0101-TX-ENDERECO = SPACES
      MOVE "ENDERECO NAO PREENCHIDO" TO WT-TX-MSG
      EXIT
   END-IF

   ...

IDENTIFICATION DIVISION é opcional

Essa foi a que mais me incomodou. Você pode começar um programa com PROGRAM-ID (ou METHOD-ID, ou CLASS-ID, se estiver programando orientado a objeto). Na boa… se não houver uma IDENTIFICATION DIVISION no início do programa vou levar três dias para entender que aquilo é COBOL…

Mas acredito que a justificativa para isso seja justamente a possibilidade de se codificar nested programs para definir classes, atributos e métodos… Se não fosse por esse motivo, teria sido melhor manter a tradição e deixar a velha ID DIVISION do jeito que estava… 😀

Acabou a hegemonia do hífen

Você agora pode usar o underscore para definir nomes de arquivos, variáveis, parágrafos, telas, relatórios etc… ARQUIVO_CLIENTE, SOMA_VALORES, WT_TOTAIS agora são nomes válidos.

Orientação a objetos

A ISO também tentou “pacificar” as diferentes sintaxes e semânticas dos compiladores que tentavam implementar a orientação a objetos em COBOL. Esse tema é mais longo. Temos um artigo específico sobre esse assunto que pode ser lido aqui.

Conclusão

Existem pelo menos outras 100 mudanças que foram implementadas na revisão de 2002 e que já foram adotadas (parcialmente) pelos melhores compiladores do mercado. Algumas achei bem interessantes. Outras confesso que não adotaria.

Existe um documento excelente disponível na internet que foi escrito por Tom Ross e William Klein, com a opinião deles sobre cada uma das mudanças sugeridas. É um documento longo, mas comenta cada uma das mudanças propostas na revisão de 2002. Esse documento está disponível aqui.

E você? Gostou das mudanças? Adotaria alguma? Ignoraria todas elas? Deixe sua opinião aqui pra gente trocar uma ideia…

 


 

Publicado por

P.A.Dias

Paulo André tem mais de 30 anos de experiência em desenvolvimento e manutenção de sistemas em plataforma mainframe. Atuou como programador, analista, coordenador técnico, gerente e executivo de projetos em uma multinacional da área de Tecnologia da Informação.

Um comentário em “As grandes mudanças do ISO COBOL 2002”

  1. Olá amigos.
    Sou programador em Cobol há mais de 20 anos. Meu copilador é Cobol 4.5 e funciona perfeitamente. Mas agora estou tendo problemas com arquivos XML. A pergunta é o que devo fazer? Baixei o CobolWare mas não estou conseguindo usar o mesmo em conjunto com o meu sistema.

Deixe uma resposta para Jorge Domiciano Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *