Translate

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

segunda-feira, 2 de novembro de 2020

CICS Conversacional e Pseudo-Conversacional - Parte III

 

Bellacosa Mainframe e a conversação em cics parte III

☕ Um Café no Bellacosa Mainframe

CICS Conversacional e Pseudo-Conversacional

Parte 3 — Channels, Containers, BMS Avançado, APIs, Observabilidade e o Futuro do CICS

"Salve novamente, jovem Padawan Mainframe! Já entendemos por que a pseudo-conversação venceu, como a COMMAREA funciona e como o CICS se integrou ao mundo REST. Agora vamos explorar o lado mais moderno do CICS, descobrir como ele conversa com aplicações em nuvem, conhecer boas práticas utilizadas em bancos e seguradoras e entender por que muitos engenheiros consideram o CICS uma das obras-primas da engenharia de software."

Pegue seu terceiro café, deixe o CEDF ligado, abra uma aba do OMEGAMON, outra do SDSF e vamos continuar.


O problema da COMMAREA

Durante décadas a COMMAREA foi suficiente.

64 KB.

Poucos campos.

Poucos estados.

Poucos dados.

Era perfeito.

Mas o mundo mudou.

Hoje temos:

JSON

JWT

XML

SOAP

REST

Objetos complexos

Payloads gigantes


A chegada dos Channels

A IBM precisava resolver isso.

E resolveu.

CICS TS 3.1

Introduziu:

Channels

Containers


O que é um Channel?

Pense em um diretório.

CLIENTE
│
├── CPF
├── ENDERECO
├── LIMITE
├── HISTORICO
└── TOKEN

O Channel funciona exatamente assim.

Um agrupador.

Pode conter vários Containers.


O que é um Container?

Container é um objeto.

Armazena informações.

Pode conter:

Texto

XML

JSON

Estruturas COBOL

Blobs

Imagens

Arquivos


Comparativo

TecnologiaCapacidade
COMMAREA64 KB
TSQMB
ContainerGB
DB2TB

Exemplo COBOL

Criando.


EXEC CICS PUT CONTAINER

CONTAINER('CLIENTE')

CHANNEL('CADASTRO')

FROM(WS-DADOS)

FLENGTH(WS-TAM)

END-EXEC.



Recuperando.


EXEC CICS GET CONTAINER

CONTAINER('CLIENTE')

CHANNEL('CADASTRO')

INTO(WS-DADOS)

END-EXEC.



BMS continua vivo?

Muito.

Talvez mais vivo do que muita gente imagina.


Grandes bancos.

Seguradoras.

Cartões.

Previdência.

Companhias aéreas.

Utilities.

Governo.


BMS avançado

Poucos desenvolvedores usam.


SEND MAP ACCUM

Acumula telas.

Exemplo


EXEC CICS SEND MAP

ACCUM

END-EXEC



SEND PAGE

Paginação.


SEND CONTROL

Controle terminal.


ERASEAUP

Limpa apenas campos editáveis.


CURSOR

Posicionamento dinâmico.


Exemplo

Cursor no CPF.



MOVE -1 TO CPFL



EXEC CICS SEND

MAP('TELA1')

CURSOR

END-EXEC




APIs no CICS

Aqui muita gente se surpreende.

O CICS é praticamente um Application Server.


Suporta.

HTTP

HTTPS

SOAP

REST

MQ

TCP/IP

JMS

JSON

XML


Exemplo moderno

Aplicativo Android.

API Gateway

z/OS Connect

CICS

COBOL

DB2


z/OS Connect

Talvez uma das melhores ideias da IBM.

Transforma.

COBOL

em

API REST.


Sem reescrever.

Sem Java.

Sem Node.

Sem Python.


Exemplo.

Cliente faz:

GET /clientes/123

Internamente.

CICS chama.


PERFORM CONSULTA-DB2


Retorna.

{

"id":123,

"nome":"Bellacosa"

}


Web Open Interface

WOI.

Pouco conhecido.

Muito poderoso.

Permite integração.

HTTP.

TCP.

Sockets.


Event Processing

Outro recurso fantástico.

CICS captura eventos.

