Translate

quarta-feira, 2 de agosto de 2023

📏 1. Tamanho dos Capítulos de uma Webnovel Japonesa

 

Bellacosa Mainframe e o tamanho ideal de um capitulo de uma webnovel

📏 1. Tamanho dos Capítulos de uma Webnovel Japonesa

🈶 Padrões japoneses (como Shōsetsuka ni Narō e Kakuyomu)

Tipo de CapítuloTamanho MédioObservações
Curto (cotidiano, slice of life)800 a 1.200 palavrasIdeal para leitores mobile; mantém ritmo leve.
Médio (fantasia, isekai, drama)1.500 a 2.500 palavrasPadrão mais comum; cabe uma cena completa.
Longo (clímax ou revelações)3.000 a 5.000 palavrasReservado para arcos emocionais ou batalhas importantes.

💡 Dica Bellacosa: pense em cada capítulo como um episódio de anime de 10 minutos — ele precisa ter introdução, conflito e gancho final.


🗂️ 2. Estrutura Interna do Capítulo

📖 Formato Padrão Japonês (adaptado ao português)

Capítulo 05O Chá Que Nunca Esfriava [1] Abertura suave: Um parágrafo que situa o leitor no momentoo cheiro do chá, a chuva leve, o estado de espírito. [2] Ação ou diálogo principal: 3 a 5 parágrafos com foco em um pequeno evento, revelação ou conversa significativa. [3] Mini reflexões: Um toque filosófico, poético ou emocional (mono no aware). [4] Fecho com gancho: Uma frase final que deixa o leitor desejando o próximo capítulo. “E foi nesse instante que o som do sino ecoou pela montanha.”

🧭 3. Formato Técnico (digitais e exportáveis)

  • Espaçamento: simples ou 1.15

  • Parágrafos curtos: 2–5 linhas cada (evita cansaço visual).

  • Diálogo em linhas separadas: como no formato japonês:

    “Você voltou, não foi?” “Voltei. Mas o mundo parece... diferente.”
  • Sem longas descrições seguidas: intercale narração com ação ou fala.

  • Uso moderado de itálicos e negrito (para ênfase, não para estilo).

  • Títulos de capítulos numerados:
    “Capítulo 07 – Entre as Cerejeiras e os Deuses Adormecidos”


📅 4. Ritmo de Publicação

FrequênciaIdeal paraVantagem
Diário (curto)Slice of life, romance, humorFideliza o leitor rapidamente.
2–3x por semanaAventura, isekai, fantasiaDá tempo para revisão e cliffhangers.
SemanalTramas densas, filosóficas ou com arte ilustradaPermite qualidade e planejamento.

⚖️ Regularidade > quantidade.
O público japonês valoriza constância e respeito ao cronograma quase como uma forma de contrato moral com o leitor.


🧪 5. Exemplo de Estrutura Ideal (2.000 palavras)

SeçãoConteúdoDuração aproximada
1. Abertura Atmosférica150 palavras1 parágrafo poético ou sensorial
2. Situação e diálogo inicial400 palavrasIntroduz o tema do capítulo
3. Ação ou dilema principal800 palavrasDesenvolvimento central
4. Reflexão ou flashback300 palavrasEmoção e contexto
5. Gancho ou frase final100 palavrasFechamento + suspense leve

🌸 6. O Ritmo Japonês de Leitura: o “Ma”

No Japão, as webnovels são lidas:

  • no trem, durante o almoço, ou antes de dormir;

  • em smartphones, com rolagem vertical;

  • em blocos curtos, como quem aprecia goles de chá, não copos inteiros.

👉 Por isso, capítulos de 1.500 a 2.000 palavras são considerados “perfeitos”:
curtos o bastante para o ritmo moderno, longos o bastante para emocionar.


🍵 Dica Bellacosa Final

“Em cada capítulo, escreva um instante — não uma saga.
O leitor deve fechar os olhos no fim e pensar: ‘quero mais um gole dessa história.’”

terça-feira, 1 de agosto de 2023

🏮 1. Entendendo o que é uma Webnovel Japonesa

 

Bellacosa Mainframe apresenta a webnovel japonesa

🏮 1. Entendendo o que é uma Webnovel Japonesa

Uma Web Novel (Webu Noberu) é um romance publicado diretamente na internet, geralmente em capítulos curtos e atualizados periodicamente pelo próprio autor. No Japão, esse formato ganhou enorme popularidade no início dos anos 2000 com plataformas como Shōsetsuka ni Narō ("Vamos nos Tornar Romancistas"), permitindo que qualquer pessoa publicasse suas histórias gratuitamente e interagisse com os leitores por meio de comentários e avaliações.

Diferentemente de uma Light Novel, que passa por revisão editorial, possui ilustrações profissionais e é publicada por uma editora, a Web Novel costuma ser a versão original da obra. Muitos autores começam escrevendo por hobby e, quando suas histórias conquistam milhares de leitores, acabam sendo contratados por editoras para transformar o texto em uma Light Novel. Posteriormente, essas obras podem receber adaptações para mangás, animes e até jogos eletrônicos.

Grande parte dos sucessos modernos do gênero isekai nasceu dessa forma. Títulos como Overlord, Re:Zero, Mushoku Tensei, That Time I Got Reincarnated as a Slime, The Rising of the Shield Hero e Kumo desu ga, Nani ka? iniciaram sua trajetória como Web Novels antes de se tornarem fenômenos internacionais.

Esse modelo revolucionou o mercado editorial japonês ao democratizar a publicação de histórias, aproximando autores e leitores. Hoje, as Web Novels são consideradas um dos principais celeiros de novas ideias para a indústria de animes, mangás e light novels, influenciando diretamente a cultura pop japonesa contemporânea.


✍️ Prefacio


Uma webnovel é uma história publicada diretamente na internet, geralmente em capítulos curtos e frequentes, em portais como Shōsetsuka ni Narō, Kakuyomu ou Syosetu.
Ela é o berço de obras famosas como:

  • Re:Zero (Tappei Nagatsuki)

  • Overlord (Kugane Maruyama)

  • That Time I Got Reincarnated as a Slime

  • Mushoku Tensei

💡 Dica: Webnovels priorizam a regularidade e o vínculo com o leitor, mais do que o perfeccionismo literário. Pense em capítulos vivos, orgânicos, que evoluem junto com o público.


✍️ 2. Como Começar a Escrever Sua Webnovel

🧩 Estrutura Base

  1. Conceito central: o que a torna única? (um isekai? slow life? fantasia urbana?)

  2. Tom narrativo: poético, leve, cômico, sombrio ou filosófico?

  3. Protagonista: crie alguém com um desejo forte e uma fraqueza humana.

  4. Mundo: crie regras, mitos e detalhes culturais que soem “vivos”.

  5. Pacing: capítulos curtos, 1.000 a 3.000 palavras, com ganchos no final.

🍃 Exemplo de Estrutura de Capítulo

Capítulo 1 – O Despertar no Vale dos Ecos - Abertura com estranhamento (o leitor precisa sentir o novo mundo) - Flash de memória do protagonista (conexão emocional) - Pequeno conflito introdutório - Gancho final (“Ele não imaginava que aquela voz não era humana…”)

🎨 3. Estilo Japonês: Como Capturar o Espírito

As webnovels japonesas têm uma linguagem simples, mas com alma — algo entre o haiku e o slice of life.

Técnicas inspiradas no estilo japonês:

  • Mono no Aware: a beleza na efemeridade.

  • Shōnen no Kokoro: a pureza do ideal e da superação.

  • Ma: o silêncio intencional entre eventos — o tempo de respirar.

  • Itadakimasu narrativo: a gratidão por cada pequeno momento.

🖋️ Dica Bellacosa:

“Não escreva o que o leitor deve sentir. Descreva o vento, o chá quente e o olhar do personagem — o leitor sentirá por si mesmo.”


🌐 4. Onde Publicar e Divulgar

🇯🇵 Plataformas Japonesas (para quem quer alcançar o público oriental)

  • Shōsetsuka ni Narō (小説家になろう) – o mais famoso, com ranking por gênero.

  • Kakuyomu – da Kadokawa, mais visual e moderno.

(Você pode publicar em português e usar tradução automática depois, ou escrever direto em inglês se quiser alcance internacional.)

🌍 Plataformas Globais

  • RoyalRoad (inglês, muito usado para fantasia e isekai)

  • ScribbleHub (comunidade calorosa, ideal para iniciantes)

  • Wattpad (ainda tem boa base de leitores no Brasil)

  • Tapas e Webnovel.com (ótimos para monetização e público de anime/webtoon)


📣 5. Como Divulgar Sua Webnovel

  1. Crie um título que evoque curiosidade e estética japonesa

    • Ex: “No Caminho das Cem Luas: O Monge que Esqueceu Seu Nome”

  2. Publique em dias fixos (consistência é o segredo).

  3. Interaja com os leitores nos comentários.

  4. Crie um banner ou capa estilo light novel.

  5. Use redes sociais de nicho:

    • Reddit (r/LightNovels, r/WebNovels)

    • Discords de autores independentes

    • Twitter/X e Threads com hashtags: #webnovel #isekai #lightnovel

💬 Dica: transforme seus capítulos em áudio (podcast curto) ou vídeo narrativo no YouTube com música ambiente japonesa.
O formato híbrido (texto + voz + arte) é uma tendência poderosa.


💰 6. Monetização e Reconhecimento

  • Kofi / Patreon: para apoiar o autor por capítulo.

  • Tapas / Webnovel.com: monetização direta.

  • Publicação física: após 100 capítulos, há chance de editoras pequenas se interessarem.

  • Adaptação em mangá: se houver ilustrações consistentes, é o próximo passo natural.


