Translate

sábado, 16 de julho de 2022

Leadale no Daichi nite: O Sysprog que Voltou ao Ambiente de Produção Após 200 Anos — A Lição Definitiva sobre Sistemas Legados, Alta Disponibilidade e Evolução sem Administradores

 

Bellacosa Mainframe e o fantastico leadale no daichi nite

☕ Um Café no Bellacosa Mainframe

Leadale no Daichi nite (リアデイルの大地にて): O Sysprog que Voltou ao Ambiente de Produção Após 200 Anos — A Lição Definitiva sobre Sistemas Legados, Alta Disponibilidade e Evolução sem Administradores

"Existe uma fantasia comum entre profissionais de TI: encontrar um sistema perfeito. Leadale mostra algo muito mais interessante. Um sistema que continuou funcionando por dois séculos depois que seus administradores desapareceram."


Ficha Técnica

Título original: リアデイルの大地にて (Leadale no Daichi nite)

Título internacional: In the Land of Leadale

Autor (Light Novel): Ceez

Ilustrador: Tenmaso

Web Novel: 2010

Light Novel: Janeiro de 2019

Mangá: 2019

Anime: Janeiro de 2022

Estúdio: Maho Film

Direção: Yuji Yanase

Música: Kujira Yumemi

Episódios: 12

Gênero:

  • Isekai

  • Fantasia

  • Slice of Life

  • Aventura

  • Comédia

  • MMORPG

  • Slow Life

Classificação indicativa aproximada:
14 anos


Sinopse

Keina Kagami vive presa a uma cama de hospital devido às sequelas de um grave acidente. Seu único contato com o mundo exterior acontece através de um VRMMORPG chamado Leadale, onde controla Cayna, uma High Elf extremamente poderosa.

Após uma falha no equipamento que a mantém viva, Keina acredita ter morrido. Entretanto, desperta dentro do universo de Leadale.

Só que existe um detalhe inesperado.

Não é exatamente o mesmo jogo.

Duzentos anos se passaram.

As cidades mudaram.

Os reinos desapareceram.

Os NPCs construíram civilizações.

Os jogadores sumiram.

O mundo evoluiu sozinho.

Ela acorda como uma espécie de administradora esquecida observando um ambiente que continuou funcionando sem manutenção durante séculos.


Resumo da História

Ao contrário da maioria dos isekais, Leadale praticamente elimina o conflito tradicional.

Não existe um Rei Demônio.

Não há torneios.

Não existe uma guerra permanente.

O objetivo da protagonista é simplesmente...

...entender o que aconteceu.

Cada episódio representa uma descoberta:

  • antigas torres do jogo;

  • antigos sistemas mágicos;

  • NPCs que evoluíram;

  • filhos adotivos criados por eventos do jogo;

  • itens lendários esquecidos;

  • tecnologias antigas.

É uma jornada de redescoberta.


O Grande Diferencial

Grande parte dos isekais utiliza esta fórmula:

protagonista fraco → treinamento → evolução → salvar o mundo.

Leadale faz exatamente o contrário.

Cayna começa absurdamente poderosa.

Ela praticamente já terminou o jogo.

O anime pergunta:

"O que acontece quando alguém com privilégios administrativos retorna depois que ninguém mais lembra como o sistema foi construído?"

Essa mudança altera completamente o foco da narrativa.


A História Sob a Ótica Bellacosa Mainframe

Imagine um ambiente IBM Z.

Em 1985 um time desenvolveu um gigantesco sistema bancário.

Os desenvolvedores se aposentaram.

Os operadores mudaram.

As empresas mudaram.

Os bancos foram comprados.

Os analistas morreram.

Mas...

o sistema nunca parou.

Quarenta anos depois chega alguém que participou da implantação original.

Essa pessoa lembra:

  • onde ficam os módulos antigos;

  • quais parâmetros nunca devem ser alterados;

  • por que determinado JOB existe;

  • quem criou aquele catálogo;

  • como restaurar uma base perdida.

Essa pessoa é Cayna.

Ela conhece absolutamente tudo.

Os habitantes enxergam magia.

Ela enxerga arquitetura.


Cayna é praticamente um Sysprog

Na visão Bellacosa Mainframe, Cayna possui privilégios equivalentes a:

  • RACF SPECIAL

  • STORAGE ADMIN

  • SECURITY ADMIN

  • OPERATOR

  • APPLICATION OWNER

  • DATABASE ADMIN

Tudo ao mesmo tempo.

Ela conhece comandos que ninguém mais conhece.

Possui itens que ninguém consegue reproduzir.

Acessa áreas proibidas.

Entra em estruturas antigas.

É literalmente uma administradora do ambiente.


Os Personagens

Cayna

Extremamente poderosa.

Mas nunca arrogante.

Ela prefere resolver problemas pequenos.

Ajuda aldeões.

Conserta pontes.

Ensina magia.

Cuida das pessoas.

Seu verdadeiro poder é emocional.


Skargo

Sacerdote.

Filho adotivo de Cayna.

Provavelmente um dos personagens mais engraçados da série.

Seu excesso de reverência produz várias situações cômicas.


Mai-Mai

Diretora da Academia.

Especialista em magia.

Apesar da aparência elegante, possui personalidade extremamente imprevisível.


Kartatz

Anão.

Construtor.

É o mais racional dos três filhos.

Representa estabilidade.


Os NPCs

Talvez o aspecto mais interessante.

Eles deixaram de agir como personagens de jogo.

Agora possuem história própria.

Memórias.

Famílias.

Objetivos.

É como observar uma IA evoluindo por séculos.


Aventuras

Cada aventura serve mais para explorar o mundo do que para criar tensão.

Entre elas:

  • exploração das torres antigas;

  • reencontro com antigos conhecidos;

  • investigação sobre os Guardiões;

  • resolução de conflitos locais;

  • ajuda a comerciantes;

  • descoberta de ruínas;

  • visitas às cidades reconstruídas;

  • compreensão da nova política mundial.

É um anime onde viajar importa mais do que lutar.


Temáticas

Segunda oportunidade

Keina teve uma vida extremamente limitada.

Leadale oferece aquilo que ela nunca teve.

Liberdade.


Solidão

Ela percebe que todos os jogadores desapareceram.

É possivelmente a última sobrevivente daquela geração.

Existe uma melancolia silenciosa em diversos episódios.


