 |
| Aprenda CICS com Bellacosa Mainframe |
📘 CICS Command Level para padawans
Walkthrough estilo Bellacosa Mainframe
 |
| CICS e suas interligações |
O IBM CICS (Customer Information Control System) é, em termos honestos de CPD, o coração online do mainframe. Se o batch é o pulmão que trabalha à noite, o CICS é o sistema nervoso que reage em milissegundos enquanto o banco, a seguradora ou o governo estão abertos.
Tecnicamente, CICS é um gerenciador de transações que roda sobre o z/OS e controla milhares (às vezes milhões) de requisições simultâneas vindas de terminais 3270, aplicações web, APIs, filas e sistemas distribuídos. Cada requisição vira uma TASK, criada, suspensa, retomada e finalizada pelo CICS com uma eficiência quase antipática. Nada de criar processo novo, nada de desperdício: tudo reaproveitado, tudo controlado.
No mundo real, CICS é quem garante que duas pessoas não atualizem o mesmo saldo ao mesmo tempo, que uma queda de energia não corrompa dados e que o sistema continue respirando mesmo sob carga absurda. Ele faz isso com controle de concorrência, integridade transacional (UOW), recuperação automática e isolamento de falhas.
No estilo Bellacosa: CICS não é framework, não é servidorzinho e não é opcional. É um ecossistema maduro, conservador e extremamente confiável. Se ainda está rodando 40 anos depois, não é nostalgia — é engenharia bem-feita.
🔹 MÓDULO I – Conceitos Básicos
 |
| IBM CICS |
Vamos ao CICS em funcionamento, versão Bellacosa Mainframe – sem romantizar, mas com respeito.
Tudo começa quando o usuário digita uma transação (ex: ABCD) no terminal 3270 ou quando um sistema chama o CICS via API. Nesse momento, o CICS não executa um programa — ele cria uma TASK. Essa TASK é uma entidade leve, controlada, numerada e com prazo de vida curto. Nada de processo pesado, nada de desperdício.
A TASK entra no dispatcher do CICS, que decide quando ela pode rodar. Se precisar de I/O (VSAM, DB2, fila, terminal), a TASK é suspensa educadamente e outra entra no lugar. Multitarefa cooperativa raiz, funcionando há décadas.
Quando o programa COBOL é chamado, ele roda em modo quasi-reentrant, usando áreas compartilhadas e dados isolados por WORKING-STORAGE ou COMMAREA. Cada comando EXEC CICS passa pelo Command Level Interface, que valida, executa e devolve RESP codes. Se algo der errado, o CICS sabe exatamente onde, quando e por quê.
Se houver atualização, o CICS controla a Unit of Work. Se a TASK termina bem, ele faz commit. Se cair, ele desfaz tudo como se nada tivesse acontecido.
No fim, o CICS devolve a resposta ao usuário, mata a TASK sem cerimônia e segue em frente. Rápido, previsível e implacavelmente confiável.
📌 O que é
Introduz o CICS (Customer Information Control System) como gerenciador transacional online, explicando o conceito de TASK, transação, domains, memória e execução concorrente.
🧠 Resumo rápido
CICS não é programa, é um sistema operacionalzinho dentro do z/OS para aplicações online. Ele cria, controla, pausa, retoma e mata tarefas sem dó.
🧪 Exemplo
Uma transação ABCD digitada no terminal cria uma TASK, que executa um programa COBOL, acessa VSAM e responde em milissegundos.
⚠️ Dica Bellacosa
Se você não entende TASK ≠ JOB, você vai sofrer no CICS.
🥚 Easter Egg
QR (Quasi-Reentrant) não é moda antiga — é o motivo pelo qual mil usuários podem usar o mesmo programa sem corrupção de dados.
🤫 Fofoquice
Todo iniciante acha que cada usuário tem “seu programa na memória”. Não tem. É tudo compartilhado. O CICS é mão de vaca por design.
🔹 MÓDULO II – Básico de Programação CICS
 |
