☕ 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 xctl. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta xctl. Mostrar todas as mensagens

quinta-feira, 3 de dezembro de 2020

CICS Conversacional e Pseudo-Conversacional - Parte IV

 

Bellacosa Mainframe e a conversação em CICS Parte IV

☕ Um Café no Bellacosa Mainframe

CICS Conversacional e Pseudo-Conversacional

Parte 4 — COMMAREA, TSQ, TDQ, Temporary Storage, Control Blocks e os Bastidores do CICS

"Salve novamente, jovem Padawan Mainframe! Se você chegou até aqui, parabéns. Você já compreendeu como a pseudo-conversação revolucionou a escalabilidade do CICS, descobriu Channels, Containers, APIs REST e até OpenTelemetry. Mas agora vamos abrir a tampa do motor do CICS. Vamos conhecer o que acontece por trás das cortinas."

Pegue mais um café.

Abra o IPCS.

Deixe o CEDF ligado.

Reserve uma aba do SDSF.

Porque agora vamos entrar na sala das máquinas.


O que realmente acontece dentro do CICS?

Quando executamos:

EXEC CICS SEND MAP
END-EXEC

Muita gente imagina algo parecido com:

Programa

Tela

Fim.

Mas o CICS faz muito mais.


Fluxo interno

Programa COBOL

        │

        ▼

Translator

        │

        ▼

EXEC Interface

        │

        ▼

Kernel CICS

        │

        ▼

Terminal Control

        │

        ▼

BMS

        │

        ▼

TIOA

        │

        ▼

3270

TIOA

Talvez uma das estruturas menos conhecidas pelos iniciantes.

TIOA

Terminal Input Output Area

É uma área onde ficam armazenados.

Dados digitados.

Cursor.

Atributos.

AID Keys.


Exemplo

ENTER

PF3

PF5

CPF

Nome

Cursor linha 7

Cursor coluna 15

Tudo isso.

Na TIOA.


TCA

Task Control Area.

Cada task possui.


Guarda.

Status.

Transação.

Programa.

Recursos.

Flags.


EIB

Você já conhece.

Mas agora sabemos.

Ele é derivado.

Da TCA.


Control Blocks interessantes

TCT

Terminal Control Table


PPT

Program Processing Table


FCT

File Control Table


PCT

Program Control Table


SIT

System Initialization Table


Temporary Storage Queue

TSQ

Muito usada.

Em pseudo-conversação.


Imagine.

1000 registros.

Não cabem.

Na COMMAREA.


Salvamos em TSQ.


EXEC CICS WRITEQ TS

QUEUE('CLI0001')

FROM(WS-DADOS)

END-EXEC



Lendo.



EXEC CICS READQ TS

QUEUE('CLI0001')

INTO(WS-DADOS)

END-EXEC



TDQ

Transient Data Queue

Muito utilizada.

Para logs.

Integração.

Mensageria.


TSQ versus TDQ

CaracterísticaTSQTDQ
Leitura múltiplaSimNão
AtualizaçãoSimNão
SequencialNãoSim
PersistênciaOpcionalSim
Uso típicoEstadoLogs

COMMAREA versus TSQ

COMMAREA

64 KB

TSQ

Megabytes


Exemplo bancário

Tela.

Lista.

5000 clientes.

Salvar TSQ.

Usuário PF8.

Recupera TSQ.

Próxima página.


Paginando consultas

PF7

Anterior

PF8

Próxima




IF EIBAID = DFHPF8

PERFORM PAGINA-SEGUINTE


END-IF



Boas práticas

Nunca coloque.

Tabela enorme.

Na COMMAREA.


Use.

TSQ.

Ou.

Containers.


LINK

Outro comando muito importante.

Chamando programa.




EXEC CICS LINK

PROGRAM('CLI0002')

COMMAREA(WS-COMM)

END-EXEC



Retorna.

Para chamador.


XCTL

Diferente.

Não retorna.



EXEC CICS XCTL

PROGRAM('MENU0001')

END-EXEC



Programa anterior.

Morre.

Novo.

Assume controle.


START

Assíncrono.

Agenda execução.




EXEC CICS START

TRANSID('CLI1')