Tempo

O tempo muda tudo.

Pessoas.

Cidades.

Civilizações.

Mesmo aquilo que parecia permanente desaparece.


Família

Os filhos adotivos nasceram como mecânica do jogo.

Agora são pessoas reais.

Isso gera uma discussão interessante:

Quando uma inteligência artificial deixa de ser apenas código?


Legado

Nenhum criador permanece para sempre.

Mas sua obra continua.


Mensagens Ocultas

Todo sistema evolui

Mesmo sem seus desenvolvedores.

Essa talvez seja a maior metáfora da série.


O conhecimento desaparece

As torres que Cayna construiu agora são ruínas.

Ninguém lembra sua finalidade.

É exatamente o que acontece em sistemas legados.

A documentação some.

Os especialistas se aposentam.

As novas gerações apenas utilizam.


Poder não significa responsabilidade

Embora tenha poder absoluto, Cayna evita interferir no destino das pessoas.

Ela entende que um bom administrador modifica apenas aquilo que realmente precisa ser modificado.

É uma filosofia muito próxima da administração de ambientes críticos.


O Estúdio Maho Film

A Maho Film nunca esteve entre os gigantes da indústria como Kyoto Animation, MAPPA, ufotable ou Bones.

Mesmo assim tornou-se conhecida por adaptar obras de fantasia confortável (iyashikei fantasy).

Outras produções incluem:

  • I'm Standing on a Million Lives

  • The World's Finest Assassin Gets Reincarnated in Another World as an Aristocrat

  • Kami-tachi ni Hirowareta Otoko (By the Grace of the Gods)

Sua principal característica é priorizar personagens simpáticos, cenários acolhedores e uma narrativa relaxante em vez de grandes sequências de ação. Em Leadale, essa abordagem combina perfeitamente com a proposta da obra.


Qualidade da Animação

Visualmente, Leadale não impressiona pela complexidade técnica.

As batalhas são simples.

Os efeitos mágicos são competentes.

Os cenários cumprem seu papel.

O verdadeiro destaque está na direção de arte.

As cidades parecem realmente habitadas.

A iluminação transmite conforto.

A trilha sonora reforça constantemente a sensação de aventura tranquila.

É um anime feito para relaxar.


Impacto Cultural

Leadale não foi um fenômeno como Sword Art Online, Overlord ou Mushoku Tensei.

Ainda assim consolidou um subgênero cada vez mais popular:

o Slow Life Isekai.

Nele, o foco deixa de ser "salvar o mundo" e passa a ser viver nele. Esse estilo influenciou e caminhou ao lado de obras como By the Grace of the Gods, I've Been Killing Slimes for 300 Years and Maxed Out My Level e Farming Life in Another World, mostrando que o público também aprecia histórias de conforto, convivência e reconstrução.


Houve censura?

Não houve registros relevantes de censura durante sua exibição no Japão ou em lançamentos internacionais.

Isso ocorre porque:

  • violência moderada;

  • praticamente nenhuma cena de gore;

  • fan service discreto;

  • linguagem leve;

  • ausência de temas políticos sensíveis.

A adaptação do anime também permaneceu bastante fiel ao tom da light novel, realizando apenas cortes naturais para condensar a história em 12 episódios, sem alterações motivadas por censura.


Curiosidades

  • O nome "Leadale" deriva da combinação de elementos ligados ao mundo virtual criado para o jogo.

  • Os "filhos" de Cayna eram originalmente um recurso do MMORPG, mas o salto temporal faz com que se tornem indivíduos completos, criando situações tão emocionantes quanto divertidas.

  • O conceito de um mundo persistente por séculos sem jogadores lembra a ideia de servidores que continuam ativos mesmo após o abandono de seus administradores.


Veredicto Bellacosa Mainframe

Se Overlord representa um superusuário assumindo o controle de um datacenter abandonado, Leadale no Daichi nite mostra algo ainda mais raro: o retorno da arquiteta original ao ambiente de produção depois de dois séculos de operação contínua.

Cayna não precisa provar sua força. Seu verdadeiro desafio é compreender como um sistema complexo evoluiu sem seus administradores, preservando serviços, criando novas regras de negócio e formando uma sociedade inteira sobre a infraestrutura que ela ajudou a construir.

Para quem trabalha com IBM Z, COBOL, CICS, DB2 ou z/OS, a metáfora é irresistível. Quantos sistemas corporativos permanecem em operação há décadas, sustentando milhões de transações, enquanto seus criadores já se aposentaram? Assim como Cayna, o especialista em mainframe frequentemente retorna a um ambiente vivo, onde o código original foi expandido por inúmeras gerações de desenvolvedores.

No fim, Leadale no Daichi nite deixa uma mensagem poderosa: o software pode sobreviver aos seus autores, mas o conhecimento sobre sua arquitetura é o verdadeiro tesouro. Em um mundo de tecnologia em constante mudança, preservar esse conhecimento é tão importante quanto manter o sistema funcionando. É uma lição que vale tanto para um reino de fantasia quanto para qualquer ambiente IBM Z que continua processando negócios críticos décadas após sua implantação.


sexta-feira, 15 de julho de 2022

☕💥 A Jornada do Sysprog Padawan – ACEE : Anatomia do Crachá Mágico do Reino IBM Z - Parte II

 

Bellacosa Mainframe apresenta o ACEE Parte II

☕💥 A Jornada do Sysprog Padawan – Parte 2

ACEE – Anatomia do Crachá Mágico do Reino IBM Z

O que realmente existe dentro de um ACEE?

"Todo Sysprog olha para um dump. O Sysprog Jedi conversa com os control blocks."

Bellacosa Mainframe


Introdução

Na Parte 1 descobrimos que o ACEE é praticamente o crachá encantado do Reino IBM Z.

Mas afinal...

O que existe dentro dele?

Ele possui apenas o userid?

Possui senha?

Está criptografado?

Pode ser alterado?

Quem consegue enxergá-lo?

Quanto espaço ocupa?

É isso que vamos explorar.


Antes de tudo

O ACEE é um Control Block do RACF.

Ele é criado em memória.

Não é VSAM.

Não é DB2.

Não é Dataset.

Não é USS File.

Ele simplesmente nasce, vive durante a sessão e desaparece ao final dela.


Onde mora o ACEE?

Depende.

Pode estar associado a:

TCB

Task Control Block


ASCB

Address Space Control Block


SRB

Service Request Block


OMVS Process


DB2 Thread


CICS Task


IMS Region


Started Task


Anatomia simplificada

Podemos imaginar o ACEE como uma estrutura lógica.

+--------------------------------+
| ACEE HEADER                    |
+--------------------------------+
| USERID                         |
+--------------------------------+
| GROUPS                         |
+--------------------------------+
| SPECIAL FLAGS                  |
+--------------------------------+
| UID / GID                      |
+--------------------------------+
| CERTIFICATES                   |
+--------------------------------+
| MFA                            |
+--------------------------------+
| SECURITY LABELS                |
+--------------------------------+
| CUSTOM ATTRIBUTES              |
+--------------------------------+
| POINTERS                       |
+--------------------------------+

Naturalmente a IBM não documenta tudo detalhadamente para programação de aplicações comuns.

Mas Sysprogs adoram estudar essas estruturas.


Campo 1 — USERID

O mais conhecido.

Exemplo

VBELLACO

Pode possuir até oito caracteres.


Ele representa:

Quem você é.


Mas atenção.

Senha NÃO fica armazenada.


Passphrase também não.


Hash de senha também não.


Segurança agradece.


Campo 2 — Nome do Grupo

Exemplo

SYS1

ou

MQADMIN

Grupo primário.


Grupo conectado.


Grupo default.


Campo 3 — Connected Groups

Pode haver dezenas.

Exemplo

DBA

SYSOPER

MQADM

IMSADM

DEVOPS

SECURITY

Essas informações permitem decisões rápidas.


Sem voltar ao banco RACF.


Campo 4 — Special Attributes

Muito importante.


Flag SPECIAL

Administrador.


OPERATIONS

Super usuário RACF.


AUDITOR

Auditoria.


CLAUTH

Gerencia Classes.


ROAUDIT

Read-only.


Curiosidade Bellacosa ☕

SPECIAL é praticamente:

A chave mestra do castelo.


OPERATIONS

É o passe VIP.


AUDITOR

É o fiscal do reino.


Campo 5 — OMVS Segment

Chegamos ao USS.


UID

Exemplo

1000

GID

100

HOME

/u/vbellaco

PROGRAM

/bin/sh

Campo 6 — Certificados

Muito usado hoje.


Digital Certificate


PKI


TLS


SSH


MQ


zOS Connect


API Gateway


Open Banking


PIX


Pode existir referência ao certificado associado ao usuário.


Campo 7 — MFA

Nos ambientes modernos.


RSA


TOTP


Smartcard


Passkey


FIDO


Token Context


Campo 8 — Labels

Pouco utilizados.

Mas interessantes.


MLS

Mandatory Access Control


Exemplos

PUBLIC


CONFIDENTIAL


SECRET


TOPSECRET

Muito comum em:

Defesa

Governo

Militar


Campo 9 — ACEE Tokens

Pouco comentado.

Muito poderoso.


Permitem passar contexto.


CICS utiliza.


DB2 utiliza.


MQ utiliza.


Subsystems utilizam.


Cross-memory utiliza.


Campo 10 — Ponteiros

Sysprog gosta.


Ponteiro para:

TCB

ASCB

Groups

Security Labels

OMVS

Certificates


É um verdadeiro mini ecossistema.


Quanto memória consome?

Pergunta clássica.


Resposta curta.

Depende.


Usuário simples

Alguns KB.


Usuário com muitos grupos

Mais.


Certificados

Mais.


MFA

Mais.


Custom Attributes

Mais.


Na prática.

Centenas.

Milhares.

De ACEEs.

Não representam um problema.


O impacto em CPU

Muito pequeno.


Comparado ao custo de consultar RACF.


ACEE economiza:

CPU

I/O

Locks

ENQ

Contention


Em um banco.

100 mil sessões.

Economia enorme.


z/OS 3.1

Novidade interessante.


Custom Fields.


Permitem aplicações modernas.

Consultar contexto.


Sem voltar ao RACF.


Menos latência.


Menos I/O.


Mais escalabilidade.


O que NÃO existe no ACEE?

Senha.


Passphrase.


Hash.


Histórico.


Dataset profiles.


Banco RACF completo.


Quem pode enxergar um ACEE?

Usuário comum?

Não.


COBOL?

Normalmente não.


Sysprog?

Sim.


IPCS

Sim.


Dumps

Sim.


Ferramentas IBM

Sim.


IPCS

Nosso sabre de luz.


Dump

IPCS

VERBX

Interpretar ACEE


Ferramentas comerciais ajudam bastante.


zSecure


Security Server utilities


IBM Support Tools


Easter Egg Bellacosa ☕

Se você abrir um dump e encontrar:

TCB

ASCB

ACEE

UID

SPECIAL

CERT


Parabéns.

Você acabou de entrar no clube dos Sysprogs que começam a conversar com os control blocks.


Analogia Bellacosa

Imagine novamente o castelo.


No crachá mágico existem:

Nome

Guilda

Permissões

Passaporte

Cartão diplomático

Etiqueta de segurança

Passe do metrô USS

Certificado digital

Token MFA


Tudo em um único objeto.


E o melhor.

O guarda SAF apenas olha para ele.


Não precisa voltar ao cartório RACF.


Economizando tempo.

CPU.

E trabalho.


Resumo para guardar

CampoFunção
USERIDIdentidade
GROUPSGrupos
SPECIALAdministração
UIDUSS
GIDUSS
CERTTLS
MFAAutenticação
LABELMLS
TOKENContexto
POINTERSLigações internas

☕💥 Continua na Parte 3

O Nascimento do ACEE

Como ele é criado no TSO, CICS, IMS, Batch, Started Tasks, USS, MQ e DB2, incluindo RACROUTE VERIFY, SAF, FASTAUTH, diagramas passo a passo e exemplos reais de fluxo de autenticação.


quinta-feira, 14 de julho de 2022

☕💥 Arrays em COBOL: O Poder Oculto do OCCURS, SSRANGE e a Guerra Contra a Invasão de Memória

 

Bellacosa Mainframe e as tabelas internas no COBOL occurs e arrays

☕💥 Arrays em COBOL: O Poder Oculto do OCCURS, SSRANGE e a Guerra Contra a Invasão de Memória

