☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

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

sexta-feira, 8 de agosto de 2025

Principais Variáveis EIB no CICS (Execute Interface Block)

 

Bellacosa Mainframe e as principais variaveis EIB no CICS 

Principais Variáveis EIB no CICS (Execute Interface Block)

4,424 followers

Salve jovem padawan, em minhas aulas de CICS, é costume apresentar as variáveis EIB no decorrer do curso, elas auxiliam um programa online, recebendo valores importantes para o processamento das transações, abaixo apresento uma breve definição. Listo as mais usadas, seu significado e valor.

📘 Definição

O EIB (Execute Interface Block) é uma área de memória automática criada pelo CICS em tempo de execução de uma transação. Ela contém informações contextuais e de controle sobre a execução da task CICS — como horário de início, terminal, ID da transação, teclas pressionadas, retorno de comandos, etc.

Ou seja: é o ambiente operacional da transação, disponível para o seu programa COBOL, PL/I, C, etc., automaticamente.

🔍 Quando e como o EIB é usado

Ao executar um programa em CICS, o sistema insere essa estrutura chamada DFHEIBLK no início do programa. Assim, não é necessário declarar explicitamente, apenas referenciar:

Variável

EIBTRNID

ID da transação em execução (ex: M001, INQ1)

EIBTASKN

Número da task do CICS. É único enquanto a task estiver ativa.

EIBDATE

Data de início da task no formato Julian (AAMMDD)

EIBTIME

Hora de início da task (em centésimos de segundo após meia-noite)

EIBCPOSN

Byte offset do erro de comunicação

EIBCALEN

Tamanho da COMMAREA recebida

EIBAID

Tecla de atenção pressionada (como ENTER, PF3, etc.)

EIBRCODE

Código de retorno da última chamada EXEC CICS (usado em tratamento de erro)

EIBRESP

Código de resposta padrão do comando EXEC CICS (usado com RESP)

EIBRESP2

Código de resposta adicional (mais detalhado que EIBRESP)

EIBRSRCE

Recurso responsável por falha em um comando (ex: nome do recurso)

EIBFN

Código da última função CICS executada (interno)

EIBDS

Nome do arquivo (VSAM, TDQ etc.) acessado mais recentemente

EIBREQID

ID de requisição mais recente (ex: para START ou LINK)

EIBRECV

Indica se houve RECEIVE bem-sucedido

EIBSEND

Indica se houve SEND

EIBATT

Tipo de atenção (PA, PF, ENTER, etc.)

EIBCID

Conversation ID em transações de comunicação interativa

EIBRLDAL

Indica se a tarefa foi reiniciada após falha (Backout recovery)

EIBCONF

Status de confirmação de transação (usado em syncpoints)

Espero ter ajudado, até o proximo artigo.


#ibm #mainframe #cobol #cics #eib #code #tips


quarta-feira, 1 de julho de 2020

CICS Conversacional e Pseudo-Conversacional - Parte I

 

Bellacosa Mainframe e as tecnicas de conversação em programas CICS parte I

☕ Um Café no Bellacosa Mainframe

CICS Conversacional e Pseudo-Conversacional

Parte 1 — Das Conversas Eternas ao Modelo que Move o Mundo

"Salve, jovem Padawan Mainframe! Pegue seu café, abra uma sessão do SDSF, deixe o IPCS de prontidão e venha comigo entender uma das maiores sacadas de engenharia já criadas pela IBM. Hoje vamos falar sobre dois conceitos que sustentam boa parte das aplicações bancárias do planeta: CICS Conversacional e Pseudo-Conversacional."


O que é uma aplicação Conversacional?

Imagine que você está conversando com alguém pelo telefone.

Você liga.

A pessoa atende.

A ligação permanece aberta.

Vocês conversam.

Você pensa.

Procura um documento.

Vai tomar café.

Volta.

Continua falando.

Finalmente desliga.

