Bellacosa Mainframe 

☕ Um Café no Bellacosa Mainframe

CRUD Walker — Quando Chuck Norris Auditou um Cadastro COBOL, Encontrou Cinquenta Clientes na WORKING-STORAGE e Descobriu que o UPDATE Fugiu Antes da Compilação

Ou: o jovem padawan chamou o programa de CRUD, Chuck Norris contou apenas três letras, Igor tentou esconder os clientes dentro de um OCCURS e o mainframe perguntou onde estavam o arquivo, o FILE STATUS e o COMMIT

---

Prólogo — O cadastro que entrou no saloon com uma letra faltando

O programa compilava.

O menu aparecia.

Clientes podiam ser incluídos, consultados, listados e excluídos. Havia confirmação antes da exclusão, tratamento de opções inválidas e até reorganização da tabela depois que um registro era removido.

Igor olhou para a tela verde, ajeitou o chapéu e anunciou:

— Está pronto! Um CRUD completo de clientes em COBOL!

No fundo da sala, Chuck Norris levantou os olhos do relatório de compilação.

Não disse nada.

Apenas escreveu quatro letras no quadro:

C — CREATE
R — READ
U — UPDATE
D — DELETE

Depois examinou o menu:

1 - INCLUIR CLIENTE
2 - CONSULTAR CLIENTE
3 - LISTAR CLIENTES
4 - EXCLUIR CLIENTE
0 - SAIR

Chuck contou novamente.

Havia CREATE, READ e DELETE. O UPDATE não estava ali.

Igor tentou explicar que “listar” talvez pudesse ser considerado o U, mas o compilador pediu demissão antes de participar daquela discussão.

O projeto não era ruim. Pelo contrário: era um laboratório muito interessante para quem está aprendendo COBOL. Ele reunia estruturas de dados, controle de fluxo, validação, pesquisa, interação pelo terminal e manipulação de registros em memória.

Mas ainda era um CRD, não um CRUD completo.

A boa notícia é que acrescentar o UPDATE não exige demolir o programa. Exige amadurecer sua construção.

E é exatamente nessa evolução que aparecem algumas das lições mais valiosas do desenvolvimento corporativo.

---

1. Antes do código: o que significa CRUD?

CRUD é um acrônimo criado para representar as quatro operações fundamentais executadas sobre dados persistentes:

Letra	Palavra	Operação
C	Create	Criar um registro
R	Read	Ler ou consultar
U	Update	Alterar um registro existente
D	Delete	Excluir um registro

Em um cadastro de clientes:

CREATE → cadastrar Paulo
READ   → consultar Paulo
UPDATE → mudar o telefone de Paulo
DELETE → remover ou inativar Paulo

Embora a sigla tenha ficado muito associada aos bancos de dados, essas operações podem ser simuladas em qualquer estrutura:

• tabela OCCURS;

• arquivo sequencial;

• VSAM KSDS;

• tabela Db2;

• fila;

• memória;

• aplicação CICS;

• serviço exposto por API.

O mecanismo muda, mas a intenção permanece.

No protótipo original, os clientes vivem dentro de uma tabela em memória. Isso permite estudar o comportamento do CRUD sem introduzir imediatamente JCL, arquivos, catálogos, VSAM, SQL, locks e unidades de trabalho.

É como aprender a estacionar em um pátio vazio antes de tentar fazê-lo na Avenida Paulista às seis da tarde.

Chuck Norris, naturalmente, estaciona o mainframe em uma vaga de motocicleta. Mas o jovem padawan deve começar com cinquenta registros.

---

2. Onde os clientes estão guardados?

A estrutura central do protótipo pode ser representada assim:

       01  WS-TABELA-CLIENTES.
           05 WS-CLIENTE OCCURS 50 TIMES.
              10 WS-CODIGO      PIC 9(05).
              10 WS-NOME        PIC X(40).
              10 WS-CPF         PIC X(11).
              10 WS-TELEFONE    PIC X(15).

O OCCURS 50 TIMES cria uma tabela com cinquenta posições.

Mas atenção: ele não cadastra cinquenta clientes.

Ele apenas reserva espaço para até cinquenta ocorrências da estrutura WS-CLIENTE.

Por isso, normalmente existe um contador:

       01  WS-CONTROLE.
           05 WS-TOTAL-CLIENTES     PIC 9(02) VALUE ZERO.
           05 WS-POSICAO            PIC 9(02) VALUE ZERO.
           05 WS-POSICAO-ENCONTRADA PIC 9(02) VALUE ZERO.

A tabela pode possuir cinquenta posições físicas, mas apenas as primeiras posições correspondentes a WS-TOTAL-CLIENTES são consideradas ocupadas.

Por exemplo:

Posição	Código	Nome	Estado
1	00001	Ana Maria	Ocupada
2	00002	Paulo Henrique	Ocupada
3	00003	Carla Souza	Ocupada
4–50	zeros/espaços	—	Livres

Nesse momento:

WS-TOTAL-CLIENTES = 03

O contador representa a fronteira entre o território ocupado e o deserto.

Se ele estiver incorreto, o programa poderá:

• ignorar clientes válidos;

• listar posições vazias;

• sobrescrever registros;

• pesquisar além da área útil;

• tentar acessar uma ocorrência fora do limite.

Uma regra fundamental é:

$$0 \leq WS\text{-}TOTAL\text{-}CLIENTES \leq 50$$

Chuck Norris não ultrapassa o limite de uma tabela. A tabela aumenta o OCCURS quando percebe que ele chegou.

---

3. PIC: não é decoração, é contrato de dados

Um iniciante pode olhar para:

05 WS-CODIGO PIC 9(05).
05 WS-NOME   PIC X(40).

e pensar que PIC serve apenas para determinar o tamanho do campo.

Mas PICTURE descreve a natureza lógica do dado.

PIC 9(05)

significa um campo numérico com cinco posições.

PIC X(40)

significa um campo alfanumérico de quarenta posições.

Essa escolha deve refletir o significado do dado.

Código do cliente

Se o código sempre tiver cinco algarismos:

05 WS-CODIGO PIC 9(05).

Se puder aceitar letras:

05 WS-CODIGO PIC X(05).

CPF

O CPF contém números, mas não representa uma quantidade.

Não fazemos:

CPF + CPF
CPF / 2
média de CPF
juros sobre CPF

O CPF é um identificador. Por isso, uma representação alfanumérica costuma ser adequada:

05 WS-CPF PIC X(11).

Isso também preserva zeros à esquerda.

Telefone

Telefone também não é quantidade:

05 WS-TELEFONE PIC X(15).

Com PIC X, podemos admitir:

• zeros à esquerda;

• código internacional;

• sinal +;

• DDD;

• diferentes tamanhos.

Uma curiosidade importante: dizer que um campo possui apenas dígitos não significa que ele deva ser numericamente armazenado. CEP, número de documento, código de barras e telefone são exemplos clássicos.

O dado pode parecer número sem ser matematicamente numérico.

---

4. O menu: onde EVALUATE controla o saloon

Uma aplicação textual normalmente apresenta as opções e recebe a escolha do usuário:

       1000-EXIBIR-MENU.
           DISPLAY "=============================="
           DISPLAY "       CADASTRO DE CLIENTES"
           DISPLAY "=============================="
           DISPLAY "1 - INCLUIR CLIENTE"
           DISPLAY "2 - CONSULTAR CLIENTE"
           DISPLAY "3 - LISTAR CLIENTES"
           DISPLAY "4 - ALTERAR CLIENTE"
           DISPLAY "5 - EXCLUIR CLIENTE"
           DISPLAY "0 - SAIR"
           DISPLAY "OPCAO: "
           ACCEPT WS-OPCAO.

Em seguida:

       1100-PROCESSAR-OPCAO.
           EVALUATE WS-OPCAO
               WHEN 1
                   PERFORM 2000-INCLUIR-CLIENTE
               WHEN 2
                   PERFORM 3000-CONSULTAR-CLIENTE
               WHEN 3
                   PERFORM 4000-LISTAR-CLIENTES
               WHEN 4
                   PERFORM 5000-ALTERAR-CLIENTE
               WHEN 5
                   PERFORM 6000-EXCLUIR-CLIENTE
               WHEN 0
                   MOVE "S" TO WS-FIM
               WHEN OTHER
                   DISPLAY "OPCAO INVALIDA"
           END-EVALUATE.

EVALUATE é apropriado porque o usuário escolhe uma alternativa entre várias possibilidades.

Seria possível usar vários IF, mas isso tornaria o fluxo menos legível:

IF WS-OPCAO = 1
   ...
ELSE
   IF WS-OPCAO = 2
      ...
   ELSE
      IF WS-OPCAO = 3

Depois de alguns níveis, Igor precisaria de um mapa, uma lanterna e uma autorização do RACF para encontrar o END-IF correto.

---

5. Nível 88: quando o número ganha significado

O COBOL permite associar nomes semânticos aos valores:

       01  WS-OPCAO                 PIC 9.
           88 OP-INCLUIR            VALUE 1.
           88 OP-CONSULTAR          VALUE 2.
           88 OP-LISTAR             VALUE 3.
           88 OP-ALTERAR            VALUE 4.
           88 OP-EXCLUIR            VALUE 5.
           88 OP-SAIR               VALUE 0.
           88 OPCAO-VALIDA          VALUE 0 THRU 5.

Agora é possível escrever:

       IF NOT OPCAO-VALIDA
           DISPLAY "OPCAO INVALIDA"
       END-IF

Em vez de perguntar “o valor está entre zero e cinco?”, o programa pergunta “a opção é válida?”.

Esse é um dos poderes discretos do COBOL: aproximar o código da linguagem do negócio.

Outro exemplo:

       01  WS-ENCONTRADO            PIC X VALUE "N".
           88 CLIENTE-ENCONTRADO    VALUE "S".
           88 CLIENTE-NAO-ENCONTRADO VALUE "N".

Então:

       IF CLIENTE-ENCONTRADO
           DISPLAY "CLIENTE LOCALIZADO"
       ELSE
           DISPLAY "CLIENTE NAO LOCALIZADO"
       END-IF

