Translate

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

sábado, 16 de maio de 2026

☕🖥️ DO DOS/360 AO z/OS: A LINHAGEM IMORTAL DOS MAINFRAMES IBM — O “DNA DIGITAL” QUE SOBREVIVE HÁ 60 ANOS ☕🖥️

 

Bellacosa Mainframe recordando as origems do Z/OS conheça o MVS 360

☕🖥️ DO DOS/360 AO z/OS: A LINHAGEM IMORTAL DOS MAINFRAMES IBM — O “DNA DIGITAL” QUE SOBREVIVE HÁ 60 ANOS ☕🖥️

Existe uma diferença brutal entre um computador comum… e uma arquitetura que literalmente ajudou a construir o planeta corporativo moderno.

E quando falamos do IBM Mainframe, estamos falando exatamente disso.

Não é exagero.

Boa parte do sistema financeiro mundial, seguradoras, companhias aéreas, governos e grandes bancos ainda carregam dentro de si fragmentos tecnológicos que nasceram no lendário IBM System/360 de 1964.

Sim…

Enquanto muita gente imagina que mainframe é “computador velho”, a verdade é muito mais absurda:

O z/OS moderno ainda carrega DNA arquitetural do OS/360.

É praticamente uma linhagem tecnológica contínua.


☕ O SYSTEM/360 — O MAINFRAME QUE REINICIOU A COMPUTAÇÃO

📅 Lançamento: 7 de abril de 1964
📅 Primeiras entregas: 1965
📅 Retirada oficial: nunca realmente “morreu” — evoluiu para System/370, 390 e linha Z

O System/360 mudou TUDO.

Antes dele:

  • softwares raramente eram compatíveis entre máquinas
  • trocar hardware era um pesadelo
  • programas precisavam ser reescritos
  • cada fabricante criava um universo isolado

A IBM decidiu fazer algo quase insano para a época:

Criar uma arquitetura padronizada e compatível entre modelos.

Hoje isso parece normal.

Nos anos 60?

Era quase ficção científica corporativa.

O projeto custou 5 bilhões de dólares da época — um dos maiores investimentos tecnológicos do século XX.


☕ DOS/360 — O “SISTEMA OPERACIONAL DE EMERGÊNCIA” QUE VIROU LENDA

📅 Lançamento: 1965
📅 Evoluiu para: DOS/VS → DOS/VSE → z/VSE
📅 Retirada do nome “DOS”: anos 80 (para evitar confusão com PC-DOS)

O DOS/360 nasceu porque o OS/360 estava atrasado.

A IBM precisava entregar alguma coisa.

E rápido.

O DOS era mais simples, menor e menos sofisticado.

Mas funcionava.

E vendeu computadores.


☕ O MUNDO ERA MECÂNICO

Hoje você sobe uma VM na nuvem em segundos.

Na era DOS/360?

O operador literalmente:

  • montava fitas
  • trocava discos físicos
  • alimentava leitora de cartões
  • controlava impressoras gigantes
  • fazia IPL manualmente

Tudo era físico.

Tudo fazia barulho.

Tudo piscava.

Era quase uma mistura de engenharia industrial com ficção científica.


☕ TOS/360 — O SISTEMA OPERACIONAL QUE RODAVA EM FITAS

📅 Lançamento: 1965
📅 Retirada: final dos anos 60/início dos 70

Sim.

Existia um sistema operacional baseado em FITA MAGNÉTICA.

O TOS/360 era usado por empresas que não podiam pagar discos.

Imagine o sofrimento operacional:

  1. monta fita
  2. carrega sistema
  3. executa job
  4. troca fita
  5. imprime resultado
  6. reza para nada travar

O boot praticamente tinha “trabalho braçal”.


☕ BOS/360 — O “MAINFRAME DE ENTRADA”

📅 Lançamento: 1965
📅 Retirada: anos 70

Voltado para máquinas pequenas como o System/360 Model 30.

E aqui entra um detalhe que explode a cabeça de qualquer geração moderna:

Esses sistemas podiam operar com 8K ou 16K de memória.

KILOBYTES.

Uma imagem simples no WhatsApp hoje pode ser maior que a memória inteira de um banco dos anos 60.


☕ OS/360 — O VERDADEIRO TITÃ

