☕ 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

quarta-feira, 25 de outubro de 2023

COBOL Recursivo sem Mistérios

 

Bellacosa Mainframe dicas e pratica em cobol mainframe recursivo

☕ Um Café no Bellacosa Mainframe

COBOL Recursivo sem Mistérios

Como Programar Funções Recursivas e Percorrer Árvores B como um Oficial da Frota Estelar

"A maioria dos programadores COBOL passa décadas escrevendo programas sem nunca utilizar recursividade. Não porque ela não exista. Mas porque o universo do processamento batch sempre favoreceu algoritmos iterativos. Entretanto, quando você entra no mundo de compiladores, parsers, XML, JSON, árvores de decisão, estruturas hierárquicas e inteligência artificial, descobrirá que existe uma arma secreta escondida dentro do Enterprise COBOL."

Prepare seu café.

Hoje o Capitão Kirk autorizou acesso aos bancos de dados mais profundos da USS Enterprise.

Vamos explorar uma tecnologia que muitos acreditam que COBOL "não possui".

Possui.

E muito bem.


O mito

Existe uma frase repetida há décadas:

"COBOL não suporta recursividade."

Isso era verdade...

...há muitos anos.

Desde o Enterprise COBOL moderno, programas podem chamar a si próprios.

Basta utilizar as opções corretas do compilador.

E entender o que realmente acontece na memória.


O que é recursividade?

Recursividade é quando um programa chama...

...ele mesmo.

Exemplo extremamente simples.

Imagine contar regressivamente.

5
4
3
2
1
Fim

Ao invés de fazer:

PERFORM VARYING

fazemos

CONTAR(5)

↓

CONTAR(4)

↓

CONTAR(3)

↓

CONTAR(2)

↓

CONTAR(1)

Cada chamada cria uma nova execução independente.


Pensando como Spock

Spock não resolveria um problema inteiro.

Ele dividiria.

Sempre.

Existe solução?

↓

Resolva um pedaço

↓

O restante é igual

↓

Chame novamente

Isso é exatamente recursividade.


Como o COBOL consegue fazer isso?

Cada chamada cria uma nova área de trabalho.

Ela contém:

  • variáveis locais

  • parâmetros

  • ponteiros

  • retorno

Tudo fica armazenado na pilha (Stack).

Visualmente.

MAIN

↓

PROGRAMA

↓

PROGRAMA

↓

PROGRAMA

↓

PROGRAMA

Cada nível ocupa memória.


Por isso existe um risco

Se esquecer a condição de parada...

Programa

↓

Programa

↓

Programa

↓

Programa

↓

Programa

↓

Programa

↓

Programa

Nunca termina.

Resultado:

Stack Overflow

Ou

S878

S80A

Storage Exhausted

Dependendo do ambiente.


A regra número 1

Toda função recursiva precisa possuir uma condição de parada.

Sempre.

Exemplo.

IF N = ZERO
    EXIT
END-IF

Sem isso...

adeus memória.


Ativando recursividade

No Enterprise COBOL normalmente utiliza-se

RECURSIVE

na identificação do programa.

IDENTIFICATION DIVISION.

PROGRAM-ID. TREESEARCH
    RECURSIVE.

ou opção equivalente do compilador dependendo da versão.

Outra prática comum é utilizar:

RENT

para permitir reentrância.


Reentrante x Recursivo

São conceitos diferentes.

Reentrante

→ vários usuários usam ao mesmo tempo.

Recursivo

→ o programa chama ele próprio.

Pode existir:

✔ Reentrante

sem ser

✔ Recursivo.


Quando utilizar?

Quando o problema possui natureza hierárquica.

Por exemplo.

Árvore.

XML.

JSON.

AST de compilador.

Pastas.

Menus.

Dependências.

Organogramas.

Genealogia.

Árvore de chamadas.


Imagine uma árvore B

Uma árvore B organiza registros.

             40

      20            60

   10   30      50     70

Encontrar um valor nela é extremamente elegante usando recursividade.


Estrutura lógica

Cada nó possui

Valor

Filho esquerdo

Filho direito

No COBOL real normalmente usamos tabelas e índices.

Exemplo didático.

NODE-ID

LEFT-CHILD

RIGHT-CHILD

Nossa missão

Encontrar

50

Algoritmo

Primeiro olhamos

40

50 é maior.

Então ignoramos todo lado esquerdo.

Seguimos para direita.

60

Agora

50 é menor.

Voltamos para esquerda.

Encontramos

50

Fim.


Em pseudocódigo

SEARCH(NODE)

IF NODE = NULL
    NÃO EXISTE

IF NODE = CHAVE
    ENCONTROU

SE CHAVE < NODE
    SEARCH(LEFT)

SENÃO
    SEARCH(RIGHT)

Perceba.

O algoritmo inteiro possui poucas linhas.

Porque ele reutiliza a própria lógica.


Exemplo COBOL simplificado

IDENTIFICATION DIVISION.
PROGRAM-ID. TREESEARCH RECURSIVE.

WORKING-STORAGE SECTION.

01 WS-KEY          PIC 9(4).

LINKAGE SECTION.

01 LK-NODE.
   05 LK-VALUE     PIC 9(4).
   05 LK-LEFT      POINTER.
   05 LK-RIGHT     POINTER.

PROCEDURE DIVISION USING LK-NODE.

    IF LK-NODE = NULL
        GOBACK
    END-IF

    IF WS-KEY = LK-VALUE
        DISPLAY "ENCONTRADO"
        GOBACK
    END-IF

    IF WS-KEY < LK-VALUE
        CALL "TREESEARCH"
             USING LK-LEFT
    ELSE
        CALL "TREESEARCH"
             USING LK-RIGHT
    END-IF.

    GOBACK.

Este exemplo é conceitual. Em aplicações reais, árvores costumam ser representadas por tabelas indexadas, estruturas dinâmicas com ALLOCATE/FREE (quando suportado) ou áreas obtidas por serviços do sistema.


Observe a mágica

O programa nunca pergunta

Estou no nível 2?

Estou no nível 5?

Estou no nível 30?

Ele simplesmente chama ele mesmo.


Visualizando a pilha

SEARCH(40)

↓

SEARCH(60)

↓

SEARCH(50)

↓

Encontrado

Depois começa retornar.

SEARCH(50)

↓

SEARCH(60)

↓

SEARCH(40)

↓

MAIN

É literalmente uma subida e descida.


O retorno automático

Cada chamada lembra onde parou.

Imagine.

A chama B

↓

B chama C

↓

C chama D

Quando D termina.

Volta para C.

Depois B.

Depois A.

Sem que você precise controlar isso.


Onde COBOL utiliza isso na prática?

Mais do que muitos imaginam.

Ferramentas IBM fazem uso intenso.

Compiladores COBOL.