END-EXEC



DELAY

Muito curioso.



EXEC CICS DELAY

FOR SECONDS(5)

END-EXEC



Raramente utilizado.


CEMT

Melhor amigo.

Administrador.


Consultar tasks.


CEMT I TASK



Consultar programas.



CEMT I PROGRAM



Consultar files.



CEMT I FILE



Consultar TSQ.



CEMT I TSQUEUE



CEDF

Ferramenta maravilhosa.


Permite.

Passo a passo.

SEND.

RECEIVE.

LINK.

READ.

WRITE.

DB2.




CEDF ON



CECI

Testador.

Interativo.



CECI READ FILE




CECI RECEIVE MAP



Curiosidades Bellacosa Mainframe

Existem sistemas.

Que utilizam.

TSQ.

Desde 1988.

Ainda funcionando.

No z16.

No z17.

Sem alterações.


Easter Egg Mainframe

Muitos programadores escondiam.

Comentários.

Como.



* THIS PROGRAM IS OLDER THAN YOU


Ou.



* IF IT BREAKS


* RUN AWAY



Ou.



* WRITTEN DURING NIGHT SHIFT


* POWERED BY COFFEE



O que veremos na Parte 5

✔ Program Control;

✔ HANDLE CONDITION;

✔ HANDLE ABEND;

✔ RESP e RESP2;

✔ Syncpoint;

✔ Journaling;

✔ Recoverable Resources;

✔ Mirror Transactions;

✔ DPL;

✔ IPIC;

✔ CICSplex;

✔ CPSM;

✔ Threadsafety;

✔ Open TCBs;

✔ OTE;

✔ E muitos outros segredos do universo CICS.


No Bellacosa Mainframe aprendemos uma regra simples: se você acredita que já conhece o CICS, provavelmente apenas encontrou a próxima porta do labirinto. Porque no IBM Z sempre existe mais um control block para estudar, mais um dump para analisar e mais um café esperando para ser servido.

 

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

terça-feira, 4 de junho de 2019

☕💥 A Jornada do Padawan COBOL – Parte 6 Desvendando o Universo dos CALLs no Mainframe

 

Bellacosa Mainframe apresenta o CALL em Cobol Parte VI

☕💥 A Jornada do Padawan COBOL – Parte 6

Desvendando o Universo dos CALLs no Mainframe

CICS LINK, XCTL, COMMAREA, Channels, Containers, APIs REST, MQ, Java e os Segredos dos Arquitetos da Nova República IBM Z

Ou como descobrir que um programa COBOL escrito em 1987 pode responder uma API REST em menos tempo do que muita startup consegue carregar um framework

Por Vagner Bellacosa – Bellacosa Mainframe


O dia em que o Padawan descobre que CALL não é a única forma de chamar programas

Até agora aprendemos:

✅ CALL estático

✅ CALL dinâmico

✅ Binder

✅ RENT

✅ CEEDUMP

✅ LPA

✅ LE

Mas um dia o Padawan entra em um ambiente CICS.

Abre um programa.

E encontra isto:

EXEC CICS LINK
     PROGRAM('PGM0001')
     COMMAREA(WS-COMM)
END-EXEC

E pensa:

Ué...

Cadê o CALL?


O universo paralelo do CICS

Em Batch usamos:

CALL 'VALIDA'

No CICS temos:

LINK

XCTL

START

RETURN

LOAD

DELETE


LINK

É praticamente o CALL do CICS.

Exemplo

EXEC CICS LINK
     PROGRAM('CPFVAL')
     COMMAREA(WS-COMMAREA)
END-EXEC

Visualmente


CLIENTE01


↓

LINK


↓

CPFVAL


↓

RETORNA


↓

CLIENTE01



Programa chamador continua vivo.

Igual ao CALL.


Vantagens

Retorna controle

Compartilha contexto

Excelente modularização

Pode executar milhares de vezes


XCTL

Agora a coisa muda.


Exemplo

EXEC CICS XCTL
     PROGRAM('MENU0001')
END-EXEC

Visualmente


TELA01

↓

XCTL

↓

MENU0001



TELA01 morre




Não retorna.

Nunca.


É quase um:

exit();

Quando usar?

Troca definitiva.

Menu.

Workflow.

Navegação.


LINK versus XCTL

CaracterísticaLINKXCTL
RetornaSimNão
Consome stackSimNão
PerformanceBoaExcelente
WorkflowMédioIdeal

COMMAREA

A rainha do CICS.


Ela transporta dados.


Exemplo

01 WS-COMM.

05 WS-CPF PIC X(11).

05 WS-NOME PIC X(30).

05 WS-RC PIC 99.

LINK

EXEC CICS LINK
PROGRAM('CPFVAL')
COMMAREA(WS-COMM)
LENGTH(100)
END-EXEC

Subprograma

DFHCOMMAREA.

O limite

64 KB


Padawan feliz.

Arquiteto preocupado.


Channels e Containers

IBM resolveu.


Nasce o conceito:

CHANNEL

CONTAINER


Praticamente JSON.

Mas IBM.


Exemplo

EXEC CICS PUT CONTAINER
CONTAINER('CLIENTE')
CHANNEL('CANAL1')
FROM(WS-CLIENTE)
END-EXEC

Ler

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

Vantagens

Gigabytes.

Múltiplos objetos.

Flexível.


MQ

Padawan evolui.

Conhece IBM MQ.


Exemplo

CALL 'MQPUT'

Visualmente



COBOL

↓

MQPUT


↓

QUEUE


↓

JAVA


↓

API




Assíncrono.

Bonito.

Elegante.

IBM aprova.


APIs REST

O grande sonho.


"Posso expor COBOL como API?"

Sim.


Muito.


zOS Connect

O mago moderno.


Ele converte

REST

em

COBOL


Visualmente



POST /cliente



↓

zOS Connect



↓

COBOL



↓

DB2



↓

JSON




Cliente pensa:

Microserviço.


Realidade:

COBOL 1989.


Exemplo

API

{
"id":123
}

COBOL

01 WS-ID PIC 9(9).

Java

Sim.

Java conversa.


JNI.

LE.

DLL.


Exemplo

CobolService.executar();

COBOL

CALL 'PROCESSA'

Python

Sim.

Também.


API REST.

MQ.

Kafka.


Tudo possível.


Metal C

Território avançado.


Muito usado.

IBM Z.

Baixa latência.


zIIP

Arquiteto sorri.

Financeiro também.


Pode descarregar CPU.


Exemplo

JSON parsing.

REST.

MQ.

DB2 DRDA.


SMF 110

O espião do CICS.


Captura:

Tempo

CPU

LINK

XCTL

DB2

MQ


APA

Application Performance Analyzer


Mostra:

Hotspots

CALLs

Loops

CPU


Strobe

Ferramenta lendária.


Veteranos adoram.


Exemplo real

Programa

1000 LINKs

Tempo

5 segundos

Após otimização

400 ms


Truques Bellacosa

Dica 1

LINK

Retorna.


Dica 2

XCTL

Não retorna.


Dica 3

Channels > COMMAREA

Projetos novos.


Dica 4

MQ desacopla.


Dica 5

REST não mata COBOL.

REST promove COBOL.


Easter Egg Mainframe

Muitos bancos possuem.

Programa.

APIGEN01

Dentro.

EXEC CICS LINK

PROGRAM('LEG1987')

END-EXEC

API moderna.

Swagger.

OAuth.

OpenAPI.

JWT.

Kubernetes.

No final...

Executa.

MOVE SALDO TO WS-SALDO

Escrito em 1987.

Funciona.

Processa bilhões.

Ninguém reclama.


Checklist Jedi da Integração

✅ Preferir LINK

✅ XCTL para troca definitiva

✅ Evitar COMMAREA grande

✅ Usar Channels

✅ Monitorar SMF110

✅ Medir CPU

✅ Utilizar MQ

✅ Explorar zOS Connect

✅ Aproveitar zIIP

✅ Testar latência

✅ Documentar APIs


A Filosofia Jedi do CALL – Parte 6

O Padawan iniciante acredita:

COBOL só conversa com COBOL.

O desenvolvedor intermediário pensa:

COBOL pode consumir APIs.

