Translate

Mostrar mensagens com a etiqueta commarea. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta commarea. Mostrar todas as mensagens

quinta-feira, 1 de maio de 2025

☕💣🚀 PADAWAN, MODERNIZAR O CICS NÃO É JOGAR COBOL FORA. É ENSINAR UMA LENDA DE 50 ANOS A FALAR REST, JAVA E CLOUD!

Bellacosa Mainframe introducao a modernizacao do cics mainframe seculo xxi


☕💣🚀 PADAWAN, MODERNIZAR O CICS NÃO É JOGAR COBOL FORA. É ENSINAR UMA LENDA DE 50 ANOS A FALAR REST, JAVA E CLOUD!

Durante décadas, muita gente repetiu a mesma profecia:

"O Mainframe vai acabar."

Enquanto isso, silenciosamente, o CICS continuou processando bilhões de transações por dia.

E aqui está a grande ironia tecnológica da nossa época:

As empresas que tentaram substituir completamente seus sistemas CICS descobriram que recriar 40 anos de regras de negócio é muito mais difícil do que parece.

Foi então que surgiu uma pergunta mais inteligente:

E se, em vez de substituir, nós modernizarmos?

É exatamente isso que o CICS moderno faz.


O PRIMEIRO ERRO: CONFUNDIR MODERNIZAÇÃO COM REESCRITA

Quando alguém fala em modernização, muitos imaginam:

COBOL -> Java
Mainframe -> Cloud
3270 -> Browser

Mas o CICS moderno propõe algo diferente:

COBOL + Java
Mainframe + Cloud
3270 + REST
VSAM + APIs

A IBM chama isso de:

Hybrid Cloud

Ou seja:

O sistema continua executando onde sempre funcionou, mas agora conversa com aplicações modernas.


PASSO 1 – ENTENDER O QUE VOCÊ POSSUI

Antes de modernizar qualquer aplicação CICS, faça um inventário.

Identifique:

  • Transações

  • Programas COBOL

  • Arquivos VSAM

  • DB2

  • COMMAREAs

  • Web Services existentes

  • Dependências

Perguntas importantes:

  • O sistema ainda usa 3270?

  • Existem APIs?

  • Existe documentação?

  • Existe código-fonte?

Acredite:

Nem sempre existe.

E sim...

Existem sistemas produtivos em que o fonte original desapareceu há décadas.


PASSO 2 – SEPARAR APRESENTAÇÃO E NEGÓCIO

A arquitetura clássica ensinada pela IBM possui:

Presentation Layer
Business Logic Layer
Data Services Layer

Exemplo clássico:

PAYPGM
    |
    v
PAYBUS
    |
    v
VSAM

O PAYPGM fala com o usuário.

O PAYBUS contém as regras de negócio.

Quando isso já existe, a modernização fica muito mais simples.


PASSO 3 – TRANSFORMAR O NEGÓCIO EM SERVIÇO

O erro mais comum é tentar modernizar a tela.

A tela não tem valor.

O valor está na regra de negócio.

Por isso o melhor caminho normalmente é:

Browser
    |
REST API
    |
PAYBUS
    |
VSAM

Observe:

O COBOL continua vivo.

Apenas ganhou uma nova interface.


PASSO 4 – APOSENTAR A COMMAREA

A COMMAREA foi uma revolução.

Mas ela possui um limite:

32767 bytes

Isso era enorme em 1975.

Hoje não é.

A solução moderna:

Channels
Containers

Antes:

EXEC CICS LINK
     COMMAREA(...)
END-EXEC

Depois:

EXEC CICS LINK
     CHANNEL('PAYROLL')
END-EXEC

Benefícios:

  • Sem limite prático

  • Dados organizados

  • Menos copybooks gigantes

  • Melhor integração


PASSO 5 – INTRODUZIR JAVA SEM TRAUMA

Aqui surge a pergunta que assombra muitos programadores COBOL:

"Precisamos reescrever tudo em Java?"

Não.

E provavelmente você não deveria.

O CICS permite executar Java dentro do próprio ambiente.

Arquitetura:

CICS
   |
JVM Server
   |
Liberty
   |
Java

Agora o cenário fica interessante:

COBOL
   |
LINK
   |
Java

e também:

Java
   |
LINK
   |
COBOL

Os dois mundos coexistem.


PASSO 6 – DESCOBRIR O PODER DO LINK TO LIBERTY

