2. Estrutura da linguagem

O Cobol foi desenvolvido na era dos primeiros mainframes, que dispunham apenas de perfuradoras e leitoras de cartão para receber informações do meio exterior. Cada linha de programa era, na verdade, um cartão de papelão perfurado e o programa completo era uma pilha de cartões. Muitas das características da linguagem, presentes até hoje, foram definidas nessa época.

Linha de programa

Por causa dos cartões perfurados, até hoje as linhas de um programa Cobol podem ter no máximo 80 caracteres, divididos em cinco áreas:

• Sequence number area: Vai da coluna 1 à coluna 6. Ela era originalmente usada para numerar as linhas (ou cartões) do programa, facilitando a reordenação manual, quando necessário. Os compiladores atuais não exigem mais que essa coluna esteja numerada e ignoraram qualquer informação colocada ali. Alguns pacotes de gestão de configuração (e alguns programadores) usam esse espaço para marcar as alterações de código.
• Indicator area: É formada apenas pela coluna 7. Essa coluna pode conter alguns caracteres que fornecem informações específicas para o compilador. Por exemplo, um asterisco (*) nesta posição indica que a linha é apenas um comentário; um hífen (-) indica que uma sentença ou um literal não coube na linha anterior e continuará nesta linha.
• Área A: Vai da coluna 8 à coluna 11. Algumas estruturas de um programa Cobol (divisões, seções, parágrafos e variáveis de nível 1, especificamente) devem começar obrigatoriamente neste espaço.
• Área B: Vai da coluna 12 à coluna 72. É usada basicamente para a codificação de variáveis de nível superior a 1, cláusulas e comandos em geral.
• Identifier Area: Vai da coluna 73 à coluna 80. Quando os programas eram codificados em cartões perfurados, essa área era usada para registrar o nome do programa, que se repetia em todos os cartões. Compiladores atuais ignoram as informações presentes neste espaço. Assim como acontece com a sequence number area, alguns pacotes de gestão de configuração (e alguns programadores) usam essas posições para registrar informações sobre as alterações realizadas sobre o programa.

Depois da revisão de 2002, o COBOL passou a permitir uma nova estrutura de linha de código, chamado free format. Nesse formato, não há a restrição de 80 caracteres por linha, e as linhas não precisa mais respeitar as áreas mencionadas acima. Muitos gostaram da novidade, outros detestaram. De qualquer forma, a grande maioria das instalações ainda segue o modelo tradicional.

Quem vê o COBOL pela primeira vez considera esse formato anacrônico e excessivamente rígido. Os editores de programa, no entanto, costumam facilitar o trabalho do programador, permitindo a configuração de zonas de tabulação (nas colunas 7, 8, 12 e depois de 4 em 4 espaços) ou oferecendo recursos como a autoedentação, que posiciona as “palavras certas” nas “colunas certas”.

O COBOL não é case sensitive. Você pode codificar o programa combinando letras maiúsculas ou minúsculas. Curiosamente, quase todos os programas que você vai encontrar foram escritos apenas com letras maiúsculas, e isso é quase uma tradição que vem do tempo em que os programas eram codificados em terminais de mainframes. O ideal é que você respeite sempre o padrão adotado pela sua empresa para manter a coerência visual dos sistemas.

Nesse livro, programas e exemplos serão codificados com letras maiúsculas, que é o formato mais frequentemente encontrado nas empresas.

Linhas de comentário

As linhas de comentários num programa COBOL são aquelas que têm um asterisco na coluna 7. Essas linhas são ignoradas pelo compilador.

*----------------------------------------------------------------*
* OBJETIVO: ABRIR ARQUIVOS E TESTAR FILE STATUS
*----------------------------------------------------------------*
 12-ABRE-ARQUIVOS.

     MOVE "NAO" TO WT-FL-ERRO.

     OPEN I-O AIA0103
     IF WT-ST-AIA0103 NOT = "00" AND "05" AND "35"
          MOVE "AIP0103" TO XXERROS-NM-PROGRAMA
          MOVE "AIA0103" TO XXERROS-NM-ARQUIVO
          MOVE WT-ST-AIA0103 TO XXERROS-CD-ERRO
          CALL "XXERROS" USING XXCOMUM-PARAMS
                               XXERROS-PARAMS
          MOVE "SIM" TO WT-FL-ERRO
     END-IF.

