Florença e o show de fantoches.

Firenze a disneylandia da Italia

De todas as cidade italianas que visitei, Firenze me marcou por ser a mais viva. Comparando-a ha um grande parque de diversões, imagine uma cidade que atrai multidões.

Justamente por ter tantos turistas a cidade se converteu em uma grande parque, com inúmeras atraçoes desde lojas sofisticadas de marcas famosas, a igrejas milenares e a museus famosos no mundo inteiro.

Uma das coisas que mais me encantaram foram os diversos shows de rua, este pequeno video é um show de fantoches, cantando e dançado, era impossível não parar e assistir um pouco.

Velhos sabores e ventos de mudanças

Velhos sabores e ventos de mudanças

O tempo passa.
E passa sem pedir submit, sem avisar no console, sem dar chance de cancel. A gente cresce, muda, reconfigura prioridades, perde referências, esquece histórias inteiras e, curiosamente, pinta outras com cores que talvez nunca tenham existido daquele jeito. A memória, como todo sistema antigo, tem seus patches, seus workarounds e seus bugs conhecidos.

Com o tempo, começamos a sentir saudade das pessoas que partiram. Não apenas das que morreram, mas também daquelas que simplesmente saíram do nosso círculo interno. Amizades que um dia rodavam em full shared mode passam a existir só como arquivos arquivados, lidos de vez em quando, em modo read-only. Outras novas surgem, entram em produção, algumas ficam, outras falham no teste de carga e desaparecem silenciosamente.

Velhos filmes já não emocionam do mesmo jeito. Filmes novos às vezes surpreendem, às vezes passam sem deixar log. A vida entra num período de inconstância contínua, uma sequência de mudanças, novidades e descobertas. Parece um sistema que nunca para, sempre em upgrade, sempre em maintenance window — e nunca totalmente estável.

A verdade é que a vida vai transcorrendo.
O relógio não para. O contador de tempo só incrementa. E, aos poucos, vamos ficando mais desapegados. Mais céticos. Com menos sonhos grandiosos e mais metas pequenas, práticas, possíveis. Aquela lista infinita de desejos vai sendo reduzida, otimizada, priorizada. Scope reduction, diriam os gerentes.

São tantas mudanças. Algumas felizes, daquelas que aquecem o coração. Outras infelizes, que deixam cicatrizes invisíveis. Momentos doces, que lembram sobremesa de infância. Momentos amargos, difíceis de engolir. E muitos, muitos momentos agridoce, esse sabor estranho que só quem já acumulou alguns bons anos de uptime conhece bem.

Mas isso é viver.
Viver é acumular experiências como quem acumula versões: umas melhores, outras piores, mas todas necessárias para chegar até aqui. É entender que nem tudo precisa ser novo, nem tudo precisa ser descartado. Alguns sabores antigos continuam fazendo sentido, mesmo num mundo obcecado por novidades.

No fim das contas, vamos seguindo.
Com menos pressa, menos ilusão, talvez menos brilho nos olhos — mas com mais entendimento. E percebendo que envelhecer não é perder sabor, é aprender a reconhecê-lo melhor.

Porque viver, no fim, é isso:
executar o job da vida, aceitar os return codes, e seguir em frente acumulando anos, histórias… e memórias que, mesmo antigas, ainda sabem exatamente como nos tocar.

🍖 GRUPO SÉRGIO — Meu Primeiro Rodízio, Minha Primeira Side Quest Gastronômica

🍖 GRUPO SÉRGIO — Meu Primeiro Rodízio, Minha Primeira Side Quest Gastronômica
Bellacosa Mainframe — Blog El Jefe Midnight Lunch

---

Há coisas que a vida guarda numa gaveta secreta da alma.
Pequenas, bobas até.
Mas que quando abertas, uau, soltam luz, cheiro, sabor e uma saudade doce.

Nos anos 1970, aquilo que hoje se faz sem pensar — pedir iFood, entrar no Outback, comer rodízio no almoço da firma — era coisa de outro mundo.
Raro. Festivo.
Um evento com brilho próprio.

E eu tenho uma dessas joias guardadas:
a primeira vez que fui a um restaurante de rodízio.

---

🍞 Antes do luxo existia marmita afetiva

Eu fuço os cantos da memória e não lembro exatamente quando.
Só sei que veio depois de muitas viagens onde o restaurante era o céu, mas nós ficávamos com os pés bem plantados na terra.

A regra era clara:
Dona Mercedes não gastava no que podia cozinhar.

A gente viajava com:

• pão caseiro com manteiga e mortadela

• bolo gelado embrulhado em papel alumínio