Este é um dos recursos mais elegantes do CICS moderno.

Um programa COBOL pode chamar um método Java.

Exemplo:

@CICSProgram("CUSTGET")

Agora o COBOL pode executar:

EXEC CICS LINK
     PROGRAM('CUSTGET')
END-EXEC

Sem HTTP.

Sem REST.

Sem MQ.

Sem gambiarra.

Tudo dentro do próprio CICS.


PASSO 7 – ADOTAR APIs REST

Uma das formas mais comuns de modernização é expor programas COBOL como APIs REST.

Arquitetura:

Mobile App
     |
REST
     |
Java
     |
PAYBUS
     |
VSAM

O usuário nem imagina que existe COBOL por trás.

E isso é perfeitamente aceitável.

Aliás...

É exatamente o objetivo.


PASSO 8 – IMPLEMENTAR EVENT PROCESSING

Aqui está um superpoder pouco conhecido.

Imagine um sistema de apostas.

Toda vez que alguém aposta mais de R$ 50.000:

Evento

Mas você perdeu o fonte.

Como alterar o programa?

Você não altera.

O CICS observa eventos.

Exemplo:

EXEC CICS LINK

Ao detectar o comando:

Evento gerado

Sem modificar uma linha de COBOL.

Isso é Event Processing.


PASSO 9 – PROGRAMAÇÃO ASSÍNCRONA

Outro recurso poderoso.

Tradicional:

Programa A
espera B
espera C
espera D

Moderno:

Programa A

+---- B
|
+---- C
|
+---- D

Tudo executando simultaneamente.

Novas APIs:

RUN TRANSID
FETCH CHILD
FETCH ANY
FREE CHILD

Menos espera.

Mais throughput.

Mais escalabilidade.


PASSO 10 – ENTRAR NO MUNDO DEVOPS

Aqui muitos profissionais acreditam que existe:

DevOps Linux
DevOps Mainframe

Mas a IBM foi direta:

Existe apenas:

DevOps

Ferramentas modernas:

Git
VS Code
Zowe
Jenkins
DBB
Ansible
UrbanCode

O fluxo torna-se:

Git
 |
Build
 |
Test
 |
Deploy
 |
CICS

ERROS MAIS COMUNS

Erro 1

Tentar reescrever tudo.

Resultado:

Projeto de 5 anos.

Orçamento explode.

Sistema antigo continua rodando.


Erro 2

Modernizar a interface e esquecer a regra de negócio.

A regra é o patrimônio.

A tela é apenas um detalhe.


Erro 3

Ignorar testes.

Use:

ZUnit
JUnit
Mockito
Galasa

Erro 4

Não envolver o System Programmer.

Lembre-se:

Arquivos.

Recovery.

Resources.

Bundles.

JVM Servers.

Tudo isso depende dele.


SOLUÇÃO DE PROBLEMAS

EIBCALEN = 0

Primeira entrada da transação.


Programa novo não atualiza

Execute:

NEWCOPY

ou

REFRESH PROGRAM

COMMAREA truncada

Provavelmente ultrapassou:

32K

Migre para Containers.


LINK retornando erro

Verifique:

RESP
RESP2

Sempre.


CURIOSIDADE

Pouca gente sabe, mas o CICS nasceu em uma época em que muitos computadores ainda trabalhavam com cartões perfurados.

Hoje ele executa:

  • APIs REST

  • Java

  • JSON

  • Liberty

  • Cloud

  • DevOps

Sem abandonar sua essência transacional.

Isso talvez explique sua longevidade.


EASTER EGG MAINFRAME

Existe uma frase que quase todo profissional experiente de CICS aprende depois de alguns anos:

"O problema nunca está no CICS."

Primeiro você culpa:

  • CICS

  • VSAM

  • RACF

  • DB2

  • MQ

Depois de algumas horas investigando...

Descobre que esqueceu de fazer:

EXEC CICS RETURN
END-EXEC

ou

EXEC CICS HANDLE CONDITION
END-EXEC

ou simplesmente compilou o programa errado.

Acontece mais do que deveria.


CONCLUSÃO

☕💣🚀 PADAWAN, O MAIOR SEGREDO DA MODERNIZAÇÃO NÃO É TROCAR COBOL POR JAVA.

É entender que o verdadeiro valor está nas regras de negócio acumuladas durante décadas.