🔮 7. O Espírito da Escrita Bellacosa

“Escrever uma webnovel é como servir chá num templo vazio — você escreve para o silêncio, e o silêncio responde com leitores que entenderam seu mundo.”

Use a escrita como meditação. Não corra.
Cada capítulo é uma folha de outono que o vento leva até o coração de alguém.

sábado, 29 de julho de 2023

IBM Solutions Powered by Fast Processors sem Mistérios

 

Bellacosa Mainframe apresenta ibm solutions powered by fast processors

☕ Um Café no Bellacosa Mainframe

IBM Solutions Powered by Fast Processors sem Mistérios

O guia do programador COBOL Padawan para compreender nuvem híbrida, inteligência artificial, automação, segurança e modernização dignas da Frota Estelar

Imagine que você acabou de receber sua primeira designação na Frota Estelar.

O uniforme ainda está impecável, o comunicador brilha no peito e, diante de você, existe um painel repleto de nomes aparentemente desconectados:

IBM Cloud. watsonx. Red Hat OpenShift. IBM Security. Automação. Dados. Inteligência Artificial. Modernização de aplicações. IBM Z. Storage. Consultoria.

Para um programador COBOL iniciante, essa lista pode parecer tão complexa quanto o painel de engenharia da USS Enterprise durante uma falha no núcleo de dobra.

A primeira reação costuma ser:

“Eu só queria aprender COBOL. Por que preciso entender tudo isso?”

A resposta é simples, tripulante:

Porque o COBOL moderno não vive sozinho.

Ele faz parte de um ecossistema empresarial gigantesco, no qual programas escritos há décadas conversam com aplicativos móveis, APIs REST, inteligência artificial, containers, serviços em nuvem, bancos de dados distribuídos, plataformas de segurança e sistemas de automação.

A imagem apresentada pela Fast Processors, parceira da IBM, não é apenas um anúncio comercial. Ela funciona como uma espécie de mapa estelar da tecnologia empresarial moderna.

Ela mostra como diferentes produtos e serviços podem ser combinados para alcançar objetivos de negócio como:

  • modernizar aplicações;

  • automatizar processos;

  • proteger dados;

  • utilizar inteligência artificial;

  • escalar operações;

  • reduzir custos;

  • melhorar a experiência de clientes;

  • manter sistemas críticos disponíveis.

Nesta viagem, vamos desmontar esse mapa peça por peça.

Prepare o café, abra sua sessão 3270 e ajuste os sensores de longo alcance. Nossa missão é compreender como a IBM organiza seu universo tecnológico — e onde o programador COBOL entra nessa história.


A tecnologia não é o destino: ela é o motor de dobra

Uma das primeiras lições que todo profissional de tecnologia precisa aprender é que empresas não compram servidores, softwares ou inteligência artificial apenas porque essas tecnologias são interessantes.

Elas compram resultados.

Um banco não deseja um IBM Z apenas porque o gabinete é bonito.

Ele deseja:

  • processar milhões de transações;

  • evitar fraudes;

  • manter os sistemas disponíveis;

  • proteger dados financeiros;

  • cumprir exigências regulatórias;

  • atender clientes rapidamente.

Uma seguradora não compra uma plataforma de automação porque gosta de fluxogramas.

Ela quer:

  • reduzir tarefas manuais;

  • acelerar a análise de sinistros;

  • diminuir erros;

  • detectar comportamentos suspeitos;

  • melhorar o atendimento.

Esse é o princípio escondido na comunicação da Fast Processors.

A mensagem não é apenas:

“Temos produtos IBM.”

A mensagem verdadeira é:

“Usamos tecnologias IBM para resolver problemas empresariais complexos.”

Essa diferença é fundamental.

No mundo corporativo, tecnologia sem objetivo é apenas custo.

Tecnologia ligada a resultados torna-se investimento.


O que é a Fast Processors nesse cenário?

A Fast Processors se apresenta como uma empresa de consultoria, implementação, integração, modernização e serviços gerenciados baseados em tecnologias IBM.

Isso significa que ela atua como uma ponte entre o fabricante da tecnologia e a empresa que precisa utilizá-la.

Pense na IBM como a organização que constrói naves, motores, sistemas de comunicação, computadores de bordo e escudos defensivos.

A Fast Processors seria a equipe de engenharia que ajuda cada cliente a montar a nave adequada para sua missão.

Ela pode auxiliar em atividades como:

  • entender o ambiente atual do cliente;

  • identificar gargalos;

  • definir uma arquitetura futura;

  • instalar produtos;

  • integrar sistemas;

  • migrar aplicações;

  • modernizar processos;

  • automatizar operações;

  • criar controles de segurança;

  • treinar equipes;

  • operar ambientes após a implantação.

Esse trabalho é necessário porque grandes organizações raramente começam do zero.

Elas já possuem:

  • mainframes;

  • servidores Linux;

  • aplicações Windows;

  • sistemas Java;

  • bancos de dados;

  • ERPs;

  • aplicações COBOL;

  • integrações por arquivos;

  • filas IBM MQ;

  • APIs;

  • ambientes em nuvem;

  • regras de segurança;

  • processos regulatórios.

Modernizar uma empresa não significa apagar tudo e pressionar o botão “instalar o futuro”.

Significa evoluir sem destruir aquilo que já funciona.


O mito da substituição total

Existe uma fantasia recorrente no mercado de tecnologia:

“Vamos substituir todos os sistemas antigos por uma solução moderna.”

Essa frase parece elegante em apresentações de PowerPoint.

Na vida real, ela pode signific anos de projeto, bilhões em custos, interrupções, perda de conhecimento e riscos operacionais enormes.

Sistemas legados carregam décadas de regras de negócio.

Um programa COBOL pode conter detalhes sobre:

  • cálculo de juros;

  • tributação;

  • limites financeiros;

  • contratos;

  • folha de pagamento;

  • reservas;

  • faturamento;

  • logística;

  • aposentadorias;

  • seguros.

Essas regras não são “código velho”.

Elas são conhecimento empresarial compilado.

Modernizar não é necessariamente reescrever.

Modernizar pode ser:

  • expor uma função COBOL como API;

  • criar uma nova interface web;

  • automatizar a compilação;

  • integrar o sistema com uma fila MQ;

  • enviar eventos para uma plataforma analítica;

  • utilizar inteligência artificial para consultar dados;

  • transferir partes específicas para containers;

  • melhorar observabilidade e segurança.

A modernização inteligente preserva o que é valioso e transforma o que limita o negócio.

É a velha sabedoria de engenharia da Frota Estelar:

Você não desmonta o núcleo de dobra durante uma viagem em velocidade máxima sem possuir um plano de contingência.


IBM Cloud: a estação espacial de serviços

IBM Cloud é a plataforma de nuvem da IBM.

Uma plataforma de nuvem oferece recursos computacionais sob demanda, como:

  • servidores virtuais;

  • armazenamento;

  • bancos de dados;

  • redes;

  • containers;

  • Kubernetes;

  • serviços de inteligência artificial;

  • ferramentas de integração;

  • observabilidade;

  • recursos de segurança.

Em vez de uma empresa comprar, instalar e manter toda a infraestrutura fisicamente, ela pode consumir parte desses recursos como serviço.

Por exemplo, uma organização pode criar um servidor virtual para testes, utilizá-lo durante algumas semanas e depois removê-lo.

Também pode disponibilizar uma aplicação em várias regiões, criar cópias de dados, aumentar capacidade durante picos e reduzir recursos nos períodos de menor movimento.

Entretanto, o diferencial empresarial não está apenas na facilidade de criar máquinas virtuais.

Grandes organizações precisam pensar em:

  • localização de dados;

  • privacidade;

  • auditoria;

  • controle de acesso;

  • continuidade de negócio;

  • integração com sistemas internos;

  • criptografia;

  • requisitos regulatórios.

Por isso, a nuvem empresarial não é simplesmente “colocar tudo na internet”.

É criar uma arquitetura controlada, segura e governável.


Nuvem híbrida: a Federação dos ambientes tecnológicos

A nuvem híbrida é um dos conceitos centrais da estratégia da IBM.

Ela combina vários ambientes:

  • infraestrutura local;

  • nuvem privada;

  • nuvem pública;

  • mainframe;

  • servidores distribuídos;

  • edge computing;

  • aplicações SaaS.

Imagine um banco que possui seu sistema de contas correntes no IBM Z.

O aplicativo móvel pode rodar em containers.

A análise de comportamento pode utilizar inteligência artificial em uma plataforma de nuvem.

As mensagens entre sistemas podem passar pelo IBM MQ.

Os dados históricos podem estar em um data lake.

A autenticação pode utilizar uma solução central de identidade.

Tudo isso precisa funcionar como uma única arquitetura.

A nuvem híbrida reconhece uma realidade importante:

O futuro não substituirá todos os ambientes por uma única plataforma. O futuro conectará ambientes diferentes com segurança, governança e automação.

Para o programador COBOL, essa notícia é excelente.

O mainframe não precisa desaparecer para participar da nuvem.

Ele pode tornar-se uma das plataformas mais importantes dentro de uma arquitetura híbrida.


Exemplo prático: uma transferência bancária moderna

Vamos acompanhar uma transferência realizada por aplicativo.

O cliente abre o aplicativo no celular e informa os dados da operação.

A jornada pode ser semelhante a esta:

Aplicativo móvel
      |
      v
API Gateway
      |
      v
Serviço em container no OpenShift
      |
      v
API do z/OS Connect
      |
      v
Programa COBOL no CICS
      |
      v
Db2 ou VSAM
      |
      v
Resposta ao aplicativo

Ao mesmo tempo, outros componentes podem participar:

Evento da transferência
      |
      +--> Sistema antifraude
      |
      +--> Plataforma analítica
      |
      +--> Auditoria
      |
      +--> Monitoramento
      |
      +--> Motor de IA

Perceba o detalhe mais importante:

O programa COBOL não está isolado.

Ele participa de uma arquitetura moderna.

O usuário talvez nunca veja uma tela 3270, mas o COBOL pode continuar processando a regra financeira essencial.


IBM watsonx: inteligência artificial para empresas

O IBM watsonx representa a estratégia de inteligência artificial empresarial da IBM.

É importante compreender que inteligência artificial corporativa não consiste apenas em abrir uma caixa de chat e fazer perguntas.

Empresas precisam controlar:

  • quais modelos podem ser utilizados;

  • quais dados alimentam esses modelos;

  • quem possui permissão;

  • quais respostas foram produzidas;

  • quais riscos existem;

  • como monitorar desempenho;

  • como cumprir regulamentos;

  • como evitar vazamento de informações.

O ecossistema watsonx pode ser entendido por meio de três grandes áreas.

watsonx.ai

É o ambiente relacionado ao desenvolvimento, treinamento, ajuste, teste e execução de modelos de inteligência artificial.

Ele pode apoiar tarefas como:

  • geração de texto;

  • classificação;

  • resumo;

  • extração de informações;

  • criação de assistentes;

  • análise de documentos;

  • produção de código;

  • automação de atendimento.

watsonx.data

Está relacionado à organização e ao acesso aos dados.

A inteligência artificial precisa de dados confiáveis.

Se os dados forem incompletos, duplicados ou incorretos, as respostas também poderão ser ruins.

O watsonx.data ajuda a trabalhar com ambientes analíticos, data lakes, lakehouses e diferentes fontes de informação.

watsonx.governance

É a camada de governança.

Ela ajuda a responder perguntas essenciais:

  • Qual modelo foi usado?

  • Quem aprovou esse modelo?

  • Quais dados foram utilizados?

  • O modelo apresenta viés?

  • Existe risco regulatório?

  • O resultado pode ser explicado?

  • O modelo está se comportando de maneira diferente?

Em setores como bancos, seguros, saúde e governo, esse controle é indispensável.


A IA não substitui automaticamente o COBOL

Existe outra fantasia popular:

“A inteligência artificial vai substituir todos os sistemas existentes.”

Na prática, a IA pode tornar sistemas existentes mais acessíveis e inteligentes.

Imagine um sistema COBOL que armazena informações de contratos.

Uma aplicação com IA poderia permitir que um funcionário perguntasse:

“Quais contratos vencem nos próximos 30 dias e apresentam risco elevado?”

A IA poderia interpretar a pergunta, acessar serviços autorizados, consultar dados, resumir resultados e apresentar uma resposta.

Mas as regras oficiais do contrato continuariam no sistema transacional.

A IA não necessariamente substitui o COBOL.

Ela pode atuar como uma nova camada de interação.

O mainframe continua sendo o sistema de registro.

A IA torna o acesso ao conhecimento mais natural.


Automação e inteligência artificial não são a mesma coisa

Esse ponto merece destaque.

Automação é a execução de tarefas de acordo com regras definidas.

Exemplo:

SE o arquivo chegar
ENTÃO iniciar o processamento
SE o processamento terminar com RC=0
ENTÃO mover o arquivo para a área concluída
CASO CONTRÁRIO
ENVIAR alerta

Isso é automação.

Inteligência artificial entra quando o sistema precisa interpretar, reconhecer padrões ou gerar conteúdo.

Exemplo:

Ler a mensagem do cliente
Identificar a intenção
Classificar o assunto
Resumir o problema
Sugerir uma resposta
Encaminhar para a área adequada

Quando combinamos as duas, criamos automação inteligente.

Um fluxo pode utilizar IA para interpretar um documento e automação para executar os próximos passos.


IBM Automation: o oficial de operações da nave

O portfólio de automação da IBM pode envolver diferentes capacidades:

  • automação de processos;

  • workflows;

  • RPA;

  • gerenciamento de decisões;

  • integração;

  • automação de infraestrutura;

  • automação de TI;

  • observabilidade;

  • orquestração.

Pense em um processo de abertura de conta.

Sem automação, funcionários podem precisar:

  1. receber documentos;

  2. verificar campos;

  3. consultar sistemas;

  4. validar regras;

  5. cadastrar informações;

  6. solicitar aprovação;

  7. enviar confirmação.

Com automação, várias etapas podem ser coordenadas por um fluxo.

A inteligência artificial pode ler documentos.

Um motor de decisão pode verificar critérios.

Uma API pode consultar o mainframe.

Um workflow pode solicitar aprovação humana.

Um sistema de mensagens pode informar o cliente.

A automação não elimina necessariamente pessoas.

Ela elimina tarefas repetitivas e permite que pessoas concentrem esforço em decisões mais relevantes.


IBM Security: os escudos da Enterprise

Em ambientes empresariais, segurança não pode ser adicionada apenas no final do projeto.

Ela precisa estar presente desde o início.

IBM Security engloba áreas como:

  • identidade e acesso;

  • análise de ameaças;

  • proteção de dados;

  • monitoramento;

  • resposta a incidentes;

  • segurança de aplicações;

  • segurança de nuvem;

  • conformidade;

  • Zero Trust.

O conceito de Zero Trust pode ser resumido assim:

Nunca confiar automaticamente. Sempre verificar.

Mesmo um usuário autenticado não deve possuir acesso ilimitado.

O sistema precisa considerar:

  • identidade;

  • dispositivo;

  • localização;

  • contexto;

  • tipo de operação;

  • sensibilidade do dado;

  • comportamento.

No mainframe, essa filosofia já possui raízes antigas.

RACF, ACF2, Top Secret e SAF trabalham há décadas com autenticação, autorização e auditoria.

O mundo distribuído está redescobrindo princípios que o mainframe pratica há muito tempo.

Curiosidade Bellacosa:

Muitos conceitos promovidos hoje como novidades revolucionárias já existiam, em formas maduras, no universo de sistemas centrais. Às vezes o futuro chega usando um uniforme novo, mas carregando o mesmo manual de operações.


Data & Analytics: sem dados, a IA vira um tricorder sem sensores

Dados são a matéria-prima da inteligência artificial e da tomada de decisão.

Uma empresa produz informações por meio de:

  • vendas;

  • pagamentos;

  • estoque;

  • atendimento;

  • sensores;

  • aplicativos;

  • contratos;

  • logs;

  • transações;

  • documentos;

  • redes sociais;

  • operações de infraestrutura.

Mas possuir dados não significa possuir conhecimento.

Antes de utilizar dados, a organização precisa lidar com:

  • qualidade;

  • duplicidade;

  • integração;

  • significado;

  • segurança;

  • retenção;

  • privacidade;

  • origem;

  • atualização.

Imagine duas tabelas com o campo CLIENTE.

Em uma, o cliente é representado por CPF.

Na outra, por um número interno.

Em uma, o nome possui acentos.

Na outra, está abreviado.

Em uma, o endereço está atualizado.

Na outra, não.

Antes de construir uma análise confiável, essas diferenças precisam ser tratadas.

É por isso que governança de dados é tão importante.


O papel do programador COBOL nos dados empresariais

Grande parte dos dados mais valiosos de uma empresa nasce ou passa por sistemas transacionais.

O programador COBOL pode contribuir ao:

  • compreender a origem dos dados;

  • explicar regras de negócio;

  • identificar campos críticos;

  • documentar layouts;

  • criar interfaces;

  • disponibilizar dados por APIs;

  • produzir eventos;

  • apoiar processos de qualidade;

  • garantir consistência transacional.

Quem conhece o programa que calcula o saldo entende detalhes que talvez não estejam documentados em nenhum lugar.

Esse conhecimento é ouro.

Ou, em linguagem da Frota Estelar, é dilítio de grau militar.


Application Modernization: trocar a ponte, não afundar a nave

Modernização de aplicações pode incluir diferentes estratégias.

Rehost

Mover a aplicação para outra infraestrutura com poucas alterações.

Replatform

Adaptar a aplicação para uma nova plataforma, preservando grande parte da lógica.

Refactor

Modificar internamente o sistema para melhorar arquitetura, manutenção ou integração.

Rewrite

Reescrever a aplicação em outra tecnologia.

Replace

Substituir por um produto de mercado.

Retain

Manter como está porque continua atendendo bem.

Retire

Desativar sistemas que não são mais necessários.

A escolha correta depende de custo, risco, valor e complexidade.

Reescrever tudo pode ser a opção mais cara e perigosa.

Manter tudo sem evolução também pode criar limitações.

O objetivo é encontrar o equilíbrio.


Um passo a passo de modernização para um sistema COBOL

Considere um programa COBOL utilizado para consultar pedidos.

Passo 1 — Entender o sistema atual

Documente:

  • entradas;

  • saídas;

  • arquivos;

  • tabelas;

  • chamadas;

  • dependências;

  • regras;

  • horários;

  • volumes;

  • usuários.

Passo 2 — Identificar o objetivo

A empresa quer uma tela web?

Uma API?

Integração com aplicativo?

Automação de atendimento?

Não modernize sem saber por quê.

Passo 3 — Isolar a regra de negócio

Separe, quando possível:

  • interface;

  • lógica;

  • acesso a dados;

  • integração.

Isso facilita a reutilização.

Passo 4 — Criar uma interface

A função COBOL pode ser disponibilizada por:

  • z/OS Connect;

  • CICS Web Services;

  • IBM MQ;

  • arquivos;

  • eventos;

  • chamadas internas.

Passo 5 — Implementar segurança