• refrigerante enrolado em jornal pra ficar fresco

• e aquele cheirinho de lar que vinha junto no porta-malas

Restaurante era luxo.
Piquenique era realidade.
E olha — era bom demais.

Mas veio o grande dia.

---

🥩 GRUPO SÉRGIO — Radial Leste, na Quarta Parada: o portal para outro mundo

Não lembro quem casou.
Se era primo, vizinho, amigo do meu pai… tanto faz.
Meu foco de pequeno oni devorador era um só:
festa + comida + novidade.

Chegamos ao lendário GRUPO SÉRGIO, na Radial Leste — um salão de rodízio tão grande que mais parecia ginásio de escola técnica.
Dizem — e eu confirmo — cabiam mil pessoas lá dentro.
E não é exagero da minha pena saudosista não, hein?

💫 E lá estava eu, com os olhos faiscando…

✨ Mesas enormes, toalhas brancas impecáveis
✨ Pratos de porcelana do tamanho da lua cheia
✨ Talheres pesados como espada de samurai
✨ Garçons desfilando como NPCs de missão principal
✨ O cheiro sagrado da carne assando no altar de fogo

Atrás do balcão, três homens duelavam com as brasas.
Era arte. Era magia. Era churrasco.

Primeiro veio a massa:
spaghetti, fusili, lasagna, penne — o chef apontava, eu dizia sim pra tudo.

Depois saladas, palmito, queijo, azeitona.
Tudo chique, tudo brilhante, tudo novo.

E então…

---

🔥 ROUND 3 — A INVASÃO DAS CARNES

A verdadeira quest começou.

• linguiça calabresa

• filé macio e escapando do garfo

• costela que quase chorava no corte

• maminha, frango, pernil, carneiro

• e mais, e mais, e mais…

Eu comia como se o amanhã fosse ficção científica.
Como se aquele fosse o último jantar antes do apocalipse.
E talvez fosse — afinal, quando a vida daria outro banquete daquele?

Pequeno Vaguinho entrou no modo glória + buff de apetite + XP infinito.

Mas o final boss ainda viria…

---

🍮 O Carrinho das Sobremesas — Game Clear

Quando as bandejas se foram e o estômago já tocava o céu,
surge ele…

O carrinho brilhante, celestial, a nave mãe do açúcar.

Em cima:

• pudim de leite — o mais brilhante dos artefatos

• pudim de creme

• bolo recheado com camadas impossíveis

• pêssego em calda

• gelatinas tremelicando como geleia de pixels

• compotas, tortas, doce até a alma ficar grudenta

Resultado?

Game zerado.
Final feliz desbloqueado.
NPCs sorriam. O mundo piscava.
E eu sabia: aquele dia ficaria guardado para sempre.

---

Hoje, rodízio é trivial.
PF vira almoço de qualquer terça.
A vida segue, o paladar amplia.

Mas nenhum churrasco — por mais caro, fino, premiado que seja — superou
o primeiro portal aberto na Radial Leste, o Rodízio Grupo Sérgio.

Foi como derrotar o chefão final e, de brinde, ganhar o pergaminho da lembrança eterna.

E toda vez que fecho os olhos, ainda vejo:
a carne brilhando, o prato pesado, o sorriso da infância.

E sinto fome de novo.
Não só de comida —
de vida. 🥩🔥

– Bellacosa Mainframe, Vagner menino, Vagner hoje.

 

🧠🔥 O Mainframer do Século XXI: sobrevivente, arquiteto e tradutor de mundos

---

02:17 — Prólogo: o profissional que já foi dado como extinto

Se você perguntar para um recruiter distraído, ele dirá:

“Mainframe é legado.”

Se você perguntar para o sistema financeiro mundial, ele responde:

“Sem ele, nada abre.”

O mainframer do século XXI não é um fóssil.
Ele é um sobrevivente técnico, um arquiteto silencioso e, acima de tudo, um tradutor entre mundos.

---

1️⃣ História curta de uma profissão longa 🕰️

• Anos 70–80: operador, JCL, respeito ao batch

• Anos 90: analista, CICS, DB2, MQ

• Anos 2000: integração, web, SOA

• Anos 2010: APIs, eventos, cloud

• Hoje: core engineer + distributed architect

😈 Easter egg histórico:
Quem aprendeu CICS antes de REST já entendia request/response melhor que muito dev moderno.

---

2️⃣ Sobrevivente: por que o mainframer ainda está aqui 🧱

Ele sobreviveu porque:

• Aprendeu a respeitar estado

• Desconfiou de “eventual”

• Nunca romantizou falha

• Tratou produção como território sagrado