O CICS moderno permite adicionar:

  • REST

  • Java

  • Liberty

  • Eventos

  • APIs

  • DevOps

  • Cloud

sem destruir aquilo que já funciona.

E essa talvez seja a definição mais elegante de modernização:

Evoluir sem perder a confiança conquistada por milhões de transações executadas corretamente ao longo de décadas.

domingo, 21 de janeiro de 2024

☕🔥 COMMAREA, CHANNELS e CONTAINERS no CICS TS: O Guia Definitivo para Desenvolvedores COBOL Junior

 

Bellacosa Mainframe e commarea channels e containers no cics ts

☕🔥 COMMAREA, CHANNELS e CONTAINERS no CICS TS: O Guia Definitivo para Desenvolvedores COBOL Junior

Introdução

Todo programador COBOL que inicia no mundo CICS aprende rapidamente três palavras que aparecem em praticamente qualquer aplicação online:

  • COMMAREA

  • CHANNEL

  • CONTAINER

Embora pareçam apenas mecanismos para passagem de parâmetros, na realidade representam três gerações diferentes da evolução do CICS.

Compreender quando utilizar cada abordagem, suas limitações, vantagens, implicações de performance e integração com Web Services, APIs REST e IBM MQ é fundamental para qualquer desenvolvedor que deseje construir aplicações modernas no IBM Z.

A grande dúvida dos iniciantes costuma ser:

"Se a COMMAREA funciona há décadas, por que a IBM criou Channels e Containers?"

A resposta está diretamente relacionada à evolução dos sistemas corporativos.


Como o CICS Enxerga uma Transação

Quando uma transação executa:

Cliente
   |
TRANSAÇÃO
   |
PROGRAMA A

frequentemente o programa precisa:

  • chamar outro programa

  • enviar dados

  • receber retorno

  • transferir controle

Exemplo:

PROGRAMA A
   |
 LINK
   |
PROGRAMA B

Nesse momento os dados precisam ser transferidos.

É aí que entram COMMAREA, CHANNEL e CONTAINER.


COMMAREA — O Clássico do CICS

COMMAREA significa:

Communication Area

Ela surgiu nos primeiros anos do CICS e se tornou durante décadas o principal mecanismo de comunicação entre programas.

Exemplo:

Programa A:

EXEC CICS LINK
     PROGRAM('CLIENTE')
     COMMAREA(WS-COMMAREA)
     LENGTH(200)
END-EXEC

Programa B:

01 DFHCOMMAREA.
   05 CLI-CODIGO PIC 9(08).
   05 CLI-NOME   PIC X(40).

O CICS copia os dados de um programa para outro.


Como Funciona Internamente

Imagine:

PROGRAMA A
   |
   | 200 bytes
   |
PROGRAMA B

O CICS realiza uma cópia física do conteúdo.

Por isso o tamanho importa.


Limite da COMMAREA

O limite máximo teórico é:

64 KB

Na prática:

65.535 bytes

Porém a maioria dos sistemas utiliza:

32 KB

como limite operacional seguro.

Por quê?

Porque historicamente muitos aplicativos e interfaces foram construídos considerando esse valor.


Exemplo de Layout COMMAREA

01 WS-COMMAREA.
   05 WS-HEADER.
      10 WS-OPERACAO PIC X(08).
      10 WS-USUARIO  PIC X(20).

   05 WS-CLIENTE.
      10 WS-CONTA    PIC 9(10).
      10 WS-NOME     PIC X(40).
      10 WS-SALDO    PIC S9(9)V99 COMP-3.

Total:

82 bytes

Vantagens da COMMAREA

Simplicidade

Extremamente fácil.

EXEC CICS LINK

e pronto.


Compatibilidade

Praticamente todos os sistemas CICS do mundo utilizam COMMAREA.


Performance

Para pequenos volumes:

100 bytes
500 bytes
1 KB
2 KB

é extremamente eficiente.


Desvantagens da COMMAREA

Estrutura rígida

Quem envia e quem recebe devem conhecer exatamente o mesmo layout.

Mudou um campo?

Pode quebrar tudo.


Acoplamento forte

Programa A depende diretamente do layout do Programa B.


Limite de tamanho

Web Services modernos frequentemente ultrapassam:

32 KB
50 KB
100 KB
500 KB

A COMMAREA não foi projetada para isso.


O Problema das APIs Modernas

Imagine um JSON:

{
  "cliente": {
     "nome":"João",
     "enderecos":[...],
     "cartoes":[...],
     "seguros":[...]
  }
}

Facilmente pode ultrapassar:

40 KB
80 KB
150 KB

A COMMAREA começa a sofrer.


Surge o CHANNEL

Para resolver isso a IBM criou:

CHANNEL

Pense nele como um envelope.


O que é um CHANNEL?

Um CHANNEL não contém dados.

Ele contém:

CONTAINERS

Imagine:

CHANNEL CLIENTE

   |
   +-- HEADER
   +-- DADOS
   +-- ENDERECOS
   +-- CARTOES
   +-- SEGUROS

O que é um CONTAINER?

Container é onde os dados ficam armazenados.

Cada container possui:

  • nome

  • conteúdo

  • tamanho


Analogia Simples

COMMAREA:

1 caixa gigante

CHANNEL:

1 armário

CONTAINER:

gavetas do armário

Exemplo de Criação

Criando container:

EXEC CICS PUT CONTAINER
     CONTAINER('CLIENTE')
     CHANNEL('CANAL01')
     FROM(WS-DADOS)
     FLENGTH(500)
END-EXEC

Recuperando Dados

EXEC CICS GET CONTAINER
     CONTAINER('CLIENTE')
     CHANNEL('CANAL01')
     INTO(WS-DADOS)
END-EXEC

Limites dos Containers

Ao contrário da COMMAREA:

64 KB máximo

Containers podem armazenar:

Megabytes

de informação.

Na prática:

  • JSON grandes

  • XML grandes

  • payloads extensos

funcionam muito melhor.


Estrutura Recomendada

Exemplo:

CHANNEL CLIENTE

HEADER
CLIENTE
ENDERECOS
TELEFONES
PRODUTOS
LOGS

Cada informação isolada.


Benefícios dos Channels

Menor acoplamento

Cada container pode evoluir independentemente.


Melhor manutenção

Não é necessário reconstruir um layout monolítico.


Escalabilidade

Ideal para integrações modernas.


COMMAREA vs CHANNEL

CaracterísticaCOMMAREACHANNEL
Tamanho64 KBMuito maior
EstruturaÚnicaMúltiplos Containers
JSONLimitadoExcelente
XMLLimitadoExcelente
APIs RESTFracoExcelente
MQBomExcelente
EvoluçãoDifícilFácil

Uso com Web Services

Quando um Web Service recebe:

<cliente>
 ...
</cliente>

ou

{
 ...
}

normalmente o runtime do CICS utiliza:

CHANNEL
CONTAINER

internamente.

Motivo:

Payloads variáveis.


Uso com z/OS Connect

Praticamente todas as implementações modernas utilizam:

JSON
↓
CHANNEL
↓
COBOL

em vez de COMMAREA.


Uso com IBM MQ

MQ pode trabalhar com ambos.


Modelo Tradicional

MQ
  |
COMMAREA
  |
COBOL

Modelo Moderno

MQ
  |
CHANNEL
  |
CONTAINERS
  |
COBOL

Exemplo MQ

Mensagem recebida:

Pedido
Itens
Cliente
Pagamento

Pode ser dividida em:

PEDIDO
ITENS
CLIENTE
PAGAMENTO

Cada parte em um container.


Quando Usar COMMAREA?

Utilize quando:

✅ aplicações legadas

✅ pequenas estruturas

✅ LINK simples

✅ integração interna

Exemplo:

Consulta Cliente
Consulta Agência
Consulta Conta

Quando Usar CHANNEL?

Utilize quando:

✅ APIs REST

✅ JSON

✅ XML

✅ Web Services

✅ MQ moderno

✅ microsserviços

✅ payloads grandes


Estratégia Utilizada pelos Bancos

O que normalmente vemos hoje:

Core COBOL antigo
      |
   COMMAREA

e

APIs novas
      |
CHANNEL
CONTAINER

Os dois convivem perfeitamente.


Erros Comuns dos Iniciantes

Não validar tamanho

LENGTH(...)

deve sempre ser controlado.


Alterar layout sem sincronizar

Clássico problema de COMMAREA.


Usar container gigante

Separar logicamente os dados é melhor.


Não documentar containers

Sempre documente:

CLIENTE
ENDERECO
PRODUTO
PAGAMENTO

Boas Práticas

COMMAREA

  • manter abaixo de 32 KB

  • usar copybooks

  • versionar layouts