Exemplo.

Cliente alterou endereço.


Evento.

Publica MQ.


Outro sistema consome.


Observabilidade

Década de 80.

Console.

Dump.

IPCS.


Hoje.

OpenTelemetry.

Prometheus.

Grafana.

OMEGAMON.

Instana.

Elastic.


Métricas interessantes

Task Time.

CPU.

Response.

DB2.

MQ.

VSAM.


O CICS morreu?

Pergunta clássica.

Resposta curta.

Não.


Resposta longa.

Muito pelo contrário.


Ele evoluiu.

Muito.


Anos 70

3270

Anos 80

BMS

Anos 90

MQ

2000

SOAP

2010

REST

2020

Containers

2025

OpenTelemetry

IA

APIs

Cloud híbrida


Problemas comuns

COMMAREA gigante

Erro clássico.


Não usar pseudo

Aplicação lenta.


Múltiplos SEND

Desnecessário.


Não verificar RESP

Perigoso.


MDT ligado em tudo

Tráfego excessivo.


Dicas Bellacosa Mainframe

Utilize sempre

DATAONLY.


Sempre valide

RESP.


Use CEDF


Use CECI


Use Channels

Projetos novos.


Mantenha COMMAREA pequena


Nomeie MAPSET adequadamente

Exemplo.


CLI001


CLI002


CLI003



Easter Eggs Mainframe

Programadores antigos adoravam esconder mensagens.

Exemplo.



* MAY THE COBOL BE WITH YOU




Outro clássico.



* IF IT WORKS



* DON'T TOUCH




Mais um.



* WRITTEN 1987



* STILL RUNNING




Curiosidade

Diversos sistemas escritos em 1986.

Rodam hoje.

No z16.

No z17.

Praticamente sem alterações.

Trocaram.

CPU.

Storage.

Rede.

Interface.

Mas o COBOL.

Continua.

O CICS.

Continua.

O DB2.

Continua.

E milhões de transações continuam acontecendo diariamente.


Considerações finais

Aprender CICS conversacional e pseudo-conversacional é muito mais do que aprender comandos.

É entender como a IBM resolveu problemas de escalabilidade décadas antes da popularização da computação em nuvem.

É descobrir que conceitos como:

Stateless

Session Management

API Gateway

Observabilidade

Microserviços

Persistência de contexto

Já estavam presentes, de certa forma, em arquiteturas concebidas nos anos 70.

Talvez seja por isso que o CICS continue sendo uma das tecnologias mais fascinantes do IBM Z.

Porque ele não apenas sobreviveu ao tempo.

Ele evoluiu com ele.

E provavelmente continuará executando aplicações críticas quando muitos frameworks modernos já forem apenas uma nota de rodapé na história da computação.

No IBM Z, cada transação conta uma história. Cada COMMAREA guarda uma memória. E cada RETURN é apenas uma promessa de que a próxima task continuará exatamente de onde paramos.

Até o próximo café no Bellacosa Mainframe.


sexta-feira, 4 de setembro de 2020

CICS Conversacional e Pseudo-Conversacional - Parte II

 

Bellacosa Mainframe e a conversação em cics parte II

☕ Um Café no Bellacosa Mainframe

CICS Conversacional e Pseudo-Conversacional

Parte 2 — Escalabilidade, COMMAREA, Channels, Web Services e Boas Práticas

"Na primeira parte aprendemos que programas conversacionais gostam de ficar esperando o usuário pensar, enquanto programas pseudo-conversacionais executam como ninjas do IBM Z: aparecem, trabalham, desaparecem e retornam apenas quando necessários. Agora vamos entender por que a IBM praticamente transformou a pseudo-conversação em padrão de mercado."

Pegue mais um café, abra o CEDF, deixe o CEMT pronto e vamos continuar nossa jornada.


Os problemas do modelo Conversacional

O modelo conversacional é elegante.

É simples.

É intuitivo.

Mas infelizmente é extremamente caro.

Vamos imaginar um banco.

Cenário

50.000 usuários.

Cada usuário demora:

20 segundos

para preencher uma tela.


Aplicação Conversacional