| CICS COBOL Estrutura basica de um programa |
No modo programação em COBOL, o CICS muda completamente a forma de pensar do programador — e é aí que muita gente tropeça. Em CICS, você não escreve um programa que roda do início ao fim; você escreve respostas a eventos controladas pelo gerenciador transacional.
O programa COBOL é carregado uma vez na memória e compartilhado por centenas ou milhares de usuários. Por isso ele precisa ser quasi-reentrant: nada de variáveis globais inocentes, nada de estado permanente sem controle. Cada execução acontece dentro de uma TASK, criada pelo CICS quando uma transação é disparada ou um programa é chamado via LINK, XCTL ou START.
Toda interação com o mundo externo é feita por comandos EXEC CICS. Não existe READ direto, não existe WRITE direto, não existe DISPLAY. Tudo passa pela API do CICS: READ FILE, SEND MAP, RECEIVE MAP, WRITEQ, LINK. Cada comando retorna códigos RESP e RESP2, e ignorar isso é pedir ABEND.
O fluxo é quase sempre pseudo-conversacional: o programa recebe dados, processa, grava se necessário, envia a tela e termina. No próximo ENTER, o CICS cria outra TASK e chama o programa de novo, passando o estado mínimo via COMMAREA ou Channel/Container.
No estilo Bellacosa: programar CICS em COBOL é aceitar que o controle não é seu. E justamente por isso funciona.
📌 O que é
Ensina como escrever programas CICS em COBOL, comandos EXEC CICS, EIB, SEND/RECEIVE, pseudo-conversação e NEWCOPY.
🧠 Resumo rápido
Programar CICS é pensar em eventos, não em fluxo contínuo. Cada ENTER é um novo começo.
🧪 Exemplo
⚠️ Dica Bellacosa
Se você usar
STOP RUNem CICS, o sistema vai te julgar silenciosamente.
🥚 Easter Egg
O EIB é o “log secreto” da task. Tudo o que deu errado (ou certo) está lá.
🤫 Fofoquice
Conversacional “raiz” funciona… até o dia que 300 usuários derrubam a região.
🔹 MÓDULO III – BMS (Basic Mapping Support)
 |
| Tela BMS CICS processo de compilação |
Quando falamos de CICS + BMS + terminal 3270, estamos falando da engenharia raiz da interface homem-máquina no mainframe, sem JavaScript, sem frescura e com latência ridiculamente baixa.
A BMS (Basic Mapping Support) é a camada que define a tela 3270. Ela não desenha pixels; ela define campos: posição, tamanho, proteção, intensidade, cor, se aceita teclado ou não. Tudo isso vira um mapa físico que o terminal entende e um mapa lógico que o programa COBOL usa. É separação de responsabilidades antes de isso virar moda.
No funcionamento real, o programa CICS envia a tela usando EXEC CICS SEND MAP. O CICS converte o mapa BMS em um buffer 3270 e manda para o terminal. O usuário digita, pressiona ENTER, e o terminal não executa nada — ele apenas devolve o buffer de campos alterados. Simples e eficiente.
Quando o programa faz EXEC CICS RECEIVE MAP, o CICS interpreta o buffer recebido, preenche as áreas correspondentes no copybook do mapa e informa qual tecla foi pressionada via DFHAID. Nenhum campo inválido passa despercebido se você souber testar o byte de atributo.
No estilo Bellacosa: BMS não é feio, é honesto. Ele entrega exatamente o que promete: controle total, previsibilidade absoluta e zero surpresas em produção.
📌 O que é
BMS define telas 3270: layout, campos, atributos, cores, proteção, cursor.
🧠 Resumo rápido
BMS é HTML dos anos 70, só que mais rápido e sem frescura.
🧪 Exemplo
Campo protegido + numérico:
⚠️ Dica Bellacosa
Tela feia é culpa do programador, não do CICS.
🥚 Easter Egg
O byte de atributo é onde mora a magia: cor, intensidade, proteção e cursor.
🤫 Fofoquice
Todo mundo copia DFHBMSCA sem saber metade do que ele tem.
🔹 MÓDULO IV – Ferramentas de Apoio
 |