CHANNELS

  • containers pequenos

  • nomes padronizados

  • separar responsabilidades


MQ

  • payload desacoplado

  • evitar estruturas gigantes

  • utilizar containers temáticos


Conclusão

A COMMAREA continua viva e continuará por muitos anos. Milhares de aplicações bancárias processam bilhões de transações diariamente utilizando esse mecanismo criado há décadas.

Entretanto, o mundo mudou.

JSON, APIs REST, Open Banking, PIX, Web Services, MQ distribuído e arquiteturas orientadas a serviços exigiram uma evolução do modelo tradicional.

Foi exatamente para atender esse novo cenário que surgiram os Channels e Containers.

O desenvolvedor COBOL moderno não deve enxergar COMMAREA e CHANNEL como concorrentes.

Eles são ferramentas diferentes para problemas diferentes.

A regra prática é simples:

  • COMMAREA para integrações simples e legadas.

  • CHANNEL e CONTAINER para aplicações modernas, APIs, MQ e Web Services.

Quem domina os dois mundos consegue navegar tanto nos sistemas que sustentam os bancos há décadas quanto nas novas arquiteturas digitais que conectam o IBM Z ao restante do planeta.

E essa é uma das habilidades mais valiosas para qualquer programador COBOL que deseja evoluir para desenvolvedor CICS de alto nível.

sábado, 12 de setembro de 2015

🧠 Storage Control no CICS

 

CICS Storage Control

🧠 Storage Control no CICS

Onde o estado vive, onde ele morre e onde ele assombra produção

A imagem mostra:

Storage Control → Storage sources
• COMMAREA
• CWA (Common Work Area)
• TWA (Transaction Work Area)

Isso não é teoria.
Isso é onde bugs se escondem.


🧱 Storage Control – o papel do CICS

O Storage Control é o componente do CICS responsável por:

  • Alocar memória

  • Liberar memória

  • Isolar memória entre tasks

  • Proteger o CICS de você (sim, de você)

Tudo no CICS gira em torno de tasks concorrentes compartilhando CPU, mas não memória — salvo quando você pede explicitamente.


📦 COMMAREA

O clássico, o limitado, o abusado

O que é

Área de comunicação passada entre programas via:

  • LINK

  • XCTL

  • RETURN TRANSID

Características

  • 📏 Tamanho máximo: 32 KB

  • 🔁 Passagem explícita

  • ⏱️ Vida curta (dura o fluxo)

  • 🔒 Isolada por task

Quando usar

  • Dados pequenos

  • Estruturas simples

  • Fluxo linear clássico

Pecados capitais

  • Usar COMMAREA como banco de dados

  • Estourar tamanho

  • Reusar layout errado (ASRA clássico)

💀 ABEND típico: ASRA / AEIP


CICS TWA

🧰 TWA – Transaction Work Area

Estado temporário da transação

O que é

Área de memória associada à transação, não ao programa.

Características

  • Criada automaticamente pelo CICS

  • Acessível por qualquer programa da transação

  • Vive até o RETURN final

Quando usar

  • Guardar estado entre múltiplos programas

  • Fluxo pseudo-conversacional simples

Riscos

  • Confundir TWA com COMMAREA

  • Assumir que sobrevive entre transações (não sobrevive)

💡 Boa prática: TWA é “mochila da transação”, não cofre.


CICS CWA

🏛️ CWA – Common Work Area

O templo dos deuses (e dos pecados)

O que é

Área de memória global do CICS Region.

Características

  • Compartilhada por todas as tasks

  • Inicializada no startup

  • Não é isolada

  • Não é protegida

Quando usar (com muito cuidado)

  • Tabelas de controle

  • Flags globais

  • Cache de leitura

Quando NÃO usar

  • Dados de negócio

  • Dados por usuário

  • Qualquer coisa mutável sem controle

☠️ Risco real: corrupção de dados, race condition, caos silencioso.

CWA é poder absoluto — e poder absoluto gera incidentes absolutos.


🚀 CHANNEL & CONTAINER

O CICS moderno, civilizado e escalável

O que são

Substitutos modernos da COMMAREA.

  • CHANNEL → agrupador lógico

  • CONTAINER → estrutura de dados

Características

  • 📏 Tamanho praticamente ilimitado

  • 📦 Estruturas múltiplas

  • 🔄 Tipagem flexível

  • 🧼 Melhor manutenção

  • 🔐 Mais seguro