Ou como evitar transformar seu Address Space em um filme de terror para Sysprogs



Introdução

Existe um momento na vida de todo desenvolvedor COBOL júnior em que ele descobre duas verdades universais:

A primeira é que OCCURS parece simples até deixar de ser simples.

A segunda é que existe uma entidade maligna chamada:

SSRANGE

capaz de transformar uma manhã tranquila em uma reunião emergencial envolvendo desenvolvimento, suporte, infraestrutura, DBA, operador e um sysprog segurando uma caneca de café já fria.

E tudo isso por causa de um pequeno detalhe:

MOVE WS-NOME(9999)

quando a tabela possui apenas:

OCCURS 100 TIMES.

Bem-vindo ao fascinante mundo das tabelas COBOL.


Capítulo 1 – O que é OCCURS?

OCCURS é o mecanismo utilizado pelo COBOL para criar estruturas repetitivas.

Em linguagens modernas chamaríamos isso de:

  • Array

  • Vetor

  • Lista fixa

  • Matriz

Exemplo:

01 CLIENTES.

   05 CLIENTE OCCURS 10 TIMES.

      10 NOME PIC X(30).
      10 IDADE PIC 99.

Memória:

CLIENTE(1)
CLIENTE(2)
CLIENTE(3)
...
CLIENTE(10)

COBOL simplesmente reserva um bloco contínuo.


A origem histórica

Década de 60.

Memória era absurdamente cara.

IBM 1401

4 KB

IBM System/360

256 KB

370

1 MB

Não existia:

  • Java Collections

  • Python List

  • C++ Vector

Era necessário reservar memória antecipadamente.

Daí nasceu:

OCCURS

Curiosidade histórica

Os engenheiros da IBM chamavam essas estruturas de:

Table Handling

Muito antes da expressão Array Processing se popularizar.


Capítulo 2 — Como a memória é organizada

Exemplo:

01 TAB.

   05 ITEM OCCURS 5 TIMES.

      10 CODIGO PIC 9(5).

Cada item ocupa:

5 bytes

Total

25 bytes

Layout:

0000 ITEM(1)
0005 ITEM(2)
0010 ITEM(3)
0015 ITEM(4)
0020 ITEM(5)

Acesso:

MOVE ITEM(3) TO WS-X

COBOL faz:

Base + ((3-1)*5)

Capítulo 3 – O Terror do Out of Bounds

Tabela:

05 CLIENTE OCCURS 100 TIMES.

Código:

MOVE NOME(101)

Problema.

A posição não existe.


Antigamente

Compilador:

NOSSRANGE

Padrão.

Nenhuma verificação.

Resultado:

Leitura aleatória.

Sobrescrever memória.

Corrupção.


O verdadeiro vilão

Imagine:

01 TABELA.

05 DADOS OCCURS 100 TIMES.

05 FLAG-FINAL PIC X.

Erro:

MOVE "S" TO DADOS(101)

Na prática:

FLAG-FINAL = S

ou pior.

Modifica outra estrutura.


Isso é invasão de memória?

Sim.

Tecnicamente:

Buffer overflow

Memory overwrite

Storage corruption


Capítulo 4 — Address Space

No zOS cada Job possui.

Address Space.

Exemplo

JOB1234



Private Area


LSQA


SWA


Subpools


Heap


Stack

Seu programa COBOL vive ali.


Se escrever fora da tabela:

pode corromper:

Working Storage

Heap

LE Runtime

Control Blocks


Em casos extremos:

S0C4

S878

U4038


Capítulo 5 — SSRANGE

A melhor invenção desde o café expresso.

Compilação:

SSRANGE

ou

CBL SSRANGE

Exemplo

MOVE WS-NOME(101)

Resultado:

Abend imediato.

Mensagem:

IGZxxxx

Subscript out of range


Excelente para:

Homologação

Teste

QA


Produção?

Normalmente:

NOSSRANGE

Performance melhor.


Dica Bellacosa

Desenvolvimento

SSRANGE

Produção

NOSSRANGE


Capítulo 6 — Índices

Ruim:

77 WS-I PIC 999.

Melhor:

05 CLIENTE OCCURS 100 TIMES
   INDEXED BY IDX.

SET

SET IDX TO 1

Próximo

SET IDX UP BY 1

Anterior

SET IDX DOWN BY 1

Por que índice é melhor?

Subscript:

CLIENTE(I)

Cálculo toda vez.


Index

Endereço pronto.

Ponteiro interno.

Mais rápido.


Capítulo 7 – Navegação

Crescente

SET IDX TO 1


PERFORM UNTIL IDX > MAX

PROCESSA

SET IDX UP BY 1

END-PERFORM

Decrescente

SET IDX TO MAX


PERFORM UNTIL IDX = 0


PROCESSA


SET IDX DOWN BY 1


END-PERFORM

Muito usado em:

Compressão

Ordenação

Rollback


Capítulo 8 — SEARCH

Busca sequencial.

SEARCH CLIENTE


AT END


DISPLAY "NAO ACHOU"


WHEN ID = WS-ID


DISPLAY NOME

END-SEARCH

Complexidade

O(n)


100 mil registros.

50 mil leituras médias.


SEARCH ALL

Arma secreta.

Busca binária.


Tabela obrigatoriamente ordenada.

SEARCH ALL CLIENTE


WHEN ID(IDX)=WS-ID


DISPLAY "ACHOU"

END-SEARCH

Complexidade

O(log n)


1000000 itens.

Comparações:

~20


Magia matemática.


Capítulo 9 — OCCURS DEPENDING ON

Tabela variável.

05 QTDE PIC 9(4).


05 CLIENTE OCCURS 1 TO 1000 TIMES

DEPENDING ON QTDE.

Muito usado em:

MQ

Copybooks

APIs

Arquivos


Capítulo 10 — Bidimensional

Exemplo.

Agência x Dia

05 MOVIMENTO.

10 AG OCCURS 100.

15 DIA OCCURS 31.

20 TOTAL PIC 9(10).

Uso:

TOTAL(10,15)

Agência 10.

Dia 15.


Tridimensional

ANO

MES

DIA
VENDAS(2026,6,23)

N dimensões

Teoricamente ilimitado.

Exemplo.

Banco.

País

Estado

Agência

Conta

Produto

Dia


Capítulo 11 — Ordenação

Tabela ordenada.

ASCENDING KEY