Defina:

  • autenticação;

  • autorização;

  • criptografia;

  • auditoria;

  • limites;

  • proteção de dados.

Passo 6 — Automatizar testes

Crie testes para garantir que a modernização não alterou os resultados esperados.

Passo 7 — Construir pipeline

Automatize:

  • compilação;

  • teste;

  • análise;

  • empacotamento;

  • deploy;

  • validação.

Passo 8 — Monitorar

Observe:

  • tempo de resposta;

  • erros;

  • volume;

  • consumo;

  • disponibilidade;

  • segurança.

Modernizar sem monitorar é como ativar o motor de dobra sem olhar os indicadores de pressão.


Red Hat OpenShift: o hangar dos containers

OpenShift é uma plataforma empresarial baseada em Kubernetes.

Ela ajuda a executar aplicações em containers.

Um container empacota uma aplicação com suas dependências, tornando sua execução mais consistente entre ambientes.

O OpenShift oferece recursos como:

  • orquestração;

  • escalabilidade;

  • atualização;

  • controle de acesso;

  • redes;

  • armazenamento;

  • observabilidade;

  • integração com pipelines;

  • gerenciamento de configurações.

O ponto central é a portabilidade.

Uma aplicação pode ser implantada em diferentes ambientes com maior padronização.

Isso combina perfeitamente com a estratégia de nuvem híbrida.


COBOL roda dentro de container?

A resposta precisa ser cuidadosa.

Existem cenários nos quais aplicações COBOL podem ser compiladas ou executadas em ambientes distribuídos e containers, dependendo do compilador, runtime e arquitetura.

Entretanto, aplicações COBOL do z/OS frequentemente dependem de recursos como:

  • CICS;

  • IMS;

  • Db2 for z/OS;

  • VSAM;

  • JCL;

  • RACF;

  • serviços específicos do sistema.

Nesse caso, não basta colocar o programa em um container.

A estratégia mais comum pode ser manter a transação no mainframe e integrar serviços em containers ao redor dela.

Exemplo:

Frontend em container
        |
        v
Microsserviço Java
        |
        v
API segura
        |
        v
Programa COBOL no z/OS

Isso é modernização pragmática.

Cada plataforma executa aquilo que faz melhor.


IBM Z: o núcleo de dobra empresarial

IBM Z representa a família de mainframes da IBM.

Esses sistemas são utilizados em operações críticas porque oferecem características como:

  • elevada disponibilidade;

  • capacidade transacional;

  • segurança;

  • virtualização;

  • escalabilidade;

  • processamento de grandes volumes;

  • integração;

  • confiabilidade.

Em um IBM Z podem coexistir diferentes ambientes:

  • z/OS;

  • Linux on IBM Z;

  • z/VM;

  • múltiplas LPARs;

  • bancos de dados;

  • sistemas transacionais;

  • serviços de integração.

O mainframe moderno não é uma ilha.

Ele pode participar de APIs, eventos, DevOps, IA e nuvem híbrida.

Esse é um dos maiores segredos que o programador iniciante precisa compreender.

Aprender COBOL não significa estudar apenas o passado.

Significa aprender a lógica central de sistemas que continuam sustentando o presente.


IBM Storage: o arquivo da memória da Federação

Dados precisam ser armazenados com segurança, desempenho e disponibilidade.

Soluções IBM Storage podem apoiar:

  • armazenamento de dados críticos;

  • backup;

  • recuperação;

  • replicação;

  • proteção contra ransomware;

  • continuidade;

  • arquivamento;

  • alto desempenho.

Uma aplicação pode ser excelente, mas, se os dados forem perdidos, todo o sistema falhou.

Por isso, armazenamento não é apenas espaço em disco.

É parte da estratégia de resiliência.


Consultoria e serviços gerenciados

Nem toda organização possui especialistas em todas as tecnologias.

Uma empresa pode conhecer profundamente seu negócio, mas precisar de apoio em:

  • OpenShift;

  • segurança;

  • IA;

  • arquitetura híbrida;

  • automação;

  • migração;

  • observabilidade;

  • gerenciamento de infraestrutura.

Consultorias ajudam na criação e implantação das soluções.

Serviços gerenciados ajudam na operação contínua.

Isso pode incluir:

  • monitoramento;

  • suporte;

  • aplicação de correções;

  • gestão de capacidade;

  • resposta a incidentes;

  • atualização;

  • administração;

  • relatórios.

O objetivo é manter a nave operando mesmo quando a tripulação interna não possui especialistas para cada subsistema.


Os seis resultados de negócio

A imagem destaca resultados que representam o destino da jornada.

Modernizar

Atualizar sistemas e processos sem perder o valor acumulado.

Automatizar

Reduzir atividades manuais e aumentar consistência.

Transformar

Criar novas experiências, produtos e modelos operacionais.

Proteger

Fortalecer segurança, confiança e conformidade.

Escalar

Crescer sem reconstruir toda a arquitetura.

Sustentar

Criar operações resilientes, eficientes e responsáveis.

Esses resultados não pertencem a um único produto.

Eles surgem da combinação entre várias tecnologias.


Uma arquitetura empresarial completa

Podemos representar o cenário da seguinte forma:

Usuários e clientes
        |
        v
Aplicativos, portais e canais digitais
        |
        v
APIs e integração
        |
        v
Automação e processos
        |
        v
Inteligência artificial e analytics
        |
        v
Dados e sistemas de registro
        |
        v
IBM Z, LinuxONE, Cloud, servidores e storage

Ao redor de tudo:

Segurança
Governança
Observabilidade
DevOps
Resiliência
Compliance

Essa visão é importante porque impede que cada projeto seja tratado como uma ilha.

Uma API precisa de segurança.

A IA precisa de dados.

Os dados precisam de governança.

A automação precisa de monitoramento.

A nuvem precisa de integração.

O mainframe precisa participar da arquitetura.

Tudo está conectado.


Plano de ação para o programador COBOL Padawan

Você não precisa aprender todo o ecossistema de uma vez.

Avance por etapas.

Fase 1 — Domine a base do mainframe

Aprenda:

  • COBOL;

  • JCL;

  • TSO/ISPF;

  • arquivos sequenciais;

  • VSAM;

  • conceitos de Db2;

  • tratamento de erros;

  • leitura de spool.

Fase 2 — Entenda transações e integração

Estude:

  • CICS;

  • IMS;

  • IBM MQ;

  • APIs;

  • JSON;

  • XML;

  • REST;

  • conceitos de eventos.

Fase 3 — Aprenda DevOps

Explore:

  • Git;

  • pipelines;

  • Jenkins;

  • testes automatizados;

  • Zowe;

  • IBM Developer for z/OS;

  • IBM Z Open Editor;

  • UrbanCode;

  • DBB.

Fase 4 — Conheça nuvem e containers

Aprenda os conceitos de:

  • cloud;

  • Docker;

  • Kubernetes;

  • OpenShift;

  • microsserviços;

  • configurações;

  • observabilidade.

Fase 5 — Estude dados e inteligência artificial

Entenda:

  • qualidade de dados;

  • analytics;

  • modelos de IA;

  • RAG;

  • governança;

  • riscos;

  • uso empresarial do watsonx.

Fase 6 — Desenvolva visão arquitetural

Treine a capacidade de responder:

  • Onde a aplicação roda?

  • Onde os dados vivem?

  • Como os sistemas se comunicam?

  • Quem pode acessar?

  • Como detectar falhas?

  • Como recuperar?

  • Como escalar?

  • Como auditar?

Esse tipo de visão transforma um programador em arquiteto, consultor ou líder técnico.


Dicas do Capitão Bellacosa

Não despreze sistemas antigos antes de entendê-los.

Muitas vezes, aquilo que parece ultrapassado contém regras críticas e estabilidade conquistada ao longo de décadas.

Não confunda modernização com linguagem de programação.

Uma aplicação pode ser moderna mesmo utilizando COBOL, desde que seja testável, segura, integrada, observável e bem mantida.

Aprenda a falar com outras equipes.

O profissional mainframe moderno conversa com:

  • desenvolvedores Java;

  • engenheiros de cloud;

  • especialistas de segurança;

  • cientistas de dados;

  • administradores de banco;

  • equipes de negócio;

  • profissionais de DevOps.

Documente tudo.

No universo corporativo, conhecimento não documentado torna-se risco operacional.

Questione slogans.

Quando alguém disser “migrar para cloud”, pergunte:

  • qual workload?

  • por qual motivo?

  • qual custo?

  • qual risco?

  • qual requisito?

  • qual benefício?

  • qual plano de retorno?

Engenharia começa quando a apresentação termina.


Curiosidades para guardar no diário de bordo

A IBM possui mais de um século de história e atravessou várias eras da computação.

O mainframe evoluiu continuamente, incorporando recursos de virtualização, criptografia, APIs, Linux e automação.

A aquisição da Red Hat fortaleceu a estratégia da IBM em nuvem híbrida e OpenShift.

O termo “legado” nem sempre significa “obsoleto”. Muitas vezes significa “essencial”.

COBOL continua relevante porque regras de negócio não desaparecem quando surge uma nova interface.

Nuvem híbrida não é indecisão arquitetural. É uma resposta à diversidade real dos ambientes empresariais.

A inteligência artificial empresarial precisa de muito mais governança do que uma ferramenta usada casualmente por um indivíduo.

E o easter egg prometido?

Observe a sequência de resultados da imagem:

Modernize, Automate, Transform, Secure, Scale, Sustain.

As iniciais formam:

M A T S S S

Não é um acrônimo oficial, mas um tripulante criativo poderia reorganizá-las como o protocolo:

Mission Architecture for Trusted, Secure, Scalable Systems.

