☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

quinta-feira, 18 de abril de 2024

A Salad Bowl of Eccentrics : Quando um Programador COBOL Descobre que até uma Princesa de Outro Mundo Precisa Aprender a Conviver com Sistemas Legados

Bellacosa Mainframe apresenta a salad bowl of eccentrics

☕ Um Café no Bellacosa Mainframe

A Salad Bowl of Eccentrics (2024) sem Mistérios

Quando um Programador COBOL Descobre que até uma Princesa de Outro Mundo Precisa Aprender a Conviver com Sistemas Legados



Ficha Técnica

Título Original

Henjin no Salad Bowl (変人のサラダボウル)

Título Internacional

A Salad Bowl of Eccentrics

Autor

Yomi Hirasaka

(Ilustrado por Kantoku, conhecido também por seu trabalho em diversas light novels.)  


Estúdios

  • Studio Comet

  • SynergySP

Os dois estúdios dividiram a produção da animação, entregando uma obra visualmente simples, mas extremamente eficiente para a proposta slice of life e comédia.  


Diretor

Masafumi Satō


Roteiro

  • Kenichi Yamashita

  • Yomi Hirasaka

Um detalhe interessante é que o próprio autor participou diretamente da composição da série, preservando boa parte da personalidade da obra original. 


Data de lançamento

5 de abril de 2024

Transmitido durante a temporada de Primavera de 2024.


Episódios

12 episódios

aproximadamente 24 minutos cada. 


Classificação

Aproximadamente 14 anos.

Embora exista magia, praticamente não há violência pesada.

O anime aposta muito mais no humor, diálogos e situações sociais.


Gêneros

  • Comédia

  • Slice of Life

  • Fantasia

  • Reverse Isekai

  • Vida Urbana

  • Seinen/Shōnen (dependendo da classificação adotada)

  • Drama leve  


Sinopse

Imagine um isekai...

Agora faça exatamente o contrário.

Ao invés de um japonês morrer atropelado por um caminhão e acordar num reino medieval...

É uma princesa de um reino medieval que aparece no Japão moderno.

Sara da Odin foge de um golpe político em seu mundo.

Durante sua fuga, atravessa um portal mágico.

Quando abre os olhos...

Está em Gifu.

Sem dinheiro.

Sem documentos.

Sem entender absolutamente nada.

Quem a encontra é Sōsuke Kaburaya, um detetive particular que já mal consegue pagar o aluguel.

Enquanto isso, sua cavaleira Livia acaba chegando separadamente e inicia sua própria aventura no mundo moderno.

Daí nasce uma das comédias mais inteligentes dos últimos anos.  


Resumo

Ao contrário da maioria dos animes de fantasia, A Salad Bowl of Eccentrics não gira em torno de derrotar reis demônios, subir níveis ou conquistar reinos.

O verdadeiro foco é observar pessoas extraordinárias tentando viver uma vida completamente comum.

Cada episódio mostra como personagens vindos de um universo medieval precisam aprender:

  • usar dinheiro;

  • morar em apartamentos;

  • andar de ônibus;

  • comer em restaurantes;

  • trabalhar;

  • compreender leis;

  • entender internet;

  • conviver com pessoas extremamente excêntricas.

É uma história pequena.

Mas extremamente humana.


História

Sara pertence à família imperial de outro mundo.

Após uma conspiração política, ela precisa fugir.

Durante a perseguição utiliza magia dimensional.

O portal, entretanto, liga seu mundo ao Japão.

Ela conhece Kaburaya.

Mesmo sendo um detetive pobre, ele resolve ajudá-la.

Rapidamente Sara demonstra possuir enorme inteligência.

Ela aprende praticamente tudo sobre o Japão moderno em poucos dias.

Enquanto isso, Livia enfrenta uma trajetória completamente diferente.

Sem dinheiro.

Sem amigos.

Sem conhecer a cidade.

Curiosamente, sua honestidade e simplicidade acabam atraindo pessoas dispostas a ajudá-la.

A partir daí surgem diversas histórias paralelas envolvendo:

  • um advogado extremamente manipulador;

  • influenciadores digitais;

  • religiosos;

  • artistas;

  • moradores de rua;

  • empresários;

  • golpistas;

  • pessoas completamente fora dos padrões.

É justamente essa "salada" de personalidades que dá nome ao anime.


Principais Personagens

Sara da Odin

A princesa.

Educada.

Extremamente inteligente.

Possui magia.

Mas aprende rapidamente que conhecimento moderno também possui enorme poder.

Seu desenvolvimento é um dos melhores da série.


Sōsuke Kaburaya

Detetive particular.

Boa pessoa.

Péssimo administrador financeiro.

Acaba tornando-se praticamente uma figura paterna para Sara.

É um protagonista extremamente humano.


Livia do Udis

A cavaleira.

Leal.

Honrada.

Ingênua.

Sua adaptação ao Japão rende algumas das cenas mais engraçadas do anime.

Enquanto Sara aprende tecnologia, Livia aprende sobrevivência.


Brenda Aisaki

Uma advogada extremamente competente.

Manipuladora.

Carismática.

Representa o lado mais "cinzento" da sociedade moderna.


Demais personagens

Ao longo da série aparecem diversos indivíduos igualmente excêntricos.

Cada um representa uma pequena crítica ou observação sobre a sociedade japonesa contemporânea.


O que esse anime tem de diferente?

Praticamente tudo.

Enquanto a maioria dos isekais pergunta:

"Como sobreviver em outro mundo?"

Henjin no Salad Bowl pergunta:

"Como sobreviver no Japão moderno?"

É uma inversão completa da fórmula.

