Translate

sábado, 12 de dezembro de 2020

Quem é o dono da história — o autor ou o público?

 Quem é o dono da história — o autor ou o público?


(Um café filosófico sobre arte, ego e a tirania dos finais felizes)


O dilema da autoria

Toda vez que um final polêmico acontece — como em Usagi Drop, Attack on Titan ou Neon Genesis Evangelion — uma pergunta ressurge nas redes:
De quem é a história?
Do autor que a criou, ou do público que a viveu emocionalmente?

A resposta, na prática, é um campo de guerra.

O autor escreve com intenção, com alma, com seus demônios. Mas quando o público lê, a obra deixa de ser apenas dele. Ela passa a existir dentro de cada espectador, moldada por memórias, esperanças e dores pessoais.
Quando o autor destrói algo que o público ama, ele não está apenas “mudando o final” — está violando o universo emocional que o leitor ajudou a construir.


💥 A era da audiência participativa

Vivemos a era do “feedback instantâneo”.
Antes, o leitor escrevia cartas. Hoje, escreve threads inflamadas, vídeos de reação, campanhas de boicote e hashtags pedindo “final alternativo”.

As redes sociais transformaram o público em coparticipante da obra, e isso alterou o equilíbrio de poder:

  • O autor cria o universo.

  • O público o habita, o defende e o exige de volta quando ele muda demais.

É o que muitos chamam de “ditadura do fandom” — quando o amor pela obra vira controle sobre ela.


🎭 O paradoxo da liberdade criativa

O público diz amar a criatividade, mas só até ela contrariar suas expectativas.
Quer finais surpreendentes, mas não tristes. Quer ousadia, mas sem desconforto. Quer originalidade, desde que siga o padrão emocional aprovado pela maioria.

Esse paradoxo sufoca a arte.
A arte verdadeira nasce do risco, do erro, da coragem de desagradar.
Sem isso, tudo vira produto feito sob medida para agradar o algoritmo.


📚 Curiosidades e exemplos

  • The Last of Us Part II (2020) foi massacrado por fãs que não aceitaram a morte de um personagem querido.

  • Game of Thrones teve sua equipe perseguida online após o final da série, com petições exigindo regravações.

  • Evangelion, em 1995, gerou tantas cartas de ódio que Hideaki Anno respondeu com um final ainda mais metafórico e provocador.

  • Usagi Drop foi linchado digitalmente, mesmo sendo uma escolha coerente com a visão da autora sobre amor e amadurecimento.


🧠 Reflexão Bellacosa

O público não é dono da história, mas é dono da experiência emocional que ela lhe causou.
O autor é dono da obra, mas perde o controle sobre o que ela significa quando a entrega ao mundo.
Entre esses dois extremos, nasce o conflito moderno da arte:
quem sente, acha que tem direito; quem cria, acha que tem razão.


💬 Mensagem final

A arte não é uma democracia.
Ela é um diálogo tenso entre liberdade e empatia.
Podemos discordar, criticar, até odiar um final — mas perseguir o autor é esquecer que a frustração também é parte da experiência estética.

Nem toda história foi feita para confortar.
Algumas existem para nos desafiar a crescer, mesmo quando o autor parece cruel.


Porque às vezes, o final que detestamos… é o que mais nos revela quem realmente somos como leitores.

sexta-feira, 11 de dezembro de 2020

DotCom: Capítulo XII — O Encontro de Dois Universos: Como as Startups Acabaram Descobrindo Tudo Aquilo que o Mainframe Já Sabia

 

Bellacosa Mainframe e o estouro da bolha dotcom capitulo xii 

Capítulo XII — O Encontro de Dois Universos: Como as Startups Acabaram Descobrindo Tudo Aquilo que o Mainframe Já Sabia

Por que, vinte anos depois da bolha da Internet, a computação moderna passou a redescobrir conceitos que os grandes sistemas corporativos utilizam desde as décadas de 1960 e 1970

"Às vezes, inovar significa caminhar durante vinte anos para finalmente reencontrar uma ideia que já existia."

Existe uma cena curiosa que poderia perfeitamente acontecer em uma convenção de tecnologia.

De um lado, um jovem desenvolvedor de startup.

Fala sobre microsserviços.

Containers.

Observabilidade.

Alta disponibilidade.

Escalabilidade horizontal.

Zero downtime.

Automação.

Do outro lado...

Um veterano de mainframe, com quarenta anos de experiência em COBOL e z/OS.

Ele escuta atentamente.

Sorri discretamente.

E pensa:

"Interessante... estamos fazendo algo parecido desde antes de você nascer."

Não é arrogância.

Nem saudosismo.

É apenas uma constatação histórica.

Ao longo das últimas duas décadas, boa parte da indústria de software percorreu um caminho que acabou redescobrindo muitos dos princípios que sempre estiveram presentes no universo dos grandes sistemas corporativos.

Não porque o mainframe fosse perfeito.

Mas porque problemas complexos frequentemente levam às mesmas soluções.


O Mundo das Startups Cresceu

Nos anos 1990, muitas startups possuíam apenas alguns servidores.

Poucos usuários.

Bases de dados relativamente pequenas.

Falhas ocasionais eram aceitáveis.

Se um site saísse do ar durante algumas horas...

Não era agradável.

Mas também não era o fim do mundo.

Hoje a realidade é completamente diferente.

Milhões de pessoas dependem continuamente de serviços digitais.

Bancos.

Hospitais.

Transporte.

Energia.

Comércio.

Educação.

Comunicação.

Quando esses sistemas falham...

O impacto é imediato.

A consequência?

As startups passaram a enfrentar exatamente os mesmos desafios que bancos enfrentavam há décadas.


Disponibilidade Deixou de Ser Luxo

Existe uma frase clássica na computação corporativa.

"O sistema deve estar disponível quando o cliente precisar. Não quando for conveniente para a equipe técnica."

Durante muitos anos essa preocupação parecia exclusiva dos grandes bancos.

Hoje...

Ela vale para praticamente qualquer plataforma digital.

Imagine:

Pix indisponível.

Uber fora do ar.

WhatsApp inacessível.

Amazon parada.

Netflix indisponível durante uma estreia.

A tolerância dos usuários tornou-se extremamente pequena.

O conceito de 24x7x365, tão comum no universo IBM Z, passou a fazer parte da realidade de praticamente toda empresa digital.


Escalabilidade: O Mesmo Problema, Novas Ferramentas

Outro conceito redescoberto foi a escalabilidade.

Nos anos 1970 um banco precisava processar milhões de transações.

Hoje uma rede social também.

Mudou o tipo de aplicação.

Não mudou o desafio.

Como atender milhões de usuários simultaneamente?

Como evitar gargalos?

Como distribuir carga?

Como manter consistência?

As respostas modernas utilizam containers, Kubernetes e computação em nuvem.