📅 Lançamento: 1966/1967
📅 Evolução direta: MVS → OS/390 → z/OS

O OS/360 foi o grande sistema operacional corporativo da IBM.

E ele veio em três variantes:

  • PCP
  • MFT
  • MVT

☕ PCP — O “MODO MONOTAREFA CORPORATIVO”

📅 Lançamento: 1966
📅 Retirada: anos 70

O PCP rodava apenas UM programa por vez.

Simples assim.

Nada de multiprogramação sofisticada.

Você executava:

  • folha de pagamento
  • terminava
  • depois rodava faturamento

Era praticamente um “mainframe sequencial”.


☕ MFT — QUANDO O MAINFRAME APRENDEU MULTIPROGRAMAÇÃO

📅 Lançamento: 1966/1967
📅 Evolução: OS/VS1
📅 Retirada: anos 70

O MFT introduziu partições fixas.

Exemplo mental:

PARTIÇÃO 1 → COBOL
PARTIÇÃO 2 → SORT
PARTIÇÃO 3 → UTILITÁRIOS

O problema?

Rigidez absurda.

Se um programa precisasse mais memória…

dor de cabeça.


☕ MVT — O PAI DO z/OS MODERNO

📅 Lançamento: 1966/1967
📅 Evoluiu para: SVS → MVS → z/OS
📅 Última grande versão: MVT 21.8F (1974/1978)

Aqui nasce o DNA do mainframe moderno.

O MVT trouxe:

  • regiões variáveis
  • TSO
  • multitarefa avançada
  • multiprocessamento
  • timesharing
  • gerenciamento mais inteligente de memória

Foi aqui que o mainframe começou a parecer “moderno”.


☕ TSO — O MAINFRAME VIROU INTERATIVO

Antes:

  • submit de job
  • espera
  • impressão
  • análise

Depois do TSO?

O usuário passou a interagir ONLINE.

Isso revolucionou:

  • desenvolvimento
  • administração
  • suporte
  • produtividade

Foi uma mudança tão absurda quanto sair do MS-DOS para Windows.


☕ VS1, SVS E MVS — A REVOLUÇÃO DA MEMÓRIA VIRTUAL

OS/VS1

📅 Lançamento: 1972
📅 Retirada: anos 80

SVS (OS/VS2 R1)

📅 Lançamento: 1972
📅 Retirada: substituído pelo MVS

MVS (OS/VS2 R2)

📅 Lançamento: 1974
📅 Evolução contínua até hoje

Aqui aconteceu algo monumental:

A IBM trouxe Virtual Storage.


☕ O QUE ISSO SIGNIFICA?

Antes:

Programa → memória física

Depois:

Programa → memória virtual → paginação → memória real

Isso permitiu:

  • múltiplos address spaces
  • isolamento
  • expansão massiva
  • estabilidade
  • escalabilidade corporativa

☕ MVS — MULTIPLE VIRTUAL STORAGE

O nome diz tudo.

Cada aplicação ganhou seu próprio espaço de memória virtual.

É a base conceitual do z/OS moderno.

Sem exagero:

Boa parte da computação corporativa atual nasceu aqui.


☕ JES2 — O CORAÇÃO BATCH DO PLANETA

📅 JES2 origem: HASP
📅 JES3 origem: ASP

O JES virou o sistema nervoso do batch.

Fluxo clássico:

  1. usuário envia JCL
  2. JES recebe
  3. spoola
  4. agenda execução
  5. coleta SYSOUT
  6. libera saída

Sem JES?

O mundo batch praticamente não existiria como conhecemos.


☕ VM/370 — A IBM INVENTOU A NUVEM ANTES DA INTERNET

📅 CP/67: 1967
📅 VM/370: anos 70
📅 Evolução atual: z/VM

Aqui mora uma das maiores loucuras tecnológicas da história.

Décadas antes do VMware…

Décadas antes da AWS…

O mainframe já fazia virtualização pesada.


☕ O CONCEITO ERA GENIAL

Hardware real

CP (Hypervisor)

Máquinas virtuais independentes

Cada usuário tinha:

  • discos virtuais
  • memória virtual
  • console próprio
  • ambiente isolado

Nos ANOS 60.

Isso é completamente surreal.