Parser SQL.

Parser XML.

JSON Parser.

XPath.

XSD.

Analisadores sintáticos.

Motores de regras.


Árvore B em bancos

Db2 utiliza árvores B (B-Trees).

Quando fazemos

SELECT

WHERE CPF

O banco NÃO lê milhões de registros.

Ele navega pela árvore.

Raiz

↓

Nó

↓

Folha

Pouquíssimos acessos.


Curiosidade

Quando você cria

CREATE INDEX

Na prática.

Está construindo uma enorme árvore balanceada.


Então...

Todo programador COBOL usa árvore B.

Mesmo sem perceber.


Mas...

Devemos escrever árvore recursiva sempre?

Não.

Existe um preço.


CPU

Cada chamada possui custo.

Salvar registradores

↓

Criar stack frame

↓

Passar parâmetros

↓

Retornar

Tudo isso consome CPU.


Memória

Cada chamada cria.

Variáveis

Endereço retorno

Parâmetros

Estado

Imagine 100.000 níveis.

Pode explodir.


Comparando

Iterativo

WHILE

Consome

CPU menor

Memória fixa

Recursivo

CPU maior

Stack crescente

Então por que usar?

Porque alguns problemas ficam absurdamente mais simples.

Exemplo.

Árvore.

Iterativo

300 linhas

Recursivo

40 linhas

Mais fácil.

Mais elegante.

Menos bugs.


Quando evitar?

Processamento sequencial.

Leitura VSAM.

Arquivo QSAM.

Loops simples.

Relatórios.

Batch tradicional.

Nestes casos.

PERFORM VARYING

vence.


Tail Recursion

Existe uma otimização famosa.

Tail Recursion.

Função termina chamando ela mesma.

Alguns compiladores eliminam o crescimento da pilha.

Infelizmente.

Nem todo compilador COBOL faz isso.

Portanto.

Nunca conte com essa otimização.


Cuidado com milhões de chamadas

Imagine uma árvore degenerada.

10

 \

 20

   \

   30

     \

     40

Ela parece uma lista.

A recursividade fará milhares de chamadas.

Ruim.

Árvores balanceadas evitam isso.


B-Tree resolve exatamente este problema

Ela mantém altura pequena.

Mesmo com milhões de registros.

É justamente por isso que bancos usam B-Tree.

Não Binary Tree simples.


Dica de ouro

Nunca escreva recursividade sem antes responder:

Qual é minha condição de parada?

Se não conseguir responder.

Ainda não terminou o algoritmo.


Outra dica

Desenhe.

Sempre.

Árvores ficam muito mais fáceis no papel.


Debug

Durante testes faça:

DISPLAY

Mostrando o nível.

DISPLAY "LEVEL=" WS-NIVEL

Assim você visualiza a profundidade.


Performance em Mainframe

No IBM Z.

CPU é dinheiro.

Cada microssegundo importa.

Por isso.

Recursividade costuma aparecer mais em:

  • middleware

  • compiladores

  • parsers

  • XML

  • JSON

  • IA

  • engines

Do que em batch financeiro.


Curiosidade histórica

Nos anos 70.

Poucos compiladores COBOL aceitavam recursividade.

A memória era extremamente cara.

Muitas máquinas tinham poucos megabytes.

Era impensável desperdiçar stack.

Hoje.

Servidores IBM Z possuem centenas de gigabytes.

O cenário mudou.


Boas práticas

✔ Sempre tenha condição de parada clara.

✔ Documente a lógica antes de codificar.

✔ Prefira árvores balanceadas.

✔ Limite profundidade quando possível.

✔ Evite variáveis globais compartilhadas.

✔ Teste casos extremos.

✔ Monitore consumo de CPU e memória.

✔ Utilize recursividade apenas quando ela realmente simplifica o problema.

✔ Faça revisão de código focando em chamadas recursivas.

✔ Meça desempenho antes de concluir que a solução é "rápida".


Armadilhas comuns

❌ Esquecer a condição de parada.

❌ Modificar dados globais inesperadamente.

❌ Assumir que toda árvore é balanceada.

❌ Ignorar consumo de stack.

❌ Trocar elegância por complexidade desnecessária.

❌ Usar recursividade onde um PERFORM VARYING resolveria de forma mais simples.


Recursividade e Enterprise COBOL

As versões modernas do IBM Enterprise COBOL oferecem suporte a programas recursivos, mas é importante observar alguns detalhes:

  • Declare o programa como RECURSIVE quando necessário.

  • Utilize opções de compilação adequadas ao ambiente, frequentemente combinadas com RENT em aplicações compartilhadas.

  • Consulte sempre o padrão adotado pela sua empresa e a documentação da versão do compilador em uso, pois políticas de compilação variam entre instalações.

Em ambientes CICS, IMS ou aplicações de alta concorrência, também é essencial compreender os conceitos de reentrância, armazenamento automático e áreas de trabalho para evitar efeitos colaterais entre execuções simultâneas.


Missão para o Padawan COBOL

Depois de dominar este artigo, experimente implementar os seguintes desafios:

  1. Fatorial usando recursividade.

  2. Sequência de Fibonacci (comparando desempenho com versão iterativa).

  3. Percorrer uma árvore binária em ordem (in-order).

  4. Percorrer uma árvore em pré-ordem (pre-order).

  5. Percorrer uma árvore em pós-ordem (post-order).

  6. Simular um índice de clientes usando uma árvore binária simples.

  7. Comparar o tempo de busca entre uma tabela sequencial e uma árvore.

  8. Criar um visualizador com DISPLAY mostrando o nível de cada chamada recursiva.

Cada exercício ajudará você a entender não apenas como a recursividade funciona, mas quando ela é realmente a melhor ferramenta.

Conclusão — O Holodeck da Recursividade

Existe uma lição que diferencia um programador comum de um verdadeiro oficial da Frota Estelar.

O iniciante procura resolver problemas escrevendo mais código.

O engenheiro experiente procura resolver problemas encontrando a estrutura correta.

A recursividade é exatamente isso: uma mudança de perspectiva. Em vez de atacar um problema gigantesco de uma única vez, você o divide em pequenas partes idênticas, permitindo que o próprio algoritmo repita a solução até alcançar a condição de parada.

No universo do COBOL, ela não substitui os tradicionais PERFORM VARYING, nem foi criada para processar milhões de registros sequenciais de um batch financeiro. Seu verdadeiro poder aparece quando trabalhamos com estruturas hierárquicas: árvores B, XML, JSON, compiladores, interpretadores, mecanismos de regras, grafos e diversos algoritmos modernos que fazem parte da computação atual.

Como diria o Sr. Spock:

"A solução mais elegante normalmente é aquela que respeita a estrutura natural do problema."

Quando você compreender essa filosofia, deixará de enxergar a recursividade como um truque de linguagem e passará a vê-la como uma ferramenta de modelagem.