Os grandes sistemas utilizavam LPARs, Parallel Sysplex, Workload Manager (WLM), filas de processamento e balanceamento inteligente muito antes disso.

As tecnologias mudaram.

O problema permaneceu exatamente o mesmo.


A Redescoberta da Resiliência

Durante os primeiros anos da Web, muitas empresas aceitavam falhas frequentes.

Era quase esperado.

"Vamos reiniciar o servidor."

"Depois volta."

Hoje isso é impensável em diversos setores.

A computação moderna passou a investir fortemente em:

redundância;

replicação;

failover;

recuperação automática;

balanceamento de carga;

distribuição geográfica.

Curiosamente...

Esses conceitos sempre fizeram parte da cultura dos sistemas críticos.

O vocabulário mudou.

A filosofia permaneceu.


Observabilidade: Um Nome Novo para uma Necessidade Antiga

Hoje fala-se muito sobre observabilidade.

Logs.

Métricas.

Tracing distribuído.

Dashboards.

Alertas inteligentes.

OpenTelemetry.

Grafana.

Prometheus.

Tudo isso representa enorme evolução tecnológica.

Mas o princípio é antigo.

Um ambiente de produção precisa ser observado continuamente.

Administradores de mainframe fazem isso há décadas utilizando:

SMF.

RMF.

OMEGAMON.

NetView.

Tivoli.

Relatórios estatísticos.

Planejamento de capacidade.

Mais uma vez...

Mudaram as ferramentas.

Não mudou a necessidade.


DevOps e a Cultura Operacional

Durante muito tempo acreditou-se que DevOps representava algo totalmente novo.

Na realidade...

Ele trouxe enorme inovação.

Mas também recuperou práticas tradicionais.

Automação.

Controle de mudanças.

Padronização.

Gestão de configuração.

Monitoramento.

Integração entre desenvolvimento e operações.

Em ambientes IBM Z esses conceitos sempre estiveram profundamente presentes.

A diferença é que agora eles passaram a ser aplicados também ao restante da indústria.


Segurança Nunca Foi um Acessório

Durante os anos 1990 era relativamente comum adicionar segurança apenas no final dos projetos.

Hoje isso seria considerado extremamente perigoso.

Surgiu então o conceito de Security by Design.

Projetar segurança desde o início.

Curiosamente...

Mainframes sempre seguiram essa filosofia.

RACF.

SAF.

ACEE.

Controle de acesso.

Auditoria.

Segregação de funções.

Privilégios mínimos.

Proteção de datasets.

Tudo isso fazia parte da arquitetura.

Não era um complemento.

Era a fundação.

Hoje chamamos essa abordagem de Zero Trust em muitos ambientes distribuídos.

O princípio continua surpreendentemente parecido.


APIs Aproximaram Dois Mundos

Durante muitos anos existiu um mito.

Mainframes eram fechados.

A Internet era aberta.

Essa visão tornou-se rapidamente ultrapassada.

Hoje encontramos:

REST.

SOAP.

GraphQL.

gRPC.

MQ.

Kafka.

Eventos.

Web Services.

z/OS Connect.

IMS Connect.

CICS Web Services.

Os sistemas corporativos passaram a conversar naturalmente com aplicações modernas.

A fronteira praticamente desapareceu.

Hoje um aplicativo instalado em um smartphone frequentemente consulta informações processadas por programas COBOL executando em um IBM Z.

O usuário sequer percebe.

E talvez esse seja o maior elogio possível para uma arquitetura.

Ela funciona de forma transparente.


Cloud e Mainframe Deixaram de Ser Rivais

Outro mito importante desapareceu.

Durante anos criou-se a falsa ideia de que nuvem substituiria completamente os mainframes.

A realidade mostrou algo muito mais interessante.

Eles passaram a trabalhar juntos.

Hoje encontramos arquiteturas híbridas onde:

IBM Z processa transações críticas.

Cloud executa aplicações escaláveis.

Containers hospedam microsserviços.

APIs integram tudo.

A Inteligência Artificial analisa informações produzidas pelos sistemas corporativos.

Não existe competição.

Existe complementaridade.

Cada ambiente faz aquilo em que é melhor.


A Inteligência Artificial Reforçou Essa Aproximação

A chegada da IA acelerou ainda mais essa convergência.

Modelos precisam de dados.

Os dados mais importantes das empresas continuam armazenados em sistemas corporativos.

Bancos.

Seguradoras.

Hospitais.

Indústrias.

Governos.

Grande parte dessas informações permanece em plataformas tradicionais.

Assim, a IA não substitui o mainframe.

Ela depende dele.

É uma mudança de perspectiva extremamente importante.


O Que as Startups Ensinaram ao Mainframe

Essa história também possui o movimento inverso.

Não foram apenas as startups que aprenderam com os sistemas corporativos.

O universo mainframe também absorveu diversas ideias vindas da cultura startup.

Interfaces mais amigáveis.

Experiência do usuário.

Entrega contínua.

Git.

DevOps.

Open Source.

Containers.

Kubernetes.

APIs.

Automação.

Cloud híbrida.

Ferramentas modernas de desenvolvimento.

Hoje um desenvolvedor COBOL pode trabalhar utilizando Visual Studio Code, GitHub, pipelines CI/CD, testes automatizados e inteligência artificial para auxílio na programação.

O encontro aconteceu dos dois lados.


A Grande Convergência

Talvez este seja um dos acontecimentos mais importantes da computação nas últimas décadas.

Os dois mundos deixaram de competir.

Começaram a convergir.

Startups aprenderam robustez.

Mainframes incorporaram agilidade.

Cloud trouxe elasticidade.

IBM Z trouxe confiabilidade.

Open Source acelerou inovação.

Enterprise Computing trouxe governança.

Inteligência Artificial conectou todos esses elementos.

O resultado é um ecossistema muito mais rico do que qualquer um desses mundos isoladamente.


O Padawan COBOL Vive um Momento Único

Talvez nenhum momento da história tenha sido tão interessante para um novo profissional de tecnologia.

Hoje é possível estudar:

COBOL.

Python.

Java.

REST.

Docker.

OpenShift.

Git.

Ansible.

Cloud.

Kubernetes.

Machine Learning.

IA Generativa.

Tudo isso sem abandonar os fundamentos construídos ao longo de décadas.

Na verdade...

Quem compreende fundamentos aprende novas tecnologias muito mais rapidamente.


O Futuro Não Escolheu um Lado

Durante muitos anos parecia existir uma guerra.

Mainframe versus servidores.

COBOL versus Java.

Cloud versus IBM Z.

Legacy versus moderno.

Hoje percebemos que essas disputas eram artificiais.

Os sistemas mais sofisticados do mundo utilizam praticamente todas essas tecnologias ao mesmo tempo.

Cada uma resolve um tipo diferente de problema.

A verdadeira maturidade tecnológica consiste justamente em escolher a ferramenta adequada para cada situação.


Lições para o Padawan COBOL