Quando usar

  • Aplicações modernas

  • Integração

  • Grandes volumes

  • APIs CICS

Comparação rápida

RecursoCOMMAREACHANNEL/CONTAINER
Tamanho32 KBMuito maior
EstruturaÚnicaMúltiplas
ManutençãoDifícilLimpa
FuturoLegadoPresente e futuro

🗺️ Como ler a imagem como um mainframer

A imagem não está falando só de memória.
Ela está dizendo:

“Escolha errado onde guardar estado
e você vai debugar às 3 da manhã.”


🧠 Regra Bellacosa de Ouro

  • COMMAREA → conversa curta

  • TWA → memória da transação

  • CWA → último recurso

  • CHANNEL/CONTAINER → escolha padrão moderna


☕ Comentário El Jefe Midnight Lunch

“CICS não quebra porque é antigo.
Ele quebra porque alguém tratou memória como variável global.”

🔥 Quem entende Storage Control, domina o CICS.


quarta-feira, 12 de outubro de 2011

🔥 COMMAREA vs CHANNEL/CONTAINER no CICS

 


🔥 COMMAREA vs CHANNEL/CONTAINER no CICS



☕ Midnight Lunch, COMMAREA gigante e o CICS olhando feio

Todo mainframer já viveu esse momento:

“Só aumentei a COMMAREA… de 2K pra 32K.”

Minutos depois:

  • ASRA misterioso

  • Storage estourando

  • Performance caindo

  • E alguém sussurra:
    👉 “Por que não usaram CHANNEL?”

Hoje vamos resolver essa treta histórica: COMMAREA vs CHANNEL/CONTAINER, com números, boas práticas, cicatrizes e filosofia Bellacosa.


🏛️ História: do bloco único ao container moderno

COMMAREA

  • Nasceu nos primórdios do CICS

  • Simples, direta, rápida

  • Pensada para pequenos volumes de dados

  • Era “o suficiente” nos anos 70/80

CHANNEL/CONTAINER

  • Introduzido no CICS TS 3.x

  • Resposta à complexidade crescente

  • Feito para dados grandes, estruturados e flexíveis

  • Arquitetura mais próxima de “mensageria moderna”

📌 Não é moda. É evolução arquitetural.


🧠 Conceito essencial (guarde isso)

COMMAREA = um bloco fixo de memória
CHANNEL/CONTAINER = coleção flexível de blocos independentes

Isso muda tudo.


📦 COMMAREA – o clássico confiável (e perigoso)

O que é?

Um único bloco contínuo de memória, passado entre programas via LINK/XCTL.

📏 Tamanho máximo

  • Até 32.767 bytes (~32 KB)

Sim. Esse é o limite duro.
Passou disso? Nem adianta insistir.


👍 Pontos fortes

✔ Simples
✔ Rápido
✔ Fácil de debugar
✔ Ideal para estruturas pequenas

👎 Limitações

❌ Tamanho limitado
❌ Forte acoplamento entre programas
❌ Layout rígido
❌ Difícil evoluir sem impacto


❌ Erros comuns com COMMAREA (easter eggs)

🐣 COMMAREA gigante “só por garantia”
🐣 Layout diferente entre programas
🐣 Reutilizar COMMAREA sem limpar
🐣 Usar COMMAREA como “dump de dados”

📌 COMMAREA não é mala de viagem.


📦 CHANNEL/CONTAINER – o adulto da sala

O que é?

Um CHANNEL é um agrupador lógico.
Um CONTAINER é um bloco individual de dados dentro do channel.

📦 Channel
└── Container A
└── Container B
└── Container C

Cada um com:

  • Tamanho próprio

  • Tipo próprio

  • Vida própria


📏 Tamanho máximo

  • Praticamente ilimitado (dependente de storage)

  • Containers podem ter megabytes

  • Muito além do limite da COMMAREA

📌 Aqui o gargalo deixa de ser o CICS e passa a ser o bom senso.


👍 Pontos fortes

✔ Estrutura flexível
✔ Baixo acoplamento
✔ Ideal para dados grandes
✔ Melhor para evolução de sistemas
✔ Integra bem com Web Services e MQ

👎 Cuidados

❌ Mais verboso
❌ Exige disciplina
❌ Overkill para casos simples


🥊 COMMAREA vs CHANNEL/CONTAINER