Programa fica ativo.

Task permanece viva.

TCB permanece associado.

TCA permanece ocupada.

Storage continua reservado.

EIB continua residente.

Tudo isso...

Durante vinte segundos.


Resultado

Pouca escalabilidade.

Maior uso de CPU.

Maior consumo de memória.

Possibilidade de gargalos.


O fenômeno Think Time

Um dos maiores inimigos do CICS.

Think Time.

Tempo em que o usuário está apenas pensando.

Exemplos:

Lendo uma tela.

Pegando um documento.

Atendendo telefone.

Procurando CPF.

Conversando com cliente.


Conversacional

Think Time = recursos desperdiçados


Pseudo

Think Time = recursos liberados


A IBM fez uma escolha inteligente

Ao invés de esperar.

Finaliza a task.

Salva contexto.

Cria nova task depois.


Visualmente:

Task 1

Mostra tela

RETURN


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


Usuário pensa


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


Task 2


Recebe dados


Processa


RETURN

Múltiplas telas

Poucos desenvolvedores COBOL iniciantes percebem.

Uma pseudo-conversação pode navegar por dezenas de telas.

Exemplo:

Menu

Consulta

Inclusão

Alteração

Confirmação

Resumo

Help

Paginação


Exemplo

MENU

PF5

CONSULTA

ENTER

DETALHE

PF3

MENU


Tudo utilizando.

COMMAREA.


COMMAREA

Provavelmente um dos conceitos mais importantes do CICS.

Ela guarda estado.

Entre uma task.

E outra.


Exemplo:


01 WS-COMM.

   05 WS-MODO PIC X.

   05 WS-PAGINA PIC 99.

   05 WS-CPF PIC 9(11).

   05 WS-NOME PIC X(30).


Limitação

COMMAREA possui limite.

64 KB.


Antigamente

Era suficiente.


Hoje.

JSON.

REST.

SOAP.

XML.

JWT.

Podem ultrapassar facilmente.

64 KB.


Surge Channels e Containers

Introduzidos para resolver isso.


COMMAREA

64 KB


Container

Gigabytes.


Exemplo


EXEC CICS PUT CONTAINER

CONTAINER('CLIENTE')

FROM(WS-DADOS)

END-EXEC



Recuperando.


EXEC CICS GET CONTAINER

CONTAINER('CLIENTE')

INTO(WS-DADOS)

END-EXEC



Qual utilizar?

Sistemas antigos

COMMAREA


Novos projetos

Channels

Containers


EIBCALEN

Nos projetos antigos.

Era rei.




IF EIBCALEN = ZERO


PERFORM PRIMEIRA-VEZ


ELSE


PERFORM RETORNO


END-IF



Pseudo-Conversação com BMS

Fluxo típico.


SEND MAP

RETURN

Usuário ENTER

Nova Task

RECEIVE

DB2

SEND

RETURN


Web Services no CICS

Muitos acreditam.

Que CICS é apenas 3270.

Isso está muito longe da realidade.


CICS suporta.

SOAP.

REST.

JSON.

XML.

MQ.

JMS.

TCP/IP.

HTTP.

HTTPS.


Exemplo

Angular

API

zOS Connect

CICS

COBOL

DB2


Visualmente



Browser


   │


REST API


   │


zOS Connect


   │


CICS


   │


COBOL


   │


DB2



O COBOL muda?

Quase nada.


Exemplo


PERFORM VALIDA


PERFORM CONSULTA-DB2


PERFORM RETORNA-DADOS




Interface muda.

Negócio permanece.


SOAP

Muito usado.

Seguradoras.

Governo.

ERP.


REST

Dominante.

OpenAPI.

Swagger.

JSON.


BMS ainda é importante?

Sim.

Muito.


Milhares de aplicações.

Continuam em produção.


Além disso.

BMS ensina.

Arquitetura.

Separação de responsabilidades.

Persistência de contexto.

Gerenciamento de estado.


Problemas comuns

MAPFAIL

Usuário apertou PF3.

Sem alterar dados.


INVREQ

Sequência incorreta.


LENGERR

Área pequena.


ASRA

S0C7.