Muito útil para:

SEARCH ALL

Caches

Lookup


Capítulo 12 – Quando usar tabela

Excelente:

Parâmetros

Cache

Código UF

Tabela IR

CEP

Conversões


Ruim:

Milhões registros.


Melhor:

DB2

VSAM

IMS


Capítulo 13 – Performance

SEARCH

O(n)

SEARCH ALL

O(log n)

Index

Muito rápido

Subscript

Mais lento

SSRANGE

Seguro

NOSSRANGE

Rápido


Easter Egg COBOL

Existe uma lenda entre veteranos de mainframe.

Diz-se que em algum datacenter esquecido dos anos 80 existe um programa COBOL compilado com:

NOSSRANGE
OPT(2)
FASTSRT
ARITH(EXTEND)

executando desde 1987.

Ninguém sabe exatamente o que ele faz.

Ninguém possui o código-fonte.

Ninguém ousa recompilar.

Mas toda madrugada, às 02h17, ele produz um relatório financeiro perfeito, movimenta bilhões de dólares e desaparece novamente nas profundezas do JES2.

Os sysprogs apenas observam o spool, tomam um gole de café e repetem o antigo mantra do reino z/OS:

"Se está funcionando há 39 anos, não toque."


Conclusão

OCCURS é muito mais do que um simples array.

É uma das construções mais antigas, elegantes e eficientes já criadas para processamento em lote de grande volume.

Dominar:

  • OCCURS

  • INDEXED BY

  • SET

  • SEARCH

  • SEARCH ALL

  • SSRANGE

  • OCCURS DEPENDING ON

  • Tabelas multidimensionais

  • Navegação UP e DOWN

  • Layout de memória

  • Address Space do z/OS

é um dos marcos que separam o Padawan COBOL do Cavaleiro do Batch Jedi Council.

Porque no universo do Mainframe existe uma verdade absoluta:

"DB2 pode falhar, CICS pode reciclar, VSAM pode corromper, mas um OCCURS acessado fora dos limites sempre encontrará uma maneira criativa de arruinar o dia de alguém."

quarta-feira, 13 de julho de 2022

☕💣⏳ OS 10 ANIMES QUE HERDARAM O CÓDIGO-FONTE DE YU-NO — VIAGEM NO TEMPO, MULTIVERSOS E O DEBUG DA REALIDADE

 

Bellacosa Mainframe e animes com viagem no tempo

☕💣⏳ OS 10 ANIMES QUE HERDARAM O CÓDIGO-FONTE DE YU-NO — VIAGEM NO TEMPO, MULTIVERSOS E O DEBUG DA REALIDADE

Introdução

Existe um momento na carreira de todo profissional de tecnologia em que ele percebe uma verdade inconveniente:

Se eu pudesse voltar no tempo, teria evitado aquele erro em produção.

Quem trabalha com mainframe conhece bem essa sensação.

Um JCL enviado errado.

Um UPDATE sem WHERE.

Uma alteração em COBOL que parecia inocente.

Um restore que deveria ter sido feito antes.

Infelizmente, a vida não possui:

BACKOUT
UNDO
RESTORE POINT
GDG(-1)

Mas os animes adoram imaginar um mundo onde isso é possível.

E poucos fizeram isso de forma tão influente quanto YU-NO: A Girl Who Chants Love at the Bound of This World.

Muito antes de Steins;Gate se tornar fenômeno mundial e antes de Re:Zero transformar loops temporais em sofrimento psicológico, YU-NO já brincava com conceitos de universos paralelos, linhas temporais divergentes e consequências imprevisíveis das escolhas humanas.

Seu legado pode ser visto em dezenas de obras modernas.

Algumas herdaram o conceito de viagem temporal.

Outras exploraram o multiverso.

Outras transformaram a repetição temporal em uma ferramenta narrativa.

E algumas foram além, criando verdadeiros ambientes distribuídos de realidades alternativas.

Para um mainframeiro, essas histórias possuem um charme especial.

Cada protagonista parece um operador tentando recuperar um ambiente de produção.

Cada salto temporal lembra um restart de JOB.

Cada linha temporal parece uma geração diferente de um GDG cósmico.

E cada decisão equivocada gera um ABEND existencial.

Se você terminou YU-NO e ficou com aquela sensação de vazio pós-anime, prepare seu terminal ISPF imaginário.

A seguir estão dez obras que compartilham o DNA narrativo de YU-NO e que, de uma forma ou de outra, exploram o maior sonho da humanidade:

corrigir o passado sem derrubar o futuro.


1. STEINS;GATE

Título Original

Steins;Gate

Ano

2011

Personagem Principal

Rintarou Okabe

Sinopse

Um grupo de estudantes descobre acidentalmente uma forma de enviar mensagens para o passado.

O problema?

Cada alteração cria novas linhas temporais.

Curiosidade

É considerado por muitos o sucessor espiritual mais próximo de YU-NO.

Bellacosa Mainframe

MSG PARA O PASSADO
=
UPDATE DIRETO NA BASE DA REALIDADE

2. RE:ZERO

Título Original

Re:Zero kara Hajimeru Isekai Seikatsu

Ano

2016

Personagem Principal

Subaru Natsuki

Sinopse

Sempre que morre, Subaru retorna a um ponto anterior do tempo.

Curiosidade

Transformou o conceito de loop temporal em sofrimento psicológico.

Bellacosa Mainframe

ABEND
↓
RESTART
↓
ABEND
↓
RESTART

3. SUMMERTIME RENDER

Título Original

Summer Time Rendering

Ano

2022

Personagem Principal

Shinpei Ajiro

Sinopse

Após retornar à sua ilha natal, Shinpei descobre uma conspiração envolvendo duplicatas humanas e loops temporais.

Curiosidade

Um dos melhores animes de mistério da década de 2020.

Bellacosa Mainframe

Pense em CICS, DB2 e fantasmas rodando simultaneamente.


4. ERASED

Título Original

Boku dake ga Inai Machi

Ano

2016

Personagem Principal

Satoru Fujinuma

Sinopse

Um homem retorna à infância para impedir uma série de assassinatos.

Curiosidade

Mistura viagem temporal com suspense policial.

Bellacosa Mainframe

ROLLBACK
PARA 18 ANOS ATRÁS

5. HIGURASHI NO NAKU KORO NI

Título Original