Além disso:

  • não existe protagonista overpower destruindo exércitos;

  • não há sistema RPG;

  • não há guildas;

  • não há ranking de aventureiros;

  • não existe Rei Demônio.

Os conflitos são muito mais próximos da realidade.


Temáticas

Reverse Isekai

O conceito central.

Fantasia invade o cotidiano.


Choque Cultural

A princesa aprende:

  • supermercados;

  • impostos;

  • redes sociais;

  • televisão;

  • restaurantes;

  • aluguel.

Tudo parece magia.


Família Encontrada

Kaburaya nunca pretende virar tutor de ninguém.

Mas aos poucos nasce uma relação extremamente bonita entre ele e Sara.


Adaptação

Todos os personagens mudam.

Sem exceção.


Sociedade

Cada personagem representa uma pequena faceta da vida japonesa.

Não existe apenas humor.

Existe observação social.


As Aventuras

Embora não existam grandes guerras, os episódios conseguem transformar acontecimentos simples em aventuras memoráveis.

Entre elas:

  • encontrar moradia;

  • procurar emprego;

  • aprender costumes japoneses;

  • descobrir como funciona o transporte público;

  • usar internet;

  • fazer amizades improváveis;

  • resolver pequenos casos investigativos;

  • lidar com influenciadores digitais;

  • enfrentar golpes e manipulações.

O anime mostra que a vida cotidiana pode ser tão imprevisível quanto uma campanha de RPG.


Mensagens Ocultas

O verdadeiro poder é aprender

Sara chega com magia.

Mas percebe que aprender vale muito mais.

Conhecimento continua sendo o recurso mais poderoso.


Pessoas são mais importantes que títulos

Princesa.

Detetive.

Morador de rua.

Advogado.

Todos possuem qualidades.

Todos possuem defeitos.


Felicidade é adaptação

Nenhum personagem encontra felicidade permanecendo igual.

Todos precisam mudar.


A sociedade também pode ser um mundo fantástico

Quando vista pelos olhos de alguém completamente novo.


Gentileza muda destinos

Grande parte da história só acontece porque Kaburaya resolve ajudar uma desconhecida.

Um pequeno gesto altera dezenas de vidas.


A Qualidade da Produção

A animação não tenta competir com títulos de ação como Solo Leveling ou Kaiju No. 8.

O investimento foi direcionado para:

  • expressões faciais;

  • direção de comédia;

  • diálogos naturais;

  • cenários urbanos acolhedores;

  • excelente ritmo narrativo.

Essa escolha combina perfeitamente com o estilo da obra.


Impacto Cultural

A Salad Bowl of Eccentrics não foi um fenômeno de audiência, mas conquistou um público fiel justamente por fugir das fórmulas tradicionais do gênero isekai. Muitos fãs compararam seu clima acolhedor a obras como Hinamatsuri e Miss Kobayashi's Dragon Maid, destacando o humor leve, os personagens carismáticos e a forma como o cotidiano se torna divertido. Outro aspecto elogiado foi a ambientação em Gifu, cidade natal do autor, valorizando locais reais e reforçando a identidade regional da história. 


☕ Um Café no Bellacosa Mainframe

Quando um Programador COBOL Descobre que Todo Sistema Legado Também é um Isekai

Imagine Sara entrando em um CPD bancário.

Ela olha para um IBM Z.

Pergunta:

"É aqui que vocês guardam o Orbe Sagrado do Reino?"

O analista COBOL responde:

— Não... aqui guardamos as contas de milhões de clientes.

Ela vê um programa escrito em COBOL há quarenta anos.

— Ainda funciona?

O veterano sorri.

— Funciona tão bem que movimenta bilhões de reais antes mesmo de você terminar esse café.

Sara tenta lançar uma magia.

Nada acontece.

Então recebe um manual de JCL, outro de CICS e um terceiro de Db2.

Após algumas horas de estudo, percebe algo curioso.

Naquele ambiente, os verdadeiros magos não usam cajados.

Usam ISPF, compiladores, utilitários do z/OS e décadas de conhecimento acumulado.

Assim como em A Salad Bowl of Eccentrics, todo Programador COBOL Padawan chega a um universo estranho, repleto de regras, costumes e linguagens desconhecidas. No início, tudo parece um mundo alienígena. Mas, com curiosidade, disciplina e bons mentores, o que parecia um labirinto se revela um ecossistema sólido, confiável e fascinante. Afinal, seja em um reino de fantasia ou em um datacenter IBM Z, a verdadeira magia continua sendo a mesma: aprender, adaptar-se e compartilhar conhecimento.

quarta-feira, 17 de abril de 2024

RAD (Rapid Application Development) - A Metodologia que Mudou a Engenharia de Software e Continua Transformando o IBM Mainframe

 

Bellacosa Mainframe e RAD rapid application development

☕ Um Café no Bellacosa Mainframe

RAD (Rapid Application Development)

A Metodologia que Mudou a Engenharia de Software e Continua Transformando o IBM Mainframe

Você não está estudando apenas uma metodologia criada nos anos 90. Está entendendo a origem de grande parte das práticas modernas de desenvolvimento de software.

"O Mainframe nunca foi lento. Lento sempre foi o processo de desenvolvimento ao seu redor."


Introdução

Quando alguém fala em desenvolvimento ágil, Scrum, DevOps, Low-Code, No-Code ou Inteligência Artificial, normalmente imagina que essas tecnologias surgiram praticamente do nada.

Na realidade, muitas dessas ideias nasceram décadas antes.

Entre elas está o RAD (Rapid Application Development), metodologia criada para reduzir o tempo entre uma necessidade do negócio e a entrega de software funcionando.

Seu princípio continua extremamente atual.

