 |
| Bellacosa Mainframe o cics no z/os por trás de um programa cobol |
☕ Um Café no Bellacosa Mainframe
CICS z/OS — O Dia em que o Inspetor Bugiganga Entrou no Datacenter, Apertou o Botão Errado e Descobriu que uma Transação Não É Apenas um Programa COBOL
Ou: como aprender CICS sem confundir tela verde com museu, COMMIT com promessa eleitoral, ABEND com fim do mundo — e sem deixar o Dr. Claw instalar em produção um load module compilado “só para testar”
Havia uma porta escondida atrás do balcão do Café no Bellacosa Mainframe. Não era exatamente secreta; era apenas uma porta que ninguém abria porque trazia uma plaquinha antiga:
CICS — Entre somente se souber o que é uma Unit of Work.
Naquela manhã, o Inspetor Bugiganga apareceu com seu sobretudo, seu helicóptero particular preso ao chapéu e uma prancheta onde estava escrito: “Operação Transacional”. Atrás dele vinha Igor, carregando um teclado 3270 como quem leva uma caixa de dinamite.
— Inspetor, encontrei o programa COBOL! — disse Igor. — Posso rodá-lo?
— Calma, Igor. Isto é CICS.
— Ah. Então eu rodo duas vezes?
E foi nesse momento que o Inspetor Bugiganga percebeu que seria necessário começar pelo começo. Porque CICS não é “um lugar onde programas COBOL recebem telas”. Essa definição é mais ou menos como chamar uma hidrelétrica de “um lugar com água”.
Está tecnicamente errado? Não exatamente. Mas deixa escondido todo o mecanismo que impede a cidade de ficar às escuras quando alguém resolve ligar o chuveiro, a máquina de lavar e a air fryer ao mesmo tempo.
CICS é o grande coordenador do processamento transacional no z/OS. Ele recebe milhares — às vezes milhões — de pedidos, distribui trabalho, conversa com programas, arquivos, bancos de dados, filas, APIs, usuários e sistemas externos. E, acima de tudo, tenta garantir que uma operação importante aconteça inteira ou não aconteça de jeito nenhum.
Porque em banco, seguro, companhia aérea, varejo, governo e telecomunicações, “quase funcionou” é uma frase capaz de causar taquicardia em meia diretoria.
1. Primeiro, a pergunta de Bugiganga: “o que exatamente é uma transação?”
Imagine uma transferência bancária de R$ 100.
O sistema precisa:
Validar quem está pedindo a transferência.
Verificar se a conta de origem existe.
Conferir saldo, limite e regras antifraude.
Debitar R$ 100 da conta A.
Creditar R$ 100 na conta B.
Registrar auditoria.
Possivelmente enviar um evento para notificação, contabilidade ou outro sistema.
Informar o resultado ao usuário.
Agora imagine que a luz caia entre o débito e o crédito.
Se o dinheiro some da conta A e nunca chega à conta B, não houve uma transação: houve o começo de um episódio de investigação parlamentar.
A ideia de transação, no universo CICS, é justamente tratar esse conjunto como uma unidade lógica de trabalho. Ou tudo se confirma corretamente, ou o ambiente recupera/desfaz o que for necessário para não deixar dados em estado inconsistente.
O nome bonito para isso é Unit of Work. O nome de balcão é: “não deixe o dinheiro cair entre duas cadeiras”.
CICS é especialista nesse tipo de cenário. Ele não nasceu para exibir uma tela bonita de cadastro de endereço. Nasceu para executar operações críticas, curtas, concorrentes e confiáveis.
2. A primeira pegadinha: CICS não é o programa COBOL
O COBOL guarda a regra de negócio. Ele sabe calcular juros, validar uma parcela, aplicar uma tarifa, localizar um cliente, conferir uma data e decidir se aquele financiamento pode ou não ser aprovado.
Mas o CICS é o ambiente que organiza o tráfego.
Uma forma simples de enxergar:
| Elemento | Papel |
|---|
| COBOL | Regra de negócio |
| CICS | Coordenador da transação |
| BMS | Definição das telas 3270 |
| VSAM | Arquivos indexados ou sequenciais |
| Db2 | Banco de dados relacional |
| IBM MQ | Comunicação por mensagens |
| RACF | Identidade e autorização |
| z/OS | Sistema operacional e fundação da casa |
Se o COBOL é o funcionário que sabe fazer o trabalho, CICS é o chefe de operações que diz: “você atende este cliente, não bloqueie o corredor, use os recursos autorizados, registre o que fez e me devolva o controle quando terminar”.
É por isso que um programa CICS deve ser breve e educado. Não pode simplesmente entrar em um loop eterno, ficar esperando o usuário pensar na vida ou prender um recurso por dez minutos.
Em batch, um programa pode rodar por horas. Em CICS, uma task lenta pode atrapalhar uma multidão. É a diferença entre cozinhar uma feijoada numa panela própria e tentar fazer feijoada no elevador de um prédio comercial durante o horário de pico.
3. O CICS visto por dentro: a sala de máquinas não é um buraco negro
O Inspetor Bugiganga olhou para o painel do datacenter.
— Então o usuário digita uma transação, e o CICS faz magia?
Não, inspetor. Faz arquitetura.
Quando alguém digita um código de transação, como CLIE, PAG1 ou CONS, o CICS cria ou gerencia uma task. Essa task executa a transação associada e usa diversos componentes internos para funcionar.
Entre os personagens importantes estão:
Dispatcher: administra quando as tasks recebem tempo de CPU.
Program Control: localiza, carrega e chama programas.
File Control: cuida dos acessos a VSAM.
Terminal Control: conversa com terminais e sessões.
Temporary Storage: armazena dados temporários.
Transient Data: trabalha com filas e destinos de dados.
Task Control: gerencia a vida da task.
Recovery Manager: ajuda a manter consistência quando o mundo resolve quebrar.
Na prática, isso significa que o CICS administra muitos pequenos trabalhos simultâneos. Ele não precisa necessariamente criar uma execução isolada, pesada e exclusiva para cada usuário. Ele trabalha de modo cooperativo, com tasks curtas e bem-comportadas.
É por isso que o velho costume de escrever um programa como se ele fosse dono do computador é perigoso.
Igor levantou a mão:
— E se eu colocar um PERFORM UNTIL sem condição de saída?
O Inspetor respondeu:
— Então você aprende uma palavra nova: AICA.
AICA é um dos abends clássicos ligados a tempo excessivo de CPU ou loops. Não é um espírito maligno do mainframe; é o CICS percebendo que alguém ficou tempo demais monopolizando a sala.
4. Região CICS: não existe apenas “o CICS”
Em empresas grandes, CICS não costuma ser uma única caixa com uma etiqueta colada. Existem diversas regiões CICS, e elas podem ter funções distintas.
Por exemplo:
TOR — Terminal Owning Region: recebe a conexão dos usuários.
AOR — Application Owning Region: executa a lógica das aplicações.
FOR — File Owning Region: controla determinados arquivos.
Regiões de desenvolvimento, teste, homologação, produção e contingência.
Regiões voltadas a APIs, integrações ou cargas específicas.
É uma forma de separar responsabilidades, distribuir carga e reduzir o raio de explosão quando algo dá errado.
Pense em um restaurante enorme. Há quem receba os clientes, quem cozinha, quem cuida da despensa e quem entrega os pratos. Se todos tentarem fazer tudo ao mesmo tempo no mesmo corredor, alguém derruba a sopa. Em produção, a sopa geralmente custa alguns milhões de reais e é acompanhada de uma call às 03h17.
Para iniciar uma região CICS, entram em cena elementos como JCL, parâmetros, tabelas e a famosa SIT, System Initialization Table. Ela contém parâmetros que influenciam o comportamento da região: recursos, segurança, recuperação, limites e características do ambiente.
Esse é um ponto importante para quem programa COBOL: você não precisa ser o administrador CICS para conhecer tudo, mas precisa entender que seu programa vive dentro de um ecossistema configurado. Nem todo erro é “bug do fonte”.
Às vezes o programa está certo, mas:
A transação não foi definida.
O programa não foi instalado.
O arquivo está fechado.
O recurso não existe naquela região.
O usuário não tem autorização.
O mapset não foi encontrado.
A conexão externa está indisponível.
CICS é uma pequena cidade. Seu COBOL é apenas um dos moradores.
5. RDO, CEDA e os recursos: a burocracia que evita o caos
Para uma transação existir no CICS, ela precisa ser definida. Esse é o universo de RDO, Resource Definition Online.
É onde aparecem recursos como:
PROGRAM
TRANSACTION
MAPSET
FILE
TDQUEUE
TSQUEUE
TCPIPSERVICE
URIMAP
WEBSERVICE
MQCONN
O CEDA é uma interface administrativa clássica usada para definir, alterar, instalar e consultar recursos. O CSD, CICS System Definition, é o repositório tradicional dessas definições.
Suponha que exista um programa COBOL chamado CLIP001. Compilar o fonte e gerar o load module não basta. Alguém precisa dizer ao CICS:
Existe um programa chamado CLIP001.
A transação CLIE chama esse programa.
O mapset CLIMAP está disponível.
O arquivo CLIENTE pode ser acessado.
O grupo certo tem autorização para executar a transação.
Se uma dessas peças estiver ausente, o usuário poderá ver um erro. E CICS é bastante criativo em seus códigos. Ele não está sendo grosseiro; está tentando contar, no dialeto dele, que o prédio existe mas a chave não foi cadastrada.
Dica de ouro para iniciantes: antes de mudar COBOL desesperadamente, confirme a definição e o estado dos recursos. Um bom diagnóstico começa perguntando: “o que o CICS sabe sobre este recurso?”
6. LINK, XCTL e RETURN: a etiqueta de quem entra e sai do palco
Uma aplicação CICS madura raramente é um COBOL gigante com 18 mil linhas, 42 parágrafos com nomes criativos e uma WORKING-STORAGE que parece uma lista telefônica de 1997.
Ela tende a ser dividida em programas com responsabilidades mais claras.
Três comandos merecem tatuagem mental:
LINK: chama outro programa e espera ele devolver o controle.
XCTL: transfere o controle para outro programa e não espera retorno.
RETURN: encerra a execução atual e devolve o controle ao CICS.
Imagine uma transação de consulta de cliente:
O programa principal recebe a tela.
Faz LINK para um módulo que valida CPF.
Faz LINK para outro módulo que consulta Db2.
Monta a resposta.
Envia a tela.
Faz RETURN.
LINK é como pedir a um colega: “valide este CPF e volte com a resposta”.
XCTL é como dizer: “agora você assume o caso; eu saio de cena”.
E RETURN é a saída elegante: “CICS, terminamos por enquanto. Pode atender o próximo cidadão.”
A palavra mais importante daquele “por enquanto” é pseudo-conversação.
7. Pseudo-conversação: a conversa que não fica parada esperando Enter
No COBOL batch, você pode imaginar uma execução linear: lê, processa, grava, encerra.
Em CICS com tela, o fluxo funciona de modo diferente. O programa envia uma tela e termina sua task. O usuário pode demorar três segundos, trinta segundos ou três minutos para apertar Enter. O CICS não vai deixar uma task parada esperando, gastando recursos e olhando para o vazio.
Quando o usuário responde, uma nova task é iniciada. A aplicação recupera o contexto necessário e continua.
Esse padrão é a pseudo-conversação.
Em vez de algo como:
DISPLAY "DIGITE O CPF"
ACCEPT WS-CPF
o mundo CICS faz algo conceitualmente parecido com:
EXEC CICS
SEND MAP('CLIMAP')
MAPSET('CLIMAPS')
ERASE
END-EXEC
EXEC CICS
RETURN TRANSID('CLIE')
END-EXEC
Depois, quando o usuário responde, a transação volta e recebe o mapa.
Essa arquitetura é uma das razões pelas quais CICS atende enormes volumes de usuários e operações de forma eficiente. Também é uma das razões pelas quais quem vem do batch precisa ajustar a cabeça. Não há um programa sentado à mesa esperando o cliente voltar do café.
8. BMS e a velha tela verde que ainda precisa de bom design
BMS, Basic Mapping Support, é a tecnologia clássica para definir mapas de tela 3270.
A tela verde não é um navegador e não funciona como uma página HTML. Ela é orientada a blocos e transmite campos de forma muito eficiente. Mas eficiência não deveria ser desculpa para criar uma experiência que parece uma prova de resistência emocional.
Uma boa tela CICS deve:
Indicar claramente onde o usuário digita.
Proteger campos que são apenas informativos.
Mostrar mensagens úteis e próximas do problema.
Preservar dados já preenchidos quando houver erro.
Usar PF keys de modo consistente.
Evitar códigos crípticos sem explicação.
Quando o usuário aperta Enter sem alterar nenhum campo, pode ocorrer MAPFAIL. Isso não significa necessariamente que o sistema explodiu. Pode significar apenas que CICS não recebeu dados modificados.
Essa pequena curiosidade é quase um rito de passagem: o iniciante trata MAPFAIL como catástrofe; depois entende que, muitas vezes, é só o usuário testando se a tela ainda está viva.
9. VSAM, Db2 e MQ: três jeitos de conversar com dados e processos
Aqui começa o CICS do mundo real.
VSAM: rápido, clássico e ainda trabalhando
VSAM é uma família de organizações de arquivos muito presente no mainframe. Os tipos mais lembrados são:
KSDS: Key-Sequenced Data Set, acessado por chave.
ESDS: Entry-Sequenced Data Set, gravado em sequência.
RRDS: Relative Record Data Set, acessado por número relativo.
Um KSDS pode guardar clientes indexados por CPF ou número de conta. Ele é muito adequado quando a aplicação conhece a chave e precisa obter o registro rapidamente.
No CICS, o acesso não é um READ COBOL comum. Você usa comandos CICS, por exemplo:
EXEC CICS
READ
FILE('CLIENTE')
INTO(WS-REG-CLIENTE)
RIDFLD(WS-CPF)
RESP(WS-RESP)
END-EXEC
E aqui está um hábito profissional que vale mais que decorar vinte comandos: sempre trate RESP e, quando necessário, RESP2.
“Não encontrou o cliente”, “arquivo fechado”, “sem autorização” e “registro bloqueado” podem resultar em ações completamente diferentes. O sistema precisa saber a diferença.
Db2: quando a pergunta é relacional
Db2 entra quando a aplicação precisa de SQL, relacionamentos, consultas mais flexíveis, integridade e um modelo de dados estruturado.
Você pode ter, por exemplo, tabelas de clientes, contratos, parcelas e pagamentos. O COBOL CICS executa SQL embutido, recebe resultados e participa de uma unidade de trabalho que pode ser confirmada ou revertida.
O perigo clássico é esquecer que um SQL aparentemente simples pode ficar caro. Um SELECT sem índice adequado, em uma tabela gigante, durante o pico de uso, é a versão corporativa de colocar uma kombi atravessada na Marginal em dia de chuva.
IBM MQ: quando não é necessário esperar todo mundo responder
MQ permite comunicação por mensagens. Em vez de uma transação esperar outro sistema responder imediatamente, ela pode colocar uma mensagem em uma fila.
Exemplo: um pagamento foi aprovado. A transação pode publicar um evento para que outros sistemas cuidem de:
Nem tudo precisa ser síncrono. A pergunta certa não é “MQ é moderno?”; é:
O usuário precisa da resposta agora ou o processo pode ocorrer de modo assíncrono, seguro e rastreável?
10. Commit, rollback e a arte de não perder o dinheiro no corredor
O Inspetor Bugiganga chegou diante de dois botões:
Igor se aproximou.
— Qual deles faz o sistema ficar mais rápido?
O Inspetor puxou Igor pelo suspensório.
COMMIT confirma uma unidade de trabalho. ROLLBACK desfaz o que ainda pode ser desfeito naquela unidade.
Em uma transferência, o ideal é que débito, crédito e registros críticos sejam coordenados para que a operação tenha consistência. Se algo falhar antes da confirmação, mecanismos de recuperação entram em ação.
CICS trabalha com syncpoints, logs, journals, unidades de recuperação e integração com gerenciadores de recursos. Isso não elimina todos os problemas do planeta — integrações distribuídas sempre trazem complexidade — mas cria uma estrutura sólida para não deixar operações em estado absurdo.
Uma aplicação financeira precisa ser desenhada para falhas. A pergunta não é “o que faremos se der errado?”. A pergunta é “qual falha esperamos primeiro, e como provamos que o resultado permaneceu correto?”
Essa é a diferença entre código que funciona em demo e sistema que sobrevive a uma terça-feira de fechamento de mês.
11. ABEND não é diagnóstico: é o alarme de incêndio
Quando o CICS apresenta um abend, alguém pode dizer “o CICS caiu”. Mas essa frase geralmente é tão útil quanto dizer “o carro parou”.
O diagnóstico exige contexto:
Qual foi o código de abend?
Qual transação estava executando?
Qual programa estava ativo?
O que aparece em mensagens, logs e traces?
Houve mudança recente?
O recurso estava disponível?
O problema é repetível?
Existe dump?
Há lock, espera, loop ou falta de autorização?
Ferramentas e mecanismos como CEDF, dumps, traces, logs de aplicação e estatísticas ajudam a remontar a história.
É aí que nasce uma mentalidade importante: observabilidade.
O bom sistema não registra apenas que “algo falhou”. Ele fornece contexto suficiente para alguém responder:
O log deve ajudar a investigação, não virar uma caixa-preta com a frase “erro inesperado”. O inesperado, em produção, costuma ser muito esperado por quem está de plantão.
12. RACF: autenticar não é autorizar
CICS integra-se a mecanismos de segurança, especialmente RACF no ecossistema z/OS.
Há uma diferença fundamental:
Um usuário pode estar autenticado e ainda não ter permissão para executar a transação de manutenção de cadastro, alterar limite de crédito, ler um arquivo ou invocar determinada API.
Isso é essencial por razões técnicas, de auditoria e de negócio. Não se trata de dificultar a vida de quem trabalha; trata-se de impedir que “todo mundo consegue tudo” vire uma vulnerabilidade institucional.
No CICS, segurança pode envolver transações, programas, arquivos, filas, recursos web e diferentes perfis de acesso. O programador iniciante não precisa virar especialista RACF no primeiro mês, mas precisa entender que segurança não é uma tela de login pendurada no começo do sistema.
Segurança é uma camada que acompanha a operação inteira.
13. CICS, APIs e o mainframe que saiu da tela verde sem sair de casa
Um dos mitos mais engraçados do mercado é imaginar que modernizar significa expulsar o mainframe e colocar um letreiro de “cloud” no prédio.
CICS conversa com o mundo web por HTTP, TLS, SOAP, REST, JSON, serviços e integrações. Uma aplicação mobile pode chamar uma API; a API chega a uma região CICS; o CICS executa COBOL e consulta Db2; a resposta volta em JSON.
A regra de negócio continua robusta. O canal de acesso muda.
Essa é uma modernização muito mais inteligente que reescrever, por vaidade, décadas de regras que foram testadas contra o mundo real. O foco deve ser reduzir acoplamento, melhorar experiência, criar APIs, automatizar entregas, documentar comportamento e tornar o ambiente observável.
Modernizar não é trocar a placa da sala de máquinas. É melhorar a capacidade de a sala de máquinas servir ao negócio.
14. Performance, storage e o lugar onde moram os monstros discretos
Um sistema lento pode estar gastando CPU. Mas também pode estar esperando.
Pode esperar por:
Lock de Db2.
Registro VSAM ocupado.
Recurso remoto.
Resposta de API.
Fila MQ.
Storage insuficiente.
Conexão saturada.
Código ineficiente.
SQL mal planejado.
Por isso, performance não se resume a olhar um único número. É preciso correlacionar tempo de resposta, CPU, I/O, taxa de transações, filas, locks, storage e comportamento por transação.
Storage é especialmente traiçoeiro. Problemas de memória podem gerar sintomas esquisitos: falhas que surgem após horas, dados corrompidos, abends aparentemente desconexos e aquela frase terrível: “mas ontem funcionava”.
Quando ouvir isso, não conclua que o computador está possuído. Primeiro investigue o que mudou, quais recursos cresceram, se existe loop, se houve vazamento de storage, se alguma task não termina, se há contenda ou se uma integração externa ficou lenta.
O CICS não lê pensamentos. Ele lê parâmetros, recursos, dados e instruções. Cabe a nós não entregar a ele um enigma embrulhado em um PERFORM de 800 linhas.
15. DevOps, governança e o momento em que o programador vira profissional de verdade
No fim da trilha aparece DevOps, CI/CD, governança de dados e projeto prático. E é ótimo que apareça, porque desenvolvimento profissional não termina quando o programa compila.
Uma entrega CICS moderna deveria considerar:
Fonte versionado.
Build reproduzível.
Tradução CICS, compilação e link-edit controlados.
Testes de unidade e integração.
Promoção entre ambientes.
Definições de recursos tratadas com disciplina.
Aprovação e rastreabilidade.
Monitoramento após implantação.
Plano de rollback.
Documentação mínima do que mudou e por quê.
O procedimento “copiar o load module em produção porque é só uma correçãozinha” deveria ser colocado num museu, atrás de vidro, com uma placa: não alimente o incidente.
Governança de dados também não é burocracia decorativa. É saber quais dados existem, quem pode acessá-los, onde estão, como são protegidos, quanto tempo ficam guardados e como uma ação pode ser auditada. Para sistemas que processam dados pessoais, financeiros ou sensíveis, isso é parte do produto.
16. Um projeto de estudo que realmente ensina CICS
Para fechar a jornada, construa algo pequeno, mas completo. Em vez de apenas um CRUD de cliente, monte uma transação de transferência, pagamento ou reserva.
Ela pode ter:
Uma tela BMS para receber dados.
Um programa COBOL principal.
Subprogramas chamados com LINK.
Consulta de cliente em VSAM ou Db2.
Validação de regras de negócio.
Atualização transacional.
COMMIT ou recuperação adequada em caso de falha.
Mensagem em MQ para notificação.
Controle RACF de acesso.
Log de auditoria.
Tratamento explícito de erros.
Métricas de tempo de resposta.
Uma API REST para consulta do status da operação.
O objetivo não é fingir que você montou um banco em duas semanas. É atravessar o caminho completo: entrada, regra, persistência, integração, segurança, recuperação e observabilidade.
Quando conseguir explicar esse fluxo de ponta a ponta, você terá deixado de ser alguém que “conhece comandos CICS”. Terá começado a se tornar alguém capaz de entender um sistema transacional de verdade.
No fim da visita, o Inspetor Bugiganga guardou a prancheta, olhou para Igor e perguntou:
— Aprendeu a diferença entre COBOL e CICS?
Igor assentiu.
— Sim, inspetor. COBOL é o cérebro da regra. CICS é a cidade inteira garantindo que o cérebro não atravesse a rua sem olhar.
O helicóptero do chapéu ligou, a porta do datacenter se fechou e, em algum lugar, uma task fez RETURN corretamente.
Missão cumprida.
Ou, como diria o velho operador da madrugada ao ver o painel finalmente verde:
“Não caiu. Hoje já é uma vitória.”