Higurashi no Naku Koro ni

Ano

2006

Personagem Principal

Keiichi Maebara

Sinopse

Uma pequena vila esconde um ciclo de mortes que se repete continuamente.

Curiosidade

Inspirou inúmeras histórias de loops temporais.

Bellacosa Mainframe

O JES2 reiniciando o mesmo desastre infinitamente.


6. THE GIRL WHO LEAPT THROUGH TIME

Título Original

Toki wo Kakeru Shoujo

Ano

2006

Personagem Principal

Makoto Konno

Sinopse

Uma estudante adquire a capacidade de saltar no tempo.

Curiosidade

Um dos filmes mais importantes da ficção temporal japonesa.

Bellacosa Mainframe

O equivalente anime de um botão "UNDO".


7. NOEIN

Título Original

Noein: Mou Hitori no Kimi e

Ano

2005

Personagem Principal

Haruka Kaminogi

Sinopse

Universos paralelos entram em colisão.

Curiosidade

Mistura física quântica e drama adolescente.

Bellacosa Mainframe

GDGs de realidades alternativas entrando em conflito.


8. ORANGE

Título Original

Orange

Ano

2016

Personagem Principal

Naho Takamiya

Sinopse

Uma garota recebe cartas enviadas por ela mesma do futuro.

Curiosidade

Um dos romances temporais mais emocionantes dos animes.

Bellacosa Mainframe

E-mail enviado para a própria LPAR do passado.


9. RASCAL DOES NOT DREAM OF BUNNY GIRL SENPAI

Título Original

Seishun Buta Yarou wa Bunny Girl Senpai no Yume wo Minai

Ano

2018

Personagem Principal

Sakuta Azusagawa

Sinopse

Fenômenos temporais e quânticos afetam adolescentes.

Curiosidade

Apesar do título estranho, possui excelente ficção científica.

Bellacosa Mainframe

Problemas de sincronização entre ambientes emocionais.


10. LINK CLICK

Título Original

Shiguang Dailiren

Ano

2021

Personagem Principal

Cheng Xiaoshi

Sinopse

Dois jovens entram em fotografias para alterar eventos passados.

Curiosidade

Produção chinesa que surpreendeu o mundo dos animes.

Bellacosa Mainframe

BACKUP = FOTO
RESTORE = ENTRAR NELA

☕💣 Classificação Bellacosa Mainframe

AnimeViagem TemporalMultiversoMistérioNota
Steins;Gate⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐10/10
Re:Zero⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐10/10
Summertime Render⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐10/10
Erased⭐⭐⭐⭐⭐⭐⭐⭐⭐9/10
Higurashi⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐9/10
Toki wo Kakeru Shoujo⭐⭐⭐⭐⭐⭐⭐9/10
Noein⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐9/10
Orange⭐⭐⭐⭐⭐⭐8/10
Bunny Girl Senpai⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐9/10
Link Click⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐10/10

Conclusão

Se YU-NO é o mainframe ancestral do multiverso, então essas dez obras são os sistemas que herdaram seu código-fonte.

Algumas aprimoraram o mecanismo de rollback.

Outras reinventaram a navegação entre linhas temporais.

E algumas criaram arquiteturas tão complexas que fariam um arquiteto de sistemas do z/OS pedir documentação adicional.

Mas todas compartilham a mesma pergunta fundamental:

Se você pudesse reexecutar sua vida quantas vezes quisesse, em qual execução finalmente encontraria a resposta correta? ☕💣⏳


 

terça-feira, 12 de julho de 2022

☕🔥 GRAFANA — O “PAINEL DE CONTROLE DO MAINFRAME MODERNO” QUE TODO SYSPROG JÚNIOR PRECISA CONHECER 🔥☕

 

Bellacosa Mainframe Grafana o dashbord de monitoramento mainframe

☕🔥 GRAFANA — O “PAINEL DE CONTROLE DO MAINFRAME MODERNO” QUE TODO SYSPROG JÚNIOR PRECISA CONHECER 🔥☕

Se você veio do mundo do MVS, JES2, RMF, OMEGAMON, SDSF e consoles verdes, prepare o choque cultural:

O Grafana é praticamente o equivalente moderno de um:

  • “painel operacional do datacenter”
  • console visual de monitoração
  • cockpit de performance
  • RMF turbinado com esteroides gráficos

E o mais curioso?

Muita gente de distributed acha que inventou observabilidade em 2018…

Enquanto sysprog de mainframe já monitorava CPU, DASD, canais, paging e throughput quando a internet ainda fazia barulho de modem. ☕💾


☕ O QUE É GRAFANA?

O Grafana é uma plataforma open source de:

  • visualização de métricas
  • dashboards
  • monitoramento
  • observabilidade
  • alertas
  • analytics

Ele pega dados de várias fontes e transforma tudo em:

  • gráficos
  • gauges
  • tabelas
  • alertas
  • mapas
  • painéis em tempo real

☕ A ORIGEM DO GRAFANA

O Grafana nasceu em:

  • 2014
  • criado por Torkel Ödegaard
  • inicialmente na empresa brasileira-norueguesa Orbitz/Neteye
  • depois evoluiu para a empresa:

A ideia original era simples:

“Por que monitoramento corporativo precisa ser feio e complicado?”

E aí nasceu uma interface moderna, web, rápida e absurdamente flexível.


☕ HISTÓRIA E EVOLUÇÃO

☕ 2014 — Primeiros Releases

O Grafana surgiu focado em:

  • métricas do Graphite
  • dashboards simples
  • visualização web

Na época já era revolucionário.

Enquanto muita ferramenta corporativa parecia software de 1997…

Grafana parecia tecnologia “do futuro”.


☕ 2015–2018 — Explosão DevOps

Com a ascensão de:

  • Docker
  • Kubernetes
  • Cloud
  • DevOps
  • Prometheus

…o Grafana virou praticamente padrão de mercado.


☕ 2019+ — Observabilidade Total

Hoje o Grafana monitora:

  • Linux
  • Windows
  • Kubernetes
  • APIs
  • Banco de dados
  • Mainframe
  • Cloud
  • aplicações
  • logs
  • traces
  • IoT
  • IA

Sim…

Tem empresa usando Grafana para monitorar:

  • CICS
  • MQ
  • z/OS
  • Db2
  • OpenTelemetry em mainframe