Não desenvolver mais rápido.

Aprender mais rápido.

Para quem trabalha com COBOL e IBM Mainframe, compreender o RAD significa entender que velocidade nunca dependeu apenas da linguagem de programação. Ela depende principalmente da organização do trabalho, da automação, da participação do usuário e da capacidade de evoluir continuamente.

Esta série apresenta o RAD sob a ótica do profissional IBM Z, mostrando que seus princípios continuam mais vivos do que nunca.


O que você aprenderá nesta série

Ao longo dos três capítulos veremos:

  • a origem do RAD;

  • por que ele revolucionou a Engenharia de Software;

  • como implementar RAD na prática;

  • metodologias derivadas;

  • ferramentas clássicas e modernas;

  • integração com Low-Code, DevOps e IA;

  • aplicação em COBOL, CICS, DB2, IMS e IBM Z;

  • oportunidades profissionais para desenvolvedores Mainframe.


Capítulo 1 — O que é RAD e por que ele revolucionou o desenvolvimento de software

Resumo

O primeiro capítulo apresenta a história do Rapid Application Development, criado por James Martin em 1991.

Mostra o cenário da época, dominado pelo modelo Cascata (Waterfall), em que projetos levavam anos para serem concluídos e frequentemente chegavam ao usuário já desatualizados.

Também explica os quatro pilares do RAD:

  • desenvolvimento iterativo;

  • prototipação;

  • participação constante do usuário;

  • equipes pequenas e multidisciplinares.

O capítulo compara RAD com Waterfall e demonstra como suas ideias influenciaram praticamente todas as metodologias modernas.

Leia o capítulo completo:

👉 RAD (Rapid Application Development) – Parte 1: O Que Todo Programador COBOL Precisa Saber Sobre a Metodologia que Ensinou o Mundo a Desenvolver Software Rapidamente

https://eljefemidnightlunch.blogspot.com/2024/01/rad-rapid-application-development-o-que.html


Capítulo 2 — Como implementar RAD na prática

Resumo

Depois de entender os conceitos fundamentais, chega o momento de colocar o RAD em funcionamento.

Este capítulo apresenta um roteiro completo de implementação.

Você aprenderá:

  • como dividir projetos em pequenas entregas;

  • como montar equipes enxutas;

  • como construir protótipos;

  • como utilizar MVP (Minimum Viable Product);

  • como medir resultados;

  • indicadores de sucesso;

  • governança;

  • segurança;

  • documentação enxuta.

Também apresenta as metodologias influenciadas pelo RAD:

  • Scrum;

  • Extreme Programming (XP);

  • Lean Software Development;

  • DevOps;

  • Agile.

Além disso, faz um panorama das principais ferramentas RAD da história, como PowerBuilder, Delphi, Oracle Forms e GeneXus, chegando às plataformas atuais como Mendix, OutSystems, Power Apps, Oracle APEX e soluções baseadas em Inteligência Artificial.

Leia o capítulo completo:

👉 RAD (Rapid Application Development) – Parte 2: Como Implementar RAD na Prática, Principais Metodologias, Ferramentas e o Papel da Inteligência Artificial

https://eljefemidnightlunch.blogspot.com/2024/02/rad-rapid-application-development-como.html


Capítulo 3 — RAD no IBM Mainframe

Resumo

O terceiro capítulo aproxima definitivamente o RAD do universo IBM Z.

Mostra que o Mainframe nunca foi incompatível com desenvolvimento rápido.

Na verdade, muitos bancos já aplicavam práticas semelhantes ao RAD antes mesmo da popularização do Agile.

Entre os assuntos abordados estão:

  • RAD aplicado ao COBOL;

  • modularização;

  • COPYBOOKs;

  • reutilização;

  • APIs REST;

  • z/OS Connect;

  • CICS;

  • DB2;

  • IMS;

  • VSAM;

  • Git;

  • DevOps;

  • CI/CD;

  • testes automatizados;

  • observabilidade;

  • Inteligência Artificial aplicada ao código legado.

O capítulo também discute o futuro do desenvolvimento Mainframe e mostra como a combinação entre COBOL, IA e automação cria novas oportunidades para profissionais especializados em IBM Z.

Leia o capítulo completo:

👉 RAD (Rapid Application Development) – Parte 3: RAD no IBM Mainframe: Como Aplicar Desenvolvimento Rápido em COBOL sem Perder a Confiabilidade do IBM Z

https://eljefemidnightlunch.blogspot.com/2024/03/rad-rapid-application-development-rad.html


As principais lições da série

Ao final da leitura, fica evidente que o RAD nunca foi apenas uma metodologia para acelerar projetos.

Ele representa uma mudança de mentalidade.

Seus princípios continuam presentes em praticamente todas as práticas modernas de Engenharia de Software:

  • entregas incrementais;

  • feedback contínuo;

  • automação;

  • integração contínua;

  • testes automatizados;

  • prototipação;

  • foco no usuário;

  • redução de desperdícios;

  • melhoria contínua.

No ambiente IBM Mainframe, esses conceitos tornaram-se ainda mais relevantes graças à integração com APIs, Git, DevOps, z/OS Connect e Inteligência Artificial.

O desenvolvedor COBOL moderno não precisa abandonar décadas de conhecimento.

Precisa ampliar sua caixa de ferramentas.

Quanto mais automatizado for o processo, menor será o tempo entre uma ideia de negócio e sua implementação.

Esse sempre foi o verdadeiro objetivo do RAD.

Trinta anos depois, continua sendo uma das maiores lições da Engenharia de Software.


Próximas leituras recomendadas