☕ MVS/XA — QUANDO 16 MB VIRARAM “PEQUENOS”

📅 Lançamento: 1983
📅 Evoluiu para: MVS/ESA

Até então:

  • limite de 16 MB por address space

O XA trouxe:

  • 31 bits
  • 2 GB de endereçamento
  • multiprocessamento muito melhor

Na época isso parecia infinito.


☕ MVS/ESA — O MAINFRAME CORPORATIVO DEFINITIVO

📅 Lançamento: 1988
📅 Evoluiu para: OS/390

Trouxe:

  • Sysplex
  • ESCON
  • Hiperspaces
  • Data Spaces
  • Workload Manager moderno

Aqui o mainframe virou praticamente um “cluster corporativo”.


☕ OS/390 — A FUSÃO DOS TITÃS

📅 Lançamento: 1995/1996
📅 Retirada: substituído pelo z/OS

O OS/390 consolidou vários produtos em um ecossistema mais integrado.

Foi um período importantíssimo para:

  • automação
  • storage management
  • simplificação operacional

☕ z/OS — O HERDEIRO FINAL

📅 Lançamento: 2001
📅 Status: ativo até hoje

O z/OS é literalmente o descendente direto do MVT dos anos 60.

E isso é uma insanidade arquitetural.

Ele suporta:

  • 24 bits
  • 31 bits
  • 64 bits

Tudo convivendo.


☕ O QUE SOBREVIVEU POR DÉCADAS?

Ainda hoje existem aplicações COBOL criadas há décadas funcionando em produção.

Porque o mainframe foi projetado para preservar investimento.

Esse talvez seja o maior diferencial filosófico do ecossistema IBM.


☕ HERCULES — O “MUSEU VIVO” DOS MAINFRAMES

O Hercules permite rodar:

  • DOS/360
  • MVS 3.8J
  • VM/370
  • VSE
  • Linux/390

em PCs modernos.

Mas existe um detalhe IMPORTANTÍSSIMO:

Hercules NÃO é brinquedo.

Você precisa entender:

  • IPL
  • JCL
  • DASD
  • JES
  • VTAM
  • catalog
  • dumps
  • hexadecimal
  • arquitetura

É praticamente um laboratório de SYSprog raiz.


☕ O MAINFRAME FEZ “CLOUD COMPUTING” ANTES DA CLOUD

Essa talvez seja a maior ironia tecnológica da história.

Muito antes de:

  • Kubernetes
  • Docker
  • VMware
  • AWS
  • Azure

o mainframe já fazia:

  • virtualização
  • isolamento
  • cluster
  • workload balancing
  • alta disponibilidade
  • failover
  • timesharing
  • multiusuário massivo

Décadas antes do marketing moderno reinventar nomes para ideias antigas.


☕ CONCLUSÃO ESTILO BELLACOSA MAINFRAME

Enquanto dezenas de arquiteturas desapareceram:

  • DEC VAX
  • Burroughs
  • Univac
  • Wang
  • Data General

o DNA do System/360 continua vivo.

E talvez isso seja a maior prova de engenharia da história da computação corporativa.

O z/OS moderno não é “um sistema novo”.

Ele é uma LINHAGEM.

Uma criatura tecnológica evoluindo continuamente há mais de meio século.

E honestamente?

Pouquíssimas tecnologias na história conseguiram algo parecido.

quarta-feira, 24 de dezembro de 2025

💥 Seu CICS Não Sobe — Ele RENASCE: O Guia Definitivo de Startup e Shutdown Para Quem Vive de COBOL

 

Bellacosa Mainframe conheça o start e shutdown do CICS

💥 Seu CICS Não Sobe — Ele RENASCE: O Guia Definitivo de Startup e Shutdown Para Quem Vive de COBOL

Se você é um dev COBOL sênior, já sabe:
CICS não é só um runtime — é um organismo vivo dentro do z/OS.

E como todo organismo, ele tem dois momentos críticos:

👉 Como nasce (startup)
👉 Como morre (shutdown)

Dominar isso não é opcional. É o que separa quem “roda programa” de quem segura produção.


🧬 🕰️ UM POUCO DE HISTÓRIA (E UM EASTER EGG)

O IBM CICS nasceu lá nos anos 60/70 para resolver um problema simples:

Como processar milhares de transações simultâneas com consistência?

A resposta foi revolucionária:

  • Controle transacional (commit/rollback)
  • Gerenciamento de recursos
  • Isolamento de unidades de trabalho

💥 Easter egg:

O conceito de ACID que você vê em bancos modernos…
já era realidade no CICS décadas antes.


🚀 ⚙️ STARTUP — O NASCIMENTO DO CICS

🧠 O que realmente acontece quando você roda:

S CICSPRD1

Não é só “subir um sistema”.

👉 É isso aqui:

  1. JES inicia a task
  2. DFHSIP assume o controle
  3. SIT (System Initialization Table) é carregada
  4. Overrides são aplicados
  5. CICS consulta o catálogo
  6. Decide como iniciar
  7. Inicializa domínios
  8. Libera controle

🔥 O MOMENTO MAIS IMPORTANTE

DFHSI1517 Control is being given to CICS

👉 Tradução:

“Agora sim — pode mandar transação COBOL que eu aguento.”


🧠 TIPOS DE START (O PASSADO DEFINE O FUTURO)

TipoQuando acontece
INITIALPrimeira vez
COLDReset
WARMNormal
EMERGENCYApós falha

💥 Insight de produção

O tipo de startup não depende do comando…
depende de como o CICS morreu antes.


📦 🔍 GLOBAL CATALOG — A MEMÓRIA DO CICS

Aqui está o segredo:

O CICS sempre pergunta:

“O que aconteceu antes?”

E a resposta vem de:

  • Recovery Manager Control Record
  • Autostart Override Record

👉 Isso define:

  • Se houve crash
  • Se há transações pendentes
  • Se precisa recovery

💥 Easter egg técnico

START=AUTO não é “automático” —
é decisão baseada em histórico persistente


🔄 🚨 EMERGENCY START — VOLTANDO DOS MORTOS

Quando o CICS cai mal:

  • CANCEL
  • Queda de energia
  • Abend

👉 Ele entra em modo cirúrgico:

  1. Lê DFHLOG
  2. Identifica transações incompletas
  3. Executa rollback
  4. Restaura consistência

💣 Realidade

Emergency Start não é erro
é o sistema tentando salvar sua pele


🛑 ⚙️ SHUTDOWN — COMO O CICS MORRE

Agora vem a parte mais negligenciada — e mais perigosa.


🟢 NORMAL SHUTDOWN — MORRER COM DIGNIDADE

CEMT P SHUT

🧠 O que acontece:

Stage 1 (Quiesce)

  • Para novas transações
  • Deixa as atuais terminarem
  • Executa PLT

Stage 2 (Finalização)

  • Fecha arquivos
  • Flush de buffers
  • Fecha VTAM
  • Resolve unidades de trabalho
  • Marca “warm start possível”

🏁 Final:

DFHKE1799 TERMINATION OF CICS IS COMPLETE

💥 Resultado

👉 Próximo start:

WARM

👉 Rápido, limpo, sem dor


🟡 IMMEDIATE SHUTDOWN — FREIO DE EMERGÊNCIA

F CICSPRD1,CEMT P SHUT IMM

⚠️ O que muda:

  • Tasks podem ser interrompidas
  • Arquivos nem sempre fechados corretamente
  • Estado não totalmente salvo

💣 Consequência:

👉 Próximo start pode ser:

EMERGENCY

💥 Easter egg real de console

Se você já viu:

THREAD ENDED WITHOUT BEING UNDUBBED

👉 Parabéns: você já viveu um shutdown “meio traumático” 😅


🔴 UNCONTROLLED — O CAOS

Quando acontece:

  • Crash
  • Falha de hardware
  • Kill job

👉 Resultado:

❌ Nenhum controle
❌ Nenhuma garantia
❌ Recovery obrigatório


🔗 🔥 A REGRA MAIS IMPORTANTE

Como você desligaComo você sofre depois
NormalTranquilo
ImmediateTalvez
CrashCom certeza

🧠 💥 VISÃO DE UM DEV COBOL SÊNIOR

Se você trabalha com:

  • VSAM
  • DB2
  • MQ
  • Transações críticas

👉 Isso impacta diretamente:

✔ Commit consistency
✔ Locking
✔ Recovery
✔ Performance