📌 Tradução Bellacosa:
Enquanto outros aprendiam com outage, o mainframer evitava que eles existissem.

---

3️⃣ Arquiteto: quando aplicações viraram distribuídas 🧩

Aplicações distribuídas trouxeram:

• Falha parcial

• Latência

• Observabilidade obrigatória

• Orquestração complexa

O mainframer já conhecia:

• Controle transacional

• Limites claros

• Contratos estáveis

• Disciplina operacional

💣 Easter egg:
Two-Phase Commit traumatiza, mas educa.

---

4️⃣ Tradutor de mundos: o papel invisível 🌍

O mainframer moderno traduz:

• Cloud → Core

• Stateless → Stateful

• Velocidade → Consistência

• Experimento → Produção

Ele explica:

“Não é que não dê para fazer.
É que não dá para fazer assim.”

---

5️⃣ Passo a passo: mentalidade distribuída para mainframers

1️⃣ Aceite falha parcial
2️⃣ Desacople sem perder controle
3️⃣ Publique eventos, não segredos
4️⃣ Trate APIs como contratos legais
5️⃣ Observe tudo
6️⃣ Documente o óbvio
7️⃣ Nunca confie só no retry

🔥 Dica Bellacosa:
Retry sem idempotência é só negação organizada.

---

6️⃣ Conhecimento básico essencial (sem modinha) 📚

Conceitos

• CAP Theorem

• Event-driven architecture

• Observabilidade

• Resiliência

• SRE

• Arquitetura híbrida

Ferramentas

• MQ / Kafka

• APIs

• z/OS Connect

• Instana / APM

• CI/CD no z/OS

---

7️⃣ Curiosidades que só mainframer percebe 👀

• “Alta disponibilidade” sempre foi requisito

• Segurança nunca foi opcional

• Batch quebrado ensina humildade

• Produção não é laboratório

😈 Easter egg:
Quem já leu SMF em hexadecimal entende logs distribuídos sem chorar.

---

8️⃣ Guia de estudo prático 🗺️

Para evoluir sem perder identidade

• Estude arquitetura, não frameworks

• Entenda cloud sem romantizar

• Aprenda a dizer “não” com argumentos

• Leia post-mortems

• Observe sistemas reais

📌 Mantra:
Tecnologia muda. Fundamentos não.

---

9️⃣ Aplicações reais desse perfil 💼

• Arquitetura corporativa

• Core banking

• Integrações críticas

• Governança técnica

• Modernização sem suicídio operacional

🎯 Mercado:
Quem entende mainframe e distribuído não fica desempregado.
Fica sobrecarregado.

---

🔟 Comentário final (03:02 — tudo verde)

O mainframer do século XXI:

• Não nega o passado

• Não idolatra o futuro

• Não quebra produção por hype

Ele conecta eras.

🖤 El Jefe Midnight Lunch encerra assim:
“Enquanto uns discutem se o mainframe morreu, ele segue processando o mundo.”

 

 🜂 El Jefe Midnight Lunch apresenta

O Último Grande Natal — 1982, O Encerramento de um Ciclo na Famiglia Bellacosa

Uma memória guardada em fita cassete, cheiro de porco assado, risada de 50 adultos, e o brilho inalcançável de um caminhão da Estrela.

---

Existem datas que não passam.
Existem fotos que desbotam, mas não desaparecem.
E existem festas que, mesmo quando terminam, continuam iluminando o coração como lâmpadas coloridas que ninguém teve coragem de guardar.

Para mim, Vagner do século XXI,
o Natal de 1982 foi essa constelação inesquecível.

Venha me acompanhar nesse mergulho no tempo —
para revisitar o último grande ritual da Famiglia,
uma despedida involuntária, doce e amarga,

antes de o Brasil virar o Brasil dos anos 80,

antes da inflação morder os sonhos, 

antes do cruzeiros novos derreterem,

antes dos adultos perderem o silêncio,

antes de entender o peso da palavra “última”.

---

🜁 O Anúncio — A Profecia de Anna

Era um domingo qualquer,
mas toda família sabe que os domingos nunca são só domingos.

Minha avó Anna, mulher de fibra, tecelã de vida e de fios,
sentou-se no almoço com aquele ar de quem guarda uma decisão maior que ela mesma.

No meio da macarronada, da criançada correndo, dos tios discutindo futebol,
ela falou a frase que dividiria a história em duas metades:

“Este será o último grande Natal.”

E o mundo parou sem parar.

Eu tinha 8 anos,
não entendia política,
não entendia inflação,
não entendia custo de carne,
não entendia aposentadoria.

