Translate

Mostrar mensagens com a etiqueta treinamento mainframe. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta treinamento mainframe. Mostrar todas as mensagens

sábado, 18 de outubro de 2025

☕💣🚀 LABORATÓRIO BELLACOSA MAINFRAME: DATABASE IMS 15.5 / 15.6 NA PRÁTICA

 

Bellacosa Mainframe úm laboratorio pratico ims database

☕💣🚀 LABORATÓRIO BELLACOSA MAINFRAME

IMS 15.5 / 15.6 NA PRÁTICA

Do Zero Até um Banco Hierárquico Funcionando


Objetivo

Construir um banco IMS completo:

CLIENTE
 |
 +-- CONTA
       |
       +-- MOVIMENTO

Aprendendo:

  • DBDGEN

  • PSBGEN

  • Managed ACB

  • DFS3PU00

  • DFSURGU0

  • DFSURGL0

  • DL/I

  • COBOL IMS

  • GU

  • GN

  • GNP

  • ISRT

  • REPL

  • DLET

  • Catalog IMS


Cenário

Banco:

BANKDB

Segmentos:

CLIENTE
CONTA
MOVIMENTO

EXERCÍCIO 1

Criando o DBD

Objetivo:

Definir a estrutura hierárquica.

Fonte DBD:

BANKDB   DBD NAME=BANKDB,ACCESS=HDAM

         DATASET DD1=AREA001

CLIENTE SEGM NAME=CLIENTE,BYTES=100
         FIELD NAME=(CPF,SEQ,U),BYTES=11,START=1

CONTA    SEGM NAME=CONTA,
               PARENT=CLIENTE,
               BYTES=80

         FIELD NAME=(NUMCONTA,SEQ,U),
               BYTES=10,
               START=1

MOVIM    SEGM NAME=MOVIMENTO,
               PARENT=CONTA,
               BYTES=120

         FIELD NAME=(DATA,SEQ),
               BYTES=8,
               START=1

         DBDGEN
         FINISH
         END

Resultado esperado:

BANKDB DBD gerado sem erros

Solução

Executar DBDGEN.


EXERCÍCIO 2

Executando DBDGEN

JCL:

//DBDGEN JOB
//ASM EXEC PGM=ASMA90
//SYSPRINT DD SYSOUT=*
//SYSIN DD DSN=IMS.SOURCE(BANKDB),DISP=SHR

Validar:

RC=0000

Solução

Verificar:

DBDLIB

contendo:

BANKDB

EXERCÍCIO 3

Criando o PSB

Criar acesso para COBOL.

BANKPSB  PSBGEN LANG=COBOL

PCB TYPE=DB,
    DBDNAME=BANKDB,
    PROCOPT=A

END

Solução

Executar:

PSBGEN

Resultado:

PSBLIB

EXERCÍCIO 4

Inserindo no IMS Catalog

IMS 15.5 e 15.6 utilizam:

Managed ACB

Executar:

DFS3PU00

para publicar:

DBD
PSB

no Catalog.


Solução

Comando:

IMPORT DEFN SOURCE(CATALOG)

Validação:

QUERY DB NAME(BANKDB)

EXERCÍCIO 5

Alocando a Base Física

Criar DBDS.

//ALLOC EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
 DEFINE CLUSTER -
 (NAME(IMS.BANKDB.AREA001) -
 CYLINDERS(10 5))