Se você gostou desta série, acompanhe também os artigos do ☕ Um Café no Bellacosa Mainframe sobre:

  • DevOps para IBM Mainframe;

  • Low-Code para Programadores COBOL;

  • No-Code e Modernização;

  • Arquitetura Transformer para Mainframe;

  • Engenharia de Dados para Desenvolvedores COBOL;

  • CASE Tools;

  • APIs REST no IBM Z;

  • Inteligência Artificial aplicada ao COBOL;

  • Git e CI/CD no z/OS;

  • Modernização de aplicações IBM Z.

Esse artigo funciona como uma página pilar (Pillar Page) para SEO, concentrando a autoridade do tema RAD e distribuindo links para os três capítulos da série.


terça-feira, 16 de abril de 2024

Resiliência IBM Z – Storage Inteligente e Capacity on Demand - Parte IV

 

Bellacosa Mainframe e a resiliencia em ibm z parte iv

☕ Um Café no Bellacosa Mainframe

O Holocron da Resiliência IBM Z

Parte IV – Storage Inteligente e Capacity on Demand: Quando o IBM Z Cresce sem Parar o Negócio

"Para um Padawan, um disco é apenas um lugar para gravar dados. Para um Mestre Mainframe, o armazenamento é uma arquitetura viva, capaz de crescer, proteger informações e continuar funcionando mesmo quando partes dela falham."

Nas partes anteriores aprendemos os fundamentos da Resiliência, conhecemos a arquitetura física do IBM Z e descobrimos como o Parallel Sysplex faz diversos mainframes trabalharem como um único sistema.

Agora chegou a hora de conhecer outro pilar da disponibilidade.

O armazenamento.

Mas cuidado.

Quando falamos em Storage no IBM Z, não estamos falando apenas de discos.

Estamos falando de uma plataforma inteligente que gerencia dados, automatiza migrações, protege informações, compartilha recursos e até aumenta a capacidade do computador sob demanda.

Os conceitos desta parte incluem DFSMS, seus componentes (DFSMSdfp, DFSMSdss, DFSMShsm, DFSMSrmm, DFSMStvs), além de System Logger, Port Sharing, Capacity Backup (CBU), Customer Initiated Upgrade (CIU), Capacity Upgrade on Demand (CUoD), On/Off Capacity on Demand (OOCoD), e-business on Demand (eBoD) e os diferentes modelos de Clusters do IBM Z.


O Maior Patrimônio de Uma Empresa Não É o Computador

Imagine um banco.

Se um servidor quebrar...

Compra-se outro.

Se uma placa apresentar defeito...

Ela pode ser substituída.

Agora imagine perder todas as contas correntes.

Todos os financiamentos.

Todos os investimentos.

Todos os históricos de pagamento.

A empresa praticamente deixa de existir.

No IBM Z, o dado vale muito mais do que o equipamento.

Por isso existe uma infraestrutura gigantesca dedicada exclusivamente à administração dessas informações.


DFSMS – O Grande Administrador dos Dados

Muitos iniciantes acreditam que o sistema operacional controla sozinho todos os discos.

Na realidade existe um conjunto de serviços chamado DFSMS.

Ele funciona como um administrador extremamente organizado.

Enquanto o programador pensa apenas no dataset...

O DFSMS decide:

  • onde armazenar;

  • como proteger;

  • quando migrar;

  • quando fazer backup;

  • quando recuperar;

  • qual volume utilizar;

  • como otimizar espaço.

É praticamente um "gerente de condomínio" dos dados.


DFSMSdfp

O Data Facility Data Management é a base de todo o armazenamento.

Ele fornece os serviços fundamentais para:

  • datasets;

  • volumes;

  • catálogos;

  • acesso aos discos;

  • gerenciamento de arquivos.

Todo programa COBOL que abre um arquivo VSAM ou Sequential está utilizando recursos administrados por esse componente.

Mesmo sem perceber.


DFSMSdss

Imagine uma equipe especializada em mudanças.

Ela copia apartamentos inteiros.

Transporta móveis.

Replica documentos.

No IBM Z, esse papel pertence ao DFSMSdss.

Ele executa:

  • cópias;

  • migrações;

  • backups;

  • restaurações;

  • replicações.

Tudo com enorme eficiência.

É uma das ferramentas mais utilizadas durante migrações e recuperação de ambientes.


DFSMShsm

Nem todo arquivo precisa permanecer em discos de alta velocidade.

Alguns são utilizados diariamente.

Outros apenas uma vez por ano.

O Hierarchical Storage Manager resolve esse problema.

Ele movimenta automaticamente os dados entre diferentes níveis de armazenamento.

Arquivos pouco utilizados podem ser enviados para mídias mais econômicas.

Quando voltam a ser necessários...

São recuperados automaticamente.

O usuário muitas vezes nem percebe essa movimentação.


DFSMSrmm

Imagine uma biblioteca gigantesca.

Milhões de fitas.

Quem sabe exatamente onde cada uma está?

O Removable Media Manager.

Ele controla:

  • fitas;

  • cartuchos;

  • movimentações;

  • retenções;

  • empréstimos;

  • descarte.

Mesmo em plena era da nuvem, fitas continuam sendo extremamente importantes para backup corporativo.


DFSMStvs

Agora imagine uma aplicação Batch gravando dados em VSAM.

No meio da atualização...

Falta energia.

Como garantir que os registros não fiquem inconsistentes?

O Transactional VSAM Services resolve exatamente esse problema.

Ele adiciona características transacionais aos arquivos VSAM.

Muito parecido com aquilo que um banco de dados faz.

Para aplicações críticas, isso representa um enorme ganho de confiabilidade.


System Logger

Imagine dezenas de aplicações produzindo eventos ao mesmo tempo.