| Comandos de linha CICS |
No CICS em linha de comando, você abandona o conforto do código e entra no território onde o sistema se revela. Ferramentas como CEDF, CEDX, CECI, CEMT, CESN, CECS e CMAC não são opcionais — são o kit de sobrevivência de quem resolve problema de verdade.
O CEDF é o debugger raiz. Ele intercepta cada EXEC CICS, mostra argumentos, RESP codes, EIB, working-storage e permite alterar valores em tempo real. O CEDX é a versão estendida: mais detalhes, mais poder, mais chance de fazer besteira se não souber o que está fazendo. Debug sem recompilar, do jeito que só mainframe permite.
O CECI é o intérprete de comandos CICS. Serve para testar READ, WRITE, SEND MAP e tudo mais sem escrever uma linha de COBOL. Ideal para provar que o erro não é do arquivo, é do programa. Já o CECS valida sintaxe de comandos CICS — evita erro bobo que vira ABEND caro.
O CEMT é o painel de controle do CICS: status de tasks, arquivos, programas, filas, conexões. Quem domina CEMT entende a região. O CESN cuida de segurança: sign-on, sign-off e identidade do usuário. E o CMAC é a enciclopédia de abends e mensagens — onde você descobre que o erro já aconteceu antes, só não com você.
Estilo Bellacosa: essas transações não são ferramentas — são raio-X do sistema vivo.
📌 O que é
CEDF, CEDX, CECI, CECS e CMAC — o kit sobrevivência do programador CICS.
🧠 Resumo rápido
CEDF é o debugger raiz: feio, poderoso e perigoso.
🧪 Exemplo
Usar CECI para testar um READ VSAM sem escrever código.
⚠️ Dica Bellacosa
Nunca use CEDF em produção sem autorização. O sysprog sente.
🥚 Easter Egg
CEDF permite forçar ABEND. Sim, oficialmente.
🤫 Fofoquice
CEDF + 2 terminais é coisa de veterano que não confia em ninguém.
🔹 MÓDULO V – Acessando Arquivos
 |
| CICS acessando Dataset VSAM |
Quando o CICS acessa um dataset VSAM, não existe improviso — existe controle fino, concorrência disciplinada e medo saudável de corromper dados. Diferente do batch, aqui tudo acontece online, em milissegundos, com dezenas ou milhares de usuários disputando o mesmo arquivo.
Antes de qualquer coisa, o VSAM é definido ao CICS como um recurso: nome lógico, tipo (KSDS, ESDS ou RRDS), modo de acesso e regras de compartilhamento. O programa COBOL nunca acessa o VSAM direto; ele pede educadamente via EXEC CICS READ, WRITE, REWRITE ou DELETE. Quem decide se pode ou não é o CICS.
No acesso direto, o programa fornece a chave (RIDFLD) e o CICS localiza o registro. Se for só leitura, tudo bem. Se for atualização, entra o jogo sério: lock de registro. O CICS garante que só uma TASK mexa naquele dado por vez. Se outra tentar, ela espera — ou recebe exceção.
No acesso sequencial (browse), o CICS cria um cursor lógico com STARTBR e entrega registro por registro via READNEXT. Tudo controlado, tudo rastreável. Se a TASK cair no meio, o CICS sabe exatamente onde estava.
Estilo Bellacosa: VSAM no CICS não é arquivo — é recurso crítico. Trate como tal, ou o sistema te cobra com juros.
📌 O que é
Leitura de arquivos VSAM (ESDS, KSDS, RRDS), acesso direto e sequencial.
🧠 Resumo rápido
CICS acessa VSAM sem JCL, sem batch, sem paciência.
🧪 Exemplo
⚠️ Dica Bellacosa
READ sem RESP é convite para ABEND invisível.
🥚 Easter Egg
Browse (STARTBR/READNEXT) é cursor de banco de dados versão 1974.
🤫 Fofoquice
Problema de concorrência quase sempre é batch rodando fora do horário.
🔹 MÓDULO VI – Atualizando Arquivos
 |