💥 Exemplo real

Você faz:

EXEC CICS WRITE FILE(...)
EXEC CICS SYNCPOINT

👉 Se o CICS cai antes do syncpoint:

  • Emergency Start vai decidir
  • Rollback pode ocorrer
  • Dados podem voltar

🔧 🧪 CHECKLIST DE PRODUÇÃO (OURO)

Antes de desligar:

✔ Verificar tasks:

CEMT I TASK

✔ Verificar filas / integrações

✔ Garantir que não há batch crítico

✔ Executar:

CEMT P SHUT

😏 CONCLUSÃO PROVOCATIVA

CICS não é sobre rodar programas
é sobre garantir que nada se perca mesmo quando tudo dá errado


🚀 O QUE VOCÊ LEVA DISSO

✔ Entende o ciclo completo
✔ Sabe ler mensagens DFH
✔ Sabe escolher tipo de shutdown
✔ Entende impacto real em dados


💥 FRASE FINAL (GUARDA ESSA)

Quem domina STARTUP aprende a subir sistema
Quem domina SHUTDOWN aprende a salvar produção

quarta-feira, 8 de março de 2017

O Choque Cultural de Quem Sai do Mundo Windows/Linux e Entra em z/OS

 

Bellacosa Mainframe e o choque cultural na chegada na Stack mainframe

☕ Um Café no Bellacosa Mainframe

O Choque Cultural de Quem Sai do Mundo Windows/Linux e Entra em z/OS

Este post é excelente porque captura exatamente a sensação de quase todo profissional que chega ao universo IBM Z pela primeira vez.

A primeira impressão costuma ser:

"Isto não é um computador. Isto é uma máquina do tempo."

E, em parte, é verdade.

Mas também é uma das arquiteturas computacionais mais sofisticadas já produzidas.

Vamos desmontar alguns mitos e aprofundar os conceitos.


O primeiro choque: não existem pastas

Quem vem de Windows pensa:

C:
 ├── Projetos
 │    ├── Cobol
 │    ├── Testes

Quem vem de Linux pensa:

/opt/cobol/src/
/home/user/programs

No z/OS, historicamente não existiu um sistema de arquivos hierárquico.

Você encontra:

IBMUSER.TEST.COBOL

ou

BELLACOSA.DEV.SOURCE

ou

BANK01.CICS.COPYLIB

Não são diretórios.

São datasets.


Dataset é um conceito muito mais antigo que um arquivo

Dataset significa literalmente:

Conjunto de dados

Há vários tipos.

Sequential Dataset

PS

Exemplo:

USER01.JCL

Contém apenas um fluxo.

Como um TXT gigante.


PDS

Partitioned Data Set

Aqui começa o choque.

Imagine:

Windows

Cobol
 ├── CLIENTE.cbl
 ├── CONTA.cbl
 └── CARTAO.cbl

No Mainframe:

Dataset

USER01.COBOL.SOURCE

Membros

CLIENTE
CONTA
CARTAO

Notação:

USER01.COBOL.SOURCE(CLIENTE)

Muito elegante.

Um único catálogo.

Milhares de programas.


O PDS não é uma pasta

Esta é uma distinção importante.

Um diretório moderno é dinâmico.

Um PDS é pré-alocado.

Você define:

Primary Space

Secondary Space

Directory Blocks

Exemplo:

SPACE=(CYL,(10,5,20))

20 blocos de diretório.

Acabaram?

Não cria sozinho.

Você recria.

Ou comprime.


Os fantasmas dentro do PDS

Essa foi uma observação muito boa do autor.

Quando alteramos:

CLIENTE

CLIENTE

CLIENTE

CLIENTE

O ISPF grava uma nova versão física.

A antiga continua ocupando espaço.

Marcada como deletada.

Mas ainda existe.

Igual um SSD sem TRIM.


Compress

No ISPF:

Utilities

3.1

Compress Dataset

ou

IEBCOPY

//STEP1 EXEC PGM=IEBCOPY

Ele reorganiza.

Remove membros mortos.

Compacta.

Recupera espaço.


O famoso ABEND Sx37

O texto menciona 0E37.

Na realidade os mais comuns são:

SB37

Sem espaço em disco


SE37

Sem extents disponíveis