Quando um jovem oficial entra pela primeira vez na sala de engenharia da USS Enterprise, costuma ficar impressionado com os motores de dobra, os painéis holográficos e a tecnologia futurista.

Mas o engenheiro-chefe sabe de um segredo.

Nenhuma nave permanece em operação durante décadas apenas porque possui equipamentos modernos.

Ela continua voando porque respeita princípios fundamentais de engenharia.

Redundância.

Monitoramento.

Segurança.

Planejamento.

Disciplina.

Melhoria contínua.

Foi exatamente isso que aconteceu com a computação.

As startups trouxeram velocidade.

O mainframe trouxe estabilidade.

A nuvem trouxe elasticidade.

A Inteligência Artificial trouxe uma nova forma de interação.

Nenhuma dessas revoluções anulou a anterior.

Cada uma acrescentou uma nova camada ao edifício da tecnologia.

Talvez essa seja a maior lição de toda esta jornada.

O futuro raramente destrói completamente o passado.

Na maioria das vezes...

Ele é construído sobre ele.

No próximo capítulo faremos uma última grande conexão com o presente, analisando por que a corrida da Inteligência Artificial lembra tanto os anos que antecederam a bolha das Dot-Com, quais sinais devemos observar, o que realmente mudou em vinte anos e como um profissional de tecnologia pode se preparar para aproveitar essa nova revolução sem repetir os erros do passado.


segunda-feira, 7 de dezembro de 2020

Os Rankings das Linguagens : Quando um Programador Descobre que o GitHub Não Enxerga o Mainframe... e Percebe que a Economia Mundial Funciona Graças ao Lado Invisível da Computação

Bellacosa Mainframe e os rankings das linguagens de programaçao mito ou realidade


☕ Um Café no Bellacosa Mainframe

Os Rankings das Linguagens sem Mistérios para Programadores COBOL

Quando um Programador Descobre que o GitHub Não Enxerga o Mainframe... e Percebe que a Economia Mundial Funciona Graças ao Lado Invisível da Computação

"Gentlemen, you can't fight in here! This is the War Room!"
— Dr. Strangelove (1964)

Imagine a cena.

Você acaba de entrar na famosa Sala de Guerra do Pentágono.

No centro da mesa existe um enorme painel luminoso mostrando o ranking mundial das linguagens de programação.

Python em primeiro.

C em segundo.

C++ em terceiro.

Java logo atrás.

JavaScript subindo.

Rust fazendo propaganda de si mesmo.

Enquanto isso...

Lá no canto inferior da tela...

COBOL aparece discretamente na posição 19.

Os jovens desenvolvedores olham para a tela e concluem:

"Pronto. Está morto."

Nesse momento, um general entra correndo na sala.

— Senhor!

— Sim?

— O sistema que processa a folha salarial das Forças Armadas parou.

— Em que linguagem ele foi escrito?

Silêncio.

Outro oficial responde:

— COBOL.

Cinco segundos depois...

Todos na sala percebem que talvez aquele ranking não estivesse contando exatamente toda a história.

E é exatamente sobre isso que vamos conversar hoje.

Prepare seu café.

Hoje vamos descobrir por que popularidade não é sinônimo de importância, por que o COBOL pode ser considerado uma espécie de Matéria Escura da Computação, e por que muitos rankings enxergam apenas a superfície do iceberg tecnológico.


Capítulo 1 — O Grande Mapa-Múndi das Linguagens

Todo ano surgem dezenas de rankings.

TIOBE.

RedMonk.

GitHub Octoverse.

Stack Overflow.

PYPL.

IEEE Spectrum.

Todos prometem responder à pergunta:

"Qual é a linguagem mais importante do mundo?"

Parece simples.

Mas existe um pequeno problema.

Nenhum deles mede exatamente a mesma coisa.

É como perguntar:

Qual é o melhor veículo?

E misturar numa mesma pesquisa:

  • quantidade de bicicletas vendidas;

  • número de aviões em operação;

  • caminhões registrados;

  • navios cargueiros;

  • foguetes lançados.

Todos são veículos.

Mas cumprem funções completamente diferentes.


Capítulo 2 — O Python é realmente o Rei?

Sim.

Mas depende da pergunta.

Python domina praticamente todos os indicadores modernos.

Por quê?

Porque está presente em:

  • Inteligência Artificial;

  • Machine Learning;

  • Ciência de Dados;

  • Automação;

  • DevOps;

  • Cloud Computing;

  • Segurança;

  • Ensino universitário.

Se milhões de estudantes aprendem Python todos os anos...

Os rankings naturalmente irão refletir isso.

Isso não é manipulação.

É estatística.


Capítulo 3 — O Primeiro Grande Erro

A maioria das pessoas interpreta rankings assim:

Popularidade = Importância

Só que isso é falso.

Vamos imaginar dois programas.

Programa A

Um aplicativo que troca a cor de um botão.

Escrito em JavaScript.

Possui:

  • 120.000 estrelas no GitHub

  • milhares de forks

  • vídeos no YouTube

  • milhares de perguntas no Stack Overflow


Programa B

Sistema nacional de aposentadorias.

Escrito em COBOL.

Possui:

  • zero estrelas;

  • zero forks;

  • zero vídeos;

  • zero repositórios públicos.

Mas movimenta bilhões todos os meses.

Qual deles é mais importante?

A resposta é óbvia.


Capítulo 4 — A Grande Pegadinha Estatística

Vamos analisar cada ranking.

GitHub Octoverse

Mede:

  • commits

  • pull requests

  • forks

  • repositórios públicos

Percebe o problema?

Quase nenhum banco publica seu Core Banking no GitHub.

Imagine o Itaú.

Imagine o Banco do Brasil.

Imagine o Bradesco.

Imagine a Caixa.

Imagine o Federal Reserve.

Imagine o Banco Central Europeu.

Agora imagine todos colocando seus programas COBOL em um repositório público.

Seria uma péssima ideia.


Capítulo 5 — Stack Overflow

Outro caso curioso.

Ele mede perguntas.

Mas pense no seguinte.

Quem pergunta mais?

Um iniciante.

Ou um profissional com trinta anos de experiência?

Normalmente o iniciante.

Logo...

Linguagens maduras geram menos perguntas.

COBOL sofre exatamente desse efeito.


Capítulo 6 — PYPL

Esse ranking mede buscas por tutoriais.

Quanto mais pessoas digitam:

How to learn Python

mais Python sobe.

Isso significa que Python seja mais importante economicamente?

Não.

Significa apenas que mais pessoas estão querendo aprender Python.


Capítulo 7 — O Caso TIOBE

Talvez seja o ranking mais famoso.

Também é um dos mais discutidos.

Ele mistura:

  • pesquisas;

  • livros;

  • documentação;

  • páginas na internet;

  • cursos.

Ou seja...

Ele mede interesse.

Não mede produção.


Capítulo 8 — IEEE Spectrum