S0C4.

S0CB.


Como debugar?

CEDF.

Excelente.



CEDF ON



Programa para.

Comando por comando.


CECI

Muito útil.


Exemplo


CECI RECEIVE MAP



CEMT

Consultar recursos.



CEMT I TASK




CEMT I PROG




CEMT I TRAN



Boas práticas

Sempre usar pseudo-conversação


Utilizar COMMAREA pequena


Preferir Containers

Projetos novos.


Não salvar tabelas grandes

Na COMMAREA.


Usar MDT apenas quando necessário


Utilizar DATAONLY

Reduz tráfego.


Evitar múltiplos SEND

Na mesma task.


Validar EIBRESP

Sempre.


Exemplo



IF EIBRESP NOT = DFHRESP(NORMAL)

PERFORM TRATA-ERRO


END-IF



Curiosidade Bellacosa Mainframe

Alguns bancos possuem aplicações pseudo-conversacionais escritas em 1986.

Elas foram migradas.

De 3090.

Para 9672.

Para z900.

Para z990.

Para z9.

Para z10.

Para z14.

Para z16.

E continuam praticamente inalteradas.


Easter Egg Mainframe

Nos anos 80.

Muitos desenvolvedores colocavam comentários curiosos.

Exemplo.



* MAY THE COBOL BE WITH YOU


Ou.



* DO NOT TOUCH


* WORKS SINCE 1987


Ou o clássico.



* IF YOU CHANGE THIS


* BUY COFFEE FOR THE TEAM



Continua...

Na Parte 3 veremos:

✔ Web Open Interface (WOI);

✔ CICS Event Processing;

✔ Programas COBOL completos;

✔ Pseudo-conversação com múltiplos MAPSETs;

✔ BMS avançado;

✔ Channels versus TSQ;

✔ Segurança RACF;

✔ Web Services SOAP e REST detalhados;

✔ Observabilidade moderna;

✔ OpenTelemetry;

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

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, 19 de agosto de 2018

IBM Mainframe Discovery : Capítulo VIII — A Metrópole das Transações Infinitas

 

Bellacosa Mainframe apresenta o ibm mainframe parte viii

☕ Um Café no Bellacosa Mainframe

Capítulo VIII — A Metrópole das Transações Infinitas

CICS: A Cidade que Nunca Dorme e Atende Milhões de Viajantes ao Mesmo Tempo 


QUINTA REGRA DAS GRANDES CIVILIZAÇÕES

Nunca construa uma cidade onde exista apenas um caixa.

Porque cedo ou tarde...

...todos chegarão ao mesmo tempo.

Imagine uma cidade espacial.

Ela possui:

  • cinquenta milhões de habitantes;

  • milhares de hotéis;

  • bancos;

  • hospitais;

  • aeroportos;

  • restaurantes;

  • museus;

  • lojas;

  • centros de pesquisa.

Agora imagine que todos resolvem fazer alguma operação exatamente às nove horas da manhã.

Consultar saldo.

Comprar passagem.

Reservar hotel.

Pagar contas.

Transferir dinheiro.

Comprar ações.

Se existir apenas um atendente...

a cidade para.

Foi exatamente esse problema que a IBM resolveu em 1968.

O nome da solução?

Customer Information Control System.

Ou simplesmente...

CICS.


O Maior Balcão de Atendimento da Galáxia

Esqueça computadores.

Imagine o maior centro de atendimento já construído.

Não existem:

10 caixas.

Nem 100.

Nem mil.

Existem milhares de atendimentos acontecendo simultaneamente.

Cada cliente acredita estar sendo atendido sozinho.

Mas, nos bastidores...

todos compartilham praticamente a mesma infraestrutura.

Essa é a verdadeira magia do CICS.


Antes do CICS

Voltemos algumas décadas.

Imagine um banco.

Cada cliente entra.

O gerente pega um enorme livro.

Calcula tudo manualmente.

Entrega o resultado.

Agora multiplique isso por:

dez milhões de clientes.

Não funciona.

Foi então que surgiu uma pergunta revolucionária.

"E se centenas de milhares de pessoas utilizassem o mesmo computador ao mesmo tempo?"