Chuck Norris não compara flags com "S". A flag pergunta a ele qual valor deve assumir.

---

6. Inclusão: criar não significa jogar dados na primeira vaga

Na inclusão, o programa precisa proteger alguns estados.

Antes de tudo:

       IF WS-TOTAL-CLIENTES >= 50
           DISPLAY "LIMITE DE CLIENTES ATINGIDO"
       END-IF

Depois, deve receber os dados em uma área temporária:

       01  WS-CLIENTE-ENTRADA.
           05 WS-ENT-CODIGO         PIC 9(05).
           05 WS-ENT-NOME           PIC X(40).
           05 WS-ENT-CPF            PIC X(11).
           05 WS-ENT-TELEFONE       PIC X(15).

Por que não gravar diretamente na tabela?

Porque o usuário pode:

• informar código duplicado;

• deixar o nome vazio;

• digitar CPF inválido;

• cancelar a operação;

• interromper a entrada no meio.

Se o programa escrever diretamente na tabela, poderá criar um registro parcialmente válido.

O fluxo correto é:

Receber → Validar → Verificar duplicidade → Gravar → Incrementar

Exemplo:

       2000-INCLUIR-CLIENTE.
           IF WS-TOTAL-CLIENTES >= 50
               DISPLAY "TABELA CHEIA"
           ELSE
               INITIALIZE WS-CLIENTE-ENTRADA
               PERFORM 2100-RECEBER-DADOS
               PERFORM 2200-VALIDAR-DADOS

               IF DADOS-VALIDOS
                   MOVE WS-ENT-CODIGO
                     TO WS-CODIGO-PESQUISA

                   PERFORM 7000-LOCALIZAR-CLIENTE

                   IF CLIENTE-ENCONTRADO
                       DISPLAY "CODIGO JA CADASTRADO"
                   ELSE
                       ADD 1 TO WS-TOTAL-CLIENTES

                       MOVE WS-CLIENTE-ENTRADA
                         TO WS-CLIENTE(WS-TOTAL-CLIENTES)

                       DISPLAY "CLIENTE INCLUIDO"
                   END-IF
               END-IF
           END-IF.

O contador deve ser incrementado somente quando o registro estiver aprovado para entrar na tabela.

---

7. A busca é o coração compartilhado

Consulta, alteração e exclusão começam da mesma forma:

Localize o cliente pelo código.

Em vez de escrever três pesquisas diferentes, o programa deve possuir uma rotina reutilizável:

       7000-LOCALIZAR-CLIENTE.
           SET CLIENTE-NAO-ENCONTRADO TO TRUE
           MOVE ZERO TO WS-POSICAO-ENCONTRADA

           PERFORM VARYING WS-POSICAO FROM 1 BY 1
               UNTIL WS-POSICAO > WS-TOTAL-CLIENTES
                  OR CLIENTE-ENCONTRADO

               IF WS-CODIGO(WS-POSICAO)
                    = WS-CODIGO-PESQUISA
                   SET CLIENTE-ENCONTRADO TO TRUE
                   MOVE WS-POSICAO
                     TO WS-POSICAO-ENCONTRADA
               END-IF
           END-PERFORM.

Essa é uma busca linear.

No pior caso, ela examina todos os registros:

$$O(n)$$

Para cinquenta clientes, isso é mais do que suficiente.

Um iniciante pode ficar tentado a implementar imediatamente uma pesquisa binária com SEARCH ALL. Mas ela exige que a tabela esteja ordenada pela chave.

Sem ordenação garantida, a pesquisa binária pode procurar o cliente com velocidade impressionante no lugar errado.

Dica de Chuck Norris:

Primeiro faça a busca correta. Depois meça. Só então otimize.

---

8. Consulta e listagem não são a mesma coisa

Ambas pertencem ao READ, mas possuem objetivos diferentes.

Consulta

Procura um cliente específico:

       3000-CONSULTAR-CLIENTE.
           DISPLAY "CODIGO: "
           ACCEPT WS-CODIGO-PESQUISA

           PERFORM 7000-LOCALIZAR-CLIENTE

           IF CLIENTE-ENCONTRADO
               PERFORM 7100-MOSTRAR-CLIENTE
           ELSE
               DISPLAY "CLIENTE NAO ENCONTRADO"
           END-IF.

Listagem

Percorre todos os registros ativos:

       4000-LISTAR-CLIENTES.
           IF WS-TOTAL-CLIENTES = ZERO
               DISPLAY "NENHUM CLIENTE CADASTRADO"
           ELSE
               PERFORM VARYING WS-POSICAO FROM 1 BY 1
                   UNTIL WS-POSICAO > WS-TOTAL-CLIENTES

                   DISPLAY "CODIGO: "
                       WS-CODIGO(WS-POSICAO)
                   DISPLAY "NOME: "
                       WS-NOME(WS-POSICAO)
               END-PERFORM
           END-IF.

A consulta é acesso seletivo. A listagem é varredura.

Essa diferença aparecerá novamente no Db2:

SELECT ... WHERE CODIGO = ?