Talvez seja o mais equilibrado.

Mistura:

  • mercado;

  • vagas;

  • pesquisas;

  • GitHub;

  • tendências.

Mesmo assim...

Continua dependendo de informações públicas.

E é aí que mora o problema.


Capítulo 9 — O Universo Invisível

Agora chegamos ao ponto principal.

Imagine um iceberg.

A parte visível representa:

  • GitHub;

  • Reddit;

  • Stack Overflow;

  • Hacker News;

  • LinkedIn;

  • Medium.

É um universo enorme.

Mas ainda é apenas a ponta.

A parte submersa contém:

  • bancos;

  • seguradoras;

  • bolsas de valores;

  • previdência;

  • governo;

  • defesa;

  • companhias aéreas;

  • telecomunicações;

  • energia.

É aqui que vivem linguagens como:

  • COBOL;

  • PL/I;

  • Natural;

  • RPG;

  • Assembly;

  • MUMPS.

Esse mundo raramente aparece nos rankings.


Easter Egg nº 1

No filme Dr. Strangelove, o mundo quase acaba porque diferentes pessoas possuem apenas uma parte da informação.

Na computação acontece algo semelhante.

O desenvolvedor Front-End conhece React.

O arquiteto conhece Java.

O DBA conhece Db2.

O Sysprog conhece z/OS.

O operador conhece JES2.

Mas pouquíssimas pessoas enxergam o sistema inteiro.


Capítulo 10 — O Conceito de Deep Language

Não existe uma definição acadêmica oficial para "Deep Language", mas a expressão ajuda a visualizar um fenômeno real.

Podemos pensar em linguagens "profundas" como aquelas que:

  • sustentam sistemas críticos;

  • vivem em ambientes fechados;

  • são pouco visíveis ao público;

  • possuem décadas de evolução;

  • armazenam regras de negócio acumuladas ao longo do tempo.

São linguagens que operam nas camadas mais profundas da infraestrutura digital.


Capítulo 11 — O Cofre Invisível

Imagine um enorme cofre.

Dentro dele existem:

  • cinquenta milhões de linhas COBOL;

  • vinte milhões PL/I;

  • milhares de programas Assembly;

  • regras bancárias acumuladas durante cinquenta anos.

Nenhum mecanismo de busca consegue enxergar isso.

Nenhum ranking consegue contar essas linhas.

É literalmente um universo invisível.


Curiosidade Bellacosa

Muitos sistemas corporativos nem sequer usam Git.

Você encontrará ferramentas como:

  • Endevor;

  • ISPW;

  • ChangeMan;

  • Panvalet;

  • Librarian.

Ou seja...

Mesmo que você fosse contar commits...

Eles simplesmente não existem no GitHub.


Capítulo 12 — O Peso Econômico

Uma linha COBOL vale o mesmo que uma linha JavaScript?

Claro que não.

Imagine:

if (button == red)

Agora compare com:

CALCULAR-JUROS-COMPOSTOS
VALIDAR-LIMITE-CREDITO
PROCESSAR-PAGAMENTO
AUTORIZAR-PIX

As consequências de um erro são completamente diferentes.


Easter Egg nº 2

No universo de Dr. Strangelove existe a famosa "Máquina do Juízo Final".

No mundo financeiro também existe uma espécie de máquina invisível.

Ela não lança bombas.

Ela lança:

  • salários;

  • aposentadorias;

  • dividendos;

  • seguros;

  • financiamentos.

E boa parte dessa máquina ainda conversa fluentemente em COBOL.


Capítulo 13 — O Iceberg Tecnológico

Visualize:

              PYTHON
            JAVASCRIPT
               JAVA
             TYPESCRIPT
             GO
             RUST
------------------------------
          COBOL
          PL/I
         NATURAL
            RPG
        ASSEMBLY

A parte superior muda rapidamente.

A inferior muda lentamente.

E justamente por isso continua funcionando há décadas.


Capítulo 14 — O Paradoxo da Invisibilidade

Existe um fenômeno curioso.

Quanto mais crítico um sistema...

Menos as pessoas falam dele.

Você nunca vê manchetes dizendo:

"Sistema bancário processou corretamente mais 40 bilhões de transações hoje."

Porque isso é o esperado.

As notícias aparecem apenas quando algo falha.

O silêncio operacional é um dos maiores indicadores de sucesso em ambientes críticos.


Capítulo 15 — Como Interpretar um Ranking Corretamente

Sempre faça quatro perguntas:

1. O que está sendo medido?

Commits?

Pesquisas?

Cursos?

Perguntas?

Livros?


2. Quem ficou de fora?

Empresas privadas?

Governos?

Mainframes?

Sistemas militares?


3. O que não pode ser divulgado?

Arquiteturas bancárias.

Código-fonte.

Volumes de transações.

Regras internas.


4. Qual o objetivo?

Aprender?

Contratar?

Investir?

Escolher uma linguagem?

Ou entender a infraestrutura mundial?

Cada objetivo exige uma interpretação diferente.


Dicas para o Programador COBOL Iniciante

Se você está começando agora, não caia em dois extremos.

O primeiro é acreditar que "só existe COBOL". O segundo é imaginar que "COBOL morreu porque aparece em 19º lugar". A realidade é muito mais interessante.

Algumas recomendações práticas:

  1. Aprenda COBOL profundamente, entendendo arquivos VSAM, Db2, JCL e CICS. É isso que transforma um iniciante em alguém capaz de navegar em sistemas corporativos reais.

  2. Estude também linguagens modernas, como Python ou Java. Elas são excelentes para automação, testes, integração e APIs. Hoje, muitos projetos conectam aplicações modernas a sistemas COBOL por meio de REST, mensageria e microsserviços.

  3. Aprenda a interpretar métricas. Um gráfico bonito não substitui o entendimento de como ele foi construído.

  4. Entenda o negócio, não apenas a sintaxe. Em bancos, seguradoras e órgãos públicos, as regras de negócio costumam valer mais do que a escolha da linguagem.


Curiosidade Histórica

Nos anos 1960 e 1970, praticamente ninguém se preocupava com "rankings de linguagens". A preocupação era outra:

  • o programa compila?

  • processa corretamente?

  • entrega a folha de pagamento?

  • fecha o balanço do banco?

  • a fita magnética pode ser lida amanhã?

Décadas depois, muitos desses programas continuam executando suas funções com impressionante confiabilidade.


Conclusão — Aprendendo a Amar o Iceberg

No final de Dr. Strangelove, a obsessão por indicadores, estratégias e cálculos leva os personagens a perderem a visão do todo.

Com os rankings de linguagens pode acontecer algo parecido.

É fácil olhar para uma tabela e concluir que uma linguagem "venceu" e outra "morreu". Mas tabelas contam apenas a parte visível da história. Elas mostram onde há mais repositórios públicos, mais buscas, mais cursos e mais conversas.