Foi exatamente esta filosofia que inspirou o primeiro modelo de aplicações CICS.

Modelo Conversacional

O programa permanece residente na memória durante toda a interação com o usuário.

Visualmente:

Usuário
   │
EXEC CICS RECEIVE
   │
Programa permanece ativo
   │
Processa
   │
EXEC CICS SEND
   │
Espera usuário
   │
EXEC CICS RECEIVE
   │
Processa
   │
EXEC CICS SEND
   │
...
   │
EXEC CICS RETURN

O programa nunca sai da memória.

A task permanece viva.

A TCA continua alocada.

O TCB continua associado.

A área de trabalho permanece disponível.

Tudo fica esperando.

Inclusive o usuário.


O problema

Vamos imaginar um banco em 1982.

Existem:

5.000 terminais.

3.000 usuários.

2.000 consultas simultâneas.

Cada usuário fica parado.

Lendo a tela.

Pensando.

Conferindo CPF.

Procurando documentos.

Tomando café.

Atendendo telefone.

Conversando.

Enquanto isso...

O programa continua residente.

A task continua viva.

O CICS continua consumindo recursos.

A memória continua ocupada.


O nascimento da pseudo-conversação

Os engenheiros da IBM olharam para isso e disseram:

"Por que manter um programa carregado esperando um ser humano pensar?"

E a resposta foi brilhante.

Não vamos esperar.

Vamos embora.

Quando o usuário voltar...

Criamos outra task.

Recuperamos o estado.

Continuamos.

Nascia a pseudo-conversação.


O que é Pseudo-Conversação?

A pseudo-conversação é um modelo onde o programa não fica esperando.

Ele:

Mostra a tela.

Encerra a task.

Libera recursos.

Quando o usuário aperta ENTER...

Uma nova task é criada.

Tudo continua.

Como se nada tivesse acontecido.


Fluxo


Usuário

   │

Executa CLI1

   │

Programa COBOL

   │

SEND MAP

   │

RETURN TRANSID

COMMAREA

   │

Task termina



=====================


Usuário digita


ENTER


=====================


Nova Task


Recebe COMMAREA


RECEIVE MAP


Processa


SEND MAP


RETURN


É quase uma ilusão.

Parece conversacional.

Mas não é.

Por isso o nome:

Pseudo-Conversacional.


Comparando os dois modelos

CaracterísticaConversacionalPseudo
Task ativaSimNão
Programa residenteSimNão
Consome memóriaAltaBaixa
EscalabilidadeRuimExcelente
Usado atualmenteRaroPadrão
Ideal para milhares usuáriosNãoSim

Por que a IBM venceu?

Porque ela resolveu um problema gigantesco.

Imagine.

100 mil usuários.

Cada um esperando.

Em modelo conversacional.

Seria inviável.

No pseudo.

As tasks duram poucos milissegundos.

O usuário pensa.

Mas o mainframe trabalha em outra coisa.


Analogia moderna

Conversacional:

Você deixa o Uber esperando na porta enquanto toma banho.

Pseudo-conversacional:

Você pede outro Uber quando estiver pronto.

O custo muda completamente.


O segredo: COMMAREA

A memória da aplicação.

Entre uma task e outra.

Exemplo:


01 WS-COMM.

   05 WS-CLIENTE.

      10 WS-CODIGO PIC 9(6).

      10 WS-NOME PIC X(30).

      10 WS-PAGINA PIC 99.

      10 WS-MODO PIC X.



Primeira execução

Como descobrir?

Usando:

EIBCALEN



IF EIBCALEN = ZERO

   PERFORM PRIMEIRA-VEZ

END-IF


Primeira vez.

Sem COMMAREA.


Retorno



IF EIBCALEN > ZERO

   PERFORM RETORNO


END-IF


Existe contexto.

Usuário voltou.


Salvando estado



EXEC CICS RETURN

TRANSID('CLI1')

COMMAREA(WS-COMM)

LENGTH(100)