para consulta individual, e um cursor para múltiplos registros.

---

9. O UPDATE entra pela porta principal

Agora chegamos à letra desaparecida.

O UPDATE não cria uma nova posição e não remove a existente. Ele altera determinados atributos do cliente na mesma ocorrência.

Antes:

Campo	Valor
Código	00025
Nome	Paulo Henrique
CPF	12345678909
Telefone	11999990000

Depois:

Campo	Valor
Código	00025
Nome	Paulo Henrique Silva
CPF	12345678909
Telefone	11988887777

Observe:

• o cliente continua na mesma posição;

• o código permanece igual;

• o contador não muda;

• não há deslocamento de registros;

• apenas determinados campos são substituídos.

Portanto:

CREATE → WS-TOTAL-CLIENTES aumenta
UPDATE → WS-TOTAL-CLIENTES não muda
DELETE → WS-TOTAL-CLIENTES diminui

Se uma alteração incrementar o total, o programa terá criado uma duplicata em vez de atualizar o registro.

---

10. A chave não deve ser tratada como um telefone

O código identifica o cliente:

05 WS-CODIGO PIC 9(05).

Nome, CPF e telefone são atributos.

Em geral, o UPDATE deve preservar a chave.

Permitir que o operador altere livremente o código pode causar:

• duplicidade;

• perda de referências;

• quebra da ordenação;

• inconsistência com outros arquivos;

• dificuldade de auditoria;

• relações órfãs em bancos de dados.

No protótipo, ainda não existem contas, contratos ou endereços vinculados. Mesmo assim, proteger a chave ensina a mentalidade correta.

Se realmente fosse necessário trocar o código, essa deveria ser uma operação especial, com verificação de duplicidade e atualização das referências relacionadas.

Curiosidade: em VSAM KSDS, a chave primária não é tratada como um campo comum regravável. Muitas vezes, mudar a chave exige excluir o registro antigo e gravar outro com a nova chave.

Ou seja: até o VSAM olha desconfiado quando Igor diz “vou apenas dar um MOVE na chave”.

---

11. Antes e depois: o mini-COMMIT do laboratório

A melhor construção para o UPDATE utiliza duas imagens:

       01  WS-CLIENTE-ANTES.
           05 WS-ANTES-CODIGO       PIC 9(05).
           05 WS-ANTES-NOME         PIC X(40).
           05 WS-ANTES-CPF          PIC X(11).
           05 WS-ANTES-TELEFONE     PIC X(15).

       01  WS-CLIENTE-DEPOIS.
           05 WS-DEPOIS-CODIGO      PIC 9(05).
           05 WS-DEPOIS-NOME        PIC X(40).
           05 WS-DEPOIS-CPF         PIC X(11).
           05 WS-DEPOIS-TELEFONE    PIC X(15).

Depois de localizar o cliente:

       MOVE WS-CLIENTE(WS-POSICAO-ENCONTRADA)
         TO WS-CLIENTE-ANTES

       MOVE WS-CLIENTE(WS-POSICAO-ENCONTRADA)
         TO WS-CLIENTE-DEPOIS

Os novos dados são aplicados apenas na imagem DEPOIS.

O registro oficial continua intacto até:

• os campos serem validados;

• as duplicidades serem verificadas;

• o usuário confirmar;

• o programa decidir efetivar a operação.

Depois da confirmação:

       MOVE WS-CLIENTE-DEPOIS
         TO WS-CLIENTE(WS-POSICAO-ENCONTRADA)

Esse MOVE funciona como uma espécie de commit lógico didático.

Não é um COMMIT real de banco de dados, mas a analogia é útil:

Protótipo em memória	Sistema transacional
Imagem ANTES	Estado confirmado
Imagem DEPOIS	Alteração preparada
Validação	Regras e constraints
Confirmação	Aprovação
MOVE final	Commit lógico
Descartar DEPOIS	Rollback lógico

Chuck Norris faz COMMIT olhando para o banco. O Db2 confirma por respeito.

---

12. Pressionar Enter significa o quê?

Suponha:

NOME ATUAL: PAULO HENRIQUE
NOVO NOME [ENTER=MANTER]:

O usuário apenas pressiona Enter.

Existem duas interpretações:

1. apagar o nome;

2. manter o nome atual.

O programa deve definir explicitamente a regra.

Em um cadastro, uma boa escolha é:

Campo vazio mantém o valor anterior.

Exemplo:

       DISPLAY "NOVO NOME [ENTER=MANTER]: "
       ACCEPT WS-NOVO-NOME

       IF WS-NOVO-NOME NOT = SPACES
           MOVE WS-NOVO-NOME
             TO WS-DEPOIS-NOME
       END-IF

O mesmo vale para CPF e telefone.

Mas surge outra pergunta: como o usuário apaga intencionalmente um campo opcional?

Uma solução seria aceitar um comando especial:

ENTER = manter
*     = limpar
valor = substituir