O que elas não mostram é o universo silencioso que sustenta bancos, governos, seguradoras, bolsas de valores e grandes empresas.

O COBOL raramente aparece nas manchetes porque sua missão nunca foi ser popular. Sua missão foi — e continua sendo — manter sistemas críticos funcionando de forma previsível, dia após dia, ano após ano.

Talvez essa seja a maior lição para um futuro Mestre Jedi do Mainframe: não confunda visibilidade com relevância. As tecnologias mais importantes nem sempre são as que fazem mais barulho. Muitas vezes, são justamente aquelas que trabalham em silêncio, escondidas nas profundezas do iceberg digital, onde cada linha de código carrega décadas de conhecimento, bilhões de transações e a confiança de toda uma economia.

No fim das contas, os rankings nos dizem muito sobre o entusiasmo do mercado. Já os mainframes nos lembram de algo ainda mais valioso: quando o assunto é infraestrutura crítica, a verdadeira grandeza costuma estar escondida nas camadas que quase ninguém vê — mas das quais praticamente todo o mundo depende.

 

domingo, 6 de dezembro de 2020

🌧️🍂 Bellacosa Otaku Blog — Parte 37: O Silêncio da Chuva — Expressões Japonesas de Tristeza, Melancolia e Beleza Efêmera 🍂🌧️

 

Bellacosa Mainframe a cultura japonesa nas expressoes

🌧️🍂 Bellacosa Otaku Blog — Parte 37: O Silêncio da Chuva — Expressões Japonesas de Tristeza, Melancolia e Beleza Efêmera 🍂🌧️

🍂🌧️ O Silêncio da Chuva — Expressões Japonesas de Tristeza, Melancolia e Beleza Efêmera

A cultura japonesa possui uma sensibilidade única para enxergar beleza em sentimentos que muitas sociedades tentam evitar, como a tristeza, a saudade e a melancolia. Em vez de considerar essas emoções apenas negativas, os japoneses frequentemente as associam à profundidade da experiência humana e à passagem inevitável do tempo.

Um dos conceitos mais conhecidos é o Mono no Aware, a consciência da impermanência das coisas. A queda das folhas no outono, a breve floração das cerejeiras ou o som distante da chuva despertam uma melancolia suave, acompanhada pela apreciação da beleza desses momentos passageiros.

Outro termo importante é Setsunai, que descreve uma tristeza delicada, muitas vezes ligada à saudade, ao amor não correspondido ou à sensação de que algo precioso está desaparecendo. Já Sabishii expressa a solidão emocional, enquanto Natsukashii representa a nostalgia carinhosa por tempos que não voltarão.

Esses sentimentos aparecem constantemente na literatura, na poesia, nos animes e nos filmes japoneses. Obras como Your Name, 5 Centimeters per Second, Violet Evergarden e Frieren exploram essa relação entre memória, perda e beleza.

No Japão, o som da chuva não simboliza apenas tristeza. Muitas vezes ele representa reflexão, renovação e aceitação. Assim, o silêncio da chuva se transforma em uma metáfora da vida: bela justamente porque nenhum momento dura para sempre. 🍂🌧️✨



🍃 Mono no Aware — a beleza do que se desfaz

(Versão Bellacosa: o idioma que suspira quando o vento leva as flores de cerejeira.)

Na alma do idioma japonês, existe uma melancolia serena — um modo de sentir o mundo que aceita o fim como parte da beleza.
Essa filosofia, chamada mono no aware (物の哀れ), traduz-se como “a sensibilidade para o efêmero”.
É o sentimento que encontramos em Your Lie in April, Anohana ou Violet Evergarden — onde até as despedidas brilham com ternura. 🌸


🌸 1. 物の哀れ (Mono no Aware)

Tradução: “A beleza triste das coisas passageiras.”
👉 Expressa a emoção suave diante da impermanência — o toque poético da perda.

📺 Anime vibe: Your Lie in April, 5 Centimeters per Second.
💬 Exemplo: “As flores caem, mas é por isso que são belas. Mono no aware.” 🌸


💧 2. 切ない (Setsunai)

Tradução: “Doloroso / apertado no peito.”
👉 Uma tristeza delicada, que vem do amor, da saudade ou da lembrança.

📺 Anime vibe: Clannad, Vivy: Fluorite Eye’s Song.
💬 Exemplo: “Setsunai… ainda lembro do seu sorriso.” 💔


🍁 3. 哀しみ (Kanashimi)

Tradução: “Tristeza profunda.”
👉 O sentimento direto da dor, da perda e da solidão.

📺 Anime vibe: Violet Evergarden, Naruto (arco de Zabuza e Haku).
💬 Exemplo: “Kanashimi no naka de, encontrei minha força.” 🌧️


🕊️ 4. さようなら (Sayōnara)

Tradução: “Adeus.”
👉 Diferente do simples “tchau” — sayōnara é finalidade, uma partida definitiva e silenciosa.

📺 Anime vibe: Anohana, Your Name.
💬 Exemplo: “Sayōnara... mas talvez, em outro tempo, nos vejamos de novo.” 🌌


🕰️ 5. 思い出 (Omoide)

Tradução: “Memória / lembrança.”
👉 Palavra doce e nostálgica; carrega o valor das coisas que ficaram para trás.

📺 Anime vibe: Clannad: After Story, Angel Beats!
💬 Exemplo: “Esses lugares... ainda guardam nossos omoide.” 🌇


🌾 6. 寂しい (Sabishii)

Tradução: “Solto / sozinho / com saudade.”
👉 Uma solidão calma, quase carinhosa. A falta de alguém ou de um tempo que não volta.

📺 Anime vibe: Vivy, Haibane Renmei.
💬 Exemplo: “Sabishii… o vento soa igual àquela noite.” 🌬️


🌙 7. 哀愁 (Aishū)

Tradução: “Melancolia / nostalgia romântica.”
👉 Uma tristeza elegante, como uma música antiga ou um pôr do sol de outono.

📺 Anime vibe: Kino no Tabi, Vivy, Mushishi.
💬 Exemplo: “Aishū — o perfume do que já se foi.” 🍂


💭 8. 夢 (Yume)

Tradução: “Sonho.”
👉 Tanto o sonho noturno quanto o desejo inatingível. Em contextos melancólicos, simboliza esperança perdida.

📺 Anime vibe: Paprika, Erased, Your Lie in April.
💬 Exemplo: “Foi só um yume... mas parecia tão real.” 🌌


💔 9. 未練 (Miren)

Tradução: “Apego / não conseguir desapegar.”
👉 Sentimento de quem não consegue deixar o passado ir embora.

📺 Anime vibe: Plastic Memories, Anohana.
💬 Exemplo: “Miren... ainda espero ouvir sua voz.” 🕯️


🍂 10. 終わり (Owari)

Tradução: “Fim.”
👉 Palavra simples, mas cheia de reverência. No Japão, fins são vistos como partes da vida, não tragédias.