CICS.

IMS.

Db2.

MQ.

z/OS.

Quem organiza todos esses registros?

O System Logger.

Ele funciona como um grande repositório de logs compartilhados.

Esses registros são fundamentais para:

  • auditoria;

  • recuperação;

  • sincronização;

  • diagnóstico;

  • continuidade operacional.

Sem logs consistentes...

Recuperar sistemas seria muito mais difícil.


Port Sharing

Outra característica interessante do IBM Z é o compartilhamento inteligente de portas de comunicação.

Em vez de cada aplicação monopolizar uma porta exclusiva...

Diversos serviços podem compartilhar recursos de forma controlada.

O resultado é:

  • maior escalabilidade;

  • melhor utilização do hardware;

  • menor desperdício de recursos.


Capacity on Demand – Crescendo Sem Comprar Outro Mainframe

Imagine um shopping.

No Natal chegam milhares de clientes.

Depois do Natal...

O movimento cai novamente.

Faz sentido construir outro shopping apenas para dezembro?

Claro que não.

No IBM Z acontece algo parecido.

Existem períodos de pico.

Fechamento contábil.

Pagamento de salários.

Black Friday.

Imposto de renda.

O sistema precisa crescer.

Mas apenas temporariamente.

É aí que entra o conceito de Capacity on Demand.


Capacity Backup (CBU)

Imagine que um datacenter inteiro seja perdido.

O ambiente de contingência assume toda a operação.

Mas agora ele precisa de muito mais processamento.

O CBU disponibiliza capacidade adicional justamente para essas situações de desastre.

O objetivo é garantir continuidade mesmo durante eventos extremos.


Customer Initiated Upgrade (CIU)

Em alguns casos, o próprio cliente pode ativar recursos previamente instalados no equipamento.

Sem trocar hardware.

Sem aguardar técnicos.

Sem desligar a máquina.

Isso reduz drasticamente o tempo necessário para expansão.


Capacity Upgrade on Demand (CUoD)

Imagine comprar um automóvel já preparado para ter mais potência.

Quando necessário...

Basta liberar eletronicamente os recursos.

É exatamente essa filosofia.

O hardware já possui capacidade instalada.

Ela apenas é ativada quando o negócio realmente precisa.


On/Off Capacity on Demand (OOCoD)

Agora imagine algo ainda mais inteligente.

A empresa utiliza capacidade extra apenas durante alguns dias.

Terminou o pico?

A capacidade adicional é desativada.

O cliente paga apenas pelo período utilizado.

É computação elástica muito antes da popularização da nuvem.


e-Business on Demand (eBoD)

Quando o comércio eletrônico começou a crescer rapidamente, surgiu um desafio.

Como atender milhões de acessos inesperados?

O eBoD foi criado justamente para permitir aumentos rápidos de capacidade durante eventos de grande demanda.

Hoje esse conceito continua influenciando a forma como grandes empresas planejam sua infraestrutura.


Os Diferentes Tipos de Cluster

O IBM Z também trabalha com diferentes arquiteturas de agrupamento.

Virtual Cluster

Recursos compartilhados virtualmente.

Grande flexibilidade.

Melhor utilização da infraestrutura.


Horizontal Cluster

Mais servidores trabalhando juntos.

Ideal para crescimento contínuo.

Quanto maior a demanda...

Mais membros podem ser adicionados.


Mixed Cluster

Combina diferentes gerações de hardware.

Permite evolução gradual do ambiente sem necessidade de substituição completa.


Dynamic Cluster

Talvez o mais interessante.

Os recursos podem ser reorganizados dinamicamente conforme a necessidade do negócio.

É uma infraestrutura que se adapta continuamente às mudanças da carga de trabalho.


O Que Tudo Isso Significa Para um Programador COBOL?

À primeira vista, DFSMS, Capacity on Demand e Storage parecem assuntos exclusivos da infraestrutura.

Mas não são.

Quando um programa COBOL grava um arquivo VSAM, acessa um dataset sequencial ou consulta uma base Db2, ele depende diretamente dessa arquitetura.

Compreender esses componentes ajuda o desenvolvedor a:

  • escrever aplicações mais eficientes;

  • evitar acessos desnecessários ao armazenamento;

  • entender políticas de backup e recuperação;

  • compreender tempos de resposta;

  • projetar soluções escaláveis.

O código continua sendo importante.

Mas o ambiente onde ele executa é igualmente decisivo.


A Filosofia do IBM Z

Existe uma característica que diferencia profundamente o IBM Z de muitas outras plataformas.

Enquanto em diversos ambientes a expansão costuma significar comprar novos servidores, instalar sistemas operacionais e redistribuir aplicações, no IBM Z o crescimento frequentemente acontece de forma transparente.

A infraestrutura foi concebida para evoluir junto com o negócio.

Mais usuários.

Mais processamento.

Mais armazenamento.

Mais disponibilidade.

Tudo isso sem interromper as operações críticas.

Esse é um dos motivos pelos quais bancos, seguradoras, empresas de telecomunicações e governos continuam confiando seus dados mais importantes ao IBM Z.

No próximo capítulo do Holocron da Resiliência IBM Z, exploraremos como CICS, Db2, MQ e IMS utilizam toda essa infraestrutura para construir aplicações altamente disponíveis, distribuídas e preparadas para processar milhões de transações por dia.


segunda-feira, 15 de abril de 2024

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z – O Despertar da Força dos Ponteiros - Parte I

 

Bellacosa Mainframe e os ponteiros de memoria no COBOL Parte I

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z

Parte 1 – O Despertar da Força dos Ponteiros