O protocolo secreto Bellacosa para não deixar a Enterprise cair durante a transformação digital.


Conclusão — O COBOL Padawan e a ponte entre dois mundos

A grande mensagem da solução apresentada pela Fast Processors não é que uma empresa precisa comprar todos os produtos IBM.

A mensagem é que a transformação digital exige uma visão integrada.

Nuvem sem segurança cria risco.

IA sem dados confiáveis gera respostas ruins.

Automação sem governança acelera erros.

Modernização sem compreensão do legado destrói conhecimento.

Containers sem observabilidade escondem falhas.

APIs sem controle expõem operações críticas.

Mainframes sem integração tornam-se isolados.

O verdadeiro valor aparece quando todas essas peças trabalham juntas.

É exatamente aí que surge a oportunidade do programador COBOL moderno.

Ele pode compreender os sistemas que carregam décadas de regras empresariais e, ao mesmo tempo, aprender tecnologias que os conectam ao futuro.

Esse profissional não é apenas alguém que mantém código antigo.

Ele se torna:

  • tradutor entre gerações;

  • guardião das regras de negócio;

  • engenheiro de integração;

  • participante de projetos de modernização;

  • construtor de APIs;

  • colaborador em iniciativas de IA;

  • defensor da segurança;

  • arquiteto de sistemas híbridos.

Portanto, jovem Padawan, quando você encontrar uma imagem cheia de logotipos, palavras como cloud, watsonx, automação, segurança e OpenShift, não veja apenas uma campanha comercial.

Veja um mapa.

Cada bloco representa uma parte da nave.

O IBM Z é o núcleo de dobra.

O OpenShift é o hangar dos containers.

O watsonx é o computador de bordo inteligente.

A segurança são os escudos.

Os dados são os sensores.

A automação é a sala de operações.

A nuvem híbrida é a rede que conecta toda a Federação.

E o COBOL?

O COBOL continua silenciosamente processando a missão mais importante, garantindo que, quando o capitão disser:

“Execute.”

A transação termine com código de retorno zero.

Porque no espaço corporativo, ninguém quer descobrir em produção que o núcleo de dobra recebeu um S0C7.

Vida longa ao COBOL. Vida longa ao mainframe. E que seus jobs terminem sempre com MAXCC=0.

sexta-feira, 28 de julho de 2023

O Algoritmo Apenas Nos Mostra Quem Realmente Somos?

 

Bellacosa Mainframe e o algoritmo apenas nos motra quem realmente somos

☕ Um Café no Bellacosa Mainframe

O Algoritmo Apenas Nos Mostra Quem Realmente Somos?

O Que Todo Programador COBOL Padawan Precisa Saber Sobre o Paradoxo Entre o Discurso Público, o Comportamento Privado e Como os Algoritmos Revelam a Psicologia Coletiva da Sociedade Digital

"Talvez o algoritmo não esteja criando uma nova humanidade. Talvez ele esteja apenas tornando visível uma humanidade que sempre existiu."


Introdução

Todo profissional de Mainframe conhece uma regra fundamental.

O sistema não inventa dados.

Ele processa aquilo que recebe.

Se milhões de registros entram em um banco de dados, os relatórios refletirão, com maior ou menor precisão, os padrões presentes nesses registros.

Agora imagine aplicar esse raciocínio às redes sociais.

E se o algoritmo não estivesse criando nossos desejos?

E se estivesse apenas aprendendo com eles?

Essa hipótese é desconfortável.

Porque desloca parte da responsabilidade das máquinas para nós mesmos.

Durante anos acusamos os algoritmos de promover determinados padrões de beleza, riqueza, sucesso e comportamento.

Mas talvez exista uma pergunta ainda mais difícil.

Quem ensinou isso ao algoritmo?


O Espelho Que Aprende

Existe uma diferença enorme entre um diretor de televisão e um algoritmo.

O diretor escolhe.

O algoritmo aprende.

Ele observa bilhões de pequenas decisões.

Quanto tempo você permaneceu olhando.

Qual vídeo terminou.

Qual fotografia ampliou.

Qual postagem compartilhou.

Qual comentário escreveu.

Cada ação é um voto silencioso.

Milhões desses votos constroem o feed do dia seguinte.


O Voto Que Nunca Declaramos

Nas eleições existe voto secreto.

Nas redes sociais também.

Talvez ainda mais secreto.

Pouquíssimas pessoas contam:

  • quanto tempo passaram olhando determinada fotografia;

  • quais perfis visitam;

  • quais vídeos assistem até o final;

  • quais conteúdos despertam curiosidade.

O algoritmo conhece esse comportamento.

Nem nossos amigos conhecem.


O Grande Paradoxo

Vivemos numa época em que discursos públicos e comportamentos privados podem divergir.

Publicamente defendemos:

  • inclusão;

  • diversidade;

  • respeito;

  • autenticidade.

Privadamente podemos acabar dedicando mais atenção a conteúdos que despertam desejo, novidade ou admiração.

Isso significa hipocrisia?

Nem sempre.

Significa que seres humanos possuem diferentes camadas psicológicas.


Daniel Kahneman e os Dois Sistemas

Daniel Kahneman propôs que nosso pensamento opera, de forma simplificada, por dois modos.

Sistema 1

Rápido.

Intuitivo.

Emocional.

Automático.

Sistema 2

Lento.

Reflexivo.

Racional.

Deliberativo.

Quando respondemos a uma pesquisa sobre valores, geralmente usamos mais o Sistema 2.

Quando rolamos o feed por centenas de imagens em poucos minutos, grande parte das escolhas ocorre de forma muito mais automática.

Isso ajuda a explicar por que valores declarados e comportamentos imediatos podem não coincidir.


O Que a Psicologia Evolucionista Sugere

A psicologia evolucionista propõe que algumas preferências humanas podem ter raízes profundas na história evolutiva.

Por exemplo, certos sinais de saúde, juventude ou simetria facial podem ser percebidos como atraentes em muitas culturas.

Essa é uma hipótese científica debatida e com limites importantes: cultura, contexto e preferências individuais também exercem enorme influência.

Ou seja, biologia não determina sozinha aquilo que valorizamos.


A Cultura Também Programa o Cérebro

Se tudo fosse biologia, padrões de beleza seriam idênticos em todos os tempos.

Não são.

Em diferentes épocas, já foram valorizados:

  • corpos mais robustos;

  • extrema magreza;

  • pele muito clara;

  • pele bronzeada;

  • cabelos lisos;

  • cabelos cacheados.

A cultura muda.

A moda muda.

A publicidade muda.

O algoritmo aprende essas mudanças.

Ele não as inicia sozinho.


Festinger Nunca Imaginou Isso

Leon Festinger explicou que construímos parte da nossa identidade comparando-nos com outras pessoas.

Na década de 1950 essa comparação era limitada.

Hoje ela é praticamente infinita.

Comparar-se com cinquenta pessoas já era emocionalmente exigente.

Comparar-se com cinquenta milhões talvez seja cognitivamente impossível.


Erving Goffman e a Vida Como Palco

O sociólogo Erving Goffman descreveu a vida social como uma grande representação.

Existe o palco.

E existem os bastidores.

As redes sociais transformaram essa metáfora em realidade cotidiana.

Publicamos o palco.

Vivemos os bastidores.

Depois esquecemos que o palco foi cuidadosamente montado.


A Espiral do Silêncio

A cientista política Elisabeth Noelle-Neumann propôs a teoria da Espiral do Silêncio.

Muitas pessoas evitam expressar opiniões que acreditam ser minoritárias.

Algo semelhante pode ocorrer com preferências e inseguranças.

As pessoas podem adaptar seu discurso ao que consideram socialmente aceitável, enquanto seus hábitos privados seguem caminhos diferentes.

Isso não implica falsidade deliberada.

Frequentemente é uma forma de adaptação social.


Pierre Bourdieu e o Gosto

Bourdieu argumentava que aquilo que chamamos de "gosto" não nasce apenas de preferências individuais.

Ele também é moldado por educação, classe social, ambiente cultural e busca por reconhecimento.

Quando milhões seguem determinado padrão, parte desse comportamento pode decorrer do desejo de pertencimento.

Gostamos porque realmente gostamos?

Ou aprendemos que devemos gostar?

Muitas vezes as duas coisas se misturam.


René Girard e o Desejo Mimético

René Girard apresentou uma ideia fascinante.

Desejamos aquilo que vemos outras pessoas desejando.

O objeto importa.

Mas a imitação também importa.

Nas redes sociais isso pode ser potencializado.

Quanto mais um conteúdo recebe atenção, mais pessoas o percebem como valioso.

Quanto mais valioso parece, mais atenção recebe.

É um ciclo de reforço.


A Economia da Atenção Não Faz Julgamentos

O algoritmo não pergunta:

"Isso faz bem para a sociedade?"

Ele pergunta:

"Isso mantém as pessoas aqui?"

Essa diferença é enorme.

Um sistema otimizado para retenção não precisa compreender ética.

Basta reconhecer padrões estatísticos.


O Paradoxo da Diversidade

Ao mesmo tempo, nunca houve tanta diversidade visível.

Hoje encontramos criadores de diferentes:

  • idades;

  • corpos;

  • etnias;

  • estilos;

  • condições físicas;

  • identidades.

Muitos construíram comunidades enormes justamente por desafiar padrões tradicionais.

Isso mostra que a realidade é mais rica do que a ideia de um único padrão dominante.

Existem tendências amplas, mas também múltiplos nichos e públicos.


O Feed Não É Um Retrato Perfeito da Sociedade

Esse é outro cuidado importante.

As plataformas não mostram tudo o que as pessoas gostam.

Elas mostram aquilo que maximiza seus objetivos de negócio.