E esse é um dos momentos em que um Padawan COBOL começa a trilhar o caminho para se tornar um verdadeiro Mestre do Mainframe.


terça-feira, 24 de outubro de 2023

Docker sem Mistérios : O Guia Definitivo para um Programador COBOL Padawan Entender Containers, DevOps e a Nova Engenharia de Software

Bellacosa Mainframe apresenta docker sem misterios

☕ Um Café no Bellacosa Mainframe

Docker sem Mistérios

O Guia Definitivo para um Programador COBOL Padawan Entender Containers, DevOps e a Nova Engenharia de Software

"Um programador COBOL experiente não demora muito para perceber que Docker não veio substituir o Mainframe. Veio apenas democratizar conceitos que os grandes ambientes corporativos praticam há décadas."

Existe uma curiosidade interessante sobre a evolução da tecnologia.

A cada dez ou quinze anos surge uma "nova revolução" que promete reinventar completamente a computação. Já aconteceu com orientação a objetos, Java, virtualização, cloud computing, microsserviços, Kubernetes, DevOps e, mais recentemente, Inteligência Artificial.

Mas quando olhamos um pouco mais profundamente, percebemos algo fascinante: quase todas essas revoluções não inventaram novos princípios. Elas apenas encontraram formas diferentes de aplicar conceitos que sempre existiram.

Docker é um excelente exemplo disso.

Para muitos desenvolvedores modernos, containers parecem uma tecnologia revolucionária. Para quem passou anos trabalhando com IBM Z, JES2, CICS, Db2, z/OS e COBOL, porém, Docker soa surpreendentemente familiar.

Este artigo não pretende ensinar apenas comandos. Seu objetivo é mostrar como um programador COBOL pode compreender Docker utilizando aquilo que já domina: engenharia de software, ambientes corporativos e sistemas críticos.


A maior mentira sobre Docker

Se você perguntar para um iniciante:

"O que é Docker?"

Provavelmente ouvirá:

"É uma ferramenta para criar containers."

Essa resposta está tecnicamente correta.

Mas está completamente incompleta.

Docker nunca foi apenas uma ferramenta.

Docker é uma solução para um problema antigo.

Imagine uma aplicação Java.

Ela funciona perfeitamente no computador do desenvolvedor.

Quando chega ao servidor...

Nada funciona.

Falta uma biblioteca.

A versão do Java é diferente.

Existe conflito de dependências.

Uma variável de ambiente está ausente.

Uma DLL não existe.

Um certificado expirou.

A famosa frase aparece:

"Na minha máquina funciona."

Durante décadas essa frase custou milhões de dólares às empresas.

Docker nasceu justamente para eliminar esse problema.


O verdadeiro objetivo dos Containers

Containers não existem para economizar memória.

Nem para facilitar deploy.

Nem para executar microsserviços.

Tudo isso é consequência.

O verdadeiro objetivo é tornar o ambiente reproduzível.

Ou seja...

A aplicação leva consigo tudo aquilo que precisa.

Bibliotecas.

Configurações.

Dependências.

Usuários.

Permissões.

Arquivos.

Versões.

Quando o container é iniciado, o ambiente é exatamente igual em qualquer computador.

Notebook.

Servidor.

Cloud.

Produção.

Homologação.

Tudo funciona da mesma forma.


O primeiro paralelo com o Mainframe

Esse conceito não é novo para quem vive no IBM Z.

Pense em um JOB.

Quando submetemos um JCL ao JES2, ele leva consigo:

  • o programa que será executado;

  • os parâmetros necessários;

  • os datasets de entrada;

  • os datasets de saída;

  • bibliotecas de carga;

  • bibliotecas COBOL;

  • DD Statements;

  • região de memória;

  • configurações específicas.

Perceba a semelhança.

O ambiente de execução já está definido antes mesmo do programa começar.

Docker segue exatamente essa filosofia.


Containers não são Máquinas Virtuais

Esse talvez seja o erro mais comum dos iniciantes.

Virtual Machine.

Container.

Parecem iguais.

Mas internamente são completamente diferentes.

Uma máquina virtual precisa simular praticamente um computador inteiro.

Hardware virtual.

BIOS.

Kernel.

Sistema operacional completo.

Drivers.

Depois disso...

Finalmente a aplicação.

Já um container compartilha o kernel do sistema operacional hospedeiro.

Ele isola apenas processos.

Isso muda completamente o consumo de recursos.

Enquanto uma VM pode levar minutos para iniciar, um container normalmente leva poucos segundos.

Às vezes milissegundos.


Easter Egg nº 1 — O Mainframe já fazia isso de outra forma

Uma curiosidade pouco comentada.

No IBM Z também buscamos compartilhar recursos ao máximo.

Milhares de usuários utilizam o mesmo kernel do z/OS.

Centenas de jobs compartilham CPU.

Diversas aplicações compartilham memória.

CICS executa milhares de transações simultaneamente.

Db2 atende milhares de conexões.

A filosofia sempre foi aproveitar recursos de maneira eficiente.

Docker segue exatamente essa linha.


Docker Images: o "Load Module" do mundo Cloud

Aqui aparece um dos conceitos mais importantes.

Muita gente acredita que:

Imagem = Container.

Não.

Imagem é apenas um molde.

Container é uma instância desse molde.

Para um programador COBOL isso faz muito sentido.

Primeiro escrevemos:

SOURCE.

Depois compilamos.

Geramos o OBJ.

Executamos o Link-Edit.

Criamos o Load Module.

Somente então um JOB executa aquele módulo.

O Load Module continua existindo mesmo após o JOB terminar.

O mesmo acontece com Docker.

A imagem permanece armazenada.

Os containers nascem e morrem quantas vezes forem necessárias.


Dockerfile: o PROC do mundo Linux

O Dockerfile é talvez o arquivo mais importante de toda a plataforma.

Ele descreve passo a passo como construir uma imagem.

Não existe mágica.

Existe automação.

Cada instrução representa uma ação.

FROM.

COPY.

RUN.

ENV.

WORKDIR.

CMD.

É como escrever um PROC extremamente sofisticado.

Em vez de apenas indicar o programa a ser executado, você descreve toda a preparação do ambiente.

Instale Java.

Configure usuários.

Copie arquivos.

Crie diretórios.

Abra portas.

Defina variáveis.

No final, qualquer computador consegue reproduzir exatamente aquele ambiente.


Easter Egg nº 2 — As Layers lembram muito o SMP/E

Pouca gente percebe isso.

Cada comando do Dockerfile cria uma nova camada.

Essas camadas são reutilizadas automaticamente.

Se apenas uma linha mudou...

Docker recompõe somente aquela parte.

Isso reduz drasticamente tempo de build.