📺 Anime vibe: 5 Centimeters per Second, Vivy.
💬 Exemplo: “Owari… mas cada fim guarda um novo começo.” 🌅


🍶 Curiosidades Bellacosa:

  • Mono no aware nasceu na literatura clássica japonesa, especialmente em O Conto de Genji (século XI).

  • A tristeza japonesa é contemplativa, não desesperada — é a aceitação do ciclo natural.

  • Muitos animes usam chuva, vento e flores de cerejeira como metáforas visuais desse sentimento. 🌸


🌤️ Dica Bellacosa:

  • Escute as trilhas sonoras de Violet Evergarden ou Your Lie in April enquanto lê frases como setsunai e sabishii.

  • Note como o japonês cria palavras curtas, mas cheias de sentimento não traduzível.

  • Essas expressões ensinam que a tristeza também pode ser bonita — e necessária para o coração crescer. 💫


🌸 Conclusão Bellacosa:

O japonês tem o dom raro de tornar o efêmero eterno.
Nas suas palavras suaves, há sempre um eco de perda e gratidão, uma aceitação gentil do tempo que passa.
É o idioma que entende que, às vezes, chorar também é uma forma de agradecer.

“As flores caem, o vento muda, o coração dói — e ainda assim, o mundo continua belo.” 🍃

sexta-feira, 4 de dezembro de 2020

Lava Flow Rules: Quando um Programador COBOL Descobriu que a Matrix Estava Coberta por Fluxos de Lava Digital que Ninguém Tinha Coragem de Remover

 

Bellacosa Mainframe e a lava flow rules

☕ Um Café no Bellacosa Mainframe

Lava Flow Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Estava Coberta por Fluxos de Lava Digital que Ninguém Tinha Coragem de Remover

"O maior perigo dos sistemas legados nem sempre é o código que executa. Muitas vezes é o código que ninguém ousa apagar."


Prólogo — A Sala Proibida da Matrix

Depois de inúmeras batalhas contra o Agente Smith, Neo acreditava conhecer praticamente toda a Matrix.

Foi então que o Arquiteto abriu uma porta que nunca havia sido mostrada.

Atrás dela existia um gigantesco datacenter.

Milhares de programas.

Milhões de linhas de código.

No centro da sala havia uma placa metálica.

NÃO MODIFICAR

Neo perguntou:

— O que existe aí?

O Arquiteto respondeu:

— Não sabemos exatamente.

Neo estranhou.

— Como assim?

— Esse código foi escrito antes mesmo da sexta versão da Matrix.

— Ele ainda é usado?

O Arquiteto permaneceu em silêncio.

O Oráculo apareceu.

Olhou para Neo.

Depois para o enorme programa.

Sorriu.

— Talvez sim.

Talvez não.

Neo perguntou:

— Então por que ninguém remove?

O Oráculo respondeu:

"Porque ninguém quer descobrir a resposta em plena produção."

Bem-vindo ao Lava Flow.


O que é Lava Flow?

Lava Flow é um antipadrão de software onde partes antigas do sistema permanecem indefinidamente porque ninguém sabe se ainda são utilizadas.

São blocos de código que:

  • ninguém compreende completamente;

  • aparentemente não possuem função;

  • não aparecem na documentação;

  • mas continuam existindo por medo de removê-los.

Eles se tornam verdadeiros fósseis digitais.


A origem do nome

O termo surgiu no livro clássico AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, publicado em 1998 por William J. Brown, Raphael Malveau, Hays McCormick III e Thomas Mowbray.

A metáfora é brilhante.

Quando um vulcão entra em erupção, a lava escorre livremente.

Depois de esfriar...

ela endurece.

Com o tempo ninguém consegue mais movê-la.

Mesmo que atrapalhe a construção de estradas ou cidades.

No software acontece exatamente isso.

Uma decisão antiga endurece.

Ninguém mais consegue removê-la.


Matrix explica perfeitamente

Imagine que cada versão da Matrix deixa pequenos trechos de código esquecidos.

Programas antigos.

Rotinas obsoletas.

Protocolos desativados.

Funções nunca mais chamadas.

Mas ninguém ousa apagar.

Porque talvez...

alguma parte escondida ainda dependa delas.


Como nasce um Lava Flow?

Quase sempre começa assim.

Um projeto urgente.

Uma solução temporária.

O desenvolvedor comenta:

"Depois limpamos."

Mas o projeto termina.

A equipe muda.

O conhecimento desaparece.

O código continua.


O COBOL conhece muito bem esse fenômeno

Imagine um programa escrito em 1989.

Em determinado momento existia uma regra para calcular uma antiga taxa bancária.

Essa taxa deixou de existir em 1998.

Mas a rotina continua lá.

Em 2004 alguém perguntou:

— Podemos apagar?

Resposta:

— Melhor não...

Vai que algum lote ainda usa.

Em 2012 outra pessoa perguntou.

Mesma resposta.

Em 2026...

A rotina continua.


Um exemplo clássico

Imagine um trecho como este.

IF WS-TIPO = "X"
    PERFORM CALCULA-TAXA-ESPECIAL
END-IF

Pergunta.

Existe algum cliente com tipo X?

Ninguém sabe.

A consulta nunca foi feita.

Então o código permanece.


Outro exemplo COBOL

Você encontra:

PERFORM ROTINA-LEGADA.

Procura quem chama essa rotina.

Descobre que:

ninguém.

Mas ninguém remove.

Porque talvez exista:

  • um JCL antigo;

  • um programa batch esquecido;

  • uma PROC histórica;

  • um processo anual.


Matrix Reloaded

Lembra dos programas exilados?

Merovíngio abriga programas antigos que deveriam ter sido removidos.

Eles continuam existindo porque encontraram maneiras de sobreviver.

Esses personagens representam perfeitamente o conceito de Lava Flow.

São códigos que perderam sua função original, mas continuam ocupando espaço na Matrix.


O efeito psicológico

Existe uma frase muito conhecida em equipes de manutenção.

"Se está funcionando, não mexa."

Ela protege a estabilidade.

Mas também pode proteger código morto.

O medo da mudança faz com que partes inteiras do sistema permaneçam congeladas por décadas.


O Programador COBOL Padawan

Você abre um programa.

Encontra:

IF WS-FLAG-1987 = "S"

Pergunta ao analista mais experiente.

— O que significa?

Resposta.

— Acho que tem relação com um produto antigo.

"Acho."

Essa palavra deveria acender um alerta.


O Agente Smith adora Lava Flow

Porque código morto aumenta:

  • complexidade;

  • tempo de leitura;

  • dificuldade de testes;

  • risco de manutenção.

Quanto mais difícil compreender o sistema, mais fácil ele se torna de dominar.


Um exemplo inspirado na Matrix

Neo encontra uma porta.

Ela não leva a lugar nenhum.

Pergunta ao Chaveiro.