O mundo deu uma volta gigantesca. ☕


☕ RELEASES IMPORTANTES

VersãoDestaque
1.xPrimeira geração
2.xDashboards melhores
4.xAlertas modernos
6.xTransformações de dados
7.xPainéis novos
8.xUnified Alerting
9.xObservabilidade forte
10.xIA + performance + cloud

☕ COMO O GRAFANA FUNCIONA?

Pense assim:

O Grafana NÃO coleta dados sozinho.

Ele funciona como:

  • “o painel”
  • “a camada visual”
  • “o cockpit”

Os dados vêm de:

  • Prometheus
  • InfluxDB
  • Elasticsearch
  • Loki
  • PostgreSQL
  • MySQL
  • APIs
  • CloudWatch
  • Splunk
  • OpenTelemetry

☕ ANALOGIA MAINFRAME

MainframeGrafana World
RMFPrometheus
OMEGAMONObservabilidade
SDSFDashboards operacionais
JES2 consoleAlerting
SMF recordsMétricas
SysviewGrafana

☕ CONCEITOS IMPORTANTES

☕ Dashboard

Tela com gráficos e indicadores.

Como um:

  • painel do OMEGAMON
  • cockpit do operador
  • monitor da sala de controle

☕ Panel

Cada gráfico individual.

Ex:

  • CPU
  • memória
  • rede
  • jobs
  • response time

☕ Data Source

Origem dos dados.

Ex:

  • Prometheus
  • Loki
  • PostgreSQL

☕ Alerting

Alarmes automáticos.

Ex:

  • CPU > 90%
  • disco cheio
  • aplicação caída

Quase um:

“$HASP250 JOB ABENDED” moderno ☕💥


☕ CURIOSIDADES QUE QUASE NINGUÉM SABE

☕ O nome “Grafana”

Veio da ideia de:

  • “graphs”
  • visualização gráfica

☕ Empresas gigantes usam

  • IBM
  • SAP
  • PayPal
  • eBay
  • bancos
  • telecoms
  • governos

☕ Existe integração com mainframe

Hoje existem exporters para:

  • z/OS
  • CICS
  • Db2
  • MQ
  • SMF

Sim…

Você pode colocar:

  • CPU do z/OS
  • fila do MQ
  • transação CICS

num dashboard moderno web.

Isso explodiria a cabeça de um operador de 1989. ☕💾


☕ EASTER EGGS E DETALHES DIVERTIDOS

☕ Dark Theme

Sysprog ama terminal escuro.

O Grafana praticamente virou:

“o ISPF cyberpunk”


☕ Playlists Automáticas

Você pode colocar dashboards rotativos em TVs.

Igual:

  • NOC
  • sala de operações
  • centro de monitoração

☕ Drill Down

Clicar num gráfico e navegar.

Quase como:

  • entrar do SDSF no job
  • depois no spool
  • depois no SYSOUT

☕ INSTALAÇÃO PASSO A PASSO (LAB)

🔥 LAB 01 — PRIMEIRO DASHBOARD NO GRAFANA


☕ OBJETIVO

Você vai:

✅ instalar Grafana
✅ acessar via browser
✅ criar datasource
✅ criar dashboard
✅ criar gráficos
✅ salvar painel
✅ fazer manutenção básica


☕ CENÁRIO

Imagine:

Você é um sysprog júnior moderno monitorando:

  • servidor Linux
  • CPU
  • memória
  • disco

☕ PASSO 1 — INSTALAR DOCKER

Linux:

sudo apt update
sudo apt install docker.io -y

Validar:

docker --version

☕ PASSO 2 — SUBIR GRAFANA

docker run -d \
--name grafana \
-p 3000:3000 \
grafana/grafana

☕ PASSO 3 — ACESSAR

Browser:

http://localhost:3000

Login padrão:

admin
admin

Depois:

  • altere senha

☕ PASSO 4 — INSTALAR PROMETHEUS

Prometheus coleta métricas.

Criar container:

docker run -d \
--name prometheus \
-p 9090:9090 \
prom/prometheus

☕ PASSO 5 — ADICIONAR DATASOURCE

No Grafana:

⚙️ Connections

→ Add new connection

Escolha:

  • Prometheus

URL:

http://prometheus:9090

Salvar:

  • Save & Test

☕ PASSO 6 — CRIAR DASHBOARD

➕ Create

→ Dashboard
→ Add Visualization

Selecionar:

  • Prometheus

☕ PASSO 7 — PRIMEIRA QUERY

Exemplo:

up

Isso mostra:

  • targets online

☕ PASSO 8 — CRIAR GRÁFICO DE CPU

Query:

rate(node_cpu_seconds_total[1m])

Tipo:

  • Time Series

☕ PASSO 9 — ADICIONAR MEMÓRIA

Query:

node_memory_MemAvailable_bytes

☕ PASSO 10 — SALVAR DASHBOARD

Nome:

LAB-SYSPROG-JR

☕ MANUTENÇÃO BÁSICA

☕ Editar painel

Clique:

  • painel
  • Edit

☕ Duplicar painel

Menu:

  • Duplicate

Muito usado em operações.


☕ Exportar dashboard

Menu:

  • Export JSON

Equivalente moderno de:

“guardar PROC/JCL padrão” ☕


☕ BACKUP

Dashboards ficam em:

  • banco SQLite interno
  • PostgreSQL
  • MySQL

Sysprog raiz:

SEMPRE faz backup ☕💾


☕ DICAS DE OURO PARA SYSPROG JÚNIOR

☕ 1 — Não crie dashboard “carnaval”

Erro clássico:

  • 500 gráficos
  • 90 cores
  • poluição visual

Operação precisa:

  • clareza
  • leitura rápida

☕ 2 — CPU sem contexto engana

90% CPU pode ser:

  • normal
  • batch pesado
  • pico legítimo

Mesma filosofia do RMF.


☕ 3 — Aprenda PromQL

PromQL é o “JCL do observability”.

Quem domina:

  • vira referência rapidamente.

☕ 4 — Menos é mais

Bons dashboards:

  • simples
  • objetivos
  • operacionais

☕ 5 — Nomeie tudo direito

Nunca faça:

Dashboard1
PainelNovo2
TESTEFINALFINAL

Isso vira o:

PROCLIB bagunçado do DevOps ☕💥


☕ EXEMPLO DE ESTRUTURA PROFISSIONAL