Quando o Padawan Descobre que um Endereço Pode Ser Mais Poderoso que os Dados

Por Bellacosa Mainframe


"O dado é importante. Mas conhecer onde ele vive na memória é conhecer a própria Força."

Mestre Sysprog Bellacosa


Introdução

Existe um momento na jornada de todo desenvolvedor COBOL em que ele acredita já ter visto praticamente tudo.

Aprendeu arquivos.

Aprendeu VSAM.

Aprendeu DB2.

Aprendeu CICS.

Aprendeu tabelas OCCURS.

Aprendeu REDEFINES.

Aprendeu recursão.

Aprendeu programas aninhados.

Aprendeu até THREADSAFE.

Então um dia aparece um código semelhante a este:

01 PTR-CLIENTE      USAGE POINTER.

SET PTR-CLIENTE TO ADDRESS OF WS-CLIENTE.

O jovem Padawan olha para aquilo e pergunta:

Mestre…

COBOL tem ponteiros?

O mestre sorri.

Toma um gole de café.

E responde:

Sim.

E são provavelmente uma das funcionalidades menos conhecidas, mais poderosas e potencialmente mais perigosas disponíveis no IBM Enterprise COBOL.


O grande mito

Existe um mito muito comum.

"COBOL não trabalha com endereços."

Errado.

COBOL trabalha.

Sempre trabalhou.

Só que de forma extremamente controlada.

Enquanto linguagens como C permitem brincar livremente com memória:

int *p;

COBOL diz:

Jovem Padawan...

Se você vai manipular memória...

Faça isso com respeito.


O que é um ponteiro?

Um ponteiro não é um dado.

Ele não contém um nome.

Ele não contém um CPF.

Ele não contém uma data.

Ele contém:

O endereço onde algo está.

Imagine.

Apartamento:

Rua Jedi 500

Apartamento 1001

O apartamento é o dado.

O endereço é o ponteiro.


Exemplo.

Cliente

Nome

Bellacosa

Está armazenado em:

7FFF012345678

O ponteiro guarda:

7FFF012345678

Nada mais.


Por que isso existe?

Porque às vezes queremos acessar memória dinamicamente.

Criar estruturas.

Buffers.

Caches.

Árvores.

Filas.

Listas.

Comunicar com C.

Trabalhar com APIs.

Manipular XML.

Shared Memory.

LE Runtime.


COBOL sempre teve ponteiros?

Não.

COBOL 60

Não.

COBOL 68

Não.

COBOL 74

Não.


A situação começou a mudar com:

COBOL 85


Mais tarde.

IBM Enterprise COBOL.

Introduziu:

USAGE POINTER

ADDRESS OF

BASED

ALLOCATE

FREE


Atualmente.

Enterprise COBOL

4

5

6

6.3

6.4

6.5

Suportam totalmente.


O que é USAGE POINTER?

É o tipo especial que armazena um endereço.

Exemplo.

01 WS-PTR.

   USAGE POINTER.

ou

01 WS-PTR POINTER.

Não faça:

PIC X(08)

Errado.


Não faça:

PIC 9(18)

Errado.


O compilador conhece o formato.

Você não precisa.


ADDRESS OF

Talvez seja a instrução mais importante.

Exemplo.

Temos.

01 WS-CLIENTE.

   05 WS-NOME PIC X(30).

Pegando endereço.

SET WS-PTR

TO ADDRESS OF WS-CLIENTE

Pronto.

Agora.

WS-PTR aponta.

Para WS-CLIENTE.


Visualmente

Antes.

WS-PTR


NULL

Depois.

WS-PTR


0000007FFF123450

Como funciona na memória

Imagine.

Working Storage

ENDEREÇO


1000


WS-NOME


Bellacosa



1030


WS-IDADE


52



1035


WS-PTR

Executamos.

SET PTR

TO ADDRESS OF WS-NOME

Resultado.

PTR


1000

O ponteiro virou.

Uma espécie de GPS.


O que é SET?

SET é o comando utilizado.

Para manipular ponteiros.

Exemplo.

SET PTR

TO ADDRESS OF WS-DADOS

Outro.

SET PTR TO NULL

Muito importante.

Sempre inicializar.


Boa prática.

SET PTR TO NULL

No início.


Primeiro exemplo completo

Passo 1

Criar estrutura

WORKING-STORAGE SECTION.


01 WS-CLIENTE.

   05 WS-NOME.

      PIC X(30).



01 WS-PTR

USAGE POINTER.

Passo 2

Preencher

MOVE 'BELLACOSA'

TO WS-NOME

Passo 3

Capturar endereço

SET WS-PTR

TO ADDRESS OF WS-CLIENTE

Passo 4

Display

DISPLAY 'PONTEIRO OK'

Fim.


O que o compilador faz?

Compilador cria.

Variável especial.

Compatível com arquitetura.

31 bits.

64 bits.


Padawan pergunta.

Mestre...

Então é um hexadecimal?

Resposta.

Sim.

Normalmente.


Exemplo.

0000000012345678

IBM Z e endereçamento

Aqui começa a magia.

IBM Z possui longa história.


AMODE 24

Década 70.

Memória.

16 MB.


AMODE 31

1983

2 GB


AMODE 64

zSeries

Exabytes teóricos.


COBOL acompanha.


Working Storage

Ponteiros podem apontar para:

Working Storage


Local Storage


Heap


Dynamically allocated


LE Areas


Buffers


Stack

Existe outra área.

Stack.

Exemplo.

Função chamada.

STACK



Frame A


Frame B


Frame C

Cada frame.

Possui.

Variáveis.

Retorno.

Contexto.


Ponteiros podem apontar.

Para stack.

Sim.