No Mainframe existe um conceito parecido durante manutenção do sistema operacional.

O SMP/E também trabalha reutilizando componentes ao invés de reinstalar tudo novamente.

São tecnologias completamente diferentes.

Mas a filosofia é muito semelhante.


O ciclo de vida de um Container

Todo container passa pelos mesmos estados.

Imagem.

Container criado.

Executando.

Parado.

Removido.

Nada disso significa que a aplicação desapareceu.

A imagem continua disponível.

Basta criar outra instância.

Para um profissional COBOL isso lembra imediatamente:

Programa compilado.

JOB submetido.

Executando.

Finalizado.

Novo JOB.

O programa continua existindo.

Quem nasce e morre é a execução.


Docker Networking

Talvez o assunto mais negligenciado pelos iniciantes.

Sem comunicação...

Não existe aplicação corporativa.

Imagine um banco.

O sistema precisa conversar com:

Db2.

Servidor Web.

Fila MQ.

API.

Cache.

Monitoramento.

Autenticação.

Cada componente precisa se comunicar de forma segura.

Docker oferece diferentes estratégias.

Bridge.

Host.

Overlay.

MacVLAN.

None.

Cada uma resolve um problema específico.


Easter Egg nº 3 — Overlay lembra muito Sysplex

Overlay permite que containers distribuídos em diversos servidores conversem como se estivessem na mesma rede.

Agora pense um pouco.

Isso lembra bastante um Parallel Sysplex.

Diversos sistemas físicos trabalhando praticamente como um único ambiente lógico.

Mais uma vez...

A tecnologia mudou.

A ideia continua a mesma.


Volumes: onde mora o maior erro dos iniciantes

Container é descartável.

Dados não.

Esse conceito parece simples.

Mas produz inúmeros problemas.

Imagine gravar arquivos importantes dentro do container.

Depois alguém executa:

docker rm.

Tudo desaparece.

Por isso existem Volumes.

Eles armazenam informações fora do ciclo de vida do container.

No Mainframe isso seria equivalente a gravar dados em um Dataset permanente ao invés de um arquivo temporário.

O programa termina.

O dataset continua.


Compose: descrevendo toda uma arquitetura

Imagine uma aplicação moderna.

Banco PostgreSQL.

Redis.

API Java.

Frontend.

Servidor NGINX.

Fila RabbitMQ.

Sem Docker Compose seria necessário iniciar cada serviço individualmente.

Com Compose tudo fica descrito em um único arquivo YAML.

Uma simples instrução coloca toda a arquitetura em funcionamento.

docker compose up.

Isso lembra muito a filosofia declarativa dos grandes ambientes corporativos.

PROC.

Scheduler.

JCL.

Parâmetros.

Tudo documentado.

Tudo reproduzível.


Logs contam histórias

Existe um conselho que todo especialista em Mainframe aprende cedo.

Nunca altere código antes de entender o problema.

E para entender o problema...

Leia os logs.

Docker possui um comando extremamente simples.

docker logs.

Mas sua importância é enorme.

Ali estão mensagens de erro.

Inicialização.

Dependências.

Falhas.

Exceções.

No Mainframe fazemos exatamente a mesma coisa analisando JESMSGLG, SYSOUT, CEEDUMP, SMF, RMF e dumps do sistema.

Os logs sempre contam a história completa.


Registry: a biblioteca do mundo Cloud

Outra analogia interessante.

Docker Registry é um repositório de imagens.

Pense nele como uma gigantesca biblioteca de Load Modules.

As equipes publicam novas versões.

Outros ambientes apenas fazem download.

Tudo versionado.

Tudo controlado.

Tudo auditável.

Essa preocupação sempre existiu em ferramentas como Endevor, ISPW e ChangeMan.


A filosofia DevOps

Muitos profissionais acreditam que Docker e DevOps são sinônimos.

Não são.

Docker é apenas uma ferramenta.

DevOps é uma cultura.

Seu objetivo é reduzir a distância entre desenvolvimento e operação.

Automatizar.

Versionar.

Testar.

Monitorar.

Implantar continuamente.

Curiosamente...

Grandes ambientes IBM Z já possuíam muitos desses processos muito antes da popularização do termo DevOps.

Existiam mudanças controladas.

Promoções entre ambientes.

Auditoria.

Versionamento.

Controle de acesso.

Separação entre desenvolvimento e produção.

O que mudou foi o grau de automação.


Docker e Kubernetes

Depois que um profissional domina Docker, naturalmente surge outra pergunta.

Quem gerencia centenas ou milhares de containers?

A resposta é Kubernetes.

Mas aqui existe outro paralelo interessante.

Docker executa containers.

Kubernetes coordena containers.

No Mainframe temos algo semelhante.

O sistema operacional executa workloads.

O WLM decide prioridades.

O Sysplex distribui carga.

O SA z/OS automatiza recuperação.

Novamente...

Não são tecnologias iguais.

Mas resolvem problemas parecidos.


Curiosidades que poucos conhecem

Docker surgiu em 2013 como um projeto da empresa dotCloud, que posteriormente passou a se chamar Docker Inc.

Entretanto, a tecnologia de containers é muito mais antiga.

Ela aproveita recursos do kernel Linux chamados namespaces e cgroups, desenvolvidos anos antes do Docker existir.

Outros sistemas operacionais também possuíam conceitos semelhantes, como Solaris Zones e FreeBSD Jails.

Ou seja...

Docker não inventou containers.

Ele tornou containers acessíveis para milhões de desenvolvedores.


O verdadeiro impacto na carreira de um Programador COBOL

Talvez você esteja pensando:

"Mas eu trabalho com Mainframe. Por que deveria aprender Docker?"

A resposta é simples.

Porque praticamente toda arquitetura moderna conversa com containers.

APIs.

Microsserviços.

CI/CD.

Pipelines.

Integração contínua.

OpenShift.

Kubernetes.

Cloud híbrida.

Mesmo que o seu COBOL continue executando no IBM Z, ele provavelmente será integrado a aplicações empacotadas em containers.

Entender Docker deixa de ser um diferencial.

Passa a ser uma competência estratégica.


O maior ensinamento

Existe uma frase que resume tudo o que vimos.

Ferramentas mudam.

Princípios permanecem.

Um bom engenheiro de software não memoriza centenas de comandos.

Ele compreende conceitos.

É justamente por isso que muitos profissionais IBM Z aprendem Docker, Kubernetes e DevOps com relativa facilidade.

Eles já conhecem os fundamentos.

Sabem o valor da padronização.

Da automação.

Da confiabilidade.

Da rastreabilidade.

Da observabilidade.

Da documentação.

Da recuperação de falhas.

Da estabilidade operacional.

Docker apenas apresenta esses princípios com uma nova interface.

E talvez essa seja a maior lição deste artigo.