END-EXEC.


CICS guarda.

Task termina.

Memória liberada.


Criando nova task

Usuário aperta ENTER.

CICS cria:

Nova TCA

Nova Task

Novo TCB

Novo EIB

Mas entrega a COMMAREA.

Tudo continua.

Mágica.

Engenharia.

IBM.


O papel do BMS

Sem BMS.

Pseudo-conversação seria muito mais complicada.

Precisaríamos:

Salvar coordenadas.

Salvar cursor.

Salvar atributos.

Salvar campos.

O BMS faz tudo isso.


SEND MAP

Mostra tela.



EXEC CICS SEND MAP

MAP('TELA1')

MAPSET('CLIMAP')

ERASE

FREEKB

END-EXEC.



RECEIVE MAP

Recebe dados.



EXEC CICS RECEIVE MAP

MAP('TELA1')

MAPSET('CLIMAP')

INTO(TELA1I)

END-EXEC.



Curiosidade Bellacosa Mainframe

Muitos sistemas bancários desenvolvidos em 1985 ainda utilizam exatamente este modelo.

Mudou o hardware.

Mudou o storage.

Mudou a CPU.

Mudou a interface.

Mas a arquitetura continua.

E continua funcionando.

Talvez esta seja uma das maiores demonstrações da elegância da engenharia IBM.


Easter Egg Mainframe

Alguns desenvolvedores chamavam aplicações conversacionais de:

Programas preguiçosos.

Porque passavam a maior parte do tempo...

Esperando o usuário pensar.

Enquanto os programas pseudo-conversacionais eram apelidados de:

Programas ninja.

Aparecem.

Executam.

Desaparecem.

Voltam.

Executam.

Somem novamente.

Tudo em poucos milissegundos.


Continua...

Na Parte 2 veremos:

✔ Problemas clássicos do modelo conversacional;

✔ Deadlocks de recursos;

✔ Pseudo-conversação com múltiplas telas;

✔ COMMAREA versus Channels e Containers;

✔ Web Services no CICS;

✔ REST, SOAP e z/OS Connect;

✔ Exemplos COBOL completos;

✔ Boas práticas;

✔ Troubleshooting;

✔ Curiosidades e easter eggs pouco conhecidos do universo CICS.


quarta-feira, 14 de agosto de 2019

O Envelope Invisível do CICS : Como a COMMAREA Carrega o Destino de Milhões de Transações Sem Que Ninguém a Veja

 

Bellacosa Mainframe e o envelope inivsivel do cics

☕ Um Café no Bellacosa Mainframe

O Envelope Invisível do CICS

Como a COMMAREA Carrega o Destino de Milhões de Transações Sem Que Ninguém a Veja

"Existem objetos que todos os programadores conhecem. Existem objetos que poucos compreendem. E existe a COMMAREA... invisível aos usuários, silenciosa para os operadores, mas absolutamente indispensável para que bancos movimentem bilhões de reais todos os dias."


Prólogo

A Noite em que o Envelope Desapareceu

Chicago.

Outubro de 1958.

A chuva caía sobre o asfalto como se tentasse apagar todos os rastros.

Dentro do Bellacosa Mainframe Café, um velho detetive de sistemas observava um envelope pardo sobre a mesa.

Não havia remetente.

Não havia destinatário.

Apenas uma inscrição feita à máquina:

"Nunca abra antes do LINK."

O jovem programador COBOL olhou intrigado.

— Um envelope vazio?

O velho sorriu.

— Não.

— O envelope mais importante de todo o CICS.

Décadas depois ele receberia outro nome.

COMMAREA.

Naquele instante o rapaz ainda não sabia, mas aquele simples "envelope" era responsável por conectar milhares de programas COBOL espalhados por um dos maiores bancos do planeta.

E o mais curioso...

Nenhum cliente jamais saberia que ele existia.


O Mistério da Comunicação Silenciosa

Imagine um Internet Banking.

Você faz login.