O Arquiteto IBM Z entende:

COBOL conversa com qualquer tecnologia capaz de trocar bytes, mensagens, estruturas, JSON, XML ou eventos.

E é exatamente por isso que alguns dos sistemas mais modernos do planeta possuem uma arquitetura semelhante a esta:

Mobile

↓

API Gateway

↓

REST

↓

zOS Connect

↓

CICS LINK

↓

COBOL

↓

DB2

↓

MQ

↓

Analytics

↓

IA

Enquanto o cliente enxerga apenas um botão escrito "Consultar Saldo", um pequeno exército de programas COBOL, escritos ao longo de quarenta anos, continua executando silenciosamente milhões de chamadas por segundo, provando mais uma vez que, no Mainframe, a Força nunca esteve na moda da tecnologia, mas na sua capacidade de durar décadas sem perder desempenho, segurança e confiabilidade.


Próxima aventura do Padawan COBOL – Parte 7

Assembler, BALR, BASSM, PC-Bit, SVC, LE Internals, SRBs, TCBs, Cross Memory Services, zIIP, HiperDispatch e os segredos obscuros dos Sysprogs Jedi do IBM Z.


domingo, 13 de janeiro de 2019

O Mistério das Três Portas do CICS : Quando um Jovem Programador COBOL Descobriu que uma Escolha Entre LINK, XCTL e START Poderia Decidir o Destino de Milhões de Transações

 

Bellacosa Mainframe e o misterio das 3 portas do cics

☕ Um Café no Bellacosa Mainframe

O Mistério das Três Portas do CICS

Quando um Jovem Programador COBOL Descobriu que uma Escolha Entre LINK, XCTL e START Poderia Decidir o Destino de Milhões de Transações

"Naquela noite, o relógio marcava 02h17 da madrugada. O CPD estava silencioso. Apenas o som dos discos girando quebrava o silêncio. Um jovem programador COBOL observava um abend misterioso enquanto um velho analista, conhecido apenas como Bellacosa, aproximava-se lentamente com uma xícara de café fumegante. Sem dizer uma palavra, desenhou três portas em um bloco de papel. Sobre elas escreveu apenas três nomes: LINK. XCTL. START. 'Todo programador chega a este corredor um dia', disse ele. 'O problema é que muitos escolhem a porta errada...'."


O Caso das Três Portas

Se existe um tema que separa um programador COBOL iniciante de um desenvolvedor CICS experiente, é o entendimento do Program Control.

À primeira vista, LINK, XCTL e START parecem comandos semelhantes. Todos executam outro programa. Todos transferem controle. Todos podem utilizar COMMAREA.

Mas essa semelhança é apenas superficial.

Na prática, eles representam três formas completamente diferentes de pensar uma aplicação transacional.

É como três detetives investigando o mesmo crime usando métodos distintos.

Um faz perguntas e volta com respostas.

Outro assume a investigação inteira.

O terceiro abre um novo caso enquanto continua trabalhando no atual.

Entender essa diferença é compreender uma das peças centrais da arquitetura do CICS.

E essa história começa muito antes da primeira linha de COBOL.


O CICS Nunca Perde o Controle

O primeiro erro dos iniciantes é imaginar que um programa COBOL "chama" outro programa.

Na realidade...

Quem chama é o CICS.

Seu programa apenas faz um pedido.

Imagine um grande hotel cinco estrelas.

O hóspede não entra na cozinha.

Ele não abre a porta da lavanderia.

Ele não liga diretamente para o gerente.

Tudo passa pela recepção.

O CICS funciona exatamente assim.

Quando escrevemos:

EXEC CICS LINK PROGRAM('VALIDA')
END-EXEC.

não estamos dizendo ao computador:

Execute o programa VALIDA.

Estamos dizendo ao CICS:

"Por favor, transfira o controle para VALIDA seguindo todas as regras da arquitetura."

Isso muda completamente nossa forma de pensar.

O CICS controla:

  • Memória

  • Tasks

  • Locks

  • Arquivos

  • Transações

  • Recursos

  • Segurança

  • Recuperação

Nada acontece sem sua autorização.


O Verdadeiro Significado de "Program Control"