Exemplo:

       EVALUATE TRUE
           WHEN WS-NOVO-TELEFONE = SPACES
               CONTINUE
           WHEN WS-NOVO-TELEFONE = "*"
               MOVE SPACES TO WS-DEPOIS-TELEFONE
           WHEN OTHER
               MOVE WS-NOVO-TELEFONE
                 TO WS-DEPOIS-TELEFONE
       END-EVALUATE.

Esse pequeno detalhe mostra que interface não é apenas ACCEPT e DISPLAY. Ela também é um contrato de significado.

---

13. O CPF novo pode pertencer a outro cliente

Se o CPF puder ser alterado, o programa precisa verificar duplicidade.

Mas há uma armadilha.

Ao procurar o novo CPF, o sistema encontrará o CPF do próprio cliente. Por isso, a validação deve ignorar a posição que está sendo atualizada:

       MOVE "N" TO WS-CPF-DUPLICADO

       PERFORM VARYING WS-POSICAO FROM 1 BY 1
           UNTIL WS-POSICAO > WS-TOTAL-CLIENTES
              OR WS-CPF-DUPLICADO = "S"

           IF WS-POSICAO NOT = WS-POSICAO-ENCONTRADA
              AND WS-CPF(WS-POSICAO) = WS-DEPOIS-CPF
               MOVE "S" TO WS-CPF-DUPLICADO
           END-IF
       END-PERFORM.

A expressão:

WS-POSICAO NOT = WS-POSICAO-ENCONTRADA

é essencial.

Sem ela, o sistema rejeitaria o CPF atual como duplicado de si mesmo.

É o equivalente cadastral de Chuck Norris ser barrado na porta porque sua fotografia se parece demais com ele.

---

14. O fluxo completo da alteração

Uma estrutura modular poderia ser:

       5000-ALTERAR-CLIENTE.
           DISPLAY "=== ALTERAR CLIENTE ==="
           DISPLAY "CODIGO: "
           ACCEPT WS-CODIGO-PESQUISA

           PERFORM 7000-LOCALIZAR-CLIENTE

           IF CLIENTE-NAO-ENCONTRADO
               DISPLAY "CLIENTE NAO ENCONTRADO"
           ELSE
               PERFORM 5100-PREPARAR-IMAGENS
               PERFORM 5200-MOSTRAR-DADOS-ATUAIS
               PERFORM 5300-RECEBER-NOVOS-DADOS
               PERFORM 5400-VALIDAR-ALTERACAO

               IF DADOS-VALIDOS
                   PERFORM 5500-MOSTRAR-COMPARACAO
                   PERFORM 5600-CONFIRMAR-ALTERACAO

                   IF ALTERACAO-CONFIRMADA
                       PERFORM 5700-EFETIVAR-ALTERACAO
                   ELSE
                       DISPLAY "ALTERACAO CANCELADA"
                   END-IF
               END-IF
           END-IF.

Essa divisão deixa cada parágrafo com uma responsabilidade.

Preparação

       5100-PREPARAR-IMAGENS.
           MOVE WS-CLIENTE(WS-POSICAO-ENCONTRADA)
             TO WS-CLIENTE-ANTES

           MOVE WS-CLIENTE(WS-POSICAO-ENCONTRADA)
             TO WS-CLIENTE-DEPOIS.

Entrada

       5300-RECEBER-NOVOS-DADOS.
           INITIALIZE WS-NOVO-NOME
                      WS-NOVO-CPF
                      WS-NOVO-TELEFONE

           DISPLAY "NOVO NOME [ENTER=MANTER]: "
           ACCEPT WS-NOVO-NOME

           DISPLAY "NOVO CPF [ENTER=MANTER]: "
           ACCEPT WS-NOVO-CPF

           DISPLAY "NOVO TELEFONE [ENTER=MANTER]: "
           ACCEPT WS-NOVO-TELEFONE.

Efetivação

       5700-EFETIVAR-ALTERACAO.
           MOVE WS-CLIENTE-DEPOIS
             TO WS-CLIENTE(WS-POSICAO-ENCONTRADA)

           DISPLAY "CLIENTE ALTERADO COM SUCESSO".

---

15. E se nada tiver mudado?

O usuário pode entrar na alteração e manter todos os campos.

Nesse caso:

       IF WS-CLIENTE-ANTES = WS-CLIENTE-DEPOIS
           DISPLAY "NENHUMA ALTERACAO INFORMADA"
           SET DADOS-INVALIDOS TO TRUE
       END-IF.

Isso evita apresentar:

CLIENTE ALTERADO COM SUCESSO

quando nada foi alterado.

Em sistemas corporativos, atualizações vazias também podem gerar efeitos desnecessários:

• logs;

• auditoria;

• locks;

• escrita em disco;

• replicação;

• triggers;

• mensagens;

• alteração de timestamp;

• eventos para outros sistemas.

Uma operação tecnicamente válida pode ainda ser operacionalmente inútil.

---

16. Exclusão: fechar o buraco deixado na mesa

Considere:

Posição	Cliente
1	Ana
2	Bruno
3	Carla
4	Diego

Ao excluir Bruno, a posição 2 ficaria vazia.