— Posso removê-la?

O Chaveiro responde.

— Talvez.

Neo insiste.

— Alguém usa?

O Chaveiro sorri.

— Faz muito tempo que ninguém passa por ela...

Mas ninguém quer ser o primeiro a descobrir.


Como reconhecer Lava Flow?

Alguns sinais são clássicos.

Comentários antigos

TEMPORÁRIO
REMOVER DEPOIS

E o comentário tem quinze anos.


Código nunca executado

Cobertura de testes mostra zero chamadas.


Variáveis sem uso

Declaradas.

Nunca lidas.


COPYBOOKs esquecidos

Presentes.

Jamais referenciados.


JCLs históricos

Executados pela última vez em 2014.


O custo invisível

Cada novo desenvolvedor precisa entender:

o código ativo

o código morto.

Mesmo que metade nunca execute.


O impacto no Mainframe

Mainframes corporativos costumam preservar compatibilidade por décadas.

Isso é excelente para o negócio.

Mas também significa que:

  • programas antigos sobrevivem;

  • interfaces antigas permanecem;

  • layouts históricos continuam disponíveis.

Nem tudo pode ser removido imediatamente.


Atenção!

Lava Flow não significa simplesmente "código antigo".

Código antigo pode ser extremamente importante.

O problema é:

código antigo

sem propósito conhecido.


A diferença

Legado

Ainda possui função.


Lava Flow

Ninguém sabe se possui função.


Curiosidade

Diversos sistemas bancários ainda mantêm rotinas para formatos de arquivos que não são utilizados há muitos anos, apenas porque existe a possibilidade de algum cliente institucional ainda depender deles em um processamento específico.


Ferramentas ajudam

Hoje é possível descobrir muito mais do que antigamente.

Ferramentas como:

  • IBM Application Discovery and Delivery Intelligence (ADDI);

  • IBM Developer for z/OS;

  • IBM COBOL Check;

  • SonarQube;

  • Enterprise Analyzer;

permitem identificar:

  • programas sem referências;

  • COPYBOOKs não utilizados;

  • dependências reais;

  • fluxo de chamadas;

  • cobertura de execução.

Elas reduzem significativamente o medo de remover código.


Como evitar?

Descoberta arquitetural

Conheça dependências reais.


Testes automatizados

Eles fornecem confiança.


Monitoramento

Descubra quem realmente utiliza cada componente.


Refatoração contínua

Pequenas limpezas são mais seguras do que grandes reescritas.


Documentação viva

Explique por que algo permanece.


Revisões periódicas

Reserve tempo para eliminar o que perdeu utilidade.


O perigo da limpeza precipitada

O extremo oposto também é perigoso.

Imagine remover uma rotina porque "parece inútil".

Na madrugada do último dia útil do ano...

ela é executada pelo fechamento contábil.

Resultado:

ABEND.

Incidente crítico.

Por isso remover exige evidências.

Nunca intuição.


Matrix e os Programas Exilados

O Merovíngio colecionava programas antigos.

Eles não tinham mais função oficial.

Mesmo assim continuavam vivos.

Esses personagens representam exatamente os componentes esquecidos que permanecem escondidos em sistemas corporativos.

Nem todos causam problemas.

Mas todos aumentam a complexidade.


O papel da IA

Ferramentas baseadas em IA podem:

  • localizar código aparentemente morto;

  • resumir módulos antigos;

  • mapear dependências;

  • identificar duplicações;

  • sugerir candidatos à remoção.

Entretanto, a decisão final continua sendo humana.

Especialmente em ambientes críticos.


Os riscos

Complexidade crescente

Mais código para entender.


Testes maiores

Mais cenários.


Custos

Mais manutenção.


Bugs

Mudanças evitadas por medo.


Segurança

Bibliotecas antigas podem permanecer vulneráveis.


Conhecimento perdido

Ninguém sabe mais o propósito original.


Erros clássicos

  • Nunca revisar código legado.

  • Confundir estabilidade com imobilidade.

  • Manter funcionalidades desativadas indefinidamente.

  • Não registrar decisões arquiteturais.

  • Ignorar ferramentas de análise de dependência.


Boas práticas

  • Mantenha inventário de componentes.

  • Monitore utilização real.

  • Elimine código comprovadamente morto.

  • Escreva testes antes de remover.

  • Documente exceções de negócio.

  • Faça limpezas graduais.


Aplicabilidade

Lava Flow aparece em praticamente qualquer tecnologia:

  • COBOL;

  • PL/I;

  • Java;

  • C#;

  • Python;

  • C++;

  • APIs;

  • microsserviços;

  • aplicações em nuvem;

  • sistemas embarcados.

Quanto maior a vida útil do software, maior a chance desse antipadrão surgir.


O ensinamento do Oráculo

O Oráculo leva Neo até um antigo rio de lava endurecida.

Ela pergunta:

— O que você vê?

Neo responde.

— Pedra.

Ela toca a superfície.

Debaixo dela ainda existe calor.

Então diz:

"No software acontece igual. O código pode parecer morto, mas ainda pode sustentar parte da montanha."

Antes de remover.

Investigue.


Lições para um Programador COBOL Padawan

Ao iniciar sua carreira no universo IBM Z, você encontrará programas com décadas de existência. Alguns conterão comentários escritos por pessoas que já se aposentaram. Outros farão referência a produtos, moedas, legislações e tecnologias que nem existem mais.

Não assuma que tudo isso é lixo.

Também não assuma que tudo é indispensável.

Seu papel é agir como um arqueólogo digital:

  • entender o contexto;

  • mapear dependências;

  • conversar com especialistas;

  • validar com testes;

  • registrar descobertas;

  • remover apenas aquilo cuja inutilidade esteja comprovada.

Essa disciplina preserva a estabilidade do negócio e, ao mesmo tempo, impede que a lama endurecida continue crescendo indefinidamente.


Conclusão — Nem Toda Rocha Deve Permanecer Para Sempre

Na Matrix, programas antigos podiam sobreviver escondidos entre versões sucessivas da simulação. Alguns ainda tinham propósito. Outros apenas ocupavam espaço.

Nos sistemas corporativos acontece exatamente o mesmo.

O Lava Flow representa decisões antigas que endureceram com o tempo. Elas deixaram de ser questionadas porque questioná-las parece perigoso.

Mas engenharia madura não significa apagar tudo.

Significa compreender antes de agir.

Para um Programador COBOL, essa é uma das maiores demonstrações de responsabilidade profissional. Cada remoção deve ser sustentada por evidências, testes, monitoramento e conhecimento do negócio.

No universo Bellacosa Mainframe existe uma máxima que o próprio Oráculo aprovaria:

"O código mais perigoso não é o antigo. É aquele cujo propósito ninguém mais consegue explicar."

Porque, assim como na Matrix, o verdadeiro desafio não é destruir o passado.

