 |
| 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 — DELETEDepois examinou o menu:
1 - INCLUIR CLIENTE
2 - CONSULTAR CLIENTE
3 - LISTAR CLIENTES
4 - EXCLUIR CLIENTE
0 - SAIRChuck 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 PauloEmbora 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 = 03O 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 é:
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 CPFO 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 = 3Depois 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-IFEm 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-IFChuck 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-IFDepois, 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 → IncrementarExemplo:
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:
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 diminuiSe 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-DEPOISOs 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:
apagar o nome;
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-IFO 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 = substituirExemplo:
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 SUCESSOquando 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-CLIENTESDepois:
| 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 TRUEO 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
DISPLAYIsso oferece uma interface textual, mas não comprova que o sistema seja uma transação CICS nem uma verdadeira tela 3270.
Dependendo do ambiente:
ACCEPTpode ler da entrada padrão;DISPLAYpode 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 CICSe 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
CLOSEE também:
FILE STATUSO arquivo sequencial traz persistência, mas a atualização fica mais trabalhosa.
Para alterar um cliente:
abrir o arquivo original;
abrir um arquivo temporário;
ler cada registro;
gravar todos no temporário;
quando encontrar o cliente, gravar a versão alterada;
fechar os arquivos;
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-CODIGONo 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: 11999990000Operador A muda para:
11911112222Operador B, que ainda vê a versão antiga, muda para:
11933334444Se 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-LIDASe 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
TELEFONEDecida tamanhos e tipos conscientemente.
Passo 2 — Crie a tabela
OCCURS 50 TIMESMantenha 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 - SAIRChuck 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çãoO 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
UPDATEnã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.