Palavras reservadas

Palavras reservadas são aquelas que têm um significado pré-determinado para o compilador e que, por esse motivo, não podem ser usadas pelos programadores para dar nomes a parágrafos, variáveis, arquivos etc.

Todo compilador COBOL adota um dos padrões ANS/ISO (74, 85, 2002, 2014…) e implementam algumas extensões que não foram previstas pelo padrão. Por esse motivo, a lista de palavras reservadas pode variar de compilador para compilador e o melhor lugar para obter essa lista é o próprio manual.

Se você seguir o padrão de nomenclatura que usaremos nesse livro dificilmente usará uma palavra reservada acidentalmente. Mas se eventualmente isso acontecer o compilador se encarregará de alertá-lo em tempo de compilação para que faça as devidas correções.

Nomes definidos pelo programador

Além das palavras reservadas, que formam o vocabulário da linguagem, o programador terá que dar nomes a diversos componentes, tais como parágrafos, arquivos, campos dos arquivos, variáveis de trabalho, argumentos de execução etc. Muitos manuais se referem a esses nomes como data names ou data items.

Os nomes definidos pelo programador podem ter até 30 caracteres e devem ser formados por letras, números e hífens.

Dois fatores precisamos ser considerados pelo programador no momento em que os nomes são criados:

1. É importante que o nome tenha um significado que qualquer programador consiga entender no futuro. Uma variável de trabalho chamada SALARIO-MENSAL ou CONTADOR-LIDOS é melhor do que SL ou CL
2. Programas comerciais frequentemente trabalham com diversos arquivos, dependem de dezenas de campos de arquivo e variáveis de trabalho e seus algoritmos são formados por vários parágrafos. É importante, portanto, seguir o padrão de nomenclatura definido pela instalação, ou adotar um padrão próprio, se a empresa não o fizer.

Uma prática muito comum é usar prefixos para diferenciar os campos de um arquivo das variáveis de trabalho usadas pelo programa. Por exemplo, CRA0201-SALARIO-MENSAL sugere que o campo SALARIO-MENSAL pertence ao arquivo CRA0201, enquanto WT-CONTADOR-LIDOS dá a entender que essa é uma variável de trabalho definida na WORKING-STORAGE, sobre a qual falaremos mais adiante.

Divisões, seções, parágrafos e sentenças

O COBOL foi concebido para que o programa fonte tivesse uma estrutura parecida com um texto escrito em inglês. Todo programa possui quatro divisões. Cada divisão é organizada em seções, que por sua vez são formadas por parágrafos. Cada parágrafo possui uma ou mais sentenças. Essa hierarquia tem por objetivo facilitar a localização de determinadas informações, da mesma forma que capítulos, tópicos, parágrafos e frases facilitam a localização de determinados assuntos num livro.

A figura abaixo mostra alguns exemplos de divisões, seções, parágrafos e sentenças num programa COBOL.

Mais adiante falaremos em detalhes sobre cada uma dessas estruturas. Por ora, vamos pegar como exemplo a divisão chamada ENVIRONMENT DIVISION. Nessa divisão ficam informações sobre o ambiente onde o programa será executado. Uma das seções da ENVIRONMENT se chama INPUT-OUTPUT SECTION. Nessa seção estarão informações sobre as entradas e saídas do programa. Um dos parágrafos da INPUT-OUTPUT se chama FILE-CONTROL, onde são declarados os arquivos que serão lidos, gravados e/ou alterados. O parágrafo FILE-CONTROL é formado por uma ou mais cláusulas SELECT. Haverá um SELECT para cada arquivo, informando seu formato, seu nome interno (o nome que será usado pelo programa), seu nome externo (o nome do arquivo para o sistema operacional) e algumas outras informações.