Hoje parece óbvio.

Na década de 1960 parecia ficção científica.


A Cidade Nunca Fecha

Uma característica curiosa do Batch é que ele gosta de trabalhar sozinho.

Executa.

Termina.

Vai embora.

O CICS pensa diferente.

Ele nunca fecha as portas.

Nunca.

Enquanto existir alguém querendo realizar uma transação...

ele permanece acordado.

É uma cidade que nunca dorme.


A Recepcionista Galáctica

Imagine entrar num gigantesco hotel.

A recepcionista pergunta:

— Bom dia.

Qual o seu quarto?

Você responde.

Ela consulta o sistema.

Entrega a chave.

Tudo acontece em segundos.

O CICS faz exatamente isso.

Recebe pedidos.

Encaminha ao programa correto.

Entrega a resposta.

Tudo em frações de segundo.

Segundo Wilhelm G. Spruth, o CICS foi projetado para oferecer processamento transacional extremamente eficiente, permitindo que um único sistema atendesse simultaneamente milhares de usuários interativos.


Uma Cidade Dentro da Nave

Imagine agora que a USS Enterprise abriga uma cidade inteira.

Existem:

padarias.

correios.

escolas.

restaurantes.

hospitais.

Todos funcionando ao mesmo tempo.

Mas existe apenas uma prefeitura.

Essa prefeitura é o CICS.

Ela coordena tudo.


O Grande Equívoco do Padawan

Todo iniciante imagina:

Um usuário.

Um programa.

Uma CPU.

Fim.

Na prática...

isso seria absurdamente ineficiente.

No CICS acontece algo completamente diferente.

Milhares de usuários compartilham poucos recursos.

É como um gigantesco sistema de transporte público.


As Transações São Passageiros

Imagine uma estação espacial.

Milhares de pessoas entram.

Cada uma deseja chegar a um destino diferente.

Algumas vão ao banco.

Outras ao hospital.

Outras ao museu.

No CICS...

cada passageiro representa uma:

Transação.

Ela possui:

nome.

origem.

destino.

prioridade.

tempo de vida.

Quando termina...

desaparece.


O Programa Não Mora na Memória

Esta talvez seja uma das maiores surpresas.

Um programa COBOL no CICS normalmente não permanece executando eternamente.

Ele é chamado.

Executa rapidamente.

Entrega o resultado.

Libera recursos.

Vai embora.

É quase como um elevador.

Chega.

Recebe passageiros.

Sobe.

Desce.

Fica disponível novamente.


O Concierge da Cidade

Imagine um concierge extremamente eficiente.

Ele conhece todos os departamentos.

Ao receber um pedido...

encaminha imediatamente ao profissional correto.

O CICS faz exatamente isso.

Ele recebe uma transação e encontra rapidamente o programa responsável por executá-la.


COMMAREA — A Mochila do Viajante

Agora imagine um turista.

Ele caminha pela cidade carregando apenas uma pequena mochila.

Ali estão:

passaporte.

mapa.

dinheiro.

documentos.

Quando entra em outro prédio...

leva sua mochila consigo.

Essa mochila chama-se:

COMMAREA.

Ela transporta as informações entre programas CICS.

Durante décadas foi o principal mecanismo para troca de dados entre aplicações.


CHANNEL e CONTAINER — Os Contêineres Espaciais

Com o tempo...

os turistas começaram a transportar muito mais bagagem.

A pequena mochila ficou insuficiente.

Então surgiram:

CHANNELS

e

CONTAINERS.

Imagine enormes contêineres de carga.

Agora qualquer quantidade de informação pode viajar entre programas de forma muito mais organizada.

É a evolução natural da COMMAREA.


O Mapa da Cidade

Como um cliente encontra seu destino?

Através do:

BMS

(Basic Mapping Support).

Imagine um mapa eletrônico.

Cada tela corresponde a um prédio.

Cada campo representa uma sala.

Cada tecla possui um significado.

O BMS transforma a conversa entre terminal e programa em algo organizado e previsível.


O Tradutor Universal

Os terminais 3270 falam um idioma próprio.