Quando um Programador COBOL Padawan olha para Docker pela primeira vez, ele pode enxergar apenas uma tecnologia moderna da nuvem. Mas quando começa a compreender sua arquitetura, percebe algo muito mais profundo: grande parte das ideias consideradas "inovadoras" já fazia parte da cultura do Mainframe havia décadas. A verdadeira evolução não está em abandonar o passado, e sim em reconhecer que os melhores fundamentos da engenharia de software atravessam gerações de plataformas. Quem domina esses fundamentos consegue transitar naturalmente entre IBM Z, Linux, Cloud, Kubernetes e Inteligência Artificial, porque entende que linguagens, ferramentas e interfaces mudam continuamente, mas os princípios que sustentam sistemas críticos continuam exatamente os mesmos. Esse é o verdadeiro caminho do Mestre Bellacosa: não decorar tecnologias, mas compreender a engenharia que existe por trás delas.

segunda-feira, 23 de outubro de 2023

💫 Adeus, Lili — Crônica de uma amizade que atravessou oceanos

 


💫 Adeus, Lili — Crônica de uma amizade que atravessou oceanos
Por El Jefe, no Bellacosa Mainframe Midnight Edition

Existem amizades que não nascem de explosões épicas ou grandes coincidências do destino — mas de pequenas linhas de código da vida, compiladas com carinho ao longo dos anos. A minha com a Lili começou assim, em 1997, nos corredores do programa de trainees do Banco Real. Cada um na sua turma, cada um com sua pressa e sonhos. Mas, por um bug do universo — ou talvez uma benção — no sorteio do amigo secreto, caiu o nome dela: Lilian Yumi.



A partir dali, começou a rodar um job que duraria quase três décadas, com checkpoints de risadas, abends de brigas e reprocessamentos de amizade que só quem viveu entende.

Lili era intensa. Escorpiana no modo ON FIRE. daquelas que quando ficava brava, o ambiente inteiro dava abend S0C7. Às vezes, a fúria era contra mim — o “Capitão”, como ela gostava de me chamar. 

Brava, decidida, dona de uma energia que iluminava o andar inteiro — e às vezes queimava um ou outro no processo (eu, especialmente 😅). Quando algo saía do controle, ela vinha com a fúria típica do signo... e eu virava o alvo. 



Mas bastava o dump esfriar que vinha aquele jeitinho doce, um sorrisinho meio sem jeito e o clássico:

“Desculpa, Capitão. Foi mal.”

Aí ríamos juntos. Ríamos muito.
Ríamos da vida, dos bugs, das gambiarras, dos pepinos do sistema e dos planos malucos que fazíamos nas Horas Felizes — nosso ritual sagrado de toda semana. Fosse a marmita dividida no refeitório, fosse um restaurante étnico qualquer, o importante era estarmos juntos: eu, ela, o grupo, as histórias, as confabulações.



Conheci seus namorados — Henrique, Tokunaga, e o Alexandre, que acabou incorporado oficialmente ao grupo, como um novo módulo num sistema legado de amizade.



Em 2002, meu destino me levou para Portugal. Mas mesmo com o Atlântico no meio, nunca deixamos de manter a thread viva: emails, mensagens, reencontros ocasionais. Cada vez que eu voltava ao Brasil, lá estava ela — o mesmo sorriso, as mesmas histórias, as mesmas piadas internas que só quem viveu o Mainframe e o Banco Real entenderia.




Em 2013 voltei de vez. E a roda girou de novo — agora era ela quem partia. Canadá, novas terras, novos sonhos. A vida muda o cenário, mas nunca o vínculo.

Da época que trabalhávamos juntos, me lembro dos origamis que enfeitavam sua mesa, dos pequeninos pokemons e guardo com carinho quando começou a jornada dos mil tsurus... às vezes ajudava cortando o papel, às vezes ajudando a dobrar, era uma farra, momentos lúdicos entre um abend ou outro. Lembro dos códigos secretos e pings no computador avisando algo, que estava acontecendo no andar, ou mesmo a linguagem secreta, ao ve-la pela manha pingando buscapan na boca, sabia que aqueles dias seriam de pisar em ovos, senão levava com taco de beisebol na cabeça. A também tinha a fuga para a maquina do café e fofocas aleatórias sobre filmes, series, animes, livros, mangas, gibis e Pokémons.

Hoje, ao escrever estas linhas na penumbra da madrugada — quando as ideias ecoam e as lembranças gritam mais alto — percebo o quanto essas Horas Felizes foram um checkpoint eterno na minha história.

A Lili partiu.
Mas o job da amizade continua rodando — lá, em algum sistema maior, onde as exceções são tratadas com amor e as memórias nunca dão abend.



Adeus, Lili.
Obrigado pelas risadas, pelas broncas, pelos almoços, pelas confabulações e por ter deixado tanta luz no meu spool de lembranças.
Enquanto eu viver, o log da nossa amizade continuará ativo.

☕💻
*E lá no topo do JCL da vida, deixo registrado: //LILI FOREVER EXEC PGM=FRIENDSHIP


PS: 📓 Uma história real nascida nos bastidores do Banco Real, escrita nas madrugadas do El Jefe Midnight Lunch





🕯️ Em memória de Lilian Yumi Nishimaru (1979–2023)
👨‍💻 Por Vagner Bellacosa


📍 Blog El Jefe Midnight Lunch — onde a madrugada é produtiva, o coração é nostálgico e o Mainframe é eterno.



🎨 Parte 4 – Do Isolamento à Inspiração: Hikikomori e a Arte da Solidão Criativa

🎨 Parte 4 – Do Isolamento à Inspiração: Hikikomori e a Arte da Solidão Criativa



Ecos criativos de um quarto fechado


🌑 Introdução – Quando o Silêncio se Transforma em Voz

Há um momento, entre a madrugada e o amanhecer, em que o quarto do hikikomori parece respirar.
É o som do teclado, o brilho do monitor, o vapor do café frio.
Lá fora, o mundo dorme — aqui dentro, nasce uma ideia.

O isolamento que um dia foi refúgio começa a se tornar laboratório.
E o hikikomori, antes prisioneiro do próprio silêncio, descobre que dentro dele mora um artista.


🕯️ O Casulo da Criação

O hikikomori não foge da sociedade por ódio — mas por sensibilidade.
Ele sente demais.
E esse excesso, quando canalizado, se transforma em arte introspectiva, carregada de melancolia, ironia e lucidez.

No Japão, muitos artistas, escritores e desenvolvedores começaram suas jornadas em isolamento.
A solidão os forçou a olhar para dentro — e ali encontraram universos inteiros.

“O quarto é o estúdio do inconsciente.”
Bellacosa


💾 Criação no Silêncio – Obras Nascidas do Recolhimento

🖥️ 1. Dōjin Games e Visual Novels