OPS-LINUX
OPS-K8S
OPS-DB
OPS-MQ
OPS-ZOS
OPS-CICS

☕ O FUTURO

Grafana hoje está entrando forte em:

  • IA operacional
  • observabilidade inteligente
  • correlação automática
  • AIOps

Mas no fundo…

A lógica continua a mesma do velho operador de mainframe:

“Descobrir problema antes do usuário ligar reclamando.” ☕🔥


☕ FRASE FINAL ESTILO BELLACOSA MAINFRAME

“O sysprog antigo olhava SDSF.
O sysprog moderno olha Grafana.
Mas os dois têm a mesma missão:
manter o datacenter vivo enquanto o mundo dorme.” ☕💾🔥

 

segunda-feira, 11 de julho de 2022

💣🔥 “EU NÃO SOU O PROTAGONISTA… EU SOU O PROCESSO EM BACKGROUND” — O ISEKAI QUE RODA COMO JOB OCULTO E DOMINA O SISTEMA 🔥💣

 

Bellacosa Mainframe apresenta um heroi overpower Kage no Kitsuryokusha

💣🔥 “EU NÃO SOU O PROTAGONISTA… EU SOU O PROCESSO EM BACKGROUND” — O ISEKAI QUE RODA COMO JOB OCULTO E DOMINA O SISTEMA 🔥💣

Kage no Jitsuryokusha ni Naritakute! — O Mainframe das Sombras


🧠 ORIGEM — O JOB QUE NASCEU COMO “SCRIPT NÃO OFICIAL”

Tudo começa como uma web novel escrita por Daisuke Aizawa lá em 2018 no estilo “laboratório clandestino” (plataformas tipo Shōsetsuka ni Narō).

👉 O sucesso foi tão absurdo que virou:

  • 📚 Light Novel oficial (2018–presente)
  • 📖 Mangá (2019–presente) ilustrado por Anri Sakano
  • 🎬 Anime (2022–presente) produzido pelo estúdio Nexus

💡 Tradução Bellacosa:

Era um “job de teste”… virou workload crítico em produção.


📜 HISTÓRIA — O CARA QUE NÃO QUER SER O HERÓI (E QUEBRA O SISTEMA POR ISSO)

O protagonista Cid Kagenou NÃO quer ser o herói, nem o vilão.

Ele quer ser isso aqui:

⚠️ O “Eminência nas Sombras” — aquele processo invisível que controla tudo sem aparecer.

Após morrer (clássico isekai), ele reencarna em um mundo mágico e decide viver sua fantasia…

Só que tem um detalhe crítico:

💣 Tudo que ele inventa como “brincadeira”… é REAL.

  • Ele cria uma organização fake → ela existe de verdade
  • Ele inventa uma conspiração → é real
  • Ele improvisa planos → funcionam melhor que arquitetura enterprise

👉 Resultado:
O cara acha que está brincando…
MAS NA REAL ele virou o sysadmin do universo sem saber.


📊 NÚMEROS — O TAMANHO DO AMBIENTE EM PRODUÇÃO

📚 Light Novel

  • Volumes: ~6+ (em andamento)
  • Publicação: desde 2018

📖 Mangá

  • Volumes: ~12+
  • Spin-offs incluídos

🎬 Anime

  • Temporadas: 2
  • Episódios:
    • S1: 20 episódios
    • S2: 12 episódios
      👉 Total: 32 episódios (até agora)

🎥 E ainda vem mais conteúdo — esse sistema NÃO entrou em sunset.


🧩 EASTER EGGS — OS “LOGS OCULTOS” QUE VOCÊ NÃO PERCEBEU

💡 Esse anime é praticamente um dump de referências escondidas:

  • 🧠 Paródia de protagonistas “edgy overpower”
  • 🎭 Referências a obras como:
    • Overlord
    • Code Geass
    • Death Note
  • 💥 A organização Shadow Garden parece zoeira…
    👉 Mas funciona como uma AOR distribuída com failover emocional
  • 🧾 Nomes e falas exageradas = propositalmente “cringe”
    👉 Isso é design, não erro

🤯 CURIOSIDADES — O QUE FAZ ESSE ANIME SER DIFERENTE

🔹 1. PROTAGONISTA MAIS “BUGADO” DO ISEKAI

Cid não quer salvar o mundo…

👉 Ele quer parecer cool nas sombras
👉 O resto? “Se resolver, resolveu”


🔹 2. META-HUMOR PESADO

O anime é praticamente uma sátira do gênero isekai

💣 Ele pega TODOS os clichês e faz isso:

  • exagera
  • distorce
  • e ainda faz funcionar

🔹 3. PODER DESBALANCEADO (NÍVEL MAINFRAME EM FULL CAPACITY)

Enquanto outros treinam…

👉 Cid já nasceu com:

  • CPU ilimitada
  • Memória infinita
  • Zero latência

🔹 4. “I AM ATOMIC” — O COMANDO MAIS BRUTAL DO SISTEMA

Essa frase virou um meme global

👉 É basicamente:

EXECUTE DESTRUIR.TUDO NOW


⚙️ ANÁLISE ESTILO BELLOSA — ISSO AQUI É UM MAINFRAME DISFARÇADO

Se você olhar com lente técnica:

AnimeMainframe
CidProcesso batch invisível
Shadow GardenCluster distribuído
MundoAmbiente de produção
ConspiraçãoSistema legado real
ImprovisoAutomação avançada

👉 O cara não joga o jogo…
👉 Ele redefine o sistema operacional.


💬 COMENTÁRIO DIRETO (SEM ROMANTIZAR)

Esse anime divide pessoas:

  • ❌ Quem leva a sério → acha estranho
  • ✅ Quem entende a proposta → acha genial

💡 Porque o ponto não é a história…
👉 É o absurdo controlado funcionando perfeitamente


🔥 CONCLUSÃO — O JOB QUE NÃO DEVERIA FUNCIONAR… MAS DOMINA TUDO

Kage no Jitsuryokusha ni Naritakute! é isso:

💣 Um protagonista que acha que está fingindo
💣 Um mundo que leva tudo a sério
💣 Um sistema onde o erro vira feature


🚨 FRASE FINAL ESTILO MAINFRAME

“Enquanto você tenta ser o herói…
ele já virou o processo invisível que controla o seu JOB.” 💀



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