Mas aqui mora perigo.


O lado sombrio

Imagine.

Procedimento.

Termina.

Stack destruída.


Ponteiro ainda existe.


Aponta.

Para memória inválida.


Chamamos isso.

Dangling Pointer.


Exemplo.

PTR


12345

Memória já morreu.


Resultado.

SOC4.


Heap

Heap é diferente.

Sobrevive.

Mais tempo.


Usado em.

ALLOCATE.

CEEGTST.

GETMAIN.


Mais seguro.


Curiosidade

Muitos programas COBOL bancários.

Nunca usam ponteiros.


Por quê?

Não precisam.


COBOL nasceu.

Para registros.

Arquivos.

Campos fixos.


Ponteiros vieram.

Muito depois.


Vantagens

Extremamente rápidas.

Não copia dados.


Exemplo.

Mover.

1 MB.

Custa.

CPU.


Mover ponteiro.

8 bytes.

Instantâneo.


Onde usar?

Excelente para.

XML

JSON

Árvores

Cache

Filas

MQ

Buffers

APIs

Sockets

C

Metal C


Onde NÃO usar?

Cadastro clientes.

Folha pagamento.

Relatórios.

VSAM simples.

Batch convencional.


Performance

Muito boa.

Quase zero overhead.


Mas.

Erro custa caro.


Um MOVE errado.

Perde registro.


Ponteiro errado.

Pode derrubar programa.


SOC4.


Segurança

Ponteiros são ferramenta poderosa.

Mas perigosos.


Podem causar.

Corrupção memória.

Exposição dados.

Abends.

Memory leaks.


Padawan deve lembrar.

Ponteiro não sabe.

Se memória ainda existe.

Ele apenas acredita.


Curiosidades Bellacosa

Pouquíssimos desenvolvedores COBOL escrevem código com ponteiros diariamente.

Mas os profissionais que trabalham com:

  • Language Environment

  • XML parsers

  • CEEGTST

  • Metal C

  • DB2 internals

  • Middleware

  • MQ exits

  • CICS User Exits

  • z/OS Connect

  • Parsers de alta performance

frequentemente encontram USAGE POINTER, ADDRESS OF, BASED e estruturas dinâmicas escondidas em programas aparentemente inocentes.


O Conselho do Mestre Bellacosa

Imagine que os dados COBOL são sabres de luz.

Você pode segurá-los diretamente.

Pode copiá-los.

Pode movê-los.

Pode validá-los.

Mas um ponteiro é diferente.

Um ponteiro é um mapa para encontrar o sabre.

Ele não contém energia.

Ele não contém plasma.

Ele apenas diz:

"Vá até aquele lugar da memória e você encontrará aquilo que procura."

E essa é justamente a beleza e o perigo dos ponteiros em COBOL.

Eles permitem que o Padawan transcenda a programação tradicional baseada em registros fixos e passe a manipular a própria estrutura da memória do IBM Z.

Mas também ensinam uma das maiores lições do universo mainframe:

O dado pode estar protegido por RACF.

O dataset pode estar catalogado.

O programa pode ser RENT e THREADSAFE.

Mas um ponteiro errado continua tendo o poder de levar até mesmo um Mestre Sysprog ao temido S0C4.

Continua na Parte 2 – BASED, ALLOCATE, CEEGTST e Estruturas Dinâmicas: Construindo Listas Encadeadas no IBM Z.


domingo, 14 de abril de 2024

☕🖥️ “TRÊS GUARDIÕES DO MAINFRAME” — O DIA EM QUE O DATACENTER DESCOBRIU QUE SYSOPS, SYSADMIN E SYSPROG NÃO SÃO A MESMA COISA 🔥

 

Bellacosa Mainframe apresenta SYSOPS SYSPROG e SYSADMIN

☕🖥️ “TRÊS GUARDIÕES DO MAINFRAME” — O DIA EM QUE O DATACENTER DESCOBRIU QUE SYSOPS, SYSADMIN E SYSPROG NÃO SÃO A MESMA COISA 🔥

No universo IBM Mainframe existe uma confusão que atravessa décadas.

Muita gente olha para um datacenter e imagina que todo profissional técnico faz exatamente a mesma coisa:
“é tudo administrador de sistema”.

Mas no z/OS isso nunca foi verdade.

Dentro de um ambiente corporativo real — bancos, seguradoras, governo, companhias aéreas — existem papéis extremamente especializados. E entre os mais importantes estão três figuras lendárias:

  • SYSOPS

  • SYSADMIN

  • SYSPROG

Os três trabalham próximos.
Os três têm acesso crítico.
Os três vivem cercados de incidentes, consoles, logs e chamados urgentes.

Mas cada um protege uma camada completamente diferente do ecossistema mainframe.

E quando uma empresa não entende essa diferença…
o caos operacional começa.


☕ O SYSOPS — O GUARDIÃO DA OPERAÇÃO

O SYSOPS (System Operator) é o profissional que mantém o ambiente respirando em tempo real.

Ele é o “olho vivo” do datacenter.

Enquanto o resto da empresa dorme…
o SYSOPS está olhando consoles JES2, mensagens do sistema, jobs presos, filas de spool, automação e alertas de produção.

É ele quem percebe:

  • JOB ABENDANDO

  • fita travada

  • impressora parada

  • fila JES2 lotando

  • CICS indisponível

  • DB2 fora do ar

  • automação falhando

  • CPU explodindo

  • storage chegando no limite

O SYSOPS vive no front da guerra operacional.


☕ O QUE O SYSOPS FAZ NA PRÁTICA?