CritérioCOMMAREACHANNEL/CONTAINER
Tamanho máx~32 KBMuito grande
EstruturaFixaFlexível
EvoluçãoDifícilFácil
PerformanceExcelenteMuito boa
AcoplamentoAltoBaixo
ModernidadeClássicoAtual

📌 Não existe melhor. Existe mais adequado.


🛠️ Passo a passo: como escolher

1️⃣ Dados pequenos e estáveis? → COMMAREA
2️⃣ Muitos campos opcionais? → CHANNEL
3️⃣ Dados grandes (XML, JSON)? → CHANNEL
4️⃣ Sistema legado crítico? → COMMAREA (com cuidado)
5️⃣ Integração moderna? → CHANNEL/CONTAINER


⚡ Boas práticas Bellacosa

✅ COMMAREA

  • Use o menor tamanho possível

  • Documente o layout

  • Inicialize sempre

  • Evite “COMMAREA universal”

✅ CHANNEL/CONTAINER

  • Um container = um conceito

  • Nomeie containers claramente

  • Evite “container Frankenstein”

  • Libere quando não precisar

📌 Arquitetura também é educação.


🧪 Exemplo mental de otimização

Antes (COMMAREA)

  • Estrutura única de 30 KB

  • Metade dos campos nunca usados

  • Cada mudança quebra alguém

Depois (CHANNEL)

  • Container CLIENTE

  • Container PRODUTO

  • Container CONTROLE

  • Cada programa lê só o que precisa

🔥 Resultado:

  • Menos impacto

  • Mais clareza

  • Menos bug fantasma


📚 Guia de estudo recomendado

Para dominar o tema:

  • CICS Program Control

  • Storage Management

  • COMMAREA lifecycle

  • CHANNEL/CONTAINER APIs

  • Performance tuning em CICS

📖 Manual essencial: CICS Application Programming Guide


🤓 Curiosidades de boteco mainframe

🍺 CHANNEL foi criado porque COMMAREA virou “caixa de Pandora”
🍺 Há sistemas que simulam JSON dentro de COMMAREA (não faça isso)
🍺 Web Services no CICS usam CHANNEL por baixo dos panos
🍺 Muitos ainda usam COMMAREA por medo, não por necessidade


💬 Comentário El Jefe Midnight Lunch

“COMMAREA resolve rápido.
CHANNEL resolve certo.
O mainframe não perdoa preguiça arquitetural.”


🚀 Aplicações reais hoje

  • Core bancário moderno

  • APIs CICS

  • Integração com MQ

  • Processamento XML/JSON

  • Sistemas híbridos (CICS + Cloud)


🎯 Conclusão Bellacosa

COMMAREA não morreu.
CHANNEL não é bala de prata.

O mainframer experiente:

  • Sabe quando usar cada um

  • Respeita limites

  • Pensa no futuro

🔥 Arquitetura boa não dá abend. Dá orgulho.

domingo, 18 de fevereiro de 2007

O que é CICS?

 

Bellacosa Mainframe e o que é CICS

O que é CICS?

CICS significa:

Customer Information Control System

É o principal monitor transacional do ambiente Mainframe IBM Z e um dos softwares mais importantes da história da computação corporativa.

Criado pela IBM em 1968, o CICS é responsável por executar milhões de transações online em bancos, seguradoras, governos, companhias aéreas e grandes empresas.


Definição Simples

O CICS é:

um gerenciador de transações online.

Ele permite que milhares de usuários acessem simultaneamente aplicações COBOL, PL/I, C e Java executadas no Mainframe.


Analogia Simples

Imagine um restaurante.

  • O cliente faz o pedido.

  • O garçom recebe.

  • A cozinha prepara.

  • O prato é entregue.

No Mainframe:

Usuário
   ↓
CICS
   ↓
Programa COBOL
   ↓
DB2 / VSAM
   ↓
Resposta

O CICS é o "garçom" que coordena tudo.


Por que o CICS existe?

Sem o CICS, cada usuário precisaria executar diretamente um programa no sistema operacional.

Isso consumiria muitos recursos.

O CICS resolve esse problema:

✅ Compartilhando recursos

✅ Controlando usuários

✅ Gerenciando transações

✅ Controlando memória

✅ Gerenciando comunicação


Onde o CICS é usado?