Muitos hikikomoris transformaram o quarto em pequenos estúdios de desenvolvimento.
Sozinhos, criaram jogos independentes, narrativas visuais e romances interativos.

📌 Exemplo:
“OneShot”, “Yume Nikki” e “Omori” nasceram de mentes reclusas.
São obras profundamente existenciais, onde o jogador explora mundos mentais, sonhos e memórias — reflexo direto da vida interior de seus criadores.


📚 2. Escritores e Romancistas do Casulo

Alguns se tornam autores de light novels e webnovels, explorando a mesma temática que os cercava: isolamento, recomeço e mundos alternativos.

🌌 Exemplo:
O autor de “Re:Zero” começou publicando online em fóruns, escrevendo durante a madrugada enquanto vivia recluso.
A história de um jovem deslocado que acorda em outro mundo é, de certo modo, o grito simbólico do hikikomori:

“Quero renascer em um lugar onde eu possa existir sem vergonha.”


🎧 3. Músicos da Solidão Digital

No YouTube e no Niconico Douga, uma geração inteira de Vocaloid producers nasceu do isolamento.
Com pseudônimos e avatares, eles compõem melodias melancólicas e letras sobre ansiedade, tempo e autodescoberta.

🎶 Exemplo:
Hikikomori Demo Uta Itai” (“Mesmo recluso, ainda quero cantar”) tornou-se um pequeno hino para quem vive entre o online e o real.


🪞 O Isolamento como Espelho Filosófico

Na cultura japonesa, existe um termo: “Sabi” (寂) — a beleza que nasce da solidão.
O hikikomori, sem saber, vive essa filosofia.
Ele transforma o vazio em introspecção, o silêncio em insight.
E no lugar onde o mundo vê “fuga”, ele encontra forma e sentido.

Assim como monges zen se isolam em templos, o hikikomori se fecha em um quarto digital,
onde a iluminação não vem de velas, mas de monitores.


💡 Dicas Bellacosa – Como Transformar Solidão em Arte

  1. Crie um ritual – acenda uma luz suave, escolha uma música, abra o bloco de notas. Ritualizar o processo traz foco e calma.

  2. Transforme o tédio em prática – desenhe o mesmo personagem até encontrar a alma dele.

  3. Registre o invisível – tudo o que você sente pode ser escrito, desenhado ou musicado.

  4. A internet é ponte, não cela. Compartilhe algo, mesmo pequeno. A criação quer ser vista.

  5. Não busque perfeição. O quarto é o lugar do erro, e o erro é a semente da expressão.


🎭 Hikikomori Criador vs. Hikikomori Fantasma

TipoDescriçãoSímbolo
🕯️ CriadorTransforma o isolamento em disciplina criativaO artista da penumbra
🌫️ FantasmaDeixa-se apagar pelo próprio silêncioO eco do mundo não ouvido

A diferença entre eles é um pequeno gesto: continuar criando, mesmo sem aplausos.


🕊️ Conclusão – O Quarto Como Universo Interior

O hikikomori não precisa ser curado — precisa ser ouvido.
Pois dentro de cada quarto fechado há um universo não explorado,
uma constelação de ideias esperando um momento de coragem para brilhar.

E talvez, quando ele decidir abrir a cortina,
não seja para fugir do mundo —
mas para deixá-lo ver o que criou.


“O isolamento não mata a arte. Às vezes, é nele que ela nasce com mais verdade.”
Bellacosa

🌆 Amparo — a cidade que me escolheu



🌆 Amparo — a cidade que me escolheu
por El Jefe, Bellacosa Mainframe

Há cidades que escolhemos.
Mas há outras — raras, misteriosas — que nos escolhem primeiro.
Amparo foi assim: caí de paraquedas e, sem perceber, aterrissei dentro de um daqueles capítulos que mudam a trajetória da vida.

Carrego dela grandes e maravilhosas lembranças… mas também um furo no coração, desses que o tempo não remenda. Foi lá que aprendi que o amor pode ser abrigo e também partida.
Foi lá que me tornei um pouco mais frio, um pouco mais desconfiado do coração.



E, como toda boa história que insiste em ter continuação, voltei um dia — e reencontrei outro amor.
Os olhinhos azuis.
O coração gravado na árvore, ainda visível, resistindo à chuva e ao tempo.
O 23 de outubro, que se tornou data sagrada e melancólica.
Os apelidos carinhosos, a clandestinidade de Campinas, os finais de semana no banco da praça, o cinema da estação, o pastel mais famoso da cidade… e, claro, o algodão doce feito numa máquina centenária — doce até na lembrança.

Campinas virou depois minha armadilha favorita.
Mas Amparo… ah, Amparo foi o primeiro tom de uma melodia que nunca terminou.

Hoje, talvez aquela moça — agora senhora — nem se lembre mais de mim.
Mas eu ainda cultivo a memória, cuido dela com o mesmo zelo de quem guarda uma relíquia.
E, vez ou outra, entre um gole e outro, me pego suspirando…
porque há histórias que não pedem explicação.
Apenas acontecem, deixam marcas, e seguem colorindo o que fomos.




El Jefe, com um copo meio cheio e o coração meio vazio, lembrando que certas cidades não passam — elas permanecem. 🍷🌙


sábado, 21 de outubro de 2023

🌐 O Hikikomori e a Era Digital – Quando o Mundo Cabe em uma Tela

🌐 O Hikikomori e a Era Digital – Quando o Mundo Cabe em uma Tela

Bellacosa Mainframe e o hikikomori e a era digital


 Reflexões entre o silêncio e o pixel


💻 Introdução – O Quarto Iluminado pela Luz Azul

Há um brilho que nunca se apaga no quarto do hikikomori.
Não é o sol — é a tela.
O monitor torna-se janela, confidente e espelho.
Lá fora, o mundo é vasto e exigente. Aqui dentro, o universo é controlável, silencioso, feito de cliques e atalhos.

O hikikomori da era digital é a versão ampliada do eremita urbano.
Mas agora, em vez de solidão absoluta, ele encontra uma nova forma de existência conectada: invisível, mas onipresente.


⚙️ A Evolução Digital do Isolamento

Na década de 1990, os primeiros hikikomoris viviam isolados fisicamente e emocionalmente, cortando até o telefone.
Hoje, muitos estão hiperconectados — em fóruns, MMOs, streams e redes sociais — mas ainda afastados do convívio humano real.

A tecnologia transformou o isolamento em um estado híbrido:

  • Socialmente ausente, digitalmente ativo.

  • Invisível no bairro, presente no servidor.

  • Silencioso no mundo físico, eloquente no mundo virtual.

Essa é a nova solidão interativa: acompanhada, mas distante.


🌍 A Internet como Novo “Mundo Real”

O hikikomori digital encontrou algo que seus predecessores não tinham — um lugar onde ele pode existir sem corpo.