Nos próximos capítulos veremos em detalhes cada uma das divisões e seções de um programa COBOL.

O uso do ponto

O uso do ponto em COBOL tem papel semelhante ao ponto-e-vírgula de outras linguagens, mas pode causar alguma confusão, no início, porque seu uso costuma ser mais flexível.

Todos os nomes de divisão, seção e parágrafo devem terminar com um ponto. Nas três primeiras divisões (IDENTIFICATION, ENVIRONMENT e DATA) qualquer sentença também deve terminar com um ponto, como no exemplo abaixo:

IDENTIFICATION DIVISION.
PROGRAM-ID. LTP0101.
AUTHOR. JOAO DA SILVA.
DATE-WRITTEN. 25/10/2016.

Na PROCEDURE DIVISION, que é onde ficam os comandos do programa, apenas a última sentença de cada parágrafo precisa de um ponto. Isso só é válido para compiladores que adotaram o padrão COBOL ANS/85 ou posterior, já que foi nesta revisão que a ANS introduziu o conceito de delimitadores de escopo (END-IF, END-READ, END-PERFORM etc.). Antes do surgimento dos delimitadores, o ponto precisa ser usado para encerrar o escopo de alguns comandos.

Repare no exemplo abaixo que o único comando que precisa de um ponto é o STOP RUN na última linha, por ser o último comando do parágrafo CALCULA-TABUADA.

PROCEDURE DIVISION.
CALCULA-TABUADA.

    ACCEPT “INFORME UM NUMERO: “ WT-BASE
    PERFORM VARYING I FROM 1 BY 1 UNTIL I > 10
        DISPLAY WT-BASE “ X “ I “ = “ WT-BASE * I
    END-PERFORM
    STOP RUN.

Literais e constantes figurativas

Literais são valores constantes, formados por um conjunto de caracteres. Eles podem ser usados tanto na atribuição do valor inicial de uma variável, na alteração desse valor inicial durante a execução do programa, na exibição de mensagens ou na formação de relatórios.

77  TITULO-RELATORIO PIC X(030) VALUE “FLUXO DE CAIXA”.
MOVE “CONTAS A RECEBER 2016” TO SUBTITULO
DISPLAY “TERMINO DO PROGRAMA”

Nos exemplos acima, a primeira linha mostra o literal “FLUXO DE CAIXA” sendo atribuído como valor inicial para a variável TITULO-RELATORIO. A segunda linha, mostra uma variável chamada SUBTITULO recebendo como valor o literal “CONTAS A RECEBER 2016”. A terceira linha mostra o literal “TERMINO DO PROGRAMA” sendo exibido para o usuário.

Literais alfanuméricos, como os que usamos nesses exemplos, são formados por letras, números e caracteres especiais (espaços em branco, asteriscos, hifens…) e devem ser delimitados por aspas duplas ou simples, dependendo da parametrização que foi estabelecida para o compilador

Literais numéricos são formados por números, sinais de mais ou menos e pontos decimais, como nos exemplos abaixo:

77 PERCENTUAL-FINAL PIC 9(003) VALUE 100.
MOVE 3600 TO MINUTOS-DIA
DISPLAY “COTACAO DO DOLAR: “ 3.65

A primeira linha mostra o literal numérico 100 sendo usado como valor inicial na declaração da variável PERCENTUAL-FINAL. A segunda linha mostra literal numérico 3600 sendo atribuído à variável MINUTOS-DIA em tempo de execução. A terceira linha exibe na tela do usuário o literal alfanumérico “COTACAO DO DOLAR: “ seguido do literal numérico 3.65, que possui duas casas decimais.

Algumas palavras reservadas do COBOL substituem alguns literais numéricos e alfanuméricos. Essas palavras são chamadas de constantes figurativas. Podemos escrever, por exemplo…