/*

Solução

Dataset criado:

IMS.BANKDB.AREA001

EXERCÍCIO 6

Carga Inicial com DFSURGU0

Arquivo de entrada:

CLIENTE12345678901JOAO SILVA
CONTA0000001001
MOVIMENTO20240101PIX000100
MOVIMENTO20240102TED000200

JCL:

//LOAD EXEC PGM=DFSURGU0
//SYSOUT DD SYSOUT=*
//INPUT DD *
CLIENTE12345678901JOAO SILVA
CONTA0000001001
MOVIMENTO20240101PIX000100
MOVIMENTO20240102TED000200
/*

Solução

Banco carregado.

RC=0000

EXERCÍCIO 7

Extraindo Dados com DFSURGL0

JCL:

//UNLOAD EXEC PGM=DFSURGL0
//SYSOUT DD SYSOUT=*
//SYSUT1 DD SYSOUT=*

Solução

Saída:

CLIENTE
CONTA
MOVIMENTO
MOVIMENTO

EXERCÍCIO 8

Programa COBOL - Leitura GU

Objetivo:

Ler cliente específico.

CALL 'CBLTDLI'
 USING
 'GU  '
 PCB-MASK
 CLIENTE-AREA
 SSA-CLIENTE

SSA:

CLIENTE(CPF =12345678901)

Solução

Status:

SPACE

Registro encontrado.


EXERCÍCIO 9

Programa COBOL - Inserção ISRT

Inserir nova conta.

CALL 'CBLTDLI'
 USING
 'ISRT'
 PCB-MASK
 CONTA-AREA

Solução

Nova ocorrência criada:

CLIENTE
 |
 +-- CONTA

EXERCÍCIO 10

CRUD Completo

Executar:

Consulta

GU
GN
GNP

Atualização

REPL

Exclusão

DLET

Solução

Fluxo:

GU CLIENTE

GN CONTA

REPL CONTA

DLET MOVIMENTO

Programa COBOL Completo

IDENTIFICATION DIVISION.
PROGRAM-ID. BANKIMS.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 DLI-GU PIC X(4) VALUE 'GU  '.

LINKAGE SECTION.

01 PCB-MASK.
   05 STATUS-CODE PIC XX.

PROCEDURE DIVISION.

MAIN.

CALL 'CBLTDLI'
 USING
 DLI-GU
 PCB-MASK
 IO-AREA
 SSA.

IF STATUS-CODE = SPACES
 DISPLAY 'REGISTRO ENCONTRADO'
END-IF.

GOBACK.

Desafio Extra 1

Adicionar segmento:

ENDERECO

abaixo de CLIENTE.


Desafio Extra 2

Adicionar segmento:

CARTAO

abaixo de CONTA.


Desafio Extra 3

Criar programa COBOL para listar toda árvore:

CLIENTE
CONTA
MOVIMENTO

usando:

GU
GNP
GN

Desafio Extra 4

Criar utility REXX para executar:

ADDRESS TSO

"SUBCOM IMS"

"QUERY DB NAME(BANKDB)"

e validar status do banco.


Resultado Final Esperado

Hierarquia criada:

CLIENTE
 CPF=12345678901

   CONTA
   0000001001

      MOVIMENTO
      PIX

      MOVIMENTO
      TED

Conhecimentos adquiridos:

✓ DBDGEN

✓ PSBGEN

✓ IMS Catalog

✓ Managed ACB

✓ DFS3PU00

✓ DFSURGU0

✓ DFSURGL0

✓ DL/I

✓ COBOL IMS

✓ GU

✓ GN

✓ GNP

✓ ISRT

✓ REPL

✓ DLET

✓ Administração IMS 15.5 / 15.6


quinta-feira, 4 de janeiro de 2024

☕💣🔥 LABORATÓRIO PRÁTICO — TESTES DE PERFORMANCE PARA O PADAWAN COBOL MAINFRAME

 

Bellacosa Mainframe e laboratorio pratico de performance

☕💣🔥 LABORATÓRIO PRÁTICO — TESTES DE PERFORMANCE PARA O PADAWAN COBOL MAINFRAME

Este laboratório foi criado para transformar conceitos em prática.

A ideia é que o aluno pense como um Analista de Performance, um Desenvolvedor COBOL e um Sysprog ao mesmo tempo.

Cada exercício possui:

  • Cenário

  • Desafio

  • Solução Comentada

  • Conceitos Envolvidos


EXERCÍCIO 1

Identificando o Tipo de Teste

Cenário

O banco deseja validar se o Internet Banking suporta 5.000 usuários simultâneos.

Pergunta

Qual tipo de teste deve ser realizado?

A) Estresse

B) Resistência

C) Carga

D) Pico


Solução

Resposta:

C) Carga

O objetivo é validar a capacidade prevista do ambiente.

Não estamos ultrapassando limites.

Não estamos testando durante horas.

Não estamos simulando explosões repentinas.

Estamos simulando o uso normal esperado.


EXERCÍCIO 2

Descobrindo o Gargalo

Cenário

Uma consulta de saldo apresenta:

ComponenteTempo
Front-End50 ms
API80 ms
CICS1200 ms
DB2950 ms

Pergunta

Onde está o principal gargalo?


Solução

CICS e DB2.

O tempo de resposta total está concentrado nessas camadas.

O Front-End e API representam parcela muito pequena do processamento.

O próximo passo seria analisar:

  • SQL

  • Índices

  • Plano de acesso

  • Locks


EXERCÍCIO 3

Avaliando Throughput

Cenário

Durante um teste foram processadas:

120.000 transações

em

60 segundos

Pergunta

Qual o Throughput?


Solução

Fórmula:

TPS = Transações ÷ Tempo

120.000 ÷ 60

TPS = 2.000

Resposta:

2.000 TPS


EXERCÍCIO 4

Encontrando Problema de Código COBOL

Programa

PERFORM UNTIL WS-FIM = 'S'

   READ ARQ-CLIENTES
      AT END
         MOVE 'S' TO WS-FIM
   END-READ

   PERFORM PROCESSA-CLIENTE

END-PERFORM

Pergunta

Qual risco de performance existe?


Solução

Se o arquivo possuir milhões de registros:

  • CPU elevada

  • I/O elevado

  • Tempo excessivo

O código não está errado.

Mas pode não escalar.

Performance depende do volume.


EXERCÍCIO 5

Escolhendo a Ferramenta

Cenário

Você precisa gerar:

10.000 usuários simultâneos

realizando chamadas HTTP.

Pergunta

Qual ferramenta apresentada seria mais indicada?


Solução

Apache JMeter.

Porque:

  • Open Source

  • Escalável

  • HTTP

  • HTTPS

  • REST

  • SOAP

Foi justamente a ferramenta mostrada na apresentação.


EXERCÍCIO 6

Teste de Resistência

Cenário

Uma aplicação funciona perfeitamente por:

30 minutos

Após:

8 horas

o consumo de memória cresce continuamente.

Pergunta

Qual tipo de teste identificou o problema?


Solução

Teste de Resistência.

Também chamado:

Soak Test

ou

Endurance Test.

Esse tipo de problema dificilmente aparece em testes rápidos.


EXERCÍCIO 7

Simulando Black Friday

Cenário

Usuários simultâneos:

09:00 → 1.000

09:01 → 10.000

09:02 → 15.000

09:03 → 1.000

Pergunta

Qual tipo de teste está sendo realizado?


Solução

Teste de Pico.

Objetivo:

Validar explosões repentinas de acesso.

Muito comum em:

  • Black Friday

  • PIX

  • Campanhas

  • Venda de ingressos


EXERCÍCIO 8

Análise de Mainframe

Cenário

Durante o teste:

CPU = 35%

Tempo de Resposta = 8 segundos

Pergunta

A CPU é o problema?


Solução

Não necessariamente.

Esse é um erro clássico.

Mesmo com CPU baixa podem existir:

  • Locks DB2

  • Espera de I/O

  • MQ congestionado

  • SQL ruim

  • Contenção CICS

CPU baixa não significa ambiente saudável.


EXERCÍCIO 9

Virtualização de Serviços

Cenário

O microsserviço precisa chamar:

  • Serviço A

  • Serviço B

  • Mainframe

Mas o Mainframe está indisponível.

Pergunta

Como continuar os testes?


Solução

Utilizando Virtualização.

Criamos respostas simuladas.

Exemplo:

{
  "conta":"12345",
  "saldo":"1500.00"
}

Assim os testes continuam sem depender do ambiente real.


EXERCÍCIO 10

Diagnóstico Completo

Cenário

O Grafana mostra:

CPU = 40%

Memória = 45%

Tempo Médio = 5 segundos

Dynatrace mostra:

API = 100 ms

CICS = 250 ms

DB2 = 4200 ms

Pergunta

Onde você investigaria primeiro?


Solução

DB2.

O banco responde por mais de 80% do tempo total.

Possíveis causas:

  • Full Scan

  • Índice ausente

  • Estatísticas desatualizadas

  • Lock

  • SQL mal otimizado


DESAFIO FINAL DO PADAWAN ☕💣

Imagine a seguinte arquitetura:

Mobile
   ↓
Apache
   ↓
WebSphere
   ↓
API
   ↓
MQ
   ↓
CICS
   ↓
COBOL
   ↓
DB2

Você recebe a reclamação:

"Consultar saldo está demorando 12 segundos."

Descreva:

  1. Quais ferramentas utilizaria?

  2. Quais métricas analisaria?

  3. Quais componentes investigaria primeiro?

  4. Como executaria um teste de carga?

  5. Como validaria a correção?


GABARITO ESPERADO

Ferramentas:

  • JMeter

  • Dynatrace

  • Grafana

  • OMEGAMON

  • RMF

  • SMF

Métricas:

  • CPU

  • TPS

  • Tempo Médio

  • P95

  • P99

  • I/O

  • MQ Depth

  • Tempo DB2

Investigação:

  1. Dynatrace

  2. DB2

  3. CICS

  4. MQ

  5. API

Teste:

  • 5.000 usuários

  • Ramp-up gradual

  • Monitoramento simultâneo

Validação:

Comparar:

Antes = 12 segundos

Depois = meta inferior a 2 segundos


Missão Extra Bellacosa Mainframe

Pegue um programa COBOL real do seu ambiente e responda:

  • Quantos READs ele executa?

  • Quantos WRITEs?

  • Quantos SELECTs DB2?

  • Qual o maior loop?

  • Qual o volume esperado?

  • Como ele se comportaria com 10 milhões de registros?

Se você conseguir responder essas perguntas, já começou a pensar como um profissional de Performance Mainframe e não apenas como um programador COBOL. ☕💣🚀


terça-feira, 24 de agosto de 2021

ABEND sem Mistérios — Parte VI

 

Bellacosa Mainframe em abend sem misterios parte vi

☕ Um Café no Bellacosa Mainframe

ABEND sem Mistérios — Parte VI

O Grande Laboratório de ABENDs: Como Reproduzir, Investigar e Corrigir os Principais Erros do Mainframe Passo a Passo

"O conhecimento começa quando entendemos um ABEND. A experiência começa quando conseguimos reproduzi-lo. A maestria nasce quando sabemos evitá-lo."


Introdução

Até aqui, percorremos uma longa jornada.

Aprendemos:

  • o que é um ABEND;

  • como investigá-lo;

  • como analisar dumps;

  • como funciona a arquitetura do IBM Z;

  • como os grandes bancos utilizam observabilidade e Inteligência Artificial para prevenir incidentes.

Agora chegou a hora de colocar a mão na massa.

Existe uma diferença enorme entre ler sobre um ABEND e vê-lo acontecer diante dos seus olhos.

É exatamente assim que os grandes especialistas aprendem.

Eles não estudam apenas teoria.

Eles criam laboratórios.

Provocam erros.

Quebram programas.

Analisam dumps.

Corrigem.

Repetem.

Depois de algum tempo, passam a reconhecer um S0C7 da mesma forma que um médico reconhece uma doença comum.

Esta parte apresenta uma metodologia de treinamento que pode ser utilizada tanto em ambientes educacionais quanto em laboratórios corporativos.

O objetivo não é apenas reproduzir erros, mas compreender profundamente o motivo pelo qual eles acontecem.


Por que criar ABENDs de propósito?

Parece estranho.

Durante toda a carreira tentamos evitar erros.

Então por que provocá-los?

Porque um ambiente de testes é o lugar mais seguro para aprender.

Imagine um piloto de avião.

Antes de transportar passageiros ele treina:

  • falha hidráulica;

  • pane elétrica;

  • incêndio;

  • perda de motor.

No Mainframe fazemos o mesmo.

Treinamos quando ninguém está sendo afetado.


Como montar um laboratório de ABENDs

Você não precisa de um ambiente gigantesco.

Um pequeno sistema já é suficiente.

Por exemplo:

TSO

↓

ISPF

↓

Enterprise COBOL

↓

JCL

↓

SDSF

↓

VSAM

↓

Arquivos Sequenciais

Se houver CICS e Db2, melhor ainda.

Mas não são obrigatórios.


Regra número um

Nunca provoque ABENDs em Produção.

Parece óbvio.

Mas vale repetir.

Ambientes de treinamento existem exatamente para isso.


Exercício 1 — O primeiro S0C7

Objetivo:

Compreender Data Exception.

Crie uma variável:

01 WS-VALOR PIC 9(5).

Depois carregue:

12A45

Agora execute:

ADD 1 TO WS-VALOR.

Resultado esperado:

S0C7

O que observar?

Antes de corrigir.

Analise:

  • JESMSGLG;

  • SYSOUT;

  • CEEDUMP;

  • Offset;

  • Linha COBOL.

Depois responda:

Por que aconteceu?


Correção

Validação.

IF WS-VALOR NUMERIC
    ADD 1 TO WS-VALOR
ELSE
    DISPLAY 'DADO INVALIDO'
END-IF

Observe que o objetivo nunca foi "tirar o S0C7".

Foi impedir que dados inválidos chegassem ao cálculo.


Exercício 2 — O clássico S0C4

Monte uma tabela.

OCCURS 10 TIMES

Agora faça:

Índice = 25

Resultado.

Muito provavelmente.

S0C4

Investigação

Perguntas importantes.

O índice foi validado?

Quem alterou seu valor?

Existe PERFORM VARYING correto?

Existe INITIALIZE?


Exercício 3 — S013

Altere propositalmente:

  • LRECL

  • RECFM

Ou utilize um DDNAME incorreto.

Resultado.

IEC141I

S013

Agora investigue:

O problema está no COBOL?

Ou no JCL?

Essa diferença é fundamental.


Exercício 4 — S806

Compile normalmente.

Depois altere a STEPLIB.

Ou remova o Load Module.

Resultado.

S806

Aprendizado.

Nem todo ABEND vem do programa.


Exercício 5 — SB37

Crie um arquivo pequeno.

Depois grave milhares de registros.

O dataset ficará sem espaço.

Agora observe:

  • mensagens IEC;

  • SMS;

  • SYSOUT.


Exercício 6 — S322

Crie um loop infinito.

Exemplo.

PERFORM A
UNTIL 1 = 2

Configure TIME no JOB.

Resultado.

S322

Agora analise:

Quanto tempo demorou?

Como o sistema detectou?


Exercício 7 — FILE STATUS

Este talvez seja o exercício mais importante.

Leia um arquivo inexistente.

Sem verificar:

FILE STATUS

Depois repita verificando.

Perceba como muitos ABENDs desaparecem quando tratamos corretamente o retorno das operações.


Exercício 8 — SQLCODE

Mesmo sem gerar ABEND.

Faça:

SELECT

UPDATE

DELETE

ignorando SQLCODE.

Depois implemente tratamento.

É assim que sistemas robustos são construídos.


Exercício 9 — RESP no CICS

Execute comandos CICS.

Ignore RESP.

Depois implemente.

Você perceberá como muitos problemas são detectados antes de se transformarem em ASRA.


Exercício 10 — CEEDUMP

Escolha qualquer ABEND.

Agora tente responder apenas utilizando o CEEDUMP.

Onde ocorreu?

Qual variável estava errada?

Qual programa chamou aquele módulo?

Qual era o conteúdo da memória?

Esse exercício desenvolve enorme capacidade de investigação.


O Diário de ABENDs

Uma prática comum entre especialistas é manter um diário técnico.

Por exemplo.

DataABENDCausaSoluçãoComo evitar
10/07S0C7Campo inválidoValidaçãoIF NUMERIC
11/07S013LRECL erradoCorrigir JCLRevisão

Depois de alguns anos,

esse documento torna-se uma verdadeira biblioteca de conhecimento.


Aprendendo a formular hipóteses

Quando um incidente acontece,

não saia alterando o programa.

Primeiro formule hipóteses.

Por exemplo.

Hipótese 1

O arquivo veio corrompido.

Hipótese 2

O índice saiu do OCCURS.

Hipótese 3

O parâmetro foi passado incorretamente.

Depois procure evidências.

Esse é exatamente o método científico.


A regra de ouro da depuração

Nunca altere duas coisas ao mesmo tempo.

Imagine:

Você modifica:

  • JCL;

  • COBOL;

  • Copybook;

  • Parâmetros.

Depois funciona.

Qual alteração resolveu?

Você nunca saberá.

Faça mudanças pequenas.

Teste.

Observe.

Repita.


Simule incidentes completos

Depois de dominar os exercícios individuais,

crie cenários.

Exemplo.

O arquivo chega com layout errado.

Programa gera S0C7.

Batch seguinte não executa.

Relatório não é produzido.

Usuário abre chamado.

Agora reproduza toda a cadeia.

Essa abordagem aproxima o treinamento da realidade.


Automatizando laboratórios

Grandes empresas possuem ambientes capazes de:

  • executar centenas de testes;

  • gerar dumps automaticamente;

  • validar RC;

  • comparar resultados;

  • produzir relatórios.

Hoje isso pode ser integrado com:

  • Git;

  • Jenkins;

  • GitHub Actions;

  • IBM Dependency Based Build;

  • UrbanCode Deploy;

  • Ansible;

  • Zowe CLI.

Quanto mais automatizado o laboratório, mais rapidamente regressões são detectadas.


Como um mentor ensina ABENDs

Observe a diferença.

Professor comum:

"Esse é um S0C7."

Mentor experiente:

"Vamos provocar um S0C7, analisar o dump, descobrir a causa, corrigir o código e escrever um teste para garantir que ele nunca volte."

A segunda abordagem produz conhecimento duradouro.


O desafio dos grandes bancos

Os melhores programas não são aqueles que nunca falham.

São aqueles que:

  • detectam problemas rapidamente;

  • registram informações úteis;

  • facilitam o diagnóstico;

  • recuperam-se quando possível;

  • protegem os dados.

É exatamente esse pensamento que diferencia aplicações críticas.


Monte seu próprio catálogo

Ao longo da carreira, registre:

  • mensagens IEC;

  • mensagens IEF;

  • mensagens DFH;

  • SQLCODEs frequentes;

  • FILE STATUS;

  • RESP/RESP2;

  • ABENDs;

  • soluções.

Com o tempo você construirá um material que nenhum curso consegue fornecer.


Um roteiro de treinamento de 30 dias

Semana 1

  • S0C7

  • S0C4

  • S013

Semana 2

  • S806

  • SB37

  • S322

Semana 3

  • CEEDUMP

  • SYSMDUMP

  • JESMSGLG

  • JESYSMSG

Semana 4

  • IPCS

  • Fault Analyzer

  • Abend-AID

  • Root Cause Analysis

Ao final do mês, um Padawan terá experimentado dezenas de cenários que muitos profissionais só encontram após anos de trabalho.


Os cinco hábitos dos especialistas

  1. Nunca ignoram uma mensagem do sistema.

  2. Reproduzem o erro antes de corrigi-lo.

  3. Documentam tudo o que aprendem.

  4. Automatizam testes sempre que possível.

  5. Transformam cada incidente em conhecimento compartilhado.


Conclusão

Um ABEND não é um inimigo. Ele é um professor extremamente exigente.

Cada S0C7 ensina a validar dados. Cada S0C4 reforça a importância da memória e dos limites das tabelas. Cada S013 lembra que uma aplicação depende tanto do JCL quanto do código COBOL. Cada S806 mostra que uma compilação bem-sucedida não garante uma execução correta.

Os profissionais mais respeitados do mundo Mainframe não nasceram sabendo interpretar dumps ou localizar offsets em poucos minutos. Eles desenvolveram essa habilidade por meio de prática deliberada, repetindo investigações, registrando descobertas e aprendendo com cada incidente.

É exatamente por isso que um laboratório de ABENDs vale tanto. Nele, o erro deixa de representar um risco para o negócio e passa a ser uma ferramenta de aprendizado. E quando um Programador Padawan aprende a provocar, investigar, corrigir e prevenir os principais ABENDs em um ambiente controlado, ele chega muito mais preparado para enfrentar os desafios da produção.

No IBM Z, experiência não significa apenas tempo de carreira. Significa quantidade de problemas compreendidos, causas identificadas e conhecimento compartilhado. É assim que se forma um verdadeiro especialista em Mainframe.


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