Praticamente em:

  • Bancos

  • PIX

  • TED

  • Cartões de crédito

  • Internet Banking

  • Seguradoras

  • Governo

  • Telecomunicações

  • Companhias aéreas


Arquitetura Simplificada

Terminal
    ↓
CICS
    ↓
Programa COBOL
    ↓
DB2
    ↓
Resposta

Exemplo Real

Cliente consulta saldo:

ATM
 ↓
CICS
 ↓
COBOL
 ↓
DB2
 ↓
Saldo exibido

Tudo acontece em poucos milissegundos.


O que é uma Transação CICS?

É uma operação identificada por um código de 4 caracteres.


Exemplos

CUST
SALD
PIX1
PAGT

Fluxo

Usuário digita:

SALD

O CICS:

Localiza programa
       ↓
Executa COBOL
       ↓
Retorna resultado

Programas CICS

Normalmente escritos em:

  • COBOL

  • PL/I

  • C

  • Java


Exemplo COBOL CICS

Recebendo dados:

EXEC CICS RECEIVE
     MAP('TELA1')
END-EXEC.

Enviando dados

EXEC CICS SEND
     MAP('TELA2')
END-EXEC.

O que é uma MAP?

Tela utilizada pelo usuário.


Exemplo

+----------------------+
| CONSULTA CLIENTE     |
| CONTA: ________      |
| SALDO: ________      |
+----------------------+

BMS

Basic Mapping Support.

Ferramenta usada para criar telas CICS.


COMMAREA

Área usada para passar dados entre programas.


Exemplo

Programa A:

EXEC CICS LINK
     PROGRAM('PROG2')
     COMMAREA(WS-AREA)
END-EXEC.

Programa B

Recebe os dados pela COMMAREA.


Principais Comandos CICS

LINK

Chama outro programa.

EXEC CICS LINK
END-EXEC

XCTL

Transfere controle sem retorno.

EXEC CICS XCTL
END-EXEC

RETURN

Finaliza transação.

EXEC CICS RETURN
END-EXEC

SEND

Envia tela.

EXEC CICS SEND
END-EXEC

RECEIVE

Recebe dados.

EXEC CICS RECEIVE
END-EXEC

CICS e DB2

Integração extremamente comum.


Exemplo

EXEC SQL

   SELECT SALDO
   INTO :WS-SALDO

   FROM CLIENTES

END-EXEC.

CICS e VSAM

Também muito utilizado.


Exemplo

READ ARQCLI

CICS e Segurança

Normalmente integrado ao:

  • RACF

  • ACF2

  • Top Secret


Regiões CICS

O CICS executa dentro de uma região.


Exemplos

CICSA
CICSPRD
CICSTST

O que é uma Região?

Ambiente onde as transações executam.


Monitoramento

Comandos comuns:

CEMT
CEDA
CEDF
CECI

CEMT

Monitor operacional.


Exemplo

CEMT I TASK

Mostra tarefas ativas.


CEDA

Administração de recursos.


CEDF

Debug interativo.


CECI

Executa comandos CICS manualmente.


Erros Comuns (ABENDs CICS)

AICA

Timeout.


AEI0

Programa não encontrado.


AEIV

Erro COMMAREA.


ASRA

Exceção de programa.

Equivalente a:

S0C7
S0C4

Conceito de Transação

Uma transação deve obedecer:

ACID


Atomicidade

Tudo ou nada.


Consistência

Dados válidos.


Isolamento

Transações independentes.


Durabilidade

Dados persistem após COMMIT.


Curiosidades

1. O CICS existe desde 1968

2. Processa bilhões de transações diariamente

3. É considerado o maior monitor transacional do mundo

4. Grande parte dos sistemas bancários utiliza CICS

5. Muitas transações PIX passam por aplicações COBOL/CICS


Resumo Rápido

ConceitoFunção
CICSMonitor transacional
TransaçãoOperação online
MAPTela usuário
BMSCriação de telas
COMMAREAPassagem de dados
LINKChama programa
XCTLTransfere controle
SENDEnvia tela
RECEIVERecebe dados
CEMTAdministração
CEDADefinição recursos
CEDFDebug
CECITestes

Conclusão

O CICS (Customer Information Control System) é o principal monitor de processamento online do Mainframe IBM Z. Ele gerencia transações, usuários, programas COBOL, acesso a DB2 e VSAM, permitindo que milhões de operações críticas sejam executadas com segurança, desempenho e alta disponibilidade em tempo real.