MOVE “     “ TO NOME-DO-CLIENTE

Ou…

MOVE SPACES TO NOME-DO-CLIENTE

Neste caso, a palavra reservada SPACES está substituindo um literal alfanumérico formado apenas por espaços em branco.

Outras constantes figurativas muito usadas no COBOL são:

• HIGH-VALUES: Equivale a um literal alfanumérico formado apenas pelo maior caracter da tabela ASCII ou EBCDIC (normalmente o hexadecimal x”FF”).
• LOW-VALUES: Equivale a um literal alfanumérico formado apenas pelo menor caracter da tabela ASCII ou EBCDIC (normalmente o hexadecimal x”00”).
• ZEROS: Equivale a um literal numérico formado apenas por zeros.
• ALL caracter: Equivale a um literal alfanumérico formado apenas pelo caracter que aparece em seguida. Exemplos: ALL “X”, ALL “A”, ALL “1” etc.

Assim, se você precisar zerar uma variável tempo de execução, você pode escrever:

MOVE ZEROS TO NOME-DA-VARIAVEL

Ou se quiser criar uma variável preenchida com asteriscos, pode fazer:

03 WR-CAB3 PIC X(080) VALUE ALL “*”.

Construção e execução de um programa

Um programa COBOL passa por três etapas principais antes de ser executado: edição, compilação e linkedição.

Na edição, o programador constrói ou altera o programa fonte usando o editor de texto disponível no ambiente de desenvolvimento.

O programa fonte passa então por um processo de compilação, que verificará se as regras de sintaxe e codificação da linguagem foram cumpridas. Em mainframes, o compilador normalmente é executado por um job escrito em JCL que foi submetido pelo programador. As mensagens emitidas pelo compilador, inclusive mensagens de erro, são exibidas em relatórios gerados pelo job e disponibilizados num spool de execução após a compilação.

No Linux, normalmente o compilador é executado por um shell script que exibe as mensagens de erro na tela e/ou redireciona essas mensagens para um arquivo texto.

Existem também IDEs com interfaces gráficas (Windows, X-Window, Mac OS…) que compilam e exibem os resultados em janelas.

Se não houver nenhum erro impeditivo na compilação, um programa objeto em linguagem de máquina será gerado. Esse programa objeto passa então por um processo chamado de linkedição, que basicamente estabelece endereços de memória para instruções e dados utilizados pelo programa. Normalmente o linkeditor é executado no mesmo job do compilador (o  linkeditor é um step a mais no mesmo job ou script, de compilação).

O linkeditor também gera mensagens para o programador através de relatórios que ficam num spool de execução (no caso dos mainframes), na tela e/ou num arquivo texto (no caso do Linux) ou numa janela específica (no caso das IDEs com interfaces gráficas).

Se nenhum problema for detectado nesta etapa, o linkeditor gera um módulo de carga, que na prática é o programa executável.

Alguns comentários sobre padrões e convenções

Toda instalação estabelece seus próprios padrões de codificação que, numa linguagem com décadas de uso, foram aperfeiçoados ao longo do tempo. Mesmo que uma convenção adotada pela empresa não pareça fazer sentido (e algumas vezes realmente não faz), precisamos respeitá-la para, em última análise, manter a coesão semântica e sintática do portfólio de sistemas.

Este livro explicará os conceitos gerais de cada estrutura da linguagem COBOL, e em alguns casos discutirá (e justificará) algumas das melhores práticas que o autor encontrou em diversos projetos ao longo dos últimos 30 anos.

Mas, naturalmente, os padrões mostrados aqui não devem ser considerados melhores (ou piores) do que os outros. Poucas convenções se justificam em função de performance ou de qualquer outro motivo puramente técnico.

A maior parte das regras de codificação que fazem parte de um padrão estão preocupadas com a facilidade de manutenção futura, que só vai ser alcançada se todos os programas da instalação (ou pelo menos a grande maioria) seguirem um mesmo formato.