É descobrir quais partes dele ainda sustentam o presente e quais já podem, finalmente, descansar.

quinta-feira, 3 de dezembro de 2020

CICS Conversacional e Pseudo-Conversacional - Parte IV

 

Bellacosa Mainframe e a conversação em CICS Parte IV

☕ Um Café no Bellacosa Mainframe

CICS Conversacional e Pseudo-Conversacional

Parte 4 — COMMAREA, TSQ, TDQ, Temporary Storage, Control Blocks e os Bastidores do CICS

"Salve novamente, jovem Padawan Mainframe! Se você chegou até aqui, parabéns. Você já compreendeu como a pseudo-conversação revolucionou a escalabilidade do CICS, descobriu Channels, Containers, APIs REST e até OpenTelemetry. Mas agora vamos abrir a tampa do motor do CICS. Vamos conhecer o que acontece por trás das cortinas."

Pegue mais um café.

Abra o IPCS.

Deixe o CEDF ligado.

Reserve uma aba do SDSF.

Porque agora vamos entrar na sala das máquinas.


O que realmente acontece dentro do CICS?

Quando executamos:

EXEC CICS SEND MAP
END-EXEC

Muita gente imagina algo parecido com:

Programa

Tela

Fim.

Mas o CICS faz muito mais.


Fluxo interno

Programa COBOL

        │

        ▼

Translator

        │

        ▼

EXEC Interface

        │

        ▼

Kernel CICS

        │

        ▼

Terminal Control

        │

        ▼

BMS

        │

        ▼

TIOA

        │

        ▼

3270

TIOA

Talvez uma das estruturas menos conhecidas pelos iniciantes.

TIOA

Terminal Input Output Area

É uma área onde ficam armazenados.

Dados digitados.

Cursor.

Atributos.

AID Keys.


Exemplo

ENTER

PF3

PF5

CPF

Nome

Cursor linha 7

Cursor coluna 15

Tudo isso.

Na TIOA.


TCA

Task Control Area.

Cada task possui.


Guarda.

Status.

Transação.

Programa.

Recursos.

Flags.


EIB

Você já conhece.

Mas agora sabemos.

Ele é derivado.

Da TCA.


Control Blocks interessantes

TCT

Terminal Control Table


PPT

Program Processing Table


FCT

File Control Table


PCT

Program Control Table


SIT

System Initialization Table


Temporary Storage Queue

TSQ

Muito usada.

Em pseudo-conversação.


Imagine.

1000 registros.

Não cabem.

Na COMMAREA.


Salvamos em TSQ.


EXEC CICS WRITEQ TS

QUEUE('CLI0001')

FROM(WS-DADOS)

END-EXEC



Lendo.



EXEC CICS READQ TS

QUEUE('CLI0001')

INTO(WS-DADOS)

END-EXEC



TDQ

Transient Data Queue

Muito utilizada.

Para logs.

Integração.

Mensageria.


TSQ versus TDQ

CaracterísticaTSQTDQ
Leitura múltiplaSimNão
AtualizaçãoSimNão
SequencialNãoSim
PersistênciaOpcionalSim
Uso típicoEstadoLogs

COMMAREA versus TSQ

COMMAREA

64 KB

TSQ

Megabytes


Exemplo bancário

Tela.

Lista.

5000 clientes.

Salvar TSQ.

Usuário PF8.

Recupera TSQ.

Próxima página.


Paginando consultas

PF7

Anterior

PF8

Próxima




IF EIBAID = DFHPF8

PERFORM PAGINA-SEGUINTE


END-IF



Boas práticas

Nunca coloque.

Tabela enorme.

Na COMMAREA.


Use.

TSQ.

Ou.

Containers.


LINK

Outro comando muito importante.

Chamando programa.




EXEC CICS LINK

PROGRAM('CLI0002')

COMMAREA(WS-COMM)

END-EXEC



Retorna.

Para chamador.


XCTL

Diferente.

Não retorna.



EXEC CICS XCTL

PROGRAM('MENU0001')

END-EXEC



Programa anterior.

Morre.

Novo.

Assume controle.


START

Assíncrono.

Agenda execução.




EXEC CICS START

TRANSID('CLI1')

END-EXEC



DELAY

Muito curioso.



EXEC CICS DELAY

FOR SECONDS(5)

END-EXEC



Raramente utilizado.


CEMT

Melhor amigo.

Administrador.


Consultar tasks.


CEMT I TASK



Consultar programas.



CEMT I PROGRAM



Consultar files.



CEMT I FILE



Consultar TSQ.



CEMT I TSQUEUE



CEDF

Ferramenta maravilhosa.


Permite.

Passo a passo.

SEND.

RECEIVE.

LINK.

READ.

WRITE.

DB2.




CEDF ON



CECI

Testador.

Interativo.



CECI READ FILE




CECI RECEIVE MAP



Curiosidades Bellacosa Mainframe

Existem sistemas.

Que utilizam.

TSQ.

Desde 1988.

Ainda funcionando.

No z16.

No z17.

Sem alterações.


Easter Egg Mainframe

Muitos programadores escondiam.

Comentários.

Como.



* THIS PROGRAM IS OLDER THAN YOU


Ou.



* IF IT BREAKS


* RUN AWAY



Ou.



* WRITTEN DURING NIGHT SHIFT


* POWERED BY COFFEE



O que veremos na Parte 5

✔ Program Control;

✔ HANDLE CONDITION;

✔ HANDLE ABEND;

✔ RESP e RESP2;

✔ Syncpoint;

✔ Journaling;

✔ Recoverable Resources;

✔ Mirror Transactions;

✔ DPL;

✔ IPIC;

✔ CICSplex;

✔ CPSM;

✔ Threadsafety;

✔ Open TCBs;

✔ OTE;

✔ E muitos outros segredos do universo CICS.


No Bellacosa Mainframe aprendemos uma regra simples: se você acredita que já conhece o CICS, provavelmente apenas encontrou a próxima porta do labirinto. Porque no IBM Z sempre existe mais um control block para estudar, mais um dump para analisar e mais um café esperando para ser servido.

 

quarta-feira, 2 de dezembro de 2020

Obrigado pelos 7.500 inscritos e +550.000 visualizações.

Boa tarde amigos do meu canal.

 

Sou Vagner Bellacosa e administro o canal do Youtube El Jefe Midnight Lunch, que trata de viagens, turismo, cidade e noticias.

Hoje estou muito feliz, pela primeira vez, meu canal alcançou os 7.500 inscritos e 550.000 visualizações de videos.

Tudo graças a sua ajuda, por isso quero agradecer de coração, muito obrigado pela sua inscrição e participação no canal.

Se não esta inscrito, inscreva-se, assista, deixe joinha e comente, são 1300 videos gravados com carinho.

#Vlw e #tmj

Inscreva-se no Canal

sub_confirmation=1 #vagnerbellacosa #elJefeMidnightLunch #umAndarilho

 

 

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