Mas entendi — por alguma mágica especial que só crianças têm —
que aquilo significava que algo grande estava acabando.

---

🜃 O Avô Pedro e o Fim de Uma Era

Meu avô Pedro, homem sério e carismático à sua maneira,
estava se aposentando, após uma longa vida nas fábricas da Mooca.

E na sua casa — como na de milhões de brasileiros —
aposentadoria era sinônimo de “dinheiro mais curto”.

Somado à crise econômica dos anos 80,
à hiperinflação que começava a devorar salários antes do dia 10,
à incerteza do país que entrava numa tempestade…

ficou claro:

O Natal de 1982 não era apenas uma festa.

Era uma despedida de um estilo de vida.
Da fartura repartida.
Do porco criado no quintal e abatido exclusivamente para as ceias, eram dois um para o natal e outro para o ano novo.
Dos 20 primos correndo pelo quintal.
Dos mais de 50 adultos conversando, rindo, brigando, reconciliando —
essas coisas de família italiana que só quem vive sabe.

---

🜄 O Melhor Presente — O Caminhão Basculante da Estrela

E como é curioso o coração infantil:
enquanto o mundo dos adultos desmoronava,
você ganhava o que seria o melhor presente de Natal da sua vida.

Um caminhão basculante a pilha, da lendária fabrica de brinquedos Estrela.

Não era só um brinquedo —
era uma máquina do tempo.
Era a prova brilhante de que aquele Natal tinha sido pensado com amor,
que mesmo na sombra do “último”,
houve espaço para alegria genuína.

Criança não entende o fim das coisas,
mas entende brilho nos olhos.

E aquele caminhão brilhou, fisicamente durou somente um ano, destruído pelo incêndio de 1983, a grande tempestade, mas minha memória, ainda viva décadas dentro de você.

---

🜁 Um Ano de Partidas — Adeus, Luigi

1982 também carregou luto.

O adeus ao bisavô Luigi, figura carismática,
pilar moral, emocional e espiritual da família.

Sua partida não apagou a festa —
mas deu a ela aquele tom meio sépia,
meio nostálgico,
meio de fotografia antiga guardada na gaveta da cozinha.

Foi o último Natal da velha guarda completa.
O último com a mesa cheia de verdade.

---

🜃 O Ano Seguinte — A Tempestade de 1983

Depois da festa, veio a realidade.

1983 foi duro. Mudei, cresci na marra, morei em 3 cidades num unico ano...
Muito duro.

O país mergulhou ainda mais na crise,
as famílias apertaram o cinto,
e o ciclo dourado das festas da Famiglia Bellacosa
virou memória.

Não por falta de amor.
Mas por falta de condições.

E às vezes, a vida é assim:
não acaba com estrondo,
acaba com um anúncio no almoço de domingo.

---

🜄 Mas Nada Apaga 1982

O Natal de 1982 não está perdido.
Ele vive em:

• cada cheiro que lembra o porco assado,

• cada risada registrada na mente,

• cada primo que cresceu e se espalhou pelo mundo,

• cada adulto que partiu,

• cada gesto de Anna e Pedro,

• cada tradição que não volta mais, mas também não morre.

Ele vive, principalmente,
em mim.

No menino de 8 anos que assistiu sem entender
um ciclo inteiro se fechar.

E que hoje, décadas depois,
escreve, sente, recorda —
e revive.

---

🜂 Conclusão — O Derradeiro Adeus às Festas da Famiglia Bellacosa

As famílias são como sistemas legados:
robustas, emocionais, cheias de histórias,
mas também sensíveis às mudanças externas.

1982 foi o shutdown de um módulo inteiro da vida familiar:

• encerrou uma tradição,

• selou uma era,

• marcou a transição entre abundância e adaptação,

• e se tornou um cartão-postal emocional,
  guardado como o último backup de um tempo que não volta.

Mas, como todo bom sistema mainframeiro,
ele continua rodando na sua memória —
estável, íntegro, imutável.

Porque eu não lembro apenas da festa.
Me lembra do que ela significa:

Que mesmo quando o mundo aperta,
a família encontra um jeito de celebrar.

E alguns Natais não são apenas datas.
São destinos.

Peposa

A sobrevivente com seus 43 anos a Peposa da Vivi... os carrinhos se perderam no tempo,mas essa pequena testemunha de pelúcia, sobreviveu ao tempo.

 

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

1. Conceitos + TASK

2. EXEC CICS + EIB

3. BMS

4. VSAM READ/BROWSE

5. UPDATE + UOW

6. LINK/XCTL

7. Channel/Container

8. 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.

Trabalho em curso