Nos fóruns japoneses como 2channel, nas comunidades do Reddit, nos mundos de MMORPGs ou nos metaversos,
eles recriam laços, identidades e propósitos.
Ali, não há julgamento de aparência, fracasso escolar ou emprego.
Há apenas o valor da presença e da palavra.

O hikikomori não desapareceu — ele migrou para o ciberespaço.


🕹️ Games e Mundos Virtuais – O Casulo Interativo

Para muitos, os jogos são mais do que passatempo: são territórios existenciais.
Em um RPG online, um jovem que teme sair de casa pode ser um guerreiro lendário, respeitado por centenas.
O teclado substitui a voz.
O avatar substitui o corpo.

🎮 Exemplo em Anime:
“Sword Art Online” e “Log Horizon” exploram a fusão entre o real e o virtual, onde o isolamento físico é compensado por conexões emocionais profundas no mundo digital.
Esses animes capturam perfeitamente o dilema moderno:

“Se posso viver plenamente em um jogo… por que sair dele?”


🧠 A Psicologia do Casulo Digital

O isolamento moderno não é apenas medo do mundo — é exaustão cognitiva.
Vivemos em uma era de sobrecarga informacional, onde tudo é visível, comparável e medido.
A retração, então, torna-se um ato de defesa da mente.

O hikikomori digital não necessariamente foge das pessoas; ele foge da pressão de ser observado o tempo todo.
A internet lhe oferece algo precioso:
anonimato — a liberdade de existir sem ser julgado.


🔍 Curiosidades da Era Digital

  • Estima-se que 40% dos hikikomoris japoneses têm alguma forma de interação online regular — jogos, fóruns ou streams.

  • O Japão criou espaços chamados “Net Cafés Refúgio”, onde pessoas vivem e trabalham totalmente conectadas.

  • Alguns hikikomoris se tornaram YouTubers, artistas digitais e programadores freelancers, transformando o isolamento em produção criativa.

  • Há inclusive o termo “Netto-Hikikomori”, usado para quem vive exclusivamente em ambientes virtuais.


☕ Filosofia Bellacosa – Entre o Ser e o Clicar

O hikikomori moderno é o novo andarilho da era digital.
Ele não percorre estradas — percorre redes.
Não fala em praças — escreve em fóruns.
Não busca abrigo físico — busca comunhão simbólica.

Mas há algo de poético nisso:
talvez ele seja o primeiro a entender que o humano e o digital não são opostos, mas extensões.
Um corpo pode se isolar, mas a mente sempre buscará um lugar para existir.

“Os fios da rede são como raízes. Mesmo longe da luz, ainda tentam tocar o mundo.”


🌱 Dicas e Caminhos de Retorno

  1. Não demonize o isolamento — ele também é um mecanismo de cura.

  2. Transforme o consumo em criação — escreva fanfics, desenhe, programe, compartilhe.

  3. Crie microconexões — uma mensagem, um fórum, um grupo de estudo.
    Pequenas presenças curam grandes silêncios.

  4. Redefina sucesso — não é voltar a “ser normal”, mas voltar a se sentir vivo.


🌙 Conclusão – Entre o Pixel e o Pulso

O hikikomori digital é o filósofo oculto do nosso tempo.
Ele vive na fronteira entre o humano e o algoritmo, onde a existência é medida em bytes e emoções.
Mas, mesmo em silêncio, ele nos ensina algo essencial:

“Desconectar-se do mundo pode ser a forma mais profunda de tentar compreendê-lo.”

Talvez, no fim, o desafio não seja “trazer o hikikomori de volta ao mundo”,
mas reconstruir um mundo onde ele queira voltar.

sexta-feira, 20 de outubro de 2023

Moonstone Island : Quando um Programador COBOL Descobre que um Ambiente Distribuído Pode Ter Mais de Cem Servidores.

 

Bellacosa Mainframe apresenta o moonstone island

☕ Um Café no Bellacosa Mainframe

Moonstone Island sem Mistérios

Quando um Programador COBOL Descobre que um Ambiente Distribuído Pode Ter Mais de Cem Servidores... E Cada Ilha Guarda um Serviço Diferente Esperando para Ser Integrado

Existe uma característica comum nos RPGs modernos.

Normalmente existe um único continente.

Uma única capital.

Uma grande estrada.

Tudo gira em torno daquele mundo.

Moonstone Island resolve quebrar completamente essa lógica.

Em vez de um continente...

Existem mais de uma centena de ilhas flutuando pelos céus.

Cada uma possui:

  • biomas próprios;

  • recursos diferentes;

  • espíritos mágicos;

  • masmorras;

  • segredos.

Você não explora um mundo.

Você explora um arquipélago inteiro suspenso no céu.

Para um programador COBOL isso lembra imediatamente uma arquitetura distribuída.

Cada servidor possui sua responsabilidade.

Cada sistema oferece um serviço.

Cada aplicação conversa com outra.

Separadamente parecem pequenos.

Juntos formam um enorme ecossistema.

Moonstone Island transmite exatamente essa sensação.

Pegue sua caneca de café.

Hoje vamos embarcar em um dos RPGs independentes mais criativos dos últimos anos.


A origem

Moonstone Island foi desenvolvido pelo estúdio independente canadense Studio Supersoft. O projeto nasceu da ideia de combinar agricultura, exploração, construção de decks de cartas e captura de criaturas em um único jogo. Após uma campanha bem-sucedida no Kickstarter e anos de desenvolvimento, foi lançado para Windows PC em 20 de setembro de 2023, chegando posteriormente ao Nintendo Switch. (store.steampowered.com, )


O estúdio

O Studio Supersoft sempre teve uma proposta bastante clara.

Misturar mecânicas de vários gêneros.

Mas sem copiar nenhum.

Resultado.

Moonstone Island consegue lembrar.

  • Stardew Valley

  • Pokémon

  • Slay the Spire

  • Zelda

Ao mesmo tempo.

E ainda assim possuir personalidade própria.


A história

Você é um jovem alquimista.

Como parte da tradição.

Precisa deixar sua cidade natal.

E viver sozinho durante um ano.

Seu objetivo.

Aprender.

Explorar.

Coletar espíritos.

Descobrir os segredos das misteriosas Moonstones.

É praticamente um rito de passagem.


O verdadeiro objetivo

Curiosamente.

Também não existe apenas um.

Você pode.

  • cultivar plantações;

  • explorar ilhas;

  • capturar espíritos;

  • construir sua casa;

  • fabricar equipamentos;

  • cozinhar;

  • criar amizades.

Cada jogador cria sua própria jornada.


O mundo

Aqui está o maior diferencial.

Existem mais de 100 ilhas geradas proceduralmente.