Para manter a tabela compacta, os registros posteriores são deslocados:

       PERFORM VARYING WS-POSICAO
           FROM WS-POSICAO-ENCONTRADA BY 1
           UNTIL WS-POSICAO >= WS-TOTAL-CLIENTES

           MOVE WS-CLIENTE(WS-POSICAO + 1)
             TO WS-CLIENTE(WS-POSICAO)
       END-PERFORM

       INITIALIZE WS-CLIENTE(WS-TOTAL-CLIENTES)
       SUBTRACT 1 FROM WS-TOTAL-CLIENTES

Depois:

Posição	Cliente
1	Ana
2	Carla
3	Diego
4	vazia

O INITIALIZE da última posição é importante. Sem ele, uma cópia residual de Diego poderia permanecer na área livre.

A aplicação talvez não a listasse porque o contador agora seria 3, mas o dado antigo continuaria fisicamente na memória.

Essa é uma curiosidade importante:

Um registro pode deixar de existir logicamente e continuar presente fisicamente.

O mesmo princípio aparece em discos, bancos, caches, filas e arquivos temporários. “Excluir” nem sempre significa destruir imediatamente todos os bytes.

---

17. Exclusão física ou lógica?

Em sistemas corporativos, o cliente raramente é simplesmente apagado.

Pode haver:

• contratos;

• contas;

• movimentações;

• obrigações regulatórias;

• auditorias;

• investigações;

• histórico de atendimento.

Por isso, o sistema pode usar um status:

       05 WS-STATUS PIC X.
          88 CLIENTE-ATIVO    VALUE "A".
          88 CLIENTE-INATIVO  VALUE "I".
          88 CLIENTE-BLOQUEADO VALUE "B".

Então o DELETE de negócio seria:

       SET CLIENTE-INATIVO TO TRUE

O registro continua armazenado, mas deixa de participar das operações normais.

A isso damos frequentemente o nome de exclusão lógica.

O problema é que a aplicação precisa lembrar-se de filtrar os inativos. Caso contrário, Igor “exclui” o cliente no menu, mas ele aparece novamente na listagem cinco minutos depois como um fantasma do Db2.

---

18. ACCEPT e DISPLAY não são CICS por encantamento

O protótipo usa:

ACCEPT
DISPLAY

Isso oferece uma interface textual, mas não comprova que o sistema seja uma transação CICS nem uma verdadeira tela 3270.

Dependendo do ambiente:

• ACCEPT pode ler da entrada padrão;

• DISPLAY pode escrever na saída padrão;

• em GnuCOBOL, pode ser um terminal Windows ou Linux;

• em batch z/OS, a entrada pode vir de SYSIN;

• a saída pode aparecer em SYSOUT;

• em CICS, a interação normalmente envolve EXEC CICS e mapas BMS.

Uma execução batch poderia receber:

//SYSIN DD *
1
00001
PAULO HENRIQUE
12345678909
11999990000
0
/*

Isso não representa um operador navegando por uma tela 3270. É um job consumindo dados previamente fornecidos.

Em CICS, a construção seria diferente. A aplicação normalmente envia a tela, encerra a task e volta quando o usuário responde. Esse é o modelo pseudoconversacional.

A lição é simples:

COBOL é a linguagem. z/OS é o sistema operacional. CICS é o monitor transacional. 3270 é o modelo de terminal. Eles convivem, mas não são sinônimos.

---

19. Memória não é persistência

Todos os clientes do protótipo vivem na WORKING-STORAGE.

Quando o programa termina, os dados desaparecem.

Isso significa que o cadastro atual oferece:

• manipulação de registros;

• estado durante a execução;

• regras de validação;

• experiência didática.

Mas ainda não oferece:

• persistência;

• recuperação;

• acesso simultâneo;

• auditoria;

• compartilhamento;

• backup;

• restart;

• histórico.

A memória é como a prancheta do atendente.

VSAM ou Db2 são o arquivo oficial da empresa.

Chuck Norris memoriza todos os clientes. O restante da equipe precisa de persistência.

---

20. Primeiro degrau: arquivo sequencial

Uma próxima versão poderia utilizar um arquivo:

       SELECT CLIENTES-FILE
           ASSIGN TO CLIENTES
           ORGANIZATION IS SEQUENTIAL
           FILE STATUS IS WS-FILE-STATUS.

E:

       FD CLIENTES-FILE.
       01 CLIENTES-RECORD.
          05 CLIENTE-CODIGO    PIC 9(05).
          05 CLIENTE-NOME      PIC X(40).
          05 CLIENTE-CPF       PIC X(11).
          05 CLIENTE-TELEFONE  PIC X(15).

Agora aparecem:

OPEN
READ
WRITE
CLOSE

E também:

FILE STATUS

O arquivo sequencial traz persistência, mas a atualização fica mais trabalhosa.

Para alterar um cliente:

1. abrir o arquivo original;

2. abrir um arquivo temporário;

3. ler cada registro;

4. gravar todos no temporário;

5. quando encontrar o cliente, gravar a versão alterada;

6. fechar os arquivos;

7. substituir o original de maneira controlada.

É trabalhoso, mas ensina processamento batch real.

---

21. Segundo degrau: VSAM KSDS

Para acesso direto por código:

       SELECT CLIENTES-FILE
           ASSIGN TO CLIENTES
           ORGANIZATION IS INDEXED
           ACCESS MODE IS DYNAMIC
           RECORD KEY IS CLIENTE-CODIGO
           FILE STATUS IS WS-FILE-STATUS.

O CRUD passa a corresponder a:

Operação	VSAM
Criar	WRITE
Consultar	READ
Alterar	REWRITE
Excluir	DELETE

Exemplo do UPDATE:

       READ CLIENTES-FILE
           KEY IS CLIENTE-CODIGO
       END-READ

       IF WS-FILE-STATUS = "00"
           MOVE WS-NOVO-NOME
             TO CLIENTE-NOME

           REWRITE CLIENTES-RECORD
           END-REWRITE

           IF WS-FILE-STATUS = "00"
               DISPLAY "CLIENTE ALTERADO"
           ELSE
               DISPLAY "ERRO NO REWRITE: "
                   WS-FILE-STATUS
           END-IF
       ELSE
           DISPLAY "CLIENTE NAO ENCONTRADO"
       END-IF.

Aqui, o FILE STATUS deixa de ser um detalhe e se torna parte da lógica.

Não basta executar REWRITE. É preciso perguntar ao sistema se ele conseguiu.

---

22. Terceiro degrau: Db2

No Db2:

UPDATE CLIENTE
   SET NOME     = :HV-NOME,
       CPF      = :HV-CPF,
       TELEFONE = :HV-TELEFONE
 WHERE CODIGO   = :HV-CODIGO

No COBOL:

       EXEC SQL
           UPDATE CLIENTE
              SET NOME     = :HV-NOME,
                  CPF      = :HV-CPF,
                  TELEFONE = :HV-TELEFONE
            WHERE CODIGO   = :HV-CODIGO
       END-EXEC.

Depois, o programa verifica SQLCODE:

       EVALUATE TRUE
           WHEN SQLCODE = ZERO
               EXEC SQL
                   COMMIT
               END-EXEC
               DISPLAY "CLIENTE ALTERADO"

           WHEN SQLCODE = 100
               DISPLAY "CLIENTE NAO ENCONTRADO"

           WHEN OTHER
               EXEC SQL
                   ROLLBACK
               END-EXEC
               DISPLAY "ERRO SQL: " SQLCODE
       END-EVALUATE.

Aqui aparece uma observação importante: dependendo do comando e da forma usada, “nenhuma linha atualizada” deve ser confirmado por diagnóstico apropriado, incluindo a quantidade de linhas afetadas. Não se deve imaginar que todo sucesso técnico corresponde a uma alteração de negócio.

O Db2 também introduz:

• locks;

• isolamento;

• deadlock;

• timeout;

• integridade referencial;

• constraints;

• concorrência;

• unidade de recuperação.

O protótipo pergunta:

Posso mudar este telefone?

O sistema corporativo pergunta:

Posso mudar este telefone, neste instante, sem violar regras, perder a atualização de outro usuário ou deixar metade da transação confirmada?

---

23. O problema dos dois operadores

Imagine dois usuários consultando o mesmo cliente:

Telefone atual: 11999990000

Operador A muda para:

11911112222

Operador B, que ainda vê a versão antiga, muda para:

11933334444

Se B gravar por último, a alteração de A poderá desaparecer.

Isso é chamado de lost update, ou atualização perdida.

A tabela em memória com um único usuário não mostra esse problema. Em um ambiente corporativo, ele precisa ser tratado por:

• locks;

• isolamento;

• versionamento;

• timestamp;

• comparação da imagem anterior;

• controle otimista de concorrência.

Uma estratégia seria atualizar somente se o registro ainda estiver na versão consultada:

UPDATE CLIENTE
   SET TELEFONE = :NOVO-TELEFONE,
       VERSAO   = VERSAO + 1
 WHERE CODIGO   = :CODIGO
   AND VERSAO   = :VERSAO-LIDA

Se nenhuma linha for atualizada, alguém modificou o registro antes.

Chuck Norris não sofre lost update. Quando ele altera uma linha, os outros usuários recebem um aviso antes mesmo de abrir a tela.

---

24. Passo a passo para construir o protótipo completo

Para um iniciante, eu seguiria esta ordem:

Passo 1 — Defina o registro

CODIGO
NOME
CPF
TELEFONE

Decida tamanhos e tipos conscientemente.

Passo 2 — Crie a tabela

OCCURS 50 TIMES

Mantenha um contador de registros ativos.

Passo 3 — Crie o menu

Use DISPLAY, ACCEPT e EVALUATE.

Passo 4 — Implemente a inclusão

Receba em área temporária, valide e somente depois grave.

Passo 5 — Centralize a pesquisa

Crie LOCALIZAR-CLIENTE e armazene a posição encontrada.

Passo 6 — Implemente consulta e listagem

Uma consulta por código e uma varredura completa.

Passo 7 — Implemente o UPDATE

Use imagens ANTES e DEPOIS, proteja a chave e peça confirmação.

Passo 8 — Implemente a exclusão

Localize, confirme, desloque os registros e diminua o contador.

Passo 9 — Trate limites e entradas inválidas

Teste tabela cheia, tabela vazia, código duplicado e cliente inexistente.

Passo 10 — Crie casos de teste

Não teste apenas o caminho feliz.

---

25. Roteiro de testes sob o olhar desconfiado de Chuck Norris

Teste	Resultado esperado
Incluir primeiro cliente	Total passa de 0 para 1
Incluir código repetido	Inclusão recusada
Incluir 51º cliente	Limite informado
Consultar cliente existente	Dados exibidos
Consultar inexistente	Mensagem controlada
Listar tabela vazia	Nenhum cliente cadastrado
Alterar nome	Mesma posição e mesmo código
Alterar CPF para CPF já usado	Operação recusada
Entrar no Update e não mudar nada	Nenhuma alteração
Cancelar Update	Registro original preservado
Excluir primeiro cliente	Registros deslocados
Excluir cliente intermediário	Tabela permanece compacta
Excluir último cliente	Última posição inicializada
Cancelar exclusão	Total e tabela permanecem iguais
Digitar opção inválida	Menu reapresentado
Encerrar e reabrir	Dados desaparecem na versão em memória

O último teste não é um defeito inesperado. É uma limitação conhecida da arquitetura.

Documentar limitações é uma forma de qualidade.

---

26. Easter eggs escondidos na WORKING-STORAGE

Easter egg 1 — O CRUD estava incompleto

O primeiro segredo estava no próprio acrônimo: faltava o U.

Easter egg 2 — Listar não cria outra letra

Consulta e listagem são duas formas de leitura. Portanto, ambas pertencem ao R.

Easter egg 3 — OCCURS 50 não significa cinquenta clientes

Significa espaço para cinquenta ocorrências. O contador informa quantas estão logicamente ocupadas.

Easter egg 4 — Excluir não apaga necessariamente os bytes

A exclusão lógica e os resíduos de memória mostram que existência física e existência de negócio são conceitos diferentes.

Easter egg 5 — O MOVE final imita um commit

As áreas ANTES e DEPOIS introduzem, em miniatura, o conceito de preparar, validar, confirmar ou abandonar uma mudança.

Easter egg 6 — O terminal pode não ser 3270

Uma tela verde não transforma automaticamente ACCEPT e DISPLAY em uma aplicação CICS.

Easter egg 7 — COBOL não significa necessariamente mainframe

COBOL pode rodar em outras plataformas. Para afirmar que é uma aplicação z/OS, é preciso demonstrar o ambiente, a compilação e a execução.

Easter egg 8 — O código mais importante pode ser o que não altera nada

A validação que impede uma operação indevida pode ser mais valiosa do que o MOVE que grava os dados.

---

Epílogo — O dia em que o UPDATE voltou ao menu

Ao final da revisão, o menu apareceu novamente:

1 - INCLUIR CLIENTE
2 - CONSULTAR CLIENTE
3 - LISTAR CLIENTES
4 - ALTERAR CLIENTE
5 - EXCLUIR CLIENTE
0 - SAIR

Chuck Norris examinou a WORKING-STORAGE.

Conferiu o limite de cinquenta posições.

Testou código duplicado.

Tentou atualizar um CPF já utilizado.

Pressionou Enter sem mudar nenhum campo.

Cancelou a alteração.

Excluiu o primeiro registro.

Depois encerrou o programa e confirmou que todos os clientes desapareceram, porque ainda estavam apenas na memória.

Igor respirou aliviado:

— Agora é um CRUD completo?

Chuck Norris respondeu:

— Agora ele possui as quatro operações. Completo é outra conversa.

E essa talvez seja a maior lição do projeto.

Um CRUD em memória pode ser excelente para aprender:

• estruturação de dados;

• lógica procedural;

• modularização;

• pesquisa;

• validação;

• estados;

• inclusão;

• consulta;

• alteração;

• exclusão.

Mas um sistema corporativo também exige:

• persistência;

• controle de concorrência;

• segurança;

• auditoria;

• recuperação;

• integridade;

• testes;

• tratamento de erros;

• observabilidade;

• operações transacionais.

O protótipo não precisa fingir que já é tudo isso.

Seu valor está justamente em mostrar uma evolução compreensível:

OCCURS em memória
        ↓
arquivo sequencial
        ↓
VSAM KSDS
        ↓
Db2
        ↓
CICS
        ↓
segurança, auditoria e produção

O jovem padawan que entende essa sequência deixa de ser alguém que apenas conhece comandos COBOL.

Ele começa a compreender como dados nascem, mudam, sobrevivem, desaparecem e precisam ser protegidos dentro de sistemas que não podem improvisar.

E, sob o olhar desconfiado de Chuck Norris, a regra final ficou registrada:

Um UPDATE não é apenas sobrescrever caracteres. É localizar a entidade correta, preservar sua identidade, preparar uma nova versão, validar as regras, impedir conflitos e somente então alterar o estado oficial.

Igor tentou acrescentar essa frase ao programa usando um DISPLAY.

Chuck Norris pediu que ele criasse primeiro o FILE STATUS.