Depois consulta saldo.

Depois paga um boleto.

Depois faz um PIX.

Depois consulta extrato.

Depois encerra a sessão.

Para o usuário parece existir apenas uma aplicação.

Mas dentro do CICS...

A realidade é outra.

Pode haver:

  • LOGIN01

  • MENU0001

  • SALDO10

  • PIX020

  • TED055

  • EXTRAT1

  • LOG0009

  • AUDIT05

Cada um é um programa COBOL independente.

Então surge a pergunta:

Como um programa informa ao próximo quem é o cliente?

A resposta parece simples.

Mas foi uma ideia brilhante para a época.


Antes da COMMAREA

Imagine que ela não existisse.

Programa LOGIN:

SELECT CLIENTE

Programa SALDO

SELECT CLIENTE

Programa PIX

SELECT CLIENTE

Programa TED

SELECT CLIENTE

Programa EXTRATO

SELECT CLIENTE

Cinco consultas.

Cinco acessos ao disco.

Cinco leituras.

Cinco oportunidades para lentidão.

Agora imagine isso acontecendo

dez milhões de vezes por dia.

O custo seria gigantesco.

Foi justamente para eliminar esse desperdício que nasceu uma das maiores ideias da IBM.


Afinal...

O que é COMMAREA?

COMMAREA significa

Communication Area.

É uma área contínua de memória usada pelo CICS para transportar dados entre programas pertencentes à mesma transação.

Ela não grava nada.

Não salva nada.

Não arquiva nada.

Ela simplesmente leva informações de um programa para outro.

Pense nela como:

📨 um envelope lacrado.

O conteúdo muda.

O envelope permanece.


Uma analogia dos anos 1950

Imagine uma delegacia.

O detetive termina um interrogatório.

Dentro de um envelope coloca:

  • nome do suspeito

  • endereço

  • fotografia

  • impressões digitais

  • número do caso

O envelope segue para outro investigador.

O segundo policial não precisa investigar tudo novamente.

Basta abrir o envelope.

É exatamente isso que a COMMAREA faz.

Ela evita trabalho repetido.


A anatomia da COMMAREA

Visualmente poderíamos imaginá-la assim:

+------------------------------------------+
| CUSTOMER-ID                              |
| ACCOUNT                                  |
| BRANCH                                   |
| ACCOUNT-TYPE                             |
| BALANCE                                  |
| LANGUAGE                                 |
| USER PROFILE                             |
| TERMINAL                                 |
| CHANNEL                                  |
| OPERATION                                |
| SECURITY LEVEL                           |
+------------------------------------------+

Tudo armazenado em memória.

Nenhum acesso ao disco.


O ciclo completo

Vamos acompanhar uma transferência bancária.

Cliente abre o aplicativo.

Programa LOGIN.

Valida senha.

Consulta Db2.

Obtém:

Cliente

Conta

Agência

Limite

Perfil

Idioma

Canal

Agora tudo isso é colocado na COMMAREA.

LINK.

Programa MENU.

LINK.

Programa PIX.

LINK.

Programa VALIDADOR.

LINK.

Programa EFETIVAÇÃO.

Observe um detalhe.

Depois do LOGIN...

Nenhum outro programa precisou consultar novamente quem era o cliente.

Tudo já estava viajando dentro da COMMAREA.


A filosofia do Mainframe

Existe uma regra quase sagrada nos grandes sistemas.

Nunca leia duas vezes aquilo que você já possui em memória.

Hoje parece óbvio.

Na década de 1970...

Era uma necessidade.

CPU era cara.

Memória era cara.

Discos eram lentos.

Cada I/O economizado representava dinheiro.

Muito dinheiro.

Por isso COMMAREA tornou-se tão importante.


O que realmente acontece durante um LINK?

Quando escrevemos

EXEC CICS LINK
 PROGRAM('CLIENT02')
 COMMAREA(WS-COMMAREA)
 LENGTH(LENGTH OF WS-COMMAREA)