O operador de mainframe normalmente trabalha com:

  • JES2/JES3

  • SDSF

  • consoles MVS

  • automação

  • acompanhamento batch

  • controle de produção

  • restart de jobs

  • monitoramento

  • escalonamento de incidentes

  • IPL supervisionado

  • gerenciamento de spool

Ele não altera profundamente o sistema operacional.

Ele mantém o ambiente funcionando.

Na prática:

O SYSOPS é o bombeiro do datacenter.

Quando algo explode às 3 da manhã…
é ele quem atende primeiro.


☕ O SYSADMIN — O ADMINISTRADOR DA INFRAESTRUTURA

Aqui começa a confusão.

Em ambiente distribuído, o termo “SysAdmin” virou quase genérico.

Mas no Mainframe ele normalmente representa o administrador das plataformas, serviços e infraestrutura operacional.

O SYSADMIN trabalha mais próximo de:

  • storage

  • rede

  • segurança

  • USS (Unix System Services)

  • servidores conectados

  • middleware

  • integração

  • backups

  • automação corporativa

  • usuários

  • políticas operacionais

Dependendo da empresa, o SYSADMIN pode administrar:

  • RACF

  • TCP/IP

  • FTP

  • Connect:Direct

  • IBM MQ

  • Unix Services

  • certificados digitais

  • permissões

  • ambientes Linux on Z


☕ O SYSADMIN NÃO É O “DONO DO z/OS”

Esse é um erro clássico.

O SYSADMIN normalmente administra SERVIÇOS sobre o sistema.

Mas quem domina o núcleo profundo do z/OS…
é outra criatura.

O lendário:
SYSPROG.


☕ O SYSPROG — O ENGENHEIRO DO PRÓPRIO SISTEMA OPERACIONAL

Se o SYSOPS é o bombeiro…
e o SYSADMIN administra a infraestrutura…

o SYSPROG é literalmente o arquiteto do universo z/OS.

Esse profissional mexe onde poucos têm coragem de tocar.

Ele trabalha diretamente com:

  • núcleo do z/OS

  • PARMLIB

  • PROCLIB

  • SMP/E

  • IPL

  • APF

  • LPA

  • exits

  • subsistemas

  • JES2

  • WLM

  • VTAM

  • HCD

  • IOCDS

  • catálogos

  • performance

  • tuning

  • dumps

  • manutenção do sistema

O SYSPROG instala produtos IBM.
Aplica PTFs.
Resolve loops de sistema.
Analisa S0C4.
Debuga ABENDs complexos.
Reconstrói ambientes inteiros após falhas críticas.

Ele não administra “aplicações”.

Ele administra o próprio z/OS.


☕ O DIA EM QUE TODO MUNDO DESCOBRE QUEM É O SYSPROG

Existe um momento clássico em todo datacenter.

Quando tudo funciona…
ninguém lembra do SYSPROG.

Mas basta acontecer:

  • IPL falhar

  • catálogo corromper

  • JES2 não subir

  • LOOP no sistema

  • pane de storage

  • conflito de APF

  • erro de SMP/E

  • VTAM cair

  • WLM enlouquecer

E então o telefone toca.

Porque existe uma verdade silenciosa no Mainframe:

Quando o sistema operacional entra em guerra…
o SYSPROG vira a última linha de defesa do datacenter.


☕ RESUMINDO A GRANDE DIFERENÇA

🖥️ SYSOPS

Opera o ambiente em tempo real.

Foco:
produção, monitoramento, operação e resposta imediata.


🔐 SYSADMIN

Administra infraestrutura e serviços.

Foco:
segurança, rede, middleware, usuários, integração e plataformas.


⚙️ SYSPROG

Administra e engenharia o próprio z/OS.

Foco:
kernel do sistema, performance, instalação, manutenção e arquitetura técnica.


☕ POR QUE O MAINFRAME SEPAROU ESSES PAPÉIS?

Porque o IBM Mainframe sempre foi grande demais para uma única pessoa dominar tudo.

Um ambiente z/OS corporativo pode processar:

  • bilhões de transações

  • milhões de clientes

  • centenas de subsistemas

  • milhares de jobs

  • dezenas de LPARs

Separar responsabilidades não é burocracia.

É sobrevivência operacional.

Cada especialista protege uma camada crítica da plataforma.

E quando os três trabalham alinhados…
o datacenter vira uma máquina praticamente indestrutível.


☕ A VERDADE QUE O MAINFRAME ENSINOU AO MUNDO

Enquanto muitos ambientes modernos tentaram transformar um único profissional em “faz-tudo”…

o Mainframe seguiu outro caminho:
especialização profunda.

Porque em ambientes que movimentam dinheiro real, governo real e infraestrutura nacional…

não existe espaço para improviso.

Existe operação.
Existe engenharia.
Existe responsabilidade.

E por trás de cada grande sistema z/OS funcionando silenciosamente…

sempre haverá:
um SYSOPS atento,
um SYSADMIN organizando o ecossistema,
e um SYSPROG sustentando o coração do universo IBM Mainframe.

sábado, 13 de abril de 2024

Conheça unidade de armazenamento CARTRIDGE Storage


A
storage mainframe cartridge e robot de leitura

FUJIFILM Corporation e a IBM anunciaram o desenvolvimento de um sistema de armazenamento em fita nativo de 50 TB, apresentando a maior capacidade nativa de cartucho de fita de dados do mundo.




 

sexta-feira, 12 de abril de 2024

Uma visão geral sobre o trabalhador de Mainframe

Equipe de desenvolvimento mainframe


Descubra a Stack MAINFRAME e veja o que necessita para ser um Desenvolvedor COBOL de Sucesso. Aprenda COBOL, há 65 anos revolucionando o mercado de informática.
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...