Program Control não significa apenas mudar de programa.

Significa administrar a vida inteira da transação.

Quem continua?

Quem termina?

Quem espera?

Quem retorna?

Quem libera memória?

Quem inicia outra task?

Essas perguntas são respondidas justamente por LINK, XCTL e START.


PRIMEIRA PORTA

LINK

Na velha revista noir, Bellacosa desenha um telefone.

"LINK", diz ele.

"É como ligar para um especialista."

Você faz uma pergunta.

Ele responde.

Você continua seu trabalho.

Nada mais.


Fluxo Mental

Programa A

↓

LINK

↓

Programa B

↓

RETURN

↓

Programa A continua

Perceba que o Programa A nunca desaparece.

Ele apenas espera.


Uma Analogia Policial

Sherlock Holmes precisa descobrir se uma assinatura é falsa.

Ele chama um perito grafotécnico.

O perito faz seu trabalho.

Entrega o laudo.

Sherlock continua a investigação.

Ele não entrega o caso ao perito.

Foi apenas uma consulta.

Esse é exatamente o espírito do LINK.


Por que LINK existe?

Porque duplicar código é um crime.

Imagine um banco.

Existem milhares de programas.

Todos precisam validar CPF.

Todos precisam validar agência.

Todos precisam calcular tarifas.

Sem LINK seria algo parecido com isto:

Programa A

1000 linhas de validação

Programa B

1000 linhas iguais

Programa C

Mais 1000 linhas iguais

Resultado?

Uma manutenção impossível.

Então surgiu a ideia da modularização.

Criar um programa especializado.

Todos fazem LINK.

Todos reutilizam.


Curiosidade Histórica

Os primeiros sistemas bancários gigantes da década de 80 começaram a reduzir drasticamente o tamanho dos programas graças ao uso intensivo de LINK.

Alguns módulos chegaram a ser reutilizados por mais de 5.000 programas diferentes.

Imagine alterar uma regra tributária.

Em vez de recompilar cinco mil programas...

Recompila-se apenas um módulo.

Essa economia representa milhares de horas de trabalho.


O Stack Invisível

Existe um detalhe fascinante.

Quando fazemos LINK o CICS monta uma pilha.

Programa A

↓

Programa B

↓

Programa C

↓

Programa D

Cada programa sabe exatamente quem o chamou.

Quando termina...

Volta para quem estava esperando.

É praticamente uma pilha de execução semelhante ao que linguagens modernas como Java e C# fazem internamente.

Só que isso já existia décadas antes.


EASTER EGG Nº 1 ☕

Os programadores antigos brincavam dizendo:

"LINK é o telefone do CICS."

Você liga.

Conversa.

Desliga.

Continua a vida.


SEGUNDA PORTA

XCTL

Agora Bellacosa desenha uma flecha enorme.

Sem retorno.

"Quando atravessar essa porta..."

"...não olhe para trás."


XCTL significa substituição.

Fluxo:

Programa A

↓

XCTL

↓

Programa B

Fim.

Programa A acabou.

Nunca mais será executado.


Analogia Cinematográfica

Imagine uma corrida de revezamento.

LINK

é como emprestar uma calculadora.

Ela volta.

XCTL

é entregar o bastão.

Sua corrida terminou.

Outro atleta continua.


Quando usar?

Sempre que o programa atual terminou definitivamente.

Exemplo clássico:

LOGIN

↓

MENU

O login acabou.

Nunca mais será usado.

Então:

LOGIN

↓

XCTL MENU

Muito mais eficiente.


Economia de Recursos

Pouca gente comenta isso.

Mas XCTL ajuda o CICS a economizar memória.

Como não existe retorno...

O contexto anterior pode ser descartado.

Em um ambiente com milhares de usuários simultâneos...

Essa pequena economia torna-se gigantesca.


Uma Cidade Invisível

Imagine uma cidade.

Cada prédio representa um programa.

LINK

é visitar um prédio e voltar para casa.

XCTL

é vender sua casa.

Mudar-se definitivamente.

Nunca mais retornar.


EASTER EGG Nº 2 ☕

Existe uma frase famosa entre veteranos:

"Quem usa XCTL esperando voltar está esperando um trem que nunca passa."