| CICS CRUD em VSAM e unidades de trabalho |
No CICS, falar de CRUD sem falar de UOW (Unit of Work) é conversa de quem nunca viu dado corrompido em produção. Aqui, criar, ler, atualizar e excluir registro não é só operação — é compromisso com integridade.
O READ é o ponto de entrada: você consulta um registro VSAM ou DB2 e decide o que fazer. Se for só leitura, o CICS observa. Mas no momento em que você faz um READ UPDATE, o jogo muda. O CICS trava o registro para aquela TASK. A partir daí, qualquer CREATE (WRITE), UPDATE (REWRITE) ou DELETE passa a fazer parte de uma UOW.
A UOW é o acordo sagrado: ou tudo acontece, ou nada acontece. Se o programa termina normalmente, o CICS faz o syncpoint (commit) e grava definitivamente as alterações. Se der erro, ABEND, timeout ou queda de sistema, o CICS entra em ação e desfaz tudo usando seus logs. O sistema volta ao estado consistente como se a TASK nunca tivesse existido.
Isso permite concorrência pesada sem caos. Cem usuários podem acessar o mesmo arquivo e, ainda assim, os dados permanecem corretos. Não é sorte — é arquitetura.
Estilo Bellacosa: CRUD em CICS não é sobre gravar dado, é sobre não estragar o que já existe. Quem ignora UOW aprende rápido… geralmente em produção.
📌 O que é
UPDATE, WRITE, DELETE, UOW, integridade e recuperação.
🧠 Resumo rápido
CICS leva consistência a sério. Se cair, ele volta atrás.
🧪 Exemplo
Atualizar registro com REWRITE após READ UPDATE.
⚠️ Dica Bellacosa
UPDATE sem UOW bem definido = auditor sorrindo.
🥚 Easter Egg
UNLOCK existe porque alguém esqueceu de liberar registro em 1989.
🤫 Fofoquice
Quem não entende syncpoint nunca dormiu após deploy.
🔹 MÓDULO VII – Sub-rotinas
 |
| CICS chamando subrotinas Xctl e link |
No CICS, chamar subrotinas não é simples desvio de fluxo — é orquestração controlada de programas dentro de uma TASK. Aqui, cada chamada tem consequência arquitetural, e errar isso vira efeito dominó em produção.
O comando mais comum é o LINK. Ele chama outro programa, passa o controle, compartilha a mesma UOW e depois volta para o chamador. É a escolha certa quando você precisa reutilizar lógica e manter contexto. LINK é educado, previsível e fácil de auditar. Se o programa chamado falhar, a TASK inteira sente.
Já o XCTL é corte seco. Ele transfere o controle para outro programa e não volta. A partir daí, o chamador deixa de existir. Isso é útil para navegação de fluxo — mudar de tela, mudar de etapa — mas perigoso se usado sem critério. Muito sistema virou labirinto por abuso de XCTL.
O START cria uma nova TASK, independente, assíncrona. É processamento em paralelo versão mainframe: robusto, rastreável e com impacto real no sistema. Use com consciência.
A comunicação entre programas pode ser via COMMAREA (limitada, clássica) ou Channel/Container (moderna, flexível). Ambas exigem disciplina.
Estilo Bellacosa: em CICS, chamar programa é decisão de arquitetura, não linha de código.
📌 O que é
LINK, XCTL, START, LOAD, níveis lógicos e COMMAREA.
🧠 Resumo rápido
LINK volta, XCTL não. Parece simples, mas derruba sistemas.
🧪 Exemplo
⚠️ Dica Bellacosa
COMMAREA grande é gambiarra elegante.
🥚 Easter Egg
START cria task assíncrona — tipo thread, só que sério.
🤫 Fofoquice
Muita aplicação virou “espaguete” por abuso de XCTL.
🔹 MÓDULO VIII – Channel / Container
 |