O COBOL fala outro.

O usuário fala outro.

O BMS funciona como um tradutor universal.

Ele converte telas em dados.

Dados em telas.

Tudo automaticamente.


Pseudo-Conversação: O Segredo da Ilusão

Chegamos a um dos conceitos mais brilhantes do Mainframe.

Imagine um garçom.

Você faz um pedido.

Ele anota.

Vai embora.

Atende outras mesas.

Quando sua comida fica pronta...

ele retorna exatamente para você.

Parece que ficou o tempo inteiro ao seu lado.

Mas não ficou.

O CICS faz exatamente isso.

Esse modelo chama-se:

Pseudo-Conversação.

Após enviar uma tela ao usuário, a tarefa termina e libera recursos.

Quando o cliente responde, uma nova execução começa utilizando o estado previamente armazenado.

Segundo Spruth, esse modelo foi um dos fatores responsáveis pela enorme escalabilidade do CICS.


O Milagre da Multiplicação

Imagine possuir apenas dez garçons.

Mesmo assim...

atender cinco mil clientes.

Parece impossível.

Não no CICS.

Como cada tarefa permanece ativa apenas durante poucos milissegundos...

os mesmos recursos atendem milhares de pessoas.


TSQ e TDQ — Os Armários da Estação

Imagine que um viajante precise guardar sua bagagem.

Existem duas opções.

Um armário temporário.

Ou uma caixa de despacho.

No CICS encontramos exatamente isso.

TSQ

Temporary Storage Queue.

Permite gravar informações temporárias que podem ser lidas diversas vezes.

TDQ

Transient Data Queue.

Mais parecida com uma esteira de bagagens.

Os dados seguem adiante.

Normalmente são consumidos apenas uma vez.


O Relógio da Cidade

Imagine um turista parado diante do caixa por meia hora.

Todos atrás dele ficam esperando.

No CICS isso seria um desastre.

Por isso existe controle rigoroso de tempo.

Cada transação deve ser:

curta.

rápida.

objetiva.

Quanto menor sua duração...

mais usuários podem ser atendidos.


O Cofre da Cidade

Imagine agora que duas pessoas tentam retirar o mesmo dinheiro da mesma conta exatamente no mesmo instante.

Quem ganha?

Nenhum dos dois.

Primeiro o sistema organiza.

Depois libera.

O CICS trabalha em conjunto com o gerenciador de recuperação para garantir integridade das transações.

Esse compromisso com consistência é um dos pilares das aplicações críticas executadas sobre a plataforma.


A Cidade Conversa com Todo Mundo

O CICS nunca viveu isolado.

Ele conversa com:

Db2.

IMS.

MQ.

VSAM.

Web Services.

REST APIs.

Java.

Node.js.

Python.

Linux.

Hoje ele continua evoluindo.

Mas sua essência permanece.

Processar transações.

Rapidamente.

Com segurança.

Sem interrupções.


CICS e o COBOL

Existe uma pergunta que todo Padawan faz.

"Quem chama quem?"

Na verdade...

o COBOL trabalha como um excelente especialista.

O CICS organiza.

Recebe o cliente.

Controla recursos.

Gerencia transações.

Depois entrega o trabalho ao programa COBOL.

Quando tudo termina...

o COBOL devolve o controle.

É quase uma dança cuidadosamente ensaiada.


O Que Mudou Desde 2010?

Desde a publicação do relatório de Spruth, o universo CICS evoluiu enormemente.

Hoje encontramos:

  • APIs REST nativas.

  • JSON.

  • XML.

  • Web Services.

  • JVM Server.

  • OSGi.

  • Liberty Profile.

  • Node.js.

  • Integração com OpenShift.

  • z/OS Connect.

  • Microsserviços.

  • Observabilidade moderna.

Mesmo assim...

um programa COBOL escrito há décadas ainda pode continuar trabalhando ao lado dessas tecnologias.

Essa talvez seja a maior demonstração da elegância da arquitetura IBM Z.


Uma Curiosa Filosofia

Existe uma frase que resume o espírito do CICS.

Nunca mantenha recursos ocupados enquanto alguém está pensando.