TERCEIRA PORTA

START

Agora Bellacosa sorri.

"Esta porta..."

"...não leva ao próximo cômodo."

"Ela cria outro prédio."


Essa talvez seja a maior confusão dos iniciantes.

START

não chama programa.

START cria outra transação.

Parece a mesma coisa.

Mas está muito longe disso.


A Grande Diferença

LINK

continua na mesma task.

XCTL

continua na mesma task.

START

cria outra task.

Outro contexto.

Outra vida.

Outra execução.


Fluxo

Transação A

↓

START

↓

Nova Transação

Não existe espera.

Não existe retorno.

Cada uma segue seu caminho.


Imagine um Restaurante

Você pede um café.

Enquanto toma o café...

Pede também uma sobremesa para levar.

O garçom registra outro pedido.

Você continua tomando café.

Não espera a sobremesa ficar pronta.

Isso é START.


Um Banco de Verdade

Cliente faz PIX.

O sistema precisa:

✔ atualizar saldo

✔ gravar auditoria

✔ enviar SMS

✔ enviar e-mail

✔ atualizar Data Warehouse

✔ gerar estatísticas

O cliente deveria esperar tudo isso?

Claro que não.

Então:

START SMS
START EMAIL
START AUDITORIA

Enquanto isso...

A tela já responde:

Transferência concluída.


START pode ser Agendado

Poucos iniciantes sabem.

START pode acontecer:

Agora.

Daqui cinco segundos.

Daqui cinco minutos.

Daqui uma hora.

Em horário específico.

Isso permite automações extremamente sofisticadas.


Curiosidade

Muitos sistemas de cobrança utilizam START para criar processos futuros.

Por exemplo:

Hoje:

Cliente fez uma compra.

Daqui sete dias:

Enviar pesquisa de satisfação.

Tudo agendado pelo próprio CICS.


COMMAREA

A Mala de Viagem

Imagine uma mala.

Dentro dela estão documentos.

Valores.

Informações.

Essa mala é a COMMAREA.

LINK entrega a mala.

Recebe de volta.

XCTL entrega a mala.

Vai embora.

START entrega uma cópia da mala para outra viagem.

É exatamente isso.


Mas Existe Algo Melhor...

Nos sistemas modernos existem CHANNELS e CONTAINERS.

Eles resolvem várias limitações da COMMAREA:

✔ maior capacidade

✔ múltiplos objetos

✔ melhor organização

✔ integração com aplicações modernas

Em entrevistas técnicas isso costuma aparecer bastante.


O Erro Mais Comum

Iniciante:

"Vou usar START porque é mais rápido."

Veterano:

"Não."

START não acelera nada.

Ele apenas desacopla o processamento.

São conceitos completamente diferentes.


Outro Erro Clássico

Usar LINK para tudo.

Imagine:

Transferência

↓

LINK SMS

↓

LINK EMAIL

↓

LINK RELATÓRIO

↓

LINK LOG

Resultado?

O cliente espera tudo terminar.

Resposta lenta.

Sistema congestionado.


Outro Crime Arquitetural

Usar START para validação.

START VALIDA CPF

Enquanto isso...

A transferência continua.

Percebe o problema?

O dinheiro pode ser transferido antes da validação terminar.

Catástrofe.


Comparação Completa

CaracterísticaLINKXCTLSTART
Retorna ao programa chamadorSimNãoNão
Mesma TaskSimSimNão
Nova TransaçãoNãoNãoSim
Processamento AssíncronoNãoNãoSim
Ideal para reutilizaçãoSimNãoNão
Ideal para navegaçãoNãoSimNão
Ideal para backgroundNãoNãoSim

O Fluxo de um Banco Moderno

Imagine toda uma sessão bancária.

LOGIN

↓

XCTL MENU

O login desaparece.

Depois:

MENU

↓

LINK VALIDA CONTA

↓

LINK VALIDA LIMITE

↓

LINK CALCULA TARIFA

Cada módulo retorna.

Transferência concluída.

Agora:

START SMS

START EMAIL

START RELATÓRIO

START AUDITORIA

Enquanto isso:

Cliente já está iniciando outra operação.