Isso significa que o feed é uma mistura de:

  • preferências humanas;

  • decisões de engenharia;

  • estratégias comerciais;

  • aprendizado estatístico.

Portanto, ele não deve ser interpretado como um espelho absolutamente fiel da sociedade.

É um espelho deformado por incentivos econômicos.


A Hipocrisia Existe?

Às vezes, sim.

Como em qualquer sociedade.

Mas reduzir todo o fenômeno à hipocrisia seria simplista.

Muitas vezes convivem dentro da mesma pessoa:

  • valores igualitários sinceros;

  • respostas emocionais automáticas;

  • influência cultural;

  • curiosidade;

  • hábitos aprendidos.

Somos mais contraditórios do que gostamos de admitir.


O Mainframe e a Auditoria

Em um IBM Z não basta olhar o relatório final.

O auditor analisa:

  • origem dos dados;

  • regras de processamento;

  • filtros;

  • prioridades;

  • exceções.

Talvez devêssemos fazer o mesmo conosco.

Quando acreditamos gostar de alguma coisa, vale perguntar:

Esse desejo nasceu de mim?

Foi aprendido?

Foi reforçado?

Foi repetido tantas vezes que parece natural?

Essa auditoria interna talvez seja uma das competências mais importantes do século XXI.


O Futuro

Com Inteligência Artificial generativa, agentes pessoais e realidade aumentada, os algoritmos conhecerão nossos hábitos com precisão crescente.

A pergunta deixará de ser:

"O algoritmo sabe do que gosto?"

E passará a ser:

"Será que ele sabe antes de mim?"

Quanto melhor esses sistemas anteciparem nossos comportamentos, maior será a responsabilidade de preservar autonomia, pensamento crítico e liberdade de escolha.


Conclusão

Talvez a maior descoberta da era digital seja perceber que os algoritmos não são apenas mecanismos de recomendação.

Eles funcionam como gigantescos laboratórios de comportamento humano.

Eles registram bilhões de pequenas escolhas invisíveis.

Não perguntam o que defendemos.

Observam o que fazemos.

Mas existe um detalhe decisivo.

Aquilo que fazemos não revela, sozinho, quem somos.

Seres humanos são complexos.

Somos capazes de desejar uma coisa e defender outra.

De agir impulsivamente e refletir depois.

De mudar de opinião.

De revisar crenças.

De aprender.

Por isso, o algoritmo nunca contará toda a história.

Ele enxerga cliques.

Não enxerga arrependimento.

Enxerga tempo de tela.

Não enxerga consciência.

Enxerga padrões.

Não enxerga propósito.

Talvez o maior risco não seja que as máquinas nos conheçam profundamente.

Talvez seja aceitarmos, sem questionar, que somos apenas a soma dos nossos cliques.

Porque uma pessoa vale muito mais do que aquilo que o algoritmo consegue medir.

E essa talvez seja a última fronteira que nenhuma Inteligência Artificial conseguirá atravessar completamente: a capacidade humana de refletir sobre si mesma e escolher mudar.


quinta-feira, 27 de julho de 2023

Lambda Expressions no Java: O Manual Definitivo para um Programador COBOL Padawan Entender o Operador -> sem Medo (e Descobrir que Ele Não é Magia)

 

Bellacosa Mainframe e a lambda expressions no Java

☕ Um Café no Bellacosa Mainframe

Lambda Expressions no Java: O Manual Definitivo para um Programador COBOL Padawan Entender o Operador -> sem Medo (e Descobrir que Ele Não é Magia)

"Todo programador COBOL já passou por isso: você abre um código Java moderno e encontra algo como (x) -> x * 2. Sua primeira reação é pensar: 'Quem apagou metade do programa?' A boa notícia é que ninguém apagou nada. Você está olhando para uma Lambda Expression."


Introdução

Se você trabalha há anos no universo IBM Z, provavelmente sua realidade é composta por tecnologias como:

  • COBOL

  • JCL

  • CICS

  • IMS

  • Db2

  • MQ

  • VSAM

  • z/OS

  • REXX

  • PL/I

Neste mundo, tudo costuma ser muito explícito.

Você declara.

Você identifica.

Você define.

Você documenta.

Você implementa.

Já no mundo Java moderno acontece exatamente o contrário.

Quanto menos código existir, melhor.

É aí que surgem as Lambda Expressions, introduzidas oficialmente no Java 8 (2014).

Para muitos profissionais Mainframe, elas parecem um idioma alienígena.

Mas a verdade é outra.

Você já conhece o conceito.

Só não conhece a sintaxe.


Antes de tudo…

Existe Arrow Function em Java?

Tecnicamente...

Não.

O nome Arrow Function pertence ao JavaScript.

No Java o nome correto é:

Lambda Expression

O símbolo é exatamente o mesmo conceito visual:

->

Por isso muita gente chama informalmente de Arrow Function.


Por que a IBM adicionou Lambdas ao Java?

A resposta é simples:

Performance + produtividade.

Na década de 2000, Java era conhecido por ser extremamente verboso.

Para executar uma simples ação era comum escrever dezenas de linhas.

Exemplo antigo:

Collections.sort(lista, new Comparator<String>() {
    @Override
    public int compare(String a, String b) {
        return a.compareTo(b);
    }
});

Mais de dez linhas.

Hoje:

lista.sort((a,b) -> a.compareTo(b));

Uma linha.

Muito mais legível.


Mas o que é uma Lambda?

A definição acadêmica diz:

Uma função anônima.

Mas para um COBOL Padawan eu prefiro outra definição.

Pense nela como um PARÁGRAFO temporário.

No COBOL fazemos isso:

PERFORM CALCULAR-TOTAL

E em algum lugar existe:

CALCULAR-TOTAL.

    COMPUTE WS-TOTAL =
        WS-VALOR1 +
        WS-VALOR2.

EXIT.

No Java moderno, às vezes não vale a pena criar um método inteiro.

Você simplesmente entrega a lógica diretamente.

Algo parecido com:

(a,b) -> a+b

É como dizer:

"Aqui está o código. Execute quando precisar."


O significado do operador ->

Observe:

(a,b) -> a+b

Lendo em português:

Receba A

Receba B

Execute

Retorne A+B

Visualmente:

ENTRADA
   │
   ▼
(a,b)
   │
   ▼
   ->
   │
   ▼
a+b
   │
   ▼
SAÍDA

O operador -> separa:

lado esquerdo

parâmetros

lado direito

implementação


Comparando com COBOL

COBOL:

ADD A TO B GIVING C

Java:

(a,b) -> a+b

A intenção é praticamente igual.

A diferença é que no Java essa operação pode ser passada como parâmetro.


Uma mudança de paradigma

Durante décadas escrevemos programas assim:

Programa

↓

Métodos

↓

Chamadas

Com Lambdas passamos a escrever:

Programa

↓

Comportamentos

↓

Funções

↓

Funções recebendo funções

Isso é programação funcional.


Um exemplo simples

Sem Lambda:

Runnable tarefa = new Runnable() {

    @Override
    public void run() {

        System.out.println("Executando");

    }

};

Com Lambda:

Runnable tarefa =
    () -> System.out.println("Executando");

Mesmo comportamento.

Muito menos código.


O que mudou?

Antes era necessário criar uma classe anônima.

Agora basta informar:

  • parâmetros

  • comportamento


Quando usar ()

Sem parâmetros:

() -> ...

Um parâmetro:

x -> ...

Dois parâmetros:

(a,b) -> ...

Três parâmetros:

(a,b,c) -> ...

Quando usar chaves?

Uma linha:

x -> x*2

Mais de uma:

x -> {

    System.out.println(x);

    return x*2;

}

O retorno implícito

Observe:

x -> x+1

Não existe:

return

O Java entende automaticamente.

Já quando usamos bloco:

x -> {

    return x+1;

}

O return passa a ser obrigatório.


Interfaces Funcionais

Aqui existe uma diferença enorme para JavaScript.

No Java você não cria uma Lambda do nada.

Ela precisa implementar uma interface.

Exemplo:

@FunctionalInterface

interface Soma {

    int executar(int a,int b);

}

Uso:

Soma s =
    (a,b) -> a+b;

Pronto.

Sua Lambda implementou automaticamente a interface.


O segredo está na @FunctionalInterface

Ela permite apenas:

um único método abstrato.

Isso faz o compilador saber exatamente qual método será implementado.


Onde as Lambdas aparecem no Java moderno?

Praticamente em toda parte.

Principalmente em:

  • Streams

  • Comparator

  • Runnable

  • CompletableFuture

  • ExecutorService

  • Optional

  • Collections

  • APIs REST

  • Spring Boot

  • Jakarta EE

  • IBM Semeru Runtime

  • Open Liberty

Ou seja...

Se você pretende trabalhar com Java no IBM Z...

Vai encontrá-las diariamente.


Streams

Imagine uma lista.

List<Integer> numeros =
List.of(1,2,3,4,5);

Filtrar pares:

numeros.stream()

.filter(n -> n%2==0)

.forEach(System.out::println);

A Lambda diz apenas:

Receba um número

↓

Se for par

↓

Retorne verdadeiro

Comparando com COBOL

No COBOL seria algo como:

PERFORM VARYING IDX
FROM 1 BY 1

UNTIL IDX > MAX

    IF NUMERO(IDX)
       MOD 2 = ZERO

       DISPLAY NUMERO(IDX)

    END-IF

END-PERFORM

No Java:

.filter(n->n%2==0)

O comportamento é exatamente o mesmo.


Comparator

Ordenar nomes.

Antes:

mais de quinze linhas.

Hoje:

lista.sort(

(a,b)->a.compareTo(b)

);

Method Reference

Existe algo ainda menor.

Em vez de:

x -> System.out.println(x)

Podemos escrever:

System.out::println

Isso se chama:

Method Reference.

É praticamente uma Lambda reduzida.


Predicate

Representa perguntas.

Predicate<Integer> par =

n -> n%2==0;

É equivalente a:

É par?

↓

Sim ou Não

Function

Transforma algo.

Entrada:

Nome

Saída:

Maiúsculo
nome -> nome.toUpperCase()

Consumer

Recebe.

Consome.

Não devolve nada.

x -> System.out.println(x)

Supplier

Não recebe nada.

Mas produz.

() -> UUID.randomUUID()

Curiosidade

O nome Lambda vem da matemática.

Mais especificamente do Lambda Calculus, criado por Alonzo Church, em 1936.

Muito antes da invenção do COBOL.

Muito antes do Java.

Muito antes do C.


Alan Turing conhecia Lambdas?

Sim.

Church e Turing trabalharam praticamente na mesma época.

Os dois provaram matematicamente que era possível criar computação universal.


Então Java virou linguagem funcional?

Não.

Java continua sendo:

  • Orientado a Objetos

Mas ganhou recursos funcionais.


O que acontece na memória?

Muita gente imagina que uma Lambda cria um objeto enorme.

Na verdade não.

O compilador gera bytecode especial usando:

invokedynamic

Introduzido na JVM 7.

Depois entra em ação:

LambdaMetafactory

Ela cria dinamicamente uma implementação da interface funcional.

Ou seja...

Não existe necessariamente uma classe física como antigamente.


O papel do invokedynamic

Antes do Java 8:

Classe anônima

↓

Compilador

↓

Novo .class

Depois:

Lambda

↓

invokedynamic

↓

JVM

↓

Objeto criado dinamicamente

Muito mais eficiente.


Performance

Na maioria dos casos:

Lambda é mais rápida que classe anônima.

Por quê?

Porque:

  • menos bytecode

  • menos classes

  • melhor otimização JIT

  • HotSpot entende melhor o fluxo

No IBM Semeru Runtime isso também acontece.


Existe custo?

Sim.

Toda abstração possui custo.

Mas normalmente ele é insignificante.


Captura de variáveis

Exemplo:

int valor = 10;

Function<Integer,Integer> soma =

n -> n + valor;

Funciona.

Agora:

valor++;

Erro.

Por quê?

Porque a variável precisa ser:

effectively final.


Por que isso existe?

Para evitar problemas de concorrência.

Imagine:

100 Threads.

Todas alterando a mesma variável.

Seria um desastre.


O coletor de lixo

As Lambdas normalmente vivem pouco.

São excelentes candidatas para o Young Generation da JVM.

Resultado:

coleta extremamente rápida.


Java no IBM Z

Se você usa:

  • IBM Semeru Runtime

  • OpenJ9

  • Liberty

  • Spring Boot

  • z/OS Connect

Você está usando Lambdas o tempo inteiro.

Mesmo sem perceber.


Limitações

Nem tudo são flores.

Algumas limitações:

  • não possuem estado próprio

  • não substituem classes

  • não substituem objetos complexos

  • podem reduzir legibilidade quando abusadas

  • debugging pode ficar mais difícil

  • stack traces às vezes ficam estranhos


Pontos fortes

✔ Menos código

✔ Mais legibilidade

✔ Melhor integração com Streams

✔ Melhor paralelismo

✔ Melhor manutenção

✔ Melhor otimização da JVM

✔ Código moderno


Pontos fracos

✘ Curva de aprendizado

✘ Sintaxe inicialmente estranha

✘ Pode esconder lógica demais

✘ Debug mais complexo

✘ Não substitui arquitetura


Dicas para quem vem do COBOL

Não tente decorar a sintaxe.

Entenda a ideia.


Sempre pergunte:

"Esse trecho está apenas descrevendo um comportamento?"

Se sim...

Provavelmente cabe uma Lambda.


Streams + Lambdas são inseparáveis.

Aprenda ambos juntos.


Evite Lambdas gigantes.

Se passou de cinco ou seis linhas...

Crie um método.


Prefira Method Reference

Quando possível.

Em vez de:

x -> System.out.println(x)

Faça:

System.out::println

Easter Eggs

1. Nem toda Lambda gera um novo objeto.

A JVM pode reutilizar instâncias.


2. Uma Lambda pode não existir como classe.

Ao contrário das antigas Anonymous Classes.


3. O compilador gera métodos sintéticos.

Eles aparecem como:

lambda$0

lambda$1

lambda$2

Dentro do bytecode.


4. javap revela a mágica

Compile:

javac Exemplo.java

Depois:

javap -c -v Exemplo.class

Você verá instruções como:

  • invokedynamic

  • BootstrapMethods

  • referências ao LambdaMetafactory

É uma ótima forma de entender o que a JVM realmente executa.


5. Lambdas e paralelismo

Elas combinam naturalmente com:

parallelStream()

Mas atenção: paralelo não significa automaticamente mais rápido. Em cargas pequenas, o custo de dividir o trabalho pode superar o ganho.


Fazendo a ponte para o mundo Mainframe

Se você é um Programador COBOL Padawan, pense assim:

  • Um PERFORM executa um bloco identificado pelo nome.

  • Uma Lambda entrega esse bloco diretamente para quem vai executá-lo.

  • Um IF do COBOL pode virar um Predicate.

  • Uma rotina de transformação de registros pode virar uma Function.

  • Um DISPLAY pode ser representado por um Consumer.

O paradigma muda, mas o raciocínio continua familiar: dados entram, uma lógica é aplicada e um resultado é produzido.


Conclusão

As Lambda Expressions não vieram para substituir a Programação Orientada a Objetos, muito menos os princípios sólidos que sustentam aplicações corporativas. Elas surgiram para reduzir código repetitivo, aumentar a expressividade e permitir que o desenvolvedor descreva comportamentos da mesma forma que descreve dados.

Para quem vem do universo IBM Z, elas representam mais uma evolução do que uma revolução. Você já domina lógica estruturada, modularização, processamento em lote, concorrência, desempenho e confiabilidade. O desafio agora é aprender uma nova forma de expressar essas mesmas ideias.

No fim das contas, a Lambda é apenas uma ferramenta. Ela não torna um sistema melhor por si só. Assim como um bom PERFORM, ela precisa ser usada no lugar certo, com clareza e equilíbrio.

E talvez essa seja a maior lição para todo COBOL Padawan que começa a explorar Java no Mainframe: a tecnologia muda, a boa engenharia de software permanece.


sábado, 22 de julho de 2023

Subscript versus Index : Quando um Programador Descobre que o Maior Vírus Não Está no Data Center... Está em um Mito que Sobrevive Desde os Anos 1970

 

Bellacosa Mainframe apresenta tabelas cobol subscript versus index

☕ Um Café no Bellacosa Mainframe

Subscript versus Index sem Mistérios para Programadores COBOL

Quando um Programador Descobre que o Maior Vírus Não Está no Data Center... Está em um Mito que Sobrevive Desde os Anos 1970

"Em um laboratório subterrâneo, um microscópio pode revelar um organismo invisível. Em um mainframe, um dump pode revelar um erro invisível. Em ambos os casos, a sobrevivência depende de entender detalhes que quase ninguém percebe."


Introdução – Bem-vindo ao Laboratório P4 do Mainframe

Imagine que você acaba de ser contratado para trabalhar em um dos maiores bancos do planeta.

São duas da manhã.

O processamento noturno começou.

Milhões de contas serão atualizadas.

Bilhões de registros serão lidos.

A folha de pagamento nacional será recalculada.

O sistema de cartões irá consolidar compras realizadas no mundo inteiro.

Tudo parece tranquilo...

Até que um batch começa a consumir CPU muito acima do esperado.

O monitor RMF mostra utilização elevada.

O WLM começa a redistribuir prioridades.

O operador do console observa o relógio.

O gerente pergunta:

"O que mudou?"

Depois de algumas horas de investigação, alguém encontra uma rotina COBOL.

Ela percorre uma tabela centenas de milhões de vezes usando um método inadequado de acesso.

Não existe bug.

Não existe ABEND.

Não existe corrupção de dados.

Existe apenas uma pequena decisão tomada por um programador anos atrás.

Uma decisão aparentemente inocente.

Subscript ou Index?

É exatamente essa pequena diferença que vamos investigar hoje.

Assim como em The Andromeda Strain (1971), onde cientistas analisam um organismo microscópico para impedir uma catástrofe, nós vamos colocar o COBOL sob um microscópio e descobrir que existe muito mais acontecendo do que aparenta.

Vista seu jaleco.

O laboratório Bellacosa Mainframe está oficialmente aberto.


O paciente: OCCURS

Antes de falar sobre Subscript ou Index precisamos entender o verdadeiro protagonista.

01 CLIENTES.
   05 CLIENTE OCCURS 100 TIMES.
      10 CODIGO PIC 9(6).
      10 NOME   PIC X(30).

Essa estrutura cria uma tabela.

Ou seja...

Na memória teremos algo semelhante a:

CLIENTE(1)

CLIENTE(2)

CLIENTE(3)

CLIENTE(4)

...

CLIENTE(100)

Nada de mágico aconteceu.

A memória simplesmente possui cem blocos consecutivos.

A pergunta é:

Como chegar até o elemento número 57?

É aí que a investigação começa.


O primeiro suspeito: o Subscript

O Subscript é o método que praticamente todo iniciante aprende.

01 WS-I PIC 9(4).

Depois:

MOVE CLIENTE-NOME (WS-I)

Parece simples.

E realmente é.

Mas existe um detalhe invisível.

Toda vez que fazemos isso, o compilador precisa calcular onde está aquele elemento.

