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 normas 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
Você pode começar um programa com PROGRAM-ID (ou METHOD-ID, ou CLASS-ID, se estiver programando orientado a objeto). Acredito que a justificativa para isso seja justamente a possibilidade de se codificar nested programs para definir classes, atributos e métodos… Honestamente, se não for por esse motivo, não vejo nenhuma vantagem. Teria sido melhor manter a tradição.
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…