Tudo funcionando simultaneamente.

É arquitetura.

Não mágica.


O Que Acontece Internamente?

Quando um comando é executado, o CICS atualiza diversas estruturas internas:

  • Task Control Area (TCA): controla a execução da tarefa atual.

  • Program Control Table (PCT) e Program Processing Table (PPT): ajudam a localizar e preparar programas para execução.

  • Storage Manager: administra a memória utilizada pelos programas e COMMAREAs.

  • Dispatcher: decide quando cada task pode usar a CPU.

No caso do LINK, o CICS preserva o contexto do chamador e empilha a chamada. No XCTL, substitui o programa ativo sem manter uma pilha de retorno. No START, cria uma nova entrada de task, que poderá ser despachada conforme a disponibilidade do sistema e as prioridades definidas pelo Workload Manager (WLM).

Essa infraestrutura invisível é uma das razões pelas quais um único CICS consegue atender milhares de usuários simultaneamente.


Dicas de Ouro para Iniciantes

✅ Pense primeiro no fluxo de negócio, depois escolha o comando.

✅ Pergunte sempre: "Preciso voltar para este programa?"

  • Sim → LINK.

  • Não → XCTL.

✅ Pergunte também: "Esse processamento pode acontecer depois?"

  • Sim → START.

✅ Evite criar programas monolíticos. Um bom sistema CICS é formado por módulos pequenos, especializados e reutilizáveis.

✅ Documente claramente quando um programa espera retorno e quando transfere definitivamente o controle. Isso facilita manutenção e reduz erros.


Curiosidades que Pouca Gente Conhece

  • Alguns ambientes bancários possuem módulos de validação chamados por dezenas de milhões de LINKs por dia.

  • Em aplicações críticas, uma única transação pode executar dezenas de comandos LINK antes de terminar.

  • Muitos sistemas legados utilizam cadeias de XCTL para implementar menus completos em aplicações 3270.

  • START é frequentemente usado para disparar integrações com filas, auditorias, notificações e processamento em segundo plano, reduzindo o tempo de resposta percebido pelo usuário.


O Conselho Final de Bellacosa

Bellacosa terminou o café, fechou o bloco de anotações e apontou novamente para as três portas.

— "O segredo nunca foi decorar a sintaxe."

O jovem programador olhou confuso.

— "Então qual é o segredo?"

O velho sorriu.

— "Entender o destino da transação."

Ele desenhou três frases finais:

LINK conversa.

XCTL substitui.

START cria um novo caminho.

Depois apagou as luzes do CPD.

Enquanto caminhavam pelo corredor iluminado apenas pelos painéis azuis do mainframe, Bellacosa deixou a última pista:

"Os grandes sistemas do mundo não permanecem funcionando há décadas porque usam comandos complicados. Permanecem funcionando porque seus arquitetos sempre souberam escolher a porta certa antes de atravessá-la."

Naquela madrugada, o jovem programador percebeu que o verdadeiro mistério nunca esteve nos comandos do CICS.

O verdadeiro mistério sempre foi compreender que cada transação conta uma história, e que LINK, XCTL e START são apenas maneiras diferentes de decidir como essa história continuará. Afinal, no universo do mainframe, uma escolha aparentemente simples pode determinar se milhões de transações seguirão seu caminho com segurança... ou se um novo caso será aberto para o próximo detetive do CPD investigar.

sábado, 24 de setembro de 2011

🔥 Program Control Operation – XCTL no CICS

 


🔥 Program Control Operation – XCTL no CICS



☕ Midnight Lunch, fluxo quebrado e um XCTL mal compreendido

São 13h02.
A transação entra, processa metade da lógica… e nunca mais volta.
O analista jura:

“Mas eu só fiz um XCTL…”

Pois é. XCTL não volta mesmo.
Hoje vamos falar dessa operação poderosa, perigosa e frequentemente mal usada: o EXEC CICS XCTL.


🏛️ História: controle total desde os primórdios

Desde os primeiros releases do CICS, havia a necessidade de:

  • Trocar completamente o fluxo de execução

  • Manter a mesma transação

  • Evitar empilhamento excessivo de programas

