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


EXEC CICS SEND
     MAP('TELA01')
     MAPSET('MAP01')
END-EXEC

⚠️ Dica Bellacosa

Se você usar STOP RUN em 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:


DFHMDF POS=(5,10),LENGTH=10,ATTRB=(PROT,NUM)

⚠️ 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


EXEC CICS READ
     FILE('ARQ01')
     INTO(AREA)
     RIDFLD(CHAVE)
END-EXEC

⚠️ 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


EXEC CICS LINK
     PROGRAM('PGM02')
     COMMAREA(AREA)
END-EXEC

⚠️ 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

Em breve disponibilizarei o link do repositorio do GITHUB.

📌 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

domingo, 7 de outubro de 2012