END-EXEC.

O CICS não está copiando dezenas de registros de banco.

Ele simplesmente informa ao programa chamado:

"Existe uma área de memória neste endereço. Utilize-a."

Na prática acontece algo parecido com isto:

Endereço

7F3A9100

↓

Tamanho

256 bytes

É incrivelmente rápido.

Essa é uma das razões pelas quais CICS consegue responder milhares de transações por segundo.


DFHCOMMAREA

O personagem mais famoso do CICS

Quase todo programador COBOL já viu isso.

LINKAGE SECTION.

01 DFHCOMMAREA.

Mas poucos sabem por quê.

A resposta é elegante.

Essa memória não pertence ao programa.

Ela foi emprestada.

Por isso não fica na WORKING-STORAGE.

Ela chega pela

LINKAGE SECTION.

Depois o PROCEDURE DIVISION recebe essa estrutura.

PROCEDURE DIVISION USING DFHCOMMAREA.

É como receber uma pasta enviada por outro departamento.

Você pode consultá-la.

Mas ela não nasceu dentro do seu escritório.


Um erro clássico de iniciantes

Imagine isto.

Programa A envia

CLIENTE
CONTA
SALDO

Programa B espera

CLIENTE
SALDO
CONTA

O resultado?

Os bytes continuam chegando.

Mas os significados mudam.

O saldo vira conta.

A conta vira saldo.

O CPF vira agência.

É como tentar ler um livro começando pela página cinquenta.

Os dados continuam existindo.

Mas perderam completamente o sentido.


O poder dos COPYBOOKS

É exatamente por isso que quase todas as empresas utilizam COPYBOOK.

Em vez de declarar a estrutura em cada programa...

Todos compartilham a mesma definição.

Assim:

COPY COMMCUST.

Se houver alteração...

Todos continuam falando o mesmo idioma.

É uma prática indispensável em ambientes corporativos.


O guardião chamado EIBCALEN

Existe outro personagem silencioso.

Pouco lembrado.

Mas extremamente importante.

Seu nome é:

EIBCALEN.

Sempre que um programa recebe uma COMMAREA...

O CICS informa quantos bytes chegaram.

Se

EIBCALEN = ZERO

Não veio nenhuma COMMAREA.

Ignorar isso costuma produzir alguns dos ABENDs mais famosos do CICS.

Os veteranos sempre verificam EIBCALEN antes de tocar na DFHCOMMAREA.

É um hábito simples que evita horas de investigação.


LINK e XCTL

Dois irmãos que usam o mesmo envelope

LINK é semelhante a fazer uma ligação telefônica.

Você chama alguém.

Ele resolve um problema.

Depois devolve o controle.

Já XCTL é diferente.

É passar o bastão definitivamente.

Quem chamou desaparece.

Mas a COMMAREA continua viajando normalmente.

Ela acompanha ambos.

Esse é um dos motivos pelos quais COMMAREA aparece em praticamente todos os fluxos de programas CICS.


O limite dos 32 KB

Existe uma curiosidade histórica.

Durante décadas a COMMAREA teve um limite de aproximadamente

32.767 bytes.

Hoje isso parece pequeno.

Mas nos anos 1980...

Era enorme.

Ainda assim...

As aplicações cresceram.

Web Services chegaram.

XML apareceu.

JSON surgiu.

As informações ficaram maiores.

Então a IBM criou uma evolução.

Channels.

Containers.

Hoje ambos convivem.

A COMMAREA permanece extremamente comum em aplicações legadas.

Enquanto projetos modernos frequentemente utilizam Channels & Containers.


COMMAREA não substitui banco de dados

Esse é um erro comum entre iniciantes.

Imagine que você consulte um saldo.

Coloque esse saldo na COMMAREA.

Depois outro usuário faz um depósito.

A COMMAREA não será atualizada magicamente.

Ela contém apenas uma fotografia daquele instante.