Assim nasceu o XCTL (Transfer Control).

📌 XCTL é o “goto elegante” do CICS — se usado com juízo.


🧠 Conceito essencial (grave isso)

XCTL = transfere o controle para outro programa e NÃO retorna

✔ Mesma task
✔ Mesma transação
✔ Mesma UOW
❌ Sem retorno ao programa chamador

Quando você usa XCTL, o programa atual morre com dignidade.


🔀 O que é o XCTL no CICS?

O EXEC CICS XCTL:

  • Encerra o programa corrente

  • Passa o controle para outro programa

  • Opcionalmente passa uma COMMAREA ou CHANNEL

  • Continua a execução no novo programa


🧾 Sintaxe básica

EXEC CICS XCTL PROGRAM('PGM002') COMMAREA(WS-COMMAREA) LENGTH(LEN) END-EXEC.

📌 Parece LINK, mas o comportamento é radicalmente diferente.


🥊 XCTL vs LINK (clássico eterno)

CritérioXCTLLINK
RetornoNãoSim
StackNão empilhaEmpilha
UsoTroca de fluxoSub-rotina
RiscoFluxo perdidoStack overflow

📌 Se precisa voltar, nunca use XCTL.


🧠 Quando usar XCTL (casos corretos)

✔ Navegação de telas (pseudo-conversacional)
✔ Separação clara de etapas
✔ Fluxo linear (estado → próximo estado)
✔ Evitar profundidade excessiva de LINK

📌 XCTL é ótimo para “passar o bastão”.


⚠️ Quando NÃO usar XCTL (easter eggs)

🐣 Para chamar regra de negócio
🐣 Quando precisa retornar status
🐣 Em loops lógicos
🐣 Em fluxo condicional mal definido

📌 XCTL errado vira bug invisível.


🛠️ Passo a passo mental antes do XCTL

1️⃣ Preciso voltar para este programa?
→ Se sim, não é XCTL

2️⃣ O estado está completo na COMMAREA ou CHANNEL?

3️⃣ O próximo programa sabe exatamente o que fazer?

4️⃣ Existe risco de fluxo perdido?

5️⃣ Estou tentando “simplificar” algo que é LINK?

Se tiver dúvida, pare.


📦 XCTL com COMMAREA vs CHANNEL

COMMAREA

  • Simples

  • Limitada a ~32 KB

  • Forte acoplamento

CHANNEL

  • Flexível

  • Ideal para navegação moderna

  • Menos impacto em mudanças

📌 XCTL + CHANNEL é o padrão moderno.


🧪 Exemplo mental de fluxo

Fluxo pseudo-conversacional clássico

1️⃣ Programa A recebe tela
2️⃣ Valida dados
3️⃣ XCTL para Programa B

Programa A não existe mais.
Programa B continua como se fosse o primeiro.

🔥 Simples. Elegante. Perigoso se mal desenhado.


📚 Guia de estudo para dominar XCTL

Estude profundamente:

  • Program Control no CICS

  • Pseudo-conversational design

  • COMMAREA vs CHANNEL

  • Transaction scope

  • Recovery e rollback

📖 Manual essencial: CICS Application Programming Guide


🤓 Curiosidades de boteco mainframe

🍺 XCTL evita stack overflow que LINK pode causar
🍺 Muitos sistemas antigos abusam de XCTL como “goto”
🍺 Navegação de telas em CICS nasceu com XCTL
🍺 Um XCTL mal colocado pode “sumir” com lógica inteira


💬 Comentário El Jefe Midnight Lunch

“LINK é conversa.
XCTL é despedida.
Se você confunde os dois, o CICS te ensina.”


🚀 Aplicações reais hoje

  • Navegação pseudo-conversacional

  • Sistemas de atendimento

  • Fluxos de validação

  • Aplicações transacionais críticas


🎯 Conclusão Bellacosa

O EXEC CICS XCTL é simples, direto e definitivo.

Quem domina:

  • Desenha fluxos limpos

  • Evita empilhamento desnecessário

  • Cria sistemas previsíveis

🔥 XCTL não é erro. Erro é esperar que ele volte.

Se quiser, no próximo Midnight Lunch:


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