Imagine uma estante enorme.

Você diz:

"Quero o livro número 37."

O bibliotecário pensa:

37

menos

1

×

tamanho do livro

Só depois ele encontra a posição correta.

Em linguagem de máquina acontece algo parecido.

Base da tabela

+

(I-1)

×

Tamanho do registro

Essa conta acontece continuamente.


O segundo suspeito: o Index

Agora surge um personagem misterioso.

05 CLIENTE OCCURS 100 TIMES
   INDEXED BY IDX-CLIENTE.

Observe uma coisa.

O Index não é declarado na Working-Storage.

Ele não possui PIC.

Não possui COMP.

Não possui tamanho conhecido.

Na verdade...

Você nunca sabe como ele realmente é.

Porque ele pertence ao compilador.

É um objeto especial.


O maior mito do COBOL

Durante décadas ouvimos:

"Index é uma variável COMP."

Não.

Isso nunca foi garantido pelo padrão COBOL.

O Enterprise COBOL pode implementá-lo da maneira que desejar.

Ele normalmente utiliza deslocamentos internos.

Mas isso faz parte da implementação do compilador.

Não do programa.

Por isso não podemos fazer:

ADD 1 TO IDX

O compilador simplesmente responde:

"Não."

Quem controla o Index é ele.

Não você.


O laboratório encontra uma pista

Imagine esta tabela.

Registro

34 bytes

O elemento 2 começa exatamente após 34 bytes.

O elemento 3 começa após 68.

O elemento 4 após 102.

O Index guarda justamente esse deslocamento.

Em vez de calcular tudo novamente...

Ele já sabe onde está.

É como um GPS.

Enquanto o Subscript pergunta:

"Qual rua?"

O Index responde:

"Já estou estacionado na frente da casa."


O verdadeiro funcionamento interno

Subscript

Base

+

(I × tamanho)

Index

Base

+

Offset

Essa diferença parece pequena.

Mas em milhões de repetições...

Ela cresce.

Muito.


Então o Index sempre vence?

Não.

Aqui entra um dos maiores avanços dos compiladores modernos.

Os primeiros compiladores COBOL surgiram quando processadores eram extremamente limitados.

Multiplicar números custava caro.

Hoje...

O Enterprise COBOL 6.x é absurdamente inteligente.

Ele reconhece padrões.

Remove cálculos repetidos.

Mantém valores em registradores.

Transforma multiplicações em deslocamentos.

Faz otimizações que simplesmente não existiam nos anos 70.

Em diversas situações...

Subscript e Index acabam gerando praticamente o mesmo código de máquina.

Sim.

Você leu corretamente.


O fantasma dos anos 1970

Por que então tantos livros dizem:

"Nunca use Subscript."

Porque eles estavam certos...

Na época deles.

Era uma realidade dos compiladores antigos.

Hoje a situação mudou.

Mas o mito permaneceu vivo.

É um daqueles vírus culturais que atravessam gerações.

Assim como em The Andromeda Strain, onde o verdadeiro perigo era um organismo microscópico desconhecido, aqui o verdadeiro "vírus" é uma recomendação antiga repetida sem contexto.


SEARCH: onde o Index reina absoluto

Existe um momento em que não há discussão.

SEARCH.

SEARCH CLIENTE

Ou

SEARCH ALL CLIENTE

Esses comandos exigem Index.

Por quê?

Porque o compilador controla o deslocamento automaticamente.

Ele move o ponteiro.

Avança.

Retrocede.

Calcula posições intermediárias.

Tudo sem intervenção do programador.


SEARCH ALL e a inteligência da busca binária

Imagine uma lista com um milhão de clientes.

Uma busca sequencial faria:

1

2

3

4

5

6

...

999999

SEARCH ALL faz algo muito diferente.

500000

↓

250000

↓

375000

↓

312500

Cada comparação elimina metade da tabela.

É o famoso algoritmo Binary Search.

Complexidade:

O(log n)

Enquanto uma busca sequencial é

O(n)

A diferença entre essas duas abordagens é gigantesca quando falamos em milhões de registros.


Um detalhe que poucos conhecem

Podemos copiar índices.

SET IDX-B TO IDX-A

Isso não copia um número.

Copia o deslocamento interno.

É extremamente eficiente.


Outra curiosidade

Você consegue escrever:

DISPLAY WS-I

Mas nunca faz:

DISPLAY IDX

Porque ele não representa um número lógico.

Ele representa uma posição interna conhecida apenas pelo compilador.


O que realmente acontece no processador IBM Z?

Agora entramos na sala limpa do laboratório.

Os processadores IBM Z atuais possuem instruções extremamente sofisticadas para cálculo de endereços.

O Enterprise COBOL conhece essas instruções.

Ele utiliza registradores.

Mantém offsets.

Evita recálculos.

Explora pipelines internos do processador.

Resultado?

Muito do trabalho pesado desaparece antes mesmo do programa executar.

É uma das razões pelas quais aplicações COBOL continuam processando milhões de transações por segundo.


Comparando com C

Quem conhece C entende rapidamente.

Subscript lembra:

array[i]

O compilador faz:

base

+

i

×

sizeof(item)

Já o Index funciona como um ponteiro controlado pelo compilador.

Embora tecnicamente não seja um ponteiro exposto ao programador.


Quando usar Subscript?

Excelente escolha para:

✔ programas didáticos

✔ tabelas pequenas

✔ processamento simples

✔ manutenção fácil

✔ código mais intuitivo


Quando usar Index?

Ideal para:

✔ SEARCH

✔ SEARCH ALL

✔ tabelas enormes

✔ processamento intensivo

✔ milhões de iterações

✔ rotinas críticas


Curiosidade histórica

Nos anos 1970, CPU era um recurso precioso.

Algumas empresas alugavam tempo de processamento por minuto.

Cada instrução economizada significava dinheiro.

Não era exagero.

Era sobrevivência.

Foi nesse ambiente que a preferência por Index nasceu.

Décadas depois, muitos programadores continuam repetindo a recomendação sem conhecer sua origem.


Easter Egg Bellacosa Mainframe 🥚

Se você assistir novamente The Andromeda Strain, perceberá que praticamente toda a tensão do filme vem da investigação meticulosa.

Ninguém sai correndo.

Ninguém explode prédios.

Ninguém derrota o problema com um discurso motivacional.

Os cientistas fazem algo muito mais difícil:

Eles observam.

Coletam evidências.

Eliminam hipóteses.

É exatamente assim que trabalham os melhores analistas de performance em mainframe.

Eles não começam alterando código.

Eles analisam:

  • RMF

  • SMF

  • CPU Time

  • EXCP

  • Cache

  • WLM

  • Explain

  • Dumps

  • Estatísticas do compilador

Performance não nasce de achismos.

Nasce de evidências.


Curiosidades que poucos iniciantes conhecem

☕ O comando SET IDX UP BY 1 não soma necessariamente o valor 1. Ele ajusta o deslocamento interno para o próximo elemento da tabela, independentemente do tamanho do registro.

☕ Um OCCURS DEPENDING ON cria tabelas de tamanho variável, exigindo atenção extra ao acessar elementos.

SEARCH ALL só funciona corretamente quando a tabela está previamente ordenada pelo campo pesquisado. Muitos erros de produção surgem porque essa regra foi esquecida.

☕ O Enterprise COBOL pode eliminar cálculos redundantes durante a compilação, principalmente com níveis altos de otimização (OPTIMIZE).

☕ Em alguns casos, o gargalo não está no acesso à tabela, mas no I/O, em chamadas ao Db2, VSAM ou CICS. Otimizar Subscript versus Index sem medir o restante do programa pode não produzir ganho perceptível.


Passo a passo para escolher corretamente

  1. A tabela é pequena?
    Use Subscript. A clareza do código geralmente vale mais.

  2. Há busca frequente?
    Considere INDEXED BY e SEARCH.

  3. A tabela está ordenada?
    Aproveite SEARCH ALL para busca binária.

  4. O programa processa milhões de registros?
    Meça o desempenho antes de otimizar.

  5. O compilador moderno já resolve o problema?
    Verifique o código gerado e os relatórios de otimização antes de assumir que existe vantagem.

  6. Você está seguindo um mito ou uma evidência?
    Essa talvez seja a pergunta mais importante de todas.


Conclusão – O verdadeiro agente invisível

No fim da investigação, descobrimos que o verdadeiro inimigo não era o Subscript.

Nem o Index.

O verdadeiro agente invisível era o mito.

Durante décadas, frases como "Index sempre é mais rápido" foram repetidas como se fossem leis universais. A realidade é muito mais interessante: compiladores evoluíram, processadores IBM Z ficaram extraordinariamente eficientes e muitas otimizações passaram a acontecer automaticamente.

Isso não significa que Subscript e Index sejam iguais. Eles continuam sendo conceitos diferentes, com propósitos diferentes. O Index permanece essencial para SEARCH, SEARCH ALL e cenários de alto desempenho. O Subscript continua sendo simples, legível e perfeitamente adequado para inúmeras aplicações.

O programador COBOL que apenas memoriza regras continua preso aos manuais dos anos 1970. Já aquele que entende o funcionamento interno da linguagem, do compilador e da arquitetura IBM Z enxerga além dos mitos. Ele sabe quando confiar no compilador, quando medir desempenho e quando realmente vale a pena otimizar.

Como em The Andromeda Strain, o sucesso não pertence a quem faz mais barulho. Pertence a quem observa os detalhes invisíveis, testa hipóteses e toma decisões baseadas em evidências. No universo do mainframe, essa mentalidade é o que transforma um simples programador em um verdadeiro investigador dos sistemas críticos que sustentam bancos, governos e a economia mundial.

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