Enquanto o usuário decide qual opção escolher...

o programa já terminou.

A memória foi liberada.

A CPU voltou para outro cliente.

É uma filosofia simples.

Mas revolucionária.


Curiosidades do Diário de Bordo

🚀 O CICS processa bilhões de transações diariamente em instituições financeiras, governos, seguradoras e empresas de transporte ao redor do mundo.

🌌 A pseudo-conversação foi uma das ideias mais elegantes da engenharia de software corporativo, permitindo enorme escalabilidade com consumo mínimo de recursos.

📺 O BMS separa a lógica de apresentação da lógica de negócio, conceito que muitos frameworks web modernos adotariam décadas depois.

📦 COMMAREA, TSQ e TDQ tornaram-se componentes clássicos do desenvolvimento CICS e continuam fazendo parte do vocabulário de praticamente todo programador COBOL online.


Diário de Bordo do Padawan COBOL

Antes de deixar a metrópole das transações, registre estas coordenadas no seu Holocron Técnico:

✅ O CICS não é apenas um monitor transacional; ele é um verdadeiro sistema operacional para aplicações online.

✅ A pseudo-conversação é um dos principais segredos da escalabilidade do CICS, liberando recursos enquanto o usuário interage.

✅ O COBOL executa a lógica de negócio, enquanto o CICS coordena usuários, transações, recursos e recuperação.

✅ Grandes cidades não funcionam porque possuem ruas largas; funcionam porque possuem organização. O CICS aplica exatamente essa filosofia ao processamento de milhões de transações.


Missão Seguinte

No próximo capítulo, embarcaremos rumo ao PR/SM, às LPARs e ao universo da virtualização.

Descobriremos que o IBM Z já dividia um único computador em dezenas de máquinas independentes quando boa parte da indústria ainda acreditava que "virtualização" era apenas um conceito acadêmico. Veremos como uma única nave pode abrigar várias civilizações tecnológicas trabalhando lado a lado, sem interferirem umas nas outras — uma verdadeira federação galáctica dentro de um único computador.

☕ Um Café no Bellacosa Mainframe

O Guia Galáctico do IBM Z

Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.

Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.
01

Capítulo I — Não Entre em Pânico!

Leia no visor ou abra a publicação original.

Abrir artigo
02

Capítulo II — A Planta da Nave Mais Duradoura da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
03

Capítulo III — A Nave Que Se Recusa a Explodir

Leia no visor ou abra a publicação original.

Abrir artigo
04

Capítulo IV — A Sala dos Cofres Cósmicos

Leia no visor ou abra a publicação original.

Abrir artigo
05

Capítulo V — A Frota Invisível do Transporte Interestelar

Leia no visor ou abra a publicação original.

Abrir artigo
06

Capítulo VI — O Grande Maestro Invisível

Leia no visor ou abra a publicação original.

Abrir artigo
07

Capítulo VII — O Grande Terminal de Embarque da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
08

Capítulo VIII — A Metrópole das Transações Infinitas

Leia no visor ou abra a publicação original.

Abrir artigo
09

Capítulo IX — A Federação das Naves Invisíveis

Leia no visor ou abra a publicação original.

Abrir artigo
10

Capítulo X — A Consciência Coletiva da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
11

Capítulo XI — O Almirante Invisível da Frota

Leia no visor ou abra a publicação original.

Abrir artigo
12

Capítulo XII — A Biblioteca Infinita da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
13

Capítulo XIII — O Serviço Postal Mais Confiável da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
14

Capítulo XIV — O Jardim Secreto da Nave

Leia no visor ou abra a publicação original.

Abrir artigo
15

Capítulo XV — O Tradutor Universal da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
16

Capítulo XVI — A Fábrica Automática da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
17

Capítulo XVII — A Última Fronteira Nunca Foi o Espaço

Leia no visor ou abra a publicação original.

Abrir artigo
18

Capítulo XVIII — O Guia Nunca Terminou

Leia no visor ou abra a publicação original.

Abrir artigo
19

Conclusão — Não Entre em Pânico... A Jornada Está Apenas Começando

Leia no visor ou abra a publicação original.

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