✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
A construção mais imponente de Paris : Catedral de Notre Dame
Gente ensaiei falar tanta coisa, mas quando cheguei aqui fiquei assim cara de pastel e mudo. Imagino que emoção superior somente terei quando visitar Roma ou estar em pé, frente a pirâmide de Queops.
Imagine um cara que desde sempre sonhou em estar num lugar, ver algo, tocar algo e de repente isso acontece. Mais ou menos assim foi como me senti.
A eletricidade fluía pelo meu corpo, a cada esquina que passava eu via a pontinha da Torre Eiffel, me imaginava chegando a catedral e agora estou aqui, as portas de Notre Dame. Fazendo visita por tudo quanto é buraquinho, explorando cada detalhe de pedra, subindo na torre, descendo no subsolo e vendo o rio Sena sereno ao lado.
Barcos de turismo, uma miniatura da estátua da Liberdade as margens do Sena, bancas de pinturas e desenhistas, antiguidades, cadeados em pontes tanta coisa.
Mesmo o Arco do Triunfo que tanto simbolismo teve durante séculos. E agora estamos aqui onde tanta gente importante passou, ocupando o mesmo lugar. Apreciando os jardins e vendo a historia correr perante nossos olhos.
Nossa gente Paris é show para os avessos a direcção e veículos automóveis como eu. Aqui temos metro para tudo quanto é lado, as vezes ate 3 estações diferentes para a mesma região, único ponto negativo é o cheiro de xixi.
Mas ninguém tem a vida dificultada por falta de meios de locomoção, ate bem tarde o transporte publico funciona bem. Nunca nos deixando a mão no retorno para o albergue.
Falando da cidade, hoje fomos ao Louvre que lugar maravilhoso, jardins, edifícios, a pirâmide, os shows de rua, o mini arco do triunfo, são tantas as maravilhas que fico sem palavra para enumera-las.
Em relação a comida hoje fomos num mercadinho de bairro, abastecemos a mochila e fizemos um delicioso pic nic rodeados de ratos com asas e pardais do telhado.
Paris é uma cidade apaixonante, linda, muito bem cuidada, especialmente criada para impressionar o viajante, não vou negar que ela mexeu com meu coração, é impossível ficar indiferente a ela.
Com o perdão da palavra, para as pessoas mais serias, eu comparo Paris, a uma amante mais velha, bela e bem cuidada, deliciosa e com o coração cheio de pecado e repleta de caprichos, me perdi nos braços delas, em cada esquina ficava mais encantado que na anterior. Porem ao final eu queria voltar para casa para os braços da esposa.
Apesar de toda beleza, ela é uma cidade fria e distante. Entra-se em todos os lugares, descobre-se todos os segredos, mas mesmo assim continuamos a ser estranhos, cada um no seu lugar.
Andamos por diversas vias, vi o museu Pompidou, o Arco do Triunfo e sua vista fantástica de toda a cidade, suas ruas projectadas simetricamente iguais, a Bastilha e seus terrores, o comercio local, o bairro operário e cheio de imigrantes.
A respeito da comida provei diversos sabores estrangeiros em restaurantes étnicos para imigrantes, com preços bem mais acessíveis, longe do glamour e preços exorbitantes da cozinha francesa.
Nas eleiçoes municipais de 2016 na pre-campanha estavamos tentando conquistar nosso espaço e na busca deste espaço nada como correr atras de açoes pouco convencionais, vale tudo para conseguir chamar atençao.
☕ Um Café no Bellacosa Mainframe — Especial Red Team
“Você Conhece o Diretor Rooney?” — OSINT Antes do Google Existir
🔎 Como informação aparentemente inútil sobre pessoas, hábitos e organizações se transforma em superfície de ataque
Antes do Google.
Antes do LinkedIn.
Antes do GitHub.
Antes de alguém publicar no Instagram uma foto do crachá, da sala de reunião, do notebook corporativo, do quadro branco e, de bônus, metade da arquitetura da empresa ao fundo.
Já existia reconhecimento.
Ferris Bueller sabia disso.
Talvez não chamasse de OSINT.
Talvez não conhecesse a sigla.
Talvez jamais tivesse usado a expressão Open Source Intelligence.
Mas fazia algo muito parecido.
Ele observava.
Guardava informações.
Entendia pessoas.
Percebia relações.
Sabia quem mandava.
Sabia quem obedecia.
Sabia como as pessoas falavam.
Sabia quando alguém estava distraído.
Sabia que contexto vale tanto quanto tecnologia.
E, acima de tudo, entendia uma coisa que continua verdadeira em 2026:
antes de atacar um sistema, descubra como o sistema pensa.
Bem-vindo ao quarto episódio de:
SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula
Hoje nosso alvo não é uma vulnerabilidade.
É uma organização inteira vista de fora.
🔴 Red Team não começa com nmap
Existe uma imagem muito confortável do atacante.
Ele abre o terminal.
Digita:
nmap -sV -O target
E pronto.
A aventura começa.
Só que, em operações reais, muitas vezes o passo mais importante acontece antes.
Se uma pessoa específica pode aprovar determinada mudança e um atacante sabe:
quem ela é;
como fala;
quem é seu chefe;
qual projeto está correndo;
qual fornecedor participa;
temos contexto suficiente para tentar manipular o processo.
De novo:
não atacamos tecnologia.
Atacamos confiança.
🧾 Documentos públicos contam história operacional
Relatórios anuais.
Apresentações.
Case studies.
Whitepapers.
Slides de conferência.
Tudo isso pode revelar:
fornecedores;
plataformas;
migrações;
estratégias;
prioridades.
A empresa quer mostrar competência.
O Red Team vê arquitetura.
🎤 Conferências são maravilhosas
Profissionais técnicos adoram contar como resolveram problemas.
E devem.
Compartilhar conhecimento é ótimo.
Mas é preciso equilíbrio.
Um slide pode explicar exatamente:
como a empresa conecta sistemas;
quais produtos usa;
qual arquitetura adotou;
que problema ainda possui.
OSINT não significa impedir compartilhamento.
Significa compreender o que está sendo exposto.
🔵 Blue Team deveria fazer OSINT contra si mesmo
Essa é uma prática excelente.
Procure sua própria empresa.
Veja o que aparece.
Descubra:
quais e-mails;
quais documentos;
quais tecnologias;
quais nomes;
quais repositórios;
quais informações históricas.
É quase um espelho.
🧠 Pergunta simples: o atacante sabe mais sobre nós do que imaginamos?
Muitas vezes, sim.
E esse é o problema.
Funcionários internos supõem que certas informações são “internas” porque nunca foram oficialmente publicadas.
Mas talvez estejam espalhadas em 20 lugares.
🧩 Fragmentos públicos formam inteligência privada
Essa é a mágica.
Nenhum pedaço é secreto.
O conjunto, porém, revela algo que ninguém publicou diretamente.
Isso é inteligência.
🧪 Exemplo: reconstruindo um ambiente
Imagine encontrar:
Perfil 1:
Administrador z/OS.
Perfil 2:
Especialista CICS e MQ.
Vaga:
z/OS Connect + OAuth.
Postagem:
Migração de APIs concluída.
Apresentação:
Modernização de COBOL.
Você talvez infira uma arquitetura inteira.
Não certeza.
Mas hipótese forte.
🚪 O atacante então escolhe a porta
Talvez não ataque o mainframe.
Pode atacar:
pipeline;
API;
desenvolvedor;
fornecedor;
Help Desk;
credencial.
Reconhecimento serve para escolher caminho barato.
Atacantes são econômicos.
💰 O caminho mais fácil vence
Se quebrar criptografia custa semanas e convencer alguém custa dez minutos, adivinhe o que será tentado primeiro.
Essa é uma verdade simples.
Segurança gosta de imaginar atacantes apaixonados pela tecnologia.
Atacantes gostam de eficiência.
Ferris também.
🎩 Criatividade adversarial é combinar banalidades
Uma lista de funcionários não é exploit.
Uma vaga não é exploit.
Uma foto não é exploit.
Um PDF não é exploit.
Mas:
FUNCIONÁRIO
+
PROJETO
+
TECNOLOGIA
+
HORÁRIO
+
AUTORIDADE
pode virar pretexto.
O exploit está na combinação.
🚨 “Mas tudo isso é público”
Exatamente.
Esse é o ponto.
OSINT trabalha com o que está disponível.
O problema não é necessariamente que algo foi “vazado”.
É que informações legítimas podem ser correlacionadas.
🧠 Segurança não deve virar paranoia
Também é importante não enlouquecer.
Não dá para esconder todos os funcionários.
Apagar LinkedIn.
Parar conferências.
Proibir GitHub.
Isso seria absurdo.
A meta é entender risco.
Separar o que pode ser público do que adiciona risco desnecessário.
🧭 Classificação ajuda
Pergunte:
isso precisa ser público?
isso revela tecnologia crítica?
isso revela arquitetura?
isso entrega nomes internos?
isso ajuda um atacante a construir pretexto?
Às vezes a resposta será:
sim, vale o risco.
Tudo bem.
Segurança é gestão de risco, não invisibilidade total.
🦖 Mainframe e falsa sensação de isolamento
Em ambientes mainframe, vejo uma armadilha mental clássica:
“Nosso z/OS não está exposto.”
Ótimo.
Mas:
quem administra?
como desenvolve?
como faz deploy?
quais APIs chegam?
quais fornecedores acessam?
quais ferramentas integram?
O mainframe pode estar isolado.
O ecossistema não.
🔐 RACF aparece no LinkedIn também
Um profissional publica:
“Especialista RACF.”
Outro:
“Responsável por IAM no z/OS.”
Agora sabemos quem entende identidade.
Isso não é motivo para esconder carreira.
Mas mostra como pessoas fazem parte da superfície de informação.
🤖 Agentes de IA podem acelerar coleta
Ferris moderno poderia pedir:
“Liste tecnologias usadas por esta organização a partir de fontes públicas.”
Em minutos, teria resumo.
Isso democratiza capacidade de reconhecimento.
Mais uma razão para organizações entenderem sua pegada digital.
🛡️ Defesa começa conhecendo sua própria pegada
Um Blue Team deveria periodicamente perguntar:
o que existe sobre nós?
o que alguém pode inferir?
quais dados estão desatualizados?
quais documentos ainda estão indexados?
quais repositórios ficaram públicos?
quais contas antigas continuam ativas?
Essa higiene reduz surpresa.
☕ A pergunta Bellacosa
Eu colocaria esta na parede:
“Se eu fosse um atacante e tivesse apenas internet, o que conseguiria aprender sobre nós em uma tarde?”
Essa pergunta vale ouro.
Talvez a resposta seja:
mais do que você gostaria.
🎬 Ferris não precisava do Google
Ferris conhecia seu ambiente porque vivia nele.
Observava.
Conectava pontos.
Entendia comportamento.
Hoje temos ferramentas infinitamente melhores.
Mas muitos continuam cometendo o mesmo erro:
coletam dados e não entendem contexto.
Ferris faria o contrário.
Poucos dados.
Boa interpretação.
🧠 Reconhecimento é reduzir incerteza
Essa talvez seja a melhor definição.
Antes do recon:
você não sabe nada.
Depois:
sabe quem;
sabe o quê;
sabe quando;
sabe como;
sabe relações.
Isso reduz incerteza.
E aumenta eficiência.
🔴 Red Team começa com perguntas
Não com ferramentas.
Perguntas.
Quem trabalha aqui?
Quem manda?
Quem confia em quem?
Como as pessoas falam?
Que sistemas utilizam?
Quando estão distraídas?
Essas perguntas parecem humanas demais para cybersecurity.
E justamente por isso são poderosas.
☕ Epílogo: Rooney estava na superfície de ataque
O diretor Rooney não era servidor.
Não tinha endereço IP.
Não escutava na porta 443.
Mas fazia parte do sistema.
Seu cargo.
Seu comportamento.
Sua autoridade.
Sua obsessão.
Tudo isso era informação.
Ferris sabia.
E essa é a lição.
Uma organização não é apenas:
servidores;
firewalls;
APIs;
mainframes.
É também:
pessoas;
relações;
hábitos;
linguagem;
rotinas;
expectativas.
OSINT transforma tudo isso em mapa.
Então, antes de abrir o terminal, faça o que Ferris faria.
Olhe ao redor.
Escute.
Leia.
Conecte.
E pergunte:
“Quem conhece o diretor Rooney?”
Porque talvez você descubra que a porta mais importante da empresa não aparece no nmap.
Ela aparece no organograma.
☕ SAVE FERRIS.
No próximo artigo:
Cameron, Atenda o Telefone — Social Engineering as a Service
Porque Ferris nunca foi perigoso sozinho.
O verdadeiro poder estava na cadeia.
☕ Um Café no Bellacosa Mainframe — Especial Red Team
SAVE FERRIS — Ferris Bueller’s Red Team
Uma série de 12 artigos sobre Red Team, segurança ofensiva,
engenharia social, OSINT, integridade de dados, MFA, PAM,
rollback, Blue Team, inteligência artificial, RACF e z/OS,
usando Ferris Bueller para explorar uma pergunta fundamental:
o sistema está realmente seguro ou apenas acredita que está?
Red Team
OSINT
Engenharia Social
Blue Team
MFA
PAM
IA Generativa
RACF
z/OS
Mainframe
1
Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team
Reconhecimento, criatividade adversarial e a ideia de que
o verdadeiro alvo nem sempre é a tecnologia:
são as suposições de quem construiu o sistema.
Red Team • Recon • Threat Modeling • Criatividade Adversarial
Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade
Integridade de dados, alteração de registros, privilégio,
auditoria e a perigosa diferença entre aquilo que aconteceu
e aquilo que o banco de dados afirma ter acontecido.
Integridade • Db2 • Auditoria • Insider Threat • Dados
Cameron, Atenda o Telefone — Social Engineering as a Service
Ferris → Cameron → telefone → escola → funcionário → sistema.
Nenhuma peça precisa falhar sozinha quando a cadeia inteira
possui uma combinação explorável de confiança.
Social Engineering • Swiss Cheese Model • Human Risk
O Diretor Rooney Está Procurando Malware no Lugar Errado
Firewall, SIEM, EDR e Zero Trust podem funcionar perfeitamente
enquanto engenharia social, Help Desk e processos humanos
criam outro caminho até o objetivo.
Privilégio, acesso físico, MFA, PAM, least privilege e o risco
de proteger um ativo crítico apenas com medo, confiança
e a esperança de que ninguém ousará tocá-lo.
Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup
Rollback, restore, journaling, logs, Db2, VSAM e recuperação:
voltar o estado de um sistema não significa apagar
as consequências daquilo que aconteceu.
“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora
Red Team não termina em “conseguimos entrar”.
Ataque deve gerar descoberta, evidência, correção,
detecção e aprendizado para deixar a organização mais resiliente.
Red Teaming • Purple Team • Detection • Resilience • Learning
Ferris Bueller’s Red Team: Como Hackear o Sistema
Sem Precisar Roubar a Ferrari do Cameron
reúne os doze episódios e conecta Red Team,
engenharia social, IA, Blue Team e segurança de mainframe.
A série SAVE FERRIS, publicada no
Bellacosa Mainframe, utiliza situações inspiradas
em Ferris Bueller para explicar conceitos de
Red Team, cybersecurity, segurança ofensiva,
engenharia social, OSINT, Blue Team, Purple Team,
Zero Trust, MFA, PAM, inteligência artificial,
RACF, IBM z/OS, CICS, Db2, MQ e segurança de mainframe.
O fio condutor é simples: um atacante não precisa necessariamente
quebrar a tecnologia. Ele pode explorar relações de confiança,
processos, identidades, privilégios, integrações e suposições
existentes entre pessoas e sistemas.
A temporada acompanha o ciclo completo:
reconhecimento → engenharia social → acesso →
privilégio → impacto → detecção → correção → aprendizado.
Para Red Teams e Blue Teams, o objetivo final não é provar
quem é mais inteligente, mas encontrar caminhos invisíveis
antes que um adversário real os descubra.
Bellacosa Mainframe e 20 laboratorios praticos para z/os connect
☕ O Holocron do IBM z/OS Connect
Durante muitos anos, um programador COBOL precisava dominar JCL, CICS, DB2, VSAM e as ferramentas tradicionais do IBM Z para construir aplicações robustas. Hoje, entretanto, o mercado exige um novo conjunto de habilidades: integrar sistemas legados ao universo das APIs, aplicações móveis, microsserviços, cloud e Inteligência Artificial. É exatamente nesse cenário que o IBM z/OS Connect Enterprise Edition (z/OS Connect EE) se torna uma das tecnologias mais importantes da plataforma IBM Z.
Esta sequência de 20 laboratórios foi desenvolvida seguindo uma metodologia de aprendizado progressivo, inspirada no conceito de "Padawan". Cada laboratório apresenta um desafio prático que amplia gradualmente o conhecimento do desenvolvedor, começando pelos conceitos fundamentais da arquitetura do z/OS Connect, passando pela configuração do Liberty Server, publicação de programas COBOL como APIs REST, integração com CICS, IMS e DB2, segurança com RACF, TLS, OAuth e JWT, monitoramento, observabilidade e boas práticas de desempenho.
Ao concluir esta jornada, espera-se que o desenvolvedor seja capaz de compreender toda a arquitetura do z/OS Connect, publicar e consumir APIs com segurança, interpretar logs e métricas, diagnosticar problemas de integração e participar de projetos de modernização do IBM Z. Mais do que aprender uma ferramenta, o objetivo é formar profissionais capazes de conectar décadas de conhecimento em COBOL às arquiteturas modernas, tornando o mainframe um protagonista na era das APIs, da nuvem híbrida e dos agentes de Inteligência Artificial.
20 Laboratórios Práticos para um Padawan COBOL
Do "Hello REST" até Construir APIs Enterprise para IBM Z
Objetivo: transformar um programador COBOL tradicional em um desenvolvedor capaz de publicar, consumir, monitorar e administrar APIs utilizando o IBM z/OS Connect Enterprise Edition.
Cada laboratório foi pensado para ser executado em sequência. Ao final, o aluno terá construído uma pequena arquitetura moderna baseada em COBOL, CICS, REST, JSON, OpenAPI e observabilidade.
LAB 01 — Conhecendo o z/OS Connect
Objetivo
Entender onde o z/OS Connect fica dentro da arquitetura IBM Z.
Aprender
Liberty Server
HTTPS
JSON
REST
CICS
IMS
Batch
DB2
Exercício
Desenhar a arquitetura completa.
Cliente
↓
HTTPS
↓
Liberty
↓
z/OS Connect
↓
CICS
↓
Programa COBOL
Solução
Compreender que o z/OS Connect não substitui o COBOL.
Ele apenas traduz protocolos.
LAB 02 — Instalando o Liberty Server
Objetivo
Criar um servidor Liberty.
Exercício
Criar
ZCONN01
Subir o servidor.
Verificar:
logs
porta
servidor ativo
Solução
Servidor respondendo em HTTPS.
LAB 03 — Conhecendo o server.xml
Editar
server.xml
Identificar
features
portas
SSL
aplicações
Solução
Entender como Liberty é configurado.
LAB 04 — Explorando a estrutura USS
Navegar
/var/zosconnect
Identificar
logs
config
certificates
api archives
Solução
Compreender que grande parte da configuração fica no USS.
LAB 05 — Primeiro Hello World
Criar uma API simples.
Endpoint
GET /hello
Retornar
Hello IBM Z
Solução
Primeira API publicada.
LAB 06 — Importando um Copybook COBOL
Criar
CLIENTE.cpy
Importar utilizando o Toolkit.
Solução
Gerar automaticamente o JSON Schema.
LAB 07 — Gerando OpenAPI
Gerar documentação Swagger.
Verificar
GET
POST
parâmetros
responses
Solução
Publicação da documentação automática.
LAB 08 — Expondo um Programa COBOL
Programa
CONSCLI
Recebe
ID
Retorna
Nome
Saldo
Cidade
Solução
Transformar em API REST.
LAB 09 — Testando com Postman
Executar
GET
POST
PUT
DELETE
Visualizar
Headers
Body
Status HTTP
Solução
Validar comunicação.
LAB 10 — Debug de JSON
Gerar erros
Campo inexistente
Formato inválido
Número onde deveria existir texto
Solução
Interpretar mensagens BAQRxxxx.
LAB 11 — Segurança com RACF
Criar usuário.
Criar grupo.
Configurar autenticação.
Solução
Acesso protegido.
LAB 12 — HTTPS e Certificados
Criar
Keyring
Certificado
Handshake TLS
Solução
API funcionando via HTTPS.
LAB 13 — OAuth e JWT
Adicionar autenticação.
Testar token.
Validar expiração.
Solução
API segura.
LAB 14 — Chamando DB2
Programa COBOL consulta DB2.
Retorna JSON.
Solução
API consultando banco de dados.
LAB 15 — Chamando CICS
Programa
EXEC CICS LINK
Publicar via REST.
Solução
Primeira integração CICS.
LAB 16 — Consumindo APIs Externas
Usar API Requester.
Consumir
CEP
Clima
Cotação
Receber JSON.
Enviar ao COBOL.
Solução
COBOL consumindo REST.
LAB 17 — Performance
Executar
100
500
1000
5000
requisições.
Medir
CPU
Response Time
TPS
Heap Java
Solução
Descobrir gargalos.
LAB 18 — Monitoramento
Consultar
SMF
RMF
messages.log
trace.log
/health
/metrics
Solução
Criar dashboard.
LAB 19 — Tratamento de Erros
Simular
CICS indisponível
DB2 parado
MQ indisponível
Timeout
JSON inválido
Certificado expirado
Solução
Aprender troubleshooting.
LAB 20 — Projeto Final Enterprise
Construir uma API bancária.
Endpoints
GET /clientes
GET /clientes/{id}
POST /clientes
PUT /clientes
DELETE /clientes
GET /saldo
POST /transferencia
GET /extrato
GET /pix
GET /limite
Backend
COBOL
↓
CICS
↓
DB2
↓
z/OS Connect
↓
REST
↓
Postman
↓
Swagger
↓
OpenAPI
↓
Grafana
↓
OpenTelemetry
Solução
Projeto completo pronto para produção.
Desafios Extras (Modo Mestre Jedi)
Publicar múltiplas versões da mesma API (v1 e v2).
Implementar paginação, filtros e ordenação.
Criar políticas de Rate Limiting e CORS.
Integrar com IBM API Connect para gerenciamento do ciclo de vida das APIs.
Instrumentar a aplicação com OpenTelemetry e visualizar traces em Grafana.
Consumir a API por uma aplicação React, Angular ou Flutter.
Configurar CI/CD com Git, Jenkins ou GitHub Actions para publicação automática.
Criar um serviço que transforme dados EBCDIC em UTF-8.
Implementar autenticação via JWT com RACF.
Expor um programa COBOL que utiliza VSAM KSDS.
Criar um API Requester para consumir um serviço de IA (LLM) e retornar a resposta para um programa COBOL.
Desenvolver uma API que converta um Copybook COBOL em JSON e vice-versa.
Medir throughput, latência e uso de CPU sob diferentes cargas utilizando ferramentas de benchmark.
Resultado Esperado
Ao concluir os 20 laboratórios, o Padawan COBOL terá desenvolvido competências para:
Compreender profundamente a arquitetura do IBM z/OS Connect EE.
Publicar programas COBOL, CICS, IMS e Batch como APIs REST.
Consumir APIs externas diretamente do IBM Z.
Trabalhar com JSON, OpenAPI e Swagger.
Configurar Liberty Server, SSL/TLS, RACF e autenticação JWT/OAuth.
Diagnosticar erros utilizando logs, códigos BAQR, SMF e métricas.
Monitorar APIs com OpenTelemetry, Grafana e ferramentas de observabilidade.
Aplicar boas práticas de performance, segurança, versionamento e governança.
Integrar aplicações legadas com arquiteturas modernas de microserviços e agentes de IA.
Atuar em projetos reais de modernização IBM Z utilizando COBOL sem reescrever décadas de regras de negócio.
Ao final dessa jornada, o Padawan perceberá que o IBM z/OS Connect não substitui o legado: ele o conecta ao futuro, permitindo que programas COBOL continuem sendo protagonistas na era das APIs, da nuvem híbrida e da Inteligência Artificial.
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