SD37

Dataset VSAM cheio


No PDS, muitas vezes ocorre:

Directory Full

ou

SB37

dependendo da situação.

Compress normalmente resolve.

Regra de ouro do Sysprog:

Se um PDS antigo começou a se comportar estranho,

faça um compress.


O nome dos datasets

Ele fala em três níveis.

Na prática podem existir muitos.

Exemplo:

BANK01.DEV.COBOL.SOURCE


BANK01.TEST.COBOL.COPYLIB


BANK01.PROD.JCL.BATCH


BANK01.CICS.LOADLIB

Até 44 caracteres.

Qualificadores:

Primeiro nível

High Level Qualifier

HLQ

Exemplo:

IBMUSER

Segundo:

Aplicação

FINANCE

Terceiro:

Tipo

SOURCE
LOAD
COPYLIB
DBRM
JCL
PROC

O choque das 80 colunas

Outro fantasma tecnológico.

Cartões IBM.

80 posições.

Ainda hoje.

COBOL clássico:

1-6    Sequence


7      Indicator


8-11   Area A


12-72  Area B


73-80  Comentários

Exemplo:

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. CLIENTE.

ISPF é um editor absurdamente eficiente

No começo parece cruel.

Depois de alguns meses...

Você entende.

E não quer sair.

Comandos:

C
CC
M
MM
A
B
RR

Copiar.

Mover.

Repetir.

Excluir.

Tudo sem mouse.


Exemplo:

CC
...
CC


A

Copia cem linhas.

Instantaneamente.


Terminal versus GUI

Debate interessante.

GUI

Excelente descoberta.

Visual.

Baixa curva.


Terminal

Extremamente rápido.

Menos distrações.

Baixo consumo.

Automatizável.


Um Sysprog experiente parece um pianista.

F3

F7

F8

PF11

PF12

Enter

Tab

Em segundos percorre centenas de datasets.


Como começar no Mainframe?

Caminho 1 — IBM Z Xplore

Hoje é provavelmente o melhor caminho.

Laboratórios reais.

TSO.

JCL.

COBOL.

DB2.

USS.

RACF.

Sem instalar nada.

Excelente para iniciantes.


Caminho 2 — Hercules

Ótimo.

Mas exige bastante dedicação.

TK4-

MVS 3.8J

TK5

Ajuda muito a compreender:

JES2

Catalog

VTAM

TSO

ISPF

Porém não representa totalmente um z/OS moderno.


Caminho 3 — Zowe

Talvez seja o mais amigável.

VSCode.

Git.

SSH.

REST.

Terminal.

Mainframe híbrido.

Muito próximo do DevOps moderno.


O maior choque para quase todos os iniciantes

Normalmente é uma destas coisas:

Desenvolvedor Linux

Onde está o ls?


Desenvolvedor Windows

Cadê minhas pastas?


Programador Java

O que é um JCL?


Programador COBOL

Por que preciso dar BIND no DB2?


Sysadmin

Como assim reiniciar um LPAR custa milhões de dólares por hora?


A grande revelação

Depois de alguns meses, a percepção muda.

Você deixa de pensar em:

"Por que o Mainframe é tão estranho?"

E começa a perguntar:

"Por que os outros sistemas desperdiçam tantos recursos para fazer coisas que o Mainframe resolve há cinquenta anos?"

O IBM Z é menos um computador pessoal e mais uma infraestrutura industrial de processamento de transações, concebida para operar continuamente durante décadas, suportando bancos, bolsas de valores, seguradoras, governos e sistemas críticos. Muitas das suas peculiaridades não são limitações, mas decisões de engenharia tomadas para privilegiar estabilidade, previsibilidade, compatibilidade binária, desempenho e disponibilidade extrema. O verdadeiro desafio para quem está começando não é aprender COBOL ou decorar comandos do ISPF; é realizar uma mudança de paradigma e compreender que, no mundo do IBM Z, quase tudo foi projetado para minimizar riscos e garantir que um programa escrito há quarenta anos continue funcionando hoje, enquanto conversa com APIs REST, microsserviços, containers OpenShift e até aplicações de Inteligência Artificial. É justamente essa convivência entre passado, presente e futuro que torna o ecossistema do Mainframe tão fascinante.


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