Cada uma pode possuir.

  • clima próprio;

  • vegetação;

  • minérios;

  • espíritos;

  • recursos;

  • estruturas antigas.

Nunca faltam lugares novos.


A jogabilidade

O ciclo lembra um ambiente distribuído extremamente organizado.

Explorar Ilha

↓

Coletar Recursos

↓

Capturar Espíritos

↓

Cultivar Fazenda

↓

Criar Novas Cartas

↓

Melhorar Equipamentos

↓

Construir Base

↓

Voar Para Outra Ilha

É extremamente viciante.


Agricultura

Naturalmente.

Ela existe.

Você planta.

  • trigo;

  • frutas;

  • ervas;

  • vegetais.

Tudo utilizado em culinária e alquimia.


Alquimia

Uma das partes mais interessantes.

Você fabrica.

  • poções;

  • elixires;

  • melhorias;

  • itens especiais.

A alquimia influencia praticamente toda a aventura.


Espíritos

Eles substituem os tradicionais monstros capturáveis.

Existem dezenas de espécies.

Cada espírito pertence a um elemento.

Como.

  • Terra.

  • Água.

  • Fogo.

  • Veneno.

  • Psíquico.

Cada um possui habilidades próprias.


Combate

Aqui aparece outro diferencial.

O combate utiliza deck building.

Você monta seu baralho.

Cada carta representa.

  • ataques;

  • defesa;

  • efeitos;

  • melhorias.

Lembra bastante jogos estratégicos como Slay the Spire.


Exploração

Talvez seja o aspecto mais relaxante.

Você constrói um balão.

Depois uma vassoura.

Mais tarde.

Outros meios de transporte.

Voar entre ilhas é uma experiência extremamente agradável.


Construção

Você pode personalizar completamente sua fazenda.

Construindo.

  • cercas;

  • jardins;

  • celeiros;

  • oficinas;

  • cozinhas.

Tudo pode ser reorganizado.


Relacionamentos

Também existem.

Você conhece diversos moradores.

Pode.

  • fazer amizades;

  • namorar;

  • desenvolver relacionamentos.

Tudo sem pressa.


Curiosidades

  • A campanha no Kickstarter ajudou a financiar o desenvolvimento e consolidou uma comunidade ativa antes mesmo do lançamento.

  • O jogo é frequentemente elogiado por misturar gêneros de maneira equilibrada, sem sobrecarregar o jogador.

  • O estilo visual em pixel art moderno e a trilha sonora criam uma atmosfera acolhedora e relaxante.


Easter Eggs

Moonstone Island possui diversos pequenos segredos.

Entre eles.

  • ilhas extremamente raras;

  • eventos aleatórios;

  • estruturas escondidas;

  • espíritos incomuns;

  • itens especiais.

Grande parte deles depende apenas da curiosidade.


Os riscos

O maior risco.

Pensar.

"Vou visitar só mais uma ilha."

Duas horas depois.

Você ainda está voando.

Outro risco.

Passar tanto tempo organizando seu deck de cartas que esquece completamente da fazenda.


As vantagens

Moonstone Island reúne praticamente tudo.

✔ agricultura

✔ RPG

✔ deck building

✔ captura de criaturas

✔ exploração

✔ crafting

✔ alquimia

✔ construção

Sem.

❌ gacha

❌ energia limitada

❌ loot boxes

❌ microtransações invasivas

Compra.

Instala.

Joga.


A diversão

É difícil enjoar.

Sempre existe.

Uma ilha nova.

Um espírito novo.

Uma receita.

Uma carta.

Uma melhoria.

Uma planta.

Uma masmorra.

Tudo incentiva a continuar explorando.


O Caminho do Padawan

Se está começando.

Faça assim.

✔ plante cedo;

✔ capture espíritos variados;

✔ aprenda alquimia;

✔ organize o deck;

✔ explore ilhas próximas primeiro;

✔ economize recursos;

✔ cozinhe frequentemente.

No Bellacosa Mainframe existe uma regra semelhante.

"Não tente integrar cem sistemas no primeiro sprint."


Requisitos para PC

Mínimos:

  • Windows 10 (64 bits)

  • Intel Core i5 ou equivalente

  • 8 GB de RAM

  • GPU compatível com DirectX 11

  • Aproximadamente 2 GB de espaço livre

Recomendados:

  • Intel Core i7 ou AMD Ryzen equivalente

  • 16 GB de RAM

  • GPU dedicada moderna

Graças ao seu visual em pixel art, Moonstone Island roda muito bem em computadores intermediários e até em diversos notebooks voltados para produtividade. (store.steampowered.com)


Tipo de instalação

É um jogo premium.

Compra única.

Instalação digital.

Disponível para:

  • Windows (desktop)

  • Nintendo Switch

A instalação no PC é feita principalmente através da Steam.


Custo

O preço oficial da versão para PC gira em torno de US$ 19,99, variando conforme promoções e a região da Steam.


Classificação

  • Gênero: RPG, simulação de fazenda, captura de criaturas, deck building, aventura e exploração.

  • Modo: Um jogador.

  • Classificação indicativa: geralmente E10+ / Livre para maiores de 10 anos, por conter fantasia leve e violência cartunesca.


Site oficial

Para acompanhar novidades e atualizações:


Curiosidade para Programadores COBOL

Se Stardew Valley representa um sistema administrativo elegante...

Outward simboliza um ambiente crítico onde sobreviver é prioridade...

Core Keeper lembra a exploração das profundezas de um grande banco de dados...

Dinkum representa a expansão organizada de uma cidade...

Kynseed ensina o valor do legado...

Então Moonstone Island é uma verdadeira arquitetura orientada a serviços.

Cada ilha funciona como um pequeno sistema independente.

Cada espírito representa um módulo especializado.

Cada carta é uma rotina reutilizável.

E o jogador atua como um grande integrador, conectando todas essas partes para formar uma solução maior.

É quase como administrar dezenas de aplicações COBOL, CICS, Db2 e APIs modernas distribuídas entre vários ambientes IBM Z, garantindo que tudo converse de forma harmoniosa.


Conclusão

Moonstone Island prova que inovação não depende apenas de gráficos sofisticados ou de mundos gigantescos. Sua força está em combinar exploração, fazenda, captura de criaturas, estratégia e alquimia de forma equilibrada e acolhedora.

Sob a ótica do Bellacosa Mainframe, ele lembra um ambiente corporativo distribuído onde cada componente tem uma função específica, mas todos trabalham em conjunto para criar algo muito maior.

Sua maior mensagem é simples.

Não existe apenas um caminho para evoluir.

Às vezes, crescer significa plantar uma nova semente.

Às vezes, capturar um novo espírito.

Ou simplesmente levantar voo rumo a uma ilha desconhecida.

Porque tanto na computação quanto na aventura, os maiores horizontes pertencem àqueles que nunca deixam de explorar.

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