| CICS e o uso de commarea e cotainers |
No CICS, Channel e Container surgem como resposta adulta a um problema antigo: a COMMAREA era útil, mas pequena, rígida e fácil de virar gambiarra. Channel/Container é o CICS dizendo: “vamos fazer isso direito”.
Um Channel é um agrupador lógico. Pense nele como um envelope nomeado que viaja junto com a TASK. Dentro dele vivem os Containers, que são áreas de dados independentes, cada uma com nome, tipo e tamanho próprio. Não existe limite prático de 32K, não existe copybook único obrigatório, não existe empacotamento manual de estruturas. Cada container carrega exatamente o que precisa carregar.
Na prática, quando um programa chama outro via LINK ou XCTL, ele pode passar um Channel inteiro. O programa chamado acessa apenas os containers que lhe interessam. Isso reduz acoplamento, melhora legibilidade e facilita evolução do sistema sem quebrar o legado.
Os comandos são explícitos: PUT CONTAINER, GET CONTAINER, DELETE CONTAINER. Nada mágico, tudo rastreável. O CICS gerencia memória, ciclo de vida e limpeza automaticamente quando a TASK termina.
Estilo Bellacosa: Channel/Container não é moda — é higiene arquitetural. Quem insiste em COMMAREA gigante não está sendo “clássico”, está só adiando o próximo problema.
📌 O que é
Substituto moderno da COMMAREA.
🧠 Resumo rápido
Channel/Container é COMMAREA adulta, sem limite de 32K.
🧪 Exemplo
Passar múltiplas estruturas sem copybook único.
⚠️ Dica Bellacosa
Projeto novo? Use Channel/Container. Sempre.
 |
| CICS channel |
🥚 Easter Egg
Você pode passar XML, JSON e estruturas complexas sem dor.
🔹 MÓDULO IX – Áreas Externas
 |
| CICS em areas externas getmain e freemain |
No CICS, falar de áreas externas, GETMAIN e FREEMAIN é entrar no território onde o programador deixa de ser usuário da API e vira responsável direto pela memória. Aqui não tem coletor de lixo, não tem perdão automático.
Por padrão, programas CICS são quasi-reentrant e compartilham código. A WORKING-STORAGE existe, mas é controlada pelo CICS. Quando você precisa de memória dinâmica — tabelas em tempo de execução, buffers variáveis, listas crescentes — entra o GETMAIN. Ele pede ao CICS um bloco de memória, no tamanho exato, dentro da região apropriada (TASK ou SHARED). A memória vem zerada, identificável e sob controle do gerenciador.
O perigo começa quando o programador esquece que toda memória alocada precisa ser devolvida. É aí que entra o FREEMAIN. Ele libera explicitamente aquela área. Se você não chamar FREEMAIN, o CICS até limpa no fim da TASK, mas você cria pressão desnecessária na região, degrada performance e ganha fama silenciosa.
GETMAIN mal usado vira vazamento, corrupção e comportamento fantasma. GETMAIN bem usado resolve problemas reais com elegância.
Estilo Bellacosa: GETMAIN é poder, FREEMAIN é responsabilidade. Quem domina os dois escreve sistema robusto. Quem esquece um deles cria incidente que ninguém entende — até o sysprog olhar.
📌 O que é
GETMAIN, FREEMAIN, tabelas em memória, SET.
🧠 Resumo rápido
Memória dinâmica em CICS é poder — e perigo.
⚠️ Dica Bellacosa
Quem esquece FREEMAIN cria vazamento silencioso.
🔹 MÓDULO X – Filas TD e TS
 |
| CICS e dados armazenados em ts e td |
No CICS, filas TD e TS existem para resolver dois problemas distintos que muita gente insiste em misturar. E quando mistura, dá dor de cabeça.
As filas TD (Transient Data) são feitas para mensagens sequenciais: logs, integração, auditoria, disparo de processos. Você escreve, alguém lê, acabou. Elas podem ser intrapartition (gerenciadas totalmente pelo CICS) ou extrapartition (apontando para datasets externos). TD é fluxo, é trilha, é “escreveu, seguiu em frente”. Não é banco de dados e não é memória temporária.
Já as filas TS (Temporary Storage) são armazenamento temporário com nome. Você grava um item, lê depois, atualiza, apaga quando quiser. TS é usada para guardar contexto entre pseudo-conversações, listas temporárias, dados intermediários. Pode ser em memória ou em dataset, dependendo da configuração. É flexível, mas exige disciplina.
A regra não escrita: TD não se lê para decidir lógica; TS não se usa como persistência definitiva. TD é linear, TS é aleatório. Cada uma tem custo, impacto e comportamento próprios.
Estilo Bellacosa: TD é correio, TS é gaveta. Quem usa correio como gaveta perde carta. Quem usa gaveta como arquivo perde o sistema.
📌 O que é
Queueing no CICS: TD (logs, integração) e TS (temporário).
🧠 Resumo rápido
TD é “mensagem”, TS é “memória com nome”.
⚠️ Dica Bellacosa
TS não é banco de dados. Nunca foi.
🔹 MÓDULO XI – Tratamento de Exceções
 |
| CICS trantando erros e exceções |
No CICS, tratamento de erros e exceções não é detalhe — é parte da arquitetura. Aqui o sistema assume que algo vai dar errado e se prepara melhor do que muita aplicação moderna.
Toda chamada EXEC CICS retorna códigos RESP e RESP2. Ignorar isso é escolher viver no escuro. O RESP indica o tipo geral da condição; o RESP2 detalha o motivo real. Arquivo não encontrado, registro bloqueado, mapa inválido, segurança negada — tudo é sinalizado. Quem testa RESP controla o fluxo. Quem não testa, recebe ABEND surpresa.
Além disso, o CICS permite HANDLE CONDITION, que desvia automaticamente o fluxo quando uma exceção ocorre. É poderoso, mas exige disciplina. Existe também o NOHANDLE, para quando você quer assumir o risco conscientemente. Já o IGNORE CONDITION é a forma oficial de dizer: “sei que isso pode acontecer e não é erro”.
Para falhas graves, entra o HANDLE ABEND. Ele permite capturar o abend, registrar contexto, liberar recursos e até apresentar mensagem amigável ao usuário antes do fim da TASK. O CICS não deixa o sistema cair — ele isola o problema.
Estilo Bellacosa: erro em CICS não é acidente, é evento esperado. Trate, registre e siga em frente. Quem não faz isso vira estudo de caso no CMAC.
📌 O que é
RESP, RESP2, HANDLE CONDITION, HANDLE ABEND.
🧠 Resumo rápido
Erro não tratado em CICS vira ABEND educacional.
⚠️ Dica Bellacosa
RESP é obrigação moral.
🔹 MÓDULO XII – Programas Exemplo
📌 O que é
Integra tudo: tela, VSAM, navegação, exceções.
🧠 Resumo rápido
Aqui o aluno vira programador de verdade.
📚 GUIA DE ESTUDO (Bellacosa Approved)
 |
| Mapa do Tesouro CICS |
🥇 Ordem ideal
-
Conceitos + TASK
-
EXEC CICS + EIB
-
BMS
-
VSAM READ/BROWSE
-
UPDATE + UOW
-
LINK/XCTL
-
Channel/Container
-
Exceções
🛠️ Treinar sempre
-
CECI antes de codar
-
CEDF em ambiente controlado
-
Ler CMAC após ABEND
🧠 Mentalidade
CICS não executa programas.
Ele orquestra eventos.