Quem guarda a verdade continua sendo:

Db2.

VSAM.

IMS.

A COMMAREA apenas transporta informações.

Ela nunca substitui armazenamento permanente.


Comparando COMMAREA com outros recursos do CICS

RecursoFinalidade
COMMAREAPassar dados entre programas
TSQArmazenamento temporário reutilizável
TDQFila sequencial de processamento
VSAMPersistência de dados
Db2Banco relacional
ChannelsEvolução moderna da COMMAREA

Cada tecnologia possui um propósito específico.

Confundir essas responsabilidades costuma produzir arquiteturas ruins.


Curiosidades que pouca gente conhece

☕ Curiosidade 1

Muitos sistemas bancários executam dezenas de programas COBOL para concluir apenas uma operação simples no caixa eletrônico.

O cliente enxerga uma única tela.

O CICS enxerga uma verdadeira orquestra.


☕ Curiosidade 2

Em grandes bancos existem transações que utilizam a mesma COMMAREA durante dezenas de chamadas LINK consecutivas.

Ela percorre praticamente toda a jornada do cliente.


☕ Curiosidade 3

A maioria dos usuários do planeta jamais ouviu falar da COMMAREA.

Mesmo assim ela participa silenciosamente de pagamentos, compras, saques, financiamentos, seguros e reservas aéreas.


☕ Curiosidade 4

Em muitos projetos antigos, o layout da COMMAREA é tratado como um contrato. Alterar um único campo sem planejamento pode afetar dezenas de programas dependentes.


Passo a passo para o iniciante

Se você está começando em COBOL/CICS, memorize este fluxo:

Passo 1

Receba a requisição do usuário.

Passo 2

Leia Db2 ou VSAM.

Passo 3

Monte a COMMAREA.

Passo 4

Execute LINK ou XCTL.

Passo 5

No programa chamado, valide EIBCALEN.

Passo 6

Leia DFHCOMMAREA.

Passo 7

Continue o processamento sem acessar novamente o banco, quando os dados já estiverem disponíveis.

Esse ciclo aparece diariamente em aplicações corporativas.


Easter Egg Bellacosa ☕

Dizem os veteranos que existe uma frase escrita em algum lugar dos laboratórios onde nasceram muitos sistemas CICS:

"Os discos contam histórias. A memória conta o presente."

A COMMAREA vive exatamente nesse presente.

Ela não conhece ontem.

Não conhece amanhã.

Ela existe apenas enquanto a transação respira.

Quando o RETURN acontece...

Ela desaparece.

Como um detetive que resolve o caso antes do amanhecer e some na neblina sem deixar rastros.


O Caso do Envelope Invisível

No fim daquela noite chuvosa de 1958, o jovem programador finalmente abriu o envelope deixado sobre a mesa do Bellacosa Mainframe Café.

Não havia dinheiro.

Não havia documentos.

Nem mesmo uma folha de papel.

Havia apenas uma pequena anotação datilografada:

"Os melhores mensageiros são aqueles que ninguém percebe que existem."

Décadas depois, milhões de clientes fariam pagamentos, consultariam saldos, comprariam passagens, transfeririam recursos e movimentariam bilhões de reais sem imaginar que, entre um programa COBOL e outro, um discreto envelope invisível continuava viajando em silêncio.

Esse envelope chama-se COMMAREA.

E talvez esse seja o maior segredo do CICS: as tecnologias mais importantes raramente aparecem na tela. Elas trabalham nos bastidores, costurando programas, preservando desempenho e garantindo que cada transação siga seu caminho com rapidez, segurança e elegância.

No universo do mainframe, onde confiabilidade vale mais do que espetáculo, a COMMAREA permanece como um dos exemplos mais brilhantes de engenharia de software: simples na aparência, profunda na concepção e indispensável há mais de meio século. É a prova de que, muitas vezes, os verdadeiros protagonistas são justamente aqueles que ninguém vê.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...