Translate

sexta-feira, 4 de setembro de 2020

CICS Conversacional e Pseudo-Conversacional - Parte II

 

Bellacosa Mainframe e a conversação em cics parte II

☕ Um Café no Bellacosa Mainframe

CICS Conversacional e Pseudo-Conversacional

Parte 2 — Escalabilidade, COMMAREA, Channels, Web Services e Boas Práticas

"Na primeira parte aprendemos que programas conversacionais gostam de ficar esperando o usuário pensar, enquanto programas pseudo-conversacionais executam como ninjas do IBM Z: aparecem, trabalham, desaparecem e retornam apenas quando necessários. Agora vamos entender por que a IBM praticamente transformou a pseudo-conversação em padrão de mercado."

Pegue mais um café, abra o CEDF, deixe o CEMT pronto e vamos continuar nossa jornada.


Os problemas do modelo Conversacional

O modelo conversacional é elegante.

É simples.

É intuitivo.

Mas infelizmente é extremamente caro.

Vamos imaginar um banco.

Cenário

50.000 usuários.

Cada usuário demora:

20 segundos

para preencher uma tela.


Aplicação Conversacional

Programa fica ativo.

Task permanece viva.

TCB permanece associado.

TCA permanece ocupada.

Storage continua reservado.

EIB continua residente.

Tudo isso...

Durante vinte segundos.


Resultado

Pouca escalabilidade.

Maior uso de CPU.

Maior consumo de memória.

Possibilidade de gargalos.


O fenômeno Think Time

Um dos maiores inimigos do CICS.

Think Time.

Tempo em que o usuário está apenas pensando.

Exemplos:

Lendo uma tela.

Pegando um documento.

Atendendo telefone.

Procurando CPF.

Conversando com cliente.


Conversacional

Think Time = recursos desperdiçados


Pseudo

Think Time = recursos liberados


A IBM fez uma escolha inteligente

Ao invés de esperar.

Finaliza a task.

Salva contexto.

Cria nova task depois.


Visualmente:

Task 1

Mostra tela

RETURN


=================


Usuário pensa


=================


Task 2


Recebe dados


Processa


RETURN

Múltiplas telas

Poucos desenvolvedores COBOL iniciantes percebem.

Uma pseudo-conversação pode navegar por dezenas de telas.

Exemplo:

Menu

Consulta

Inclusão

Alteração

Confirmação

Resumo

Help

Paginação


Exemplo

MENU

PF5

CONSULTA

ENTER

DETALHE

PF3

MENU


Tudo utilizando.

COMMAREA.


COMMAREA

Provavelmente um dos conceitos mais importantes do CICS.

Ela guarda estado.

Entre uma task.

E outra.


Exemplo:


01 WS-COMM.

   05 WS-MODO PIC X.

   05 WS-PAGINA PIC 99.

   05 WS-CPF PIC 9(11).

   05 WS-NOME PIC X(30).


Limitação

COMMAREA possui limite.

64 KB.


Antigamente

Era suficiente.


Hoje.

JSON.

REST.

SOAP.

XML.

JWT.

Podem ultrapassar facilmente.

64 KB.


Surge Channels e Containers

Introduzidos para resolver isso.


COMMAREA

64 KB


Container

Gigabytes.


Exemplo


EXEC CICS PUT CONTAINER

CONTAINER('CLIENTE')

FROM(WS-DADOS)

END-EXEC



Recuperando.


EXEC CICS GET CONTAINER

CONTAINER('CLIENTE')

INTO(WS-DADOS)

END-EXEC



Qual utilizar?

Sistemas antigos

COMMAREA


Novos projetos

Channels

Containers


EIBCALEN

Nos projetos antigos.

Era rei.




IF EIBCALEN = ZERO


PERFORM PRIMEIRA-VEZ


ELSE


PERFORM RETORNO


END-IF



Pseudo-Conversação com BMS

Fluxo típico.


SEND MAP

RETURN

Usuário ENTER

Nova Task

RECEIVE

DB2

SEND

RETURN


Web Services no CICS

Muitos acreditam.

Que CICS é apenas 3270.

Isso está muito longe da realidade.


CICS suporta.

SOAP.

REST.

JSON.

XML.

MQ.

JMS.

TCP/IP.

HTTP.

HTTPS.


Exemplo

Angular

API

zOS Connect

CICS

COBOL

DB2


Visualmente



Browser


   │


REST API


   │


zOS Connect


   │


CICS


   │


COBOL


   │


DB2



O COBOL muda?

Quase nada.


Exemplo


PERFORM VALIDA


PERFORM CONSULTA-DB2


PERFORM RETORNA-DADOS




Interface muda.

Negócio permanece.


SOAP

Muito usado.

Seguradoras.

Governo.

ERP.


REST

Dominante.

OpenAPI.

Swagger.

JSON.


BMS ainda é importante?

Sim.

Muito.


Milhares de aplicações.

Continuam em produção.


Além disso.

BMS ensina.

Arquitetura.

Separação de responsabilidades.

Persistência de contexto.

Gerenciamento de estado.


Problemas comuns

MAPFAIL

Usuário apertou PF3.

Sem alterar dados.


INVREQ

Sequência incorreta.


LENGERR

Área pequena.


ASRA

S0C7.

S0C4.

S0CB.


Como debugar?

CEDF.

Excelente.



CEDF ON



Programa para.

Comando por comando.


CECI

Muito útil.


Exemplo


CECI RECEIVE MAP



CEMT

Consultar recursos.



CEMT I TASK




CEMT I PROG




CEMT I TRAN



Boas práticas

Sempre usar pseudo-conversação


Utilizar COMMAREA pequena


Preferir Containers

Projetos novos.


Não salvar tabelas grandes

Na COMMAREA.


Usar MDT apenas quando necessário


Utilizar DATAONLY

Reduz tráfego.


Evitar múltiplos SEND

Na mesma task.


Validar EIBRESP

Sempre.


Exemplo



IF EIBRESP NOT = DFHRESP(NORMAL)

PERFORM TRATA-ERRO


END-IF



Curiosidade Bellacosa Mainframe

Alguns bancos possuem aplicações pseudo-conversacionais escritas em 1986.

Elas foram migradas.

De 3090.

Para 9672.

Para z900.

Para z990.

Para z9.

Para z10.

Para z14.

Para z16.

E continuam praticamente inalteradas.


Easter Egg Mainframe

Nos anos 80.

Muitos desenvolvedores colocavam comentários curiosos.

Exemplo.



* MAY THE COBOL BE WITH YOU


Ou.



* DO NOT TOUCH


* WORKS SINCE 1987


Ou o clássico.



* IF YOU CHANGE THIS


* BUY COFFEE FOR THE TEAM



Continua...

Na Parte 3 veremos:

✔ Web Open Interface (WOI);

✔ CICS Event Processing;

✔ Programas COBOL completos;

✔ Pseudo-conversação com múltiplos MAPSETs;

✔ BMS avançado;

✔ Channels versus TSQ;

✔ Segurança RACF;

✔ Web Services SOAP e REST detalhados;

✔ Observabilidade moderna;

✔ OpenTelemetry;

✔ Curiosidades e easter eggs pouco conhecidos do universo CICS.

quinta-feira, 3 de setembro de 2020

REXX : Quando um Padawan Descobre que a Linguagem Mais Simples do Mainframe Também Pode Ser o Sabre de Luz que Automatiza uma Galáxia Inteira

 

Bellacosa Mainframe apresenta mais detalhes sobre o REXX Mainframe

☕ Um Café no Bellacosa Mainframe

REXX sem Mistérios para Programadores COBOL

Quando um Padawan Descobre que a Linguagem Mais Simples do Mainframe Também Pode Ser o Sabre de Luz que Automatiza uma Galáxia Inteira

"Não entre em pânico."
— O Guia do Mochileiro das Galáxias


Introdução — A toalha, o terminal 3270 e o estranho planeta chamado z/OS

Existe um antigo conselho interestelar que aparece em letras garrafais na capa do Guia do Mochileiro das Galáxias:

NÃO ENTRE EM PÂNICO.

Curiosamente, esse também deveria ser o primeiro conselho entregue a qualquer programador COBOL que acaba de conseguir seu primeiro acesso ao ambiente IBM Z.

Você finalmente recebe seu usuário.

TSO LOGON

A tela fica preta.

Letras verdes.

Nenhum botão.

Nenhum mouse.

Nenhuma janela.

Nenhum VS Code.

Nenhum IntelliJ.

Nenhum Visual Studio.

Você olha para aquilo e pensa:

"Será que voltei para 1984?"

Não.

Na verdade, você acabou de entrar em uma das maiores civilizações computacionais da história da humanidade.

O IBM Z é como a cidade de Megabrantis, do Guia do Mochileiro: gigantesca, viva, absurdamente organizada e funcionando sem que a maioria das pessoas faça ideia de como.

Enquanto bilhões de pessoas passam cartões, fazem PIX, compram passagens aéreas, consultam seguros ou movimentam contas bancárias, milhares de programas COBOL trabalham silenciosamente.

Mas existe um personagem pouco conhecido.

Um verdadeiro robô de manutenção.

Um droide.

Um ajudante.

Um companheiro inseparável.

Seu nome é:

REXX.

E hoje vamos descobrir por que essa pequena linguagem continua sendo uma das ferramentas mais úteis do universo IBM Z.

Pegue sua toalha.

Vamos embarcar.


Capítulo 1 — O planeta onde nasceu o REXX

Imagine o universo computacional dos anos 70.

Não existia:

  • GitHub

  • Python

  • PowerShell

  • Bash moderno

  • Docker

  • Kubernetes

  • DevOps

Os administradores realizavam praticamente tudo manualmente.

Era comum repetir comandos centenas de vezes.

Foi então que Mike Cowlishaw, pesquisador da IBM, teve uma ideia aparentemente simples:

"E se existisse uma linguagem extremamente fácil que automatizasse essas tarefas?"

Assim nasceu o REstructured EXtended eXecutor, ou simplesmente REXX.

O objetivo nunca foi competir com COBOL.

Nunca foi substituir PL/I.

Nem Assembler.

Nem C.

REXX nasceu para uma missão diferente:

Evitar que seres humanos façam trabalho repetitivo.

Em outras palavras...

Enquanto COBOL constrói bancos,

REXX ajuda os bancos a continuarem funcionando.


Capítulo 2 — Arthur Dent encontrando um terminal 3270

Imagine Arthur Dent chegando ao CPD.

Ele pergunta:

— Onde fica o botão "Executar"?

O operador responde:

— Aqui usamos JCL.

Arthur pergunta:

— Onde fica o Explorer?

O operador responde:

— Aqui usamos ISPF.

Arthur pergunta:

— Onde está o mouse?

Silêncio absoluto.

Nesse momento surge Ford Prefect.

Ele entrega uma toalha.

Depois um manual.

Depois diz:

"Aprenda REXX."

Arthur pergunta:

— Mas por quê?

Ford sorri.

Porque daqui a pouco você vai precisar executar o mesmo comando 500 vezes.


Capítulo 3 — COBOL constrói cidades. REXX organiza o trânsito.

Essa é provavelmente a melhor analogia.

Imagine uma metrópole.

COBOL constrói:

  • bancos

  • seguradoras

  • folha de pagamento

  • cartões

  • sistemas fiscais

  • aposentadorias

Já REXX faz outra coisa.

Ele liga os semáforos.

Controla o trânsito.

Verifica se alguma avenida foi interditada.

Aciona equipes.

Produz relatórios.

Organiza.

Automatiza.

Ele não constrói o prédio.

Ele faz a cidade funcionar.


Capítulo 4 — O maior mal-entendido dos iniciantes

Muitos iniciantes perguntam:

"Posso aprender só REXX?"

Tecnicamente?

Pode.

Mas seria como estudar apenas a chave inglesa e nunca aprender mecânica.

A ferramenta não substitui o conhecimento.

REXX aumenta sua produtividade.

Mas ele depende do ambiente.

Sem entender:

  • datasets

  • JES2

  • VSAM

  • TSO

  • ISPF

  • JCL

...REXX vira apenas uma coleção de comandos.


Capítulo 5 — A verdadeira hierarquia do conhecimento

A imagem apresentada resume muito bem uma ordem lógica de evolução para quem deseja construir uma carreira sólida no ecossistema IBM Z.

Nível 1 — Aprenda a língua do planeta

Antes de qualquer automação, compreenda como o sistema operacional funciona:

  • z/OS

  • TSO

  • ISPF

  • JES

  • SDSF

  • JCL

  • VSAM

  • Catálogos

  • GDGs

  • Bibliotecas PDS e PDSE

Sem isso, é como tentar pilotar uma nave sem conhecer o painel de instrumentos.


Nível 2 — Aprenda COBOL

Agora você começa a entender como a economia da galáxia funciona.

Os sistemas críticos são escritos principalmente em COBOL porque precisam ser:

  • confiáveis;

  • auditáveis;

  • estáveis;

  • rápidos;

  • duradouros.

Curiosidade: existem programas COBOL em produção com mais de 40 anos que continuam processando milhões de transações diariamente.


Nível 3 — Domine SQL e Db2

Quase nenhum sistema corporativo vive isolado.

Os dados precisam ser consultados, atualizados e protegidos.

Aprender SQL é como aprender a conversar com a memória coletiva da organização.


Nível 4 — Descubra o CICS

Se COBOL é o coração, o CICS é o sistema circulatório.

É ele quem permite milhares de transações online simultâneas.

Cada ENTER pressionado em um terminal 3270 pode representar uma conversa entre o usuário e dezenas de programas COBOL.


Nível 5 — Agora sim, REXX

Somente agora você percebe o verdadeiro potencial.

Porque você já conhece:

  • jobs;

  • datasets;

  • mensagens;

  • bibliotecas;

  • comandos TSO;

  • painéis ISPF.

Então o REXX deixa de ser uma linguagem e se transforma em um multiplicador de produtividade.


Nível 6 — O universo moderno

Aqui entram:

  • Python;

  • Git;

  • DevOps;

  • APIs REST;

  • Jenkins;

  • Zowe;

  • OpenShift;

  • Docker;

  • Ansible;

  • Inteligência Artificial.

O profissional moderno não abandona o legado.

Ele conecta o legado ao futuro.


Capítulo 6 — O poder escondido do REXX

Um bom script pode:

✔ listar milhares de datasets;

✔ procurar membros em centenas de bibliotecas;

✔ enviar comandos ao TSO;

✔ conversar com o ISPF;

✔ acessar o SDSF;

✔ verificar jobs;

✔ gerar relatórios;

✔ automatizar auditorias;

✔ criar menus personalizados;

✔ chamar programas COBOL;

✔ executar utilitários do z/OS.

Tudo isso em poucas linhas.


Capítulo 7 — O Babel Fish do Mainframe

No Guia do Mochileiro existe o famoso Peixe Babel, capaz de traduzir qualquer idioma.

No mainframe, o REXX desempenha um papel parecido.

Ele consegue "conversar" com diferentes componentes do sistema por meio de ambientes (ADDRESS) especializados.

Por exemplo:

  • ADDRESS TSO para emitir comandos do TSO;

  • ADDRESS ISPEXEC para controlar o ISPF;

  • ADDRESS SDSF para consultar jobs e filas;

  • ADDRESS SYSCALL para interagir com o UNIX System Services (USS);

  • ADDRESS COMMAND para comandos do sistema.

Essa capacidade faz do REXX uma espécie de tradutor universal entre o programador e o ecossistema do z/OS.


Capítulo 8 — Os Vogons da Automação

No universo de Douglas Adams, os Vogons são burocratas que adoram formulários intermináveis.

Todo operador de mainframe já enfrentou um equivalente moderno:

  • executar o mesmo comando dezenas de vezes;

  • conferir manualmente centenas de jobs;

  • localizar membros espalhados por várias PDS;

  • comparar listas enormes de datasets.

É aí que entra o REXX.

Em vez de repetir o trabalho manualmente, você escreve um script uma única vez.

Na próxima execução, ele realiza a tarefa em segundos.

O trabalho repetitivo desaparece, e sobra tempo para analisar resultados e resolver problemas reais.


Capítulo 9 — Easter Eggs do universo IBM Z

🥚 Easter Egg 1

A linguagem REXX foi criada para ser lida quase como inglês simples.

Muitos scripts parecem instruções escritas em linguagem natural.


🥚 Easter Egg 2

Grande parte das ferramentas internas desenvolvidas por equipes de infraestrutura em bancos utiliza REXX nos bastidores.

O usuário nem percebe.


🥚 Easter Egg 3

Diversos ambientes corporativos possuem scripts escritos há décadas que continuam funcionando sem alterações significativas.

Essa estabilidade é uma das razões para o respeito conquistado pelo REXX.


🥚 Easter Egg 4

Existem macros ISPF extremamente sofisticadas escritas em REXX que economizam milhares de horas de trabalho ao longo dos anos.


🥚 Easter Egg 5

Ansible, Python e outras ferramentas modernas frequentemente coexistem com REXX.

Em muitos projetos, eles trabalham juntos em vez de competir.


Capítulo 10 — Um roteiro de estudos digno de um mochileiro interestelar

Se eu pudesse entregar um "Guia do Viajante do Mainframe" para um iniciante, ele teria esta sequência:

  1. Aprenda conceitos básicos de computadores e sistemas operacionais.

  2. Entenda a arquitetura do IBM Z.

  3. Estude JCL.

  4. Explore TSO e ISPF.

  5. Aprenda SDSF e JES.

  6. Conheça VSAM e organização de datasets.

  7. Domine COBOL.

  8. Estude SQL e Db2.

  9. Aprenda CICS.

  10. Descubra REXX.

  11. Aprenda Git.

  12. Estude Zowe.

  13. Conheça Python.

  14. Explore APIs REST.

  15. Aprenda Ansible e automação moderna.

  16. Estude CI/CD e DevOps para IBM Z.

  17. Experimente ferramentas de IA aplicadas ao desenvolvimento e à operação.

Cada etapa fortalece a anterior.

Não pule fundamentos.


Capítulo 11 — A toalha do Programador COBOL

No Guia do Mochileiro, a toalha é o objeto mais útil do universo.

No IBM Z, sua "toalha" é composta por três itens:

  • curiosidade para aprender;

  • disciplina para estudar continuamente;

  • humildade para perguntar quando não souber.

Esses três elementos valem mais do que decorar dezenas de comandos.


Conclusão — A resposta para a pergunta inicial

Vale a pena aprender REXX?

A resposta é um sonoro sim.

Mas a pergunta mais importante é outra:

Quando aprender REXX?

A melhor resposta é:

Depois que você compreender os fundamentos do ecossistema IBM Z.

Assim, cada script deixará de ser apenas um conjunto de instruções e passará a representar conhecimento aplicado sobre o funcionamento do sistema.

No universo Bellacosa Mainframe, gosto de imaginar o IBM Z como a nave Coração de Ouro. O COBOL é seu poderoso motor de improbabilidade, responsável por mover os processos que sustentam bancos, seguradoras e governos. O Db2 guarda a memória da viagem, o CICS mantém o contato com bilhões de passageiros, o JCL define os planos de voo e o z/OS governa toda a nave.

E o REXX?

O REXX é Marvin, o androide paranoico — silencioso, aparentemente modesto, mas capaz de resolver em segundos tarefas que consumiriam horas de trabalho humano. Quem aprende a conversar com ele descobre um aliado fiel para automatizar, investigar e manter a galáxia mainframe funcionando.

No fim da jornada, o maior segredo não é escolher entre legado e modernidade. É compreender que o futuro pertence aos profissionais capazes de unir ambos. Aprenda COBOL para entender o coração dos sistemas, domine Db2 e CICS para compreender o fluxo dos negócios, use REXX para automatizar o cotidiano e abrace Python, Git, APIs, DevOps e Inteligência Artificial para construir a próxima geração de soluções.

Como diria o Guia do Mochileiro das Galáxias:

"Não entre em pânico."

No IBM Z, basta levar sua toalha, abrir o ISPF e lembrar que todo grande Mestre Jedi do Mainframe começou exatamente onde você está agora: diante de uma tela 3270 piscando, imaginando qual seria o primeiro comando da aventura. E talvez, escondido em algum membro de uma antiga PDS, exista um pequeno script REXX esperando para mostrar que, às vezes, as ferramentas mais discretas são justamente aquelas que mantêm uma galáxia inteira em funcionamento.

domingo, 30 de agosto de 2020

🌧️ Bellacosa Otaku Blog — Parte 23: Expressões de Tristeza, Perda e Superação nos Animes 🌧️

 

:

🌧️ Bellacosa Otaku Blog — Parte 23: Expressões de Tristeza, Perda e Superação nos Animes 🌧️


💔 O idioma das lágrimas e da superação nos animes

(Versão Bellacosa: suspiros, silêncios pesados e o peso da emoção que toca o coração.)

Nos animes dramáticos, shoujo, slice of life ou seinen, o japonês transmite tristeza, saudade e coragem para seguir em frente.
Cada palavra carrega emoção profunda, tornando momentos de dor e superação memoráveis.
Vamos explorar as expressões mais tocantes! 😢


😭 1. 悲しい (kanashii)

Tradução: “Triste / doloroso.”
👉 Palavra clássica para expressar tristeza ou decepção.

📺 Anime vibe: Clannad, Your Lie in April, Anohana.
💬 Exemplo: “Kanashii… por que isso aconteceu comigo?” 💔


🥺 2. 寂しい (sabishii)

Tradução: “Solitário / sinto sua falta.”
👉 Usada para expressar saudade ou vazio emocional.

📺 Anime vibe: March Comes in Like a Lion, Anohana.
💬 Exemplo: “Sabishii… queria que você estivesse aqui.” 🌧️


😓 3. 悔しい (kuyashii)

Tradução: “Frustrante / irritante (por derrota ou erro).”
👉 Expressa sentimento de arrependimento ou derrota dolorosa.

📺 Anime vibe: Haikyuu!!, Naruto, March Comes in Like a Lion.
💬 Exemplo: “Kuyashii… eu podia ter feito melhor.” ⚡


😔 4. 後悔 (koukai)

Tradução: “Arrependimento / remorso.”
👉 Palavra profunda usada em dramas e momentos de reflexão.

📺 Anime vibe: Clannad, Your Lie in April.
💬 Exemplo: “Koukai… eu deveria ter falado a verdade antes.” 💭


🌫️ 5. 涙 (namida)

Tradução: “Lágrimas.”
👉 Palavra simbólica para momentos emocionantes, tristeza ou alívio.

📺 Anime vibe: Anohana, Your Lie in April, Clannad.
💬 Exemplo: “Namida escorreu sem que eu percebesse…” 😢


💔 6. 失う (ushinau)

Tradução: “Perder / perder alguém ou algo importante.”
👉 Expressa dor de perda ou separação.

📺 Anime vibe: Anohana, Clannad: After Story.
💬 Exemplo: “Ushinau algo tão valioso dói demais.” 💔


🌟 7. 頑張れ (ganbare)

Tradução: “Força! / Continue firme!”
👉 Palavra de incentivo, usada para superar momentos difíceis.

📺 Anime vibe: March Comes in Like a Lion, Haikyuu!!.
💬 Exemplo: “Ganbare… você consegue superar isso.” 💪


🕊️ 8. 前に進もう (mae ni susumou)

Tradução: “Vamos seguir em frente.”
👉 Expressão de superação e motivação após tristeza ou perda.

📺 Anime vibe: Your Lie in April, Clannad.
💬 Exemplo: “Mae ni susumou… apesar de tudo, precisamos continuar.” 🌈


🌧️ 9. 忘れない (wasurenai)

Tradução: “Não vou esquecer / sempre lembrarei.”
👉 Palavra carregada de lembrança, memória e saudade.

📺 Anime vibe: Anohana, Clannad: After Story.
💬 Exemplo: “Wasurenai… você sempre estará no meu coração.” 💌


💫 10. 希望 (kibou)

Tradução: “Esperança.”
👉 Palavra de luz nos momentos de dificuldade, representando força para recomeçar.

📺 Anime vibe: March Comes in Like a Lion, Your Lie in April.
💬 Exemplo: “Kibou… mesmo no sofrimento, ainda há futuro.” 🌟


🏮 Curiosidades Bellacosa:

  • Palavras como kanashii, sabishii e kuyashii transmitem nuances diferentes de tristeza — desde saudade até frustração.

  • Expressões de superação (ganbare, mae ni susumou) equilibram drama com esperança, criando impacto emocional.

  • Termos de memória e lembrança (wasurenai, namida) tornam cenas de despedida ou perda inesquecíveis. 🌧️💖


🌟 Dica Bellacosa:

  • Observe tom de voz, silêncio e expressão facial: o peso emocional está tanto nas pausas quanto nas palavras.

  • Frases curtas podem ser mais impactantes do que monólogos longos — a emoção se sente nas entrelinhas.

  • Memorizar essas expressões ajuda a sentir e compreender os dramas e momentos emocionais dos animes. 😢


🌸 Conclusão Bellacosa:

As expressões de tristeza, perda e superação nos animes transformam o japonês em uma linguagem de emoção crua e esperança.
Cada palavra, lágrima e gesto revela vulnerabilidade e força, permitindo que o espectador viva junto a dor e a superação dos personagens.

“Namida caiu, sabishii ficou… mas ganbare, mae ni susumou, kibou nos guia.” 🌧️💫

sábado, 29 de agosto de 2020

DONA MERCEDES — O CORE SYSTEM DA MINHA VIDA

 


EL JEFE MIDNIGHT LUNCH

DONA MERCEDES — O CORE SYSTEM DA MINHA VIDA

por Bellacosa Mainframe

Há datas que não se apagam.
Algumas viram cicatriz. Outras viram tatuagem na alma.
29 de agosto de 2010 foi as duas coisas: um abend definitivo no coração deste escriba, o desligamento do sistema mais importante que já conheci — minha mãe.

Dona Mercedes não foi apenas minha mãe.
Foi coautora, debugger emocional, analista de suporte vital, e personagem coadjuvante — embora essencial — em cada aventura dessa minha existência meio torta, meio épica, cheia de riso, pancada, poeira, fusquinhas vermelhos, latrinas assassinas e caminhos improváveis.

E em todas essas histórias que o leitor fiel do El Jefe Midnight Lunch já conhece, sempre havia um dedinho de Dona Mercedes ali, escondido entre as linhas, como quem mexe na memória do mainframe e injeta amor sem ninguém perceber.









🌾 ORIGEM: O PRIMEIRO BOOT DO SISTEMA

Dona Mercedes nasceu em Cornélio Procópio, no Paraná, filha de colonos vivendo em um regime duro, daqueles em que o suor era mais constante que o sol.
Família grande, terra pouca, dívida muita.
Vida que começava cedo, sem tutorial, sem manual, sem help desk.

Antes mesmo de entender o mundo, ela já criava irmãos, ajudava no plantio, e trabalhava como babá e empregada doméstica ainda menina.
Estudar?
Não teve essa luxury feature.
A escola dela foi a vida — e foi mestra severa.


🏙 MIGRAÇÃO PARA SÃO PAULO — O PRIMEIRO UPGRADE

Veio para São Paulo com o primário, coragem no bolso e esperança no coração.
Trabalhou a vida inteira.
E ainda arrumou espaço para amar, casar, ter cinco filhos — onde este humilde escriba Bellacosa foi o terceiro processo na fila do batch.

Foram 15 anos de casamento com meu pai, entre brigas, separações, reconciliações e, por fim, o divórcio.
Mas Dona Mercedes era daquelas que faz IPL após desastre:
cai, levanta, recompila, segue.

Quando finalmente veio a separação definitiva — e isso é curioso — a família ganhou estabilidade.
Eu já trabalhava, ajudava em casa, e a vida de penúria foi sendo gradualmente apagada do spool.


🏡 1995 — A CONSTRUÇÃO DO PROJETO MERCEDES

Com sacrifício, suor e fé na marreta, comprei em 1995 o terreno onde futuramente ergueríamos a casinha dela.
A fortaleza.
O castelo possível.

Em 1999, levei para Itatiba a mulher que passou a vida carregando o mundo nas costas.
Ela finalmente teve paz.
Sol.
Rotina.
Família por perto.
E risadas — muitas risadas.

Porque Dona Mercedes sempre foi festeira por natureza.
Se tivesse existido carnaval no interior do Paraná, ela seria porta-bandeira.








✈️ 2005 e 2009 — O SONHO DA MENINA DO PARANÁ

Eu jamais esqueço da cena: minha maezinha — a antiga menina da roça — caminhando pelas ruas de Portugal, olhando castelos, azulejos, igrejas centenárias…
Era como se o mundo dissesse a ela:

“Olha onde você chegou.
Olha o tamanho da sua força.”

Levei-a novamente em 2009, porque memórias boas devem ser replicadas como backup redundante e conhecer o novo membro da famiglia: Luis Renato.


❤️ SAÚDE, LUTA E O ÚLTIMO BATTLE MODE

Mas a vida cobra.
E ela cobrou cedo.

A febre reumática que minha mãe pegou ainda criança, sem remédio, sem recurso, sem hospital, acabou por danificar a válvula aórtica.
Diagnóstico só veio em 1979, quando ela estava grávida do Dandan.

Foram quatro cirurgias.
Quatro batalhas épicas de alguém que já tinha lutado demais.

Na última, o corpo cansou.
E em 29/08/2010, minha maezinha partiu aos 56 anos.

Jovem demais.
Boa demais.
Importante demais.


🧩 A PEÇA QUE UNI A FAMÍLIA

Dona Mercedes não era só mãe.
Era o elo agregador, o middleware emocional, o sistema de mensagem que mantinha todos conectados.
Sabia de tudo.
Contava tudo.
Armazenava cada pequena vitória ou drama dos filhos como se fossem registros preciosos.
Era o nosso CICS familiar: sempre ativa, sempre atendendo requisições, sempre resolvendo tranqueira.


🕊 SAUDADES QUE FICAM

Hoje, quando puxo na memória todas as cidades, poeiras, aventuras, fusquinhas, poços cheios de brinquedos, latrinas assassinas, aranhas, escorpiões, galinhas psicopatas e odisséias interioranas…
Em todas elas, lá estava ela.
Mesmo quando não estava fisicamente — estava na intenção, no conselho, no afeto.

A verdade é simples e brutal:
Eu só fui quem fui porque Dona Mercedes existiu.
E sigo sendo quem sou porque ela ainda existe — aqui, no código-fonte da minha alma.


Conway's Law Rules : Quando um Programador COBOL Descobriu que a Matrix Não Era Apenas um Software… Era o Espelho de Quem a Construiu

 

Bellacosa Mainframe e a conways law rules

☕ Um Café no Bellacosa Mainframe

Conway's Law Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Não Era Apenas um Software… Era o Espelho de Quem a Construiu

"As organizações desenham sistemas que refletem sua própria forma de comunicação."Melvin Conway (1967)


Prólogo — A Matrix Tinha o Mesmo Formato de Zion

Neo caminhava pelos corredores da Cidade das Máquinas.

Esperava encontrar servidores.

Processadores.

Centrais de controle.

Mas encontrou algo muito mais curioso.

Cada setor da Matrix era administrado por um grupo diferente.

O setor dos Agentes nunca conversava diretamente com o setor do Oráculo.

O setor do Merovíngio possuía seus próprios protocolos.

O Chaveiro trabalhava isolado.

Os Sentinelas recebiam ordens por outro canal.

Neo percebeu algo estranho.

Cada módulo da Matrix parecia exatamente igual ao departamento que o desenvolvia.

Morpheus perguntou:

— O que está vendo?

Neo respondeu:

— Não estou olhando apenas para um software...

Estou olhando para o organograma da empresa.

O Oráculo sorriu.

— Finalmente você encontrou a Lei de Conway.


O que é a Lei de Conway?

A Conway's Law afirma:

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

Em português:

"As organizações que desenvolvem sistemas acabam produzindo arquiteturas que refletem sua própria estrutura de comunicação."

Ou seja...

O software não nasce apenas das decisões técnicas.

Ele nasce da forma como as pessoas trabalham juntas.


A origem da Lei de Conway

A lei foi proposta em 1967 por Melvin E. Conway, cientista da computação.

Na época, Conway observou algo curioso.

Empresas organizadas em departamentos independentes acabavam criando softwares igualmente divididos.

Não era coincidência.

Era consequência direta da comunicação humana.

Décadas depois, essa observação continua sendo uma das ideias mais influentes da arquitetura de software.


Matrix explica perfeitamente

Imagine que a Matrix fosse construída por quatro equipes.

Equipe A.

Cuida da autenticação.

Equipe B.

Cuida da economia.

Equipe C.

Cuida dos Agentes.

Equipe D.

Cuida dos Sentinelas.

Se essas equipes quase não conversam...

o software também ficará separado.

Cada módulo desenvolverá sua própria visão da realidade.


O nascimento da Lei

Conway percebeu que a arquitetura técnica segue a arquitetura social.

Se duas equipes possuem dificuldades para conversar...

os sistemas também terão dificuldades para se integrar.


O COBOL conhece isso muito bem

Imagine um grande banco.

Departamento de Cartões.

Equipe própria.

Sistema próprio.


Departamento de PIX.

Equipe diferente.

API diferente.


Departamento de Crédito.

Outro time.

Outro banco de dados.


Departamento de Investimentos.

Outro padrão.

Outro framework.

O resultado?

Integrações complexas.

Duplicação de dados.

Interfaces difíceis.

Não porque os desenvolvedores desejavam isso.

Mas porque a organização já funcionava dessa maneira.


Um exemplo simples

Empresa.

Financeiro

RH

Comercial

Software.

Sistema Financeiro

Sistema RH

Sistema Comercial

Parece natural.

Agora imagine.

Cada departamento possui regras próprias de cadastro.

Logo surgem:

  • três cadastros de clientes;

  • quatro cadastros de funcionários;

  • cinco cadastros de endereços.

O software apenas refletiu a organização.


Matrix Reloaded

Observe os personagens.

O Oráculo não faz o trabalho do Arquiteto.

O Merovíngio não administra Zion.

O Chaveiro não controla os Agentes.

Cada grupo possui funções próprias.

Agora imagine.

Nenhum deles conversa.

A Matrix rapidamente se fragmentaria.


O efeito psicológico

As pessoas tendem a conversar mais com quem está próximo.

Mesmo dentro da mesma empresa.

Logo.

Os sistemas acompanham essa divisão.


O Programador COBOL Padawan

Imagine que você trabalhe no time de CICS.

Nunca conversa com o pessoal de APIs.

Nem conhece a equipe de Open Finance.

Depois de dois anos...

as integrações começam a falhar.

Não por culpa do COBOL.

Mas porque a comunicação humana falhou antes da comunicação entre sistemas.


O Agente Smith adora isso

Smith sabe que basta dividir as pessoas.

O restante acontece sozinho.

Cada equipe cria:

  • padrões próprios;

  • nomenclaturas próprias;

  • APIs próprias;

  • documentação própria.

Pouco tempo depois.

Os sistemas deixam de conversar.


Um exemplo inspirado na Matrix

Neo pergunta.

— Quem controla o cadastro dos humanos?

Resposta.

— Depende.

A equipe dos Agentes possui um.

O Merovíngio outro.

O Oráculo outro.

Zion outro.

Neo pergunta.

— Por que existem quatro?

O Arquiteto responde.

— Porque existiam quatro departamentos.


Como reconhecer?

Existem sinais muito claros.

APIs incompatíveis

Cada área cria seu padrão.


Bancos duplicados

Mesma informação.

Vários lugares.


Nomenclaturas diferentes

CPF.

CPF_NUM.

DOCUMENTO.

CLIENT_ID.

Tudo significa a mesma coisa.


Integrações difíceis

Equipes precisam negociar constantemente.


Regras repetidas

Cada departamento implementa novamente.


O impacto no Mainframe

Grandes ambientes IBM Z frequentemente atendem diversas áreas de negócio.

Se cada área evolui isoladamente.

Logo aparecem:

  • duplicação de COPYBOOKs;

  • layouts diferentes;

  • APIs redundantes;

  • programas semelhantes;

  • tabelas quase idênticas.

Tudo consequência da estrutura organizacional.


Curiosidade

Existe um conceito moderno chamado:

Reverse Conway Maneuver

A ideia é justamente o contrário.

Em vez de deixar a arquitetura seguir a organização...

a empresa reorganiza as equipes para produzir a arquitetura desejada.

Se deseja microsserviços independentes.

Cria equipes independentes.

Se deseja plataforma integrada.

Organiza equipes integradas.


Atenção!

Conway's Law não é uma crítica.

Ela é uma observação.

Toda organização sofre sua influência.

O importante é reconhecê-la.


O custo invisível

Quando departamentos não conversam.

Surgem:

  • retrabalho;

  • integrações caras;

  • conflitos de requisitos;

  • inconsistências.

Tudo isso custa tempo.

Dinheiro.

CPU.

Produtividade.


O papel do Arquiteto

Arquitetos não desenham apenas software.

Eles aproximam equipes.

Porque sabem.

Sem comunicação.

Não existe boa arquitetura.


Matrix e Zion

Imagine Zion dividida.

Cada setor constrói um pedaço da cidade.

Sem conversar.

Resultado.

Canos que não se conectam.

Cabos incompatíveis.

Portas que não levam a lugar nenhum.

Software funciona exatamente assim.


Ferramentas ajudam

Hoje usamos:

  • Enterprise Architecture.

  • Event Storming.

  • Domain Driven Design.

  • IBM ADDI.

  • OpenAPI.

  • AsyncAPI.

  • Catálogos corporativos.

Mas nenhuma ferramenta substitui comunicação humana.


O papel da IA

A IA pode:

  • documentar APIs;

  • comparar contratos;

  • identificar duplicações;

  • sugerir padronizações.

Mas não resolve conflitos organizacionais.


Os riscos

Sistemas duplicados


APIs redundantes


Custos maiores


Integrações frágeis


Visão fragmentada do negócio


Arquitetura inconsistente


Erros clássicos

  • Criar sistemas sem envolver outras áreas.

  • Duplicar cadastros.

  • Não compartilhar padrões.

  • Cada equipe inventar sua arquitetura.

  • Ignorar governança.


Boas práticas

  • Comunicação frequente.

  • Arquitetura corporativa.

  • Catálogo de APIs.

  • Padrões comuns.

  • Revisões interequipes.

  • Compartilhamento de conhecimento.

  • Domínios bem definidos.


Aplicabilidade

A Lei de Conway aparece em:

  • COBOL.

  • Java.

  • Cloud.

  • Microsserviços.

  • ERP.

  • APIs.

  • DevOps.

  • Bancos.

  • Governo.

  • Telecom.

Ela independe da tecnologia.


Um exemplo COBOL

Imagine.

Equipe A.

Cria COPYBOOK:

CLIENTE.

Equipe B.

Cria outro.

CLIENTE-NEW.

Equipe C.

Outro.

CLIENTE-V2.

Nenhum é compatível.

O problema começou muito antes do compilador.


O ensinamento do Oráculo

O Oráculo leva Neo até um enorme espelho.

Cada equipe da Matrix aparece refletida.

Depois o espelho se transforma.

Agora revela o software.

Neo percebe algo impressionante.

As divisões eram exatamente iguais.

Ela pergunta:

— O que mudou?

Neo responde.

— Nada.

O software apenas copiou as pessoas.

Ela sorri.

"É exatamente isso que Conway descobriu."


Lições para um Programador COBOL Padawan

Ao iniciar sua carreira em um ambiente corporativo, você perceberá que muitos desafios técnicos têm origem muito antes do código ser escrito.

Às vezes o problema não está no COBOL, no CICS ou no Db2.

Está no fato de que:

  • as equipes não compartilham conhecimento;

  • cada área cria suas próprias definições;

  • os requisitos chegam incompletos;

  • não existe uma linguagem comum entre negócio e tecnologia.

Por isso, desenvolva não apenas habilidades técnicas.

Aprenda também a:

  • comunicar-se claramente;

  • participar de revisões arquiteturais;

  • documentar decisões;

  • compreender o domínio de negócio;

  • construir pontes entre equipes.

Grandes arquitetos de software são, antes de tudo, excelentes comunicadores.


Curiosidades

A influência da Lei de Conway é tão grande que ela aparece indiretamente em diversos movimentos modernos:

  • Domain-Driven Design (DDD) incentiva equipes alinhadas aos domínios de negócio.

  • Team Topologies propõe estruturas organizacionais que favorecem fluxos de software saudáveis.

  • Microservices funcionam melhor quando as equipes possuem autonomia compatível com os serviços que mantêm.

  • DevOps surgiu justamente para reduzir barreiras entre desenvolvimento e operações.

Todos esses movimentos reconhecem, de alguma forma, a observação feita por Melvin Conway em 1967.


Conclusão — A Matrix Refletia Quem a Construía

No universo Matrix, Neo descobriu que a simulação não era apenas um conjunto de programas.

Ela refletia as decisões, os conflitos e a forma como seus criadores trabalhavam.

Na Engenharia de Software acontece exatamente o mesmo.

A Lei de Conway nos lembra que sistemas não são produzidos apenas por compiladores ou linguagens de programação.

Eles são produzidos por pessoas.

Se as equipes colaboram, o software tende a ser integrado.

Se as equipes vivem isoladas, o software também se fragmenta.

Para um Programador COBOL que atua em ambientes IBM Z, essa é uma lição valiosa. O sucesso de um sistema bancário depende tanto da qualidade do código quanto da qualidade da comunicação entre analistas de negócio, arquitetos, desenvolvedores, DBAs, administradores CICS, especialistas em segurança e operações.

No universo Bellacosa Mainframe existe uma máxima que certamente poderia estar gravada na entrada de Zion:

"Antes de desenhar a arquitetura do software, observe a arquitetura da empresa. Muito provavelmente uma será o reflexo da outra."

Porque, no fim, a Matrix nunca foi apenas feita de linhas de código.

Ela sempre foi feita das pessoas que aprenderam — ou deixaram de aprender — a trabalhar juntas.

sexta-feira, 28 de agosto de 2020

DotCom : Capítulo VIII — Das Cinzas ao Renascimento: Como o Colapso das Dot-Com Preparou o Mundo para a Era Digital

 

Bellacosa Mainframe e o estouro da bolha dotcom capitulo viii

Capítulo VIII — Das Cinzas ao Renascimento: Como o Colapso das Dot-Com Preparou o Mundo para a Era Digital

Por que a maior crise da Internet foi, paradoxalmente, o evento que tornou possível o nascimento de Google, Facebook, YouTube, smartphones, computação em nuvem e Inteligência Artificial

"Uma floresta devastada por um incêndio parece morta. Mas, sob a terra, as sementes finalmente encontram espaço para crescer."

À primeira vista, o estouro da bolha da Internet parece uma história de fracasso.

Empresas quebraram.

Investidores perderam fortunas.

Milhares de profissionais ficaram desempregados.

Projetos desapareceram.

Wall Street entrou em pânico.

Entretanto...

Se observarmos a história com um pouco mais de distância, perceberemos algo surpreendente.

A bolha não destruiu a revolução digital.

Ela a tornou possível.

Pode parecer contraditório.

Mas muitas das empresas que hoje dominam nossa vida cotidiana só conseguiram crescer porque a crise eliminou os excessos da primeira geração da Internet.

Foi como uma gigantesca atualização de software.

Dolorosa.

Cara.

Mas necessária.


A Internet Sobreviveu

Existe um erro muito comum quando se fala sobre o ano 2000.

As pessoas imaginam que a Internet quase desapareceu.

Nada poderia estar mais distante da realidade.

Na verdade...

Enquanto investidores fugiam das ações de tecnologia, engenheiros continuavam trabalhando.

Cabos continuavam sendo instalados.

Servidores continuavam sendo fabricados.

Protocolos continuavam evoluindo.

Universidades continuavam pesquisando.

Empresas continuavam conectando filiais.

A infraestrutura da Internet nunca parou de crescer.

Quem entrou em crise foi o mercado financeiro.

Não a tecnologia.

Essa distinção é extremamente importante.


A Infraestrutura Ficou Pronta

Durante a euforia das Dot-Com foram investidos bilhões de dólares em infraestrutura.

Data centers.

Cabos submarinos.

Centrais telefônicas.

Equipamentos ópticos.

Backbones internacionais.

Links de alta velocidade.

Na época, muitos analistas afirmavam que havia capacidade demais.

Parecia desperdício.

Mas alguns anos depois...

Essa mesma infraestrutura permitiu uma explosão de crescimento.

É uma ironia fascinante.

Boa parte da Internet moderna utiliza uma base construída justamente durante a bolha.

O investimento parecia exagerado.

O tempo mostrou que ele apenas havia chegado cedo demais.


A Banda Larga Mudou Tudo

No início dos anos 2000 começou outra transformação silenciosa.

A Internet discada começou a ser substituída por conexões de banda larga.

Pela primeira vez, os computadores permaneciam conectados o tempo todo.

Adeus ao barulho do modem.

Adeus à linha telefônica ocupada.

Adeus à espera para estabelecer conexão.

Essa mudança alterou completamente a maneira como as pessoas utilizavam a Internet.

Ela deixou de ser uma atividade ocasional.

Passou a fazer parte da rotina diária.

Foi uma mudança de comportamento.

E mudanças de comportamento costumam gerar novas oportunidades de negócios.


A Web Aprendeu a Conversar

Durante a primeira geração da Internet, a maioria dos sites era estática.

Empresas publicavam informações.

Usuários apenas liam.

Pouco depois da crise começou a surgir um conceito completamente diferente.

A Web participativa.

As pessoas deixaram de ser apenas consumidoras.

Passaram a produzir conteúdo.

Escrever.

Fotografar.

Comentar.

Compartilhar.

Avaliar.

Nascia aquilo que mais tarde seria conhecido como Web 2.0.

A Internet deixava de ser uma biblioteca.

Transformava-se numa gigantesca praça pública.


Google Encontrou Seu Momento

Quando a poeira da crise começou a baixar, o Google estava preparado.

Sua infraestrutura crescia.

Seu algoritmo melhorava.

Seu modelo de publicidade tornava-se extremamente eficiente.

Enquanto centenas de concorrentes desapareciam, o Google concentrava cada vez mais usuários.

O curioso é que sua maior vantagem não era apenas tecnológica.

Era econômica.

Cada pesquisa gerava informações valiosas.

Cada anúncio era mais relevante.

Cada clique aperfeiçoava o sistema.

Criava-se um ciclo virtuoso.

Quanto mais pessoas utilizavam o Google...

Melhor ele ficava.


Amazon Deixou de Ser Apenas uma Livraria

Outro sobrevivente aproveitou o período para se reinventar.

A Amazon começou vendendo livros.

Mas Jeff Bezos nunca desejou construir apenas uma livraria online.

Seu objetivo era criar "a loja de tudo".

Após sobreviver à bolha, a empresa acelerou sua expansão.

Vieram:

eletrônicos.

roupas.

brinquedos.

computadores.

móveis.

alimentos.

E, posteriormente...

Serviços em nuvem.

Poucos imaginavam que uma empresa criada para vender livros se tornaria uma das maiores fornecedoras mundiais de infraestrutura para Inteligência Artificial.

Mas foi exatamente isso que aconteceu.


O Nascimento da Computação em Nuvem

Existe uma conexão direta entre a bolha da Internet e a computação em nuvem.

Durante a crise, muitas empresas perceberam que manter enormes infraestruturas próprias era caro.

Ao mesmo tempo, gigantes como Amazon possuíam data centers subutilizados.

A solução parecia natural.

Alugar capacidade computacional.

Em vez de comprar servidores...

Empresas passariam a contratar processamento sob demanda.

Hoje chamamos isso de Cloud Computing.

Na época era uma ideia revolucionária.

Mais uma vez...

A crise incentivou eficiência.


O Mundo Tornou-se Mobile

Enquanto a Internet amadurecia, outra revolução aproximava-se silenciosamente.

Os telefones celulares.

No início serviam apenas para chamadas.

Depois enviavam mensagens.

Pouco depois começaram a acessar páginas simples.

Então surgiu um dispositivo que mudaria tudo.

O smartphone.

Quando o iPhone foi lançado em 2007, encontrou uma Internet completamente diferente daquela de 1999.

Mais rápida.

Mais estável.

Mais madura.

A infraestrutura construída durante a bolha finalmente encontrou um ambiente capaz de utilizá-la plenamente.


Redes Sociais: A Segunda Onda

Pouco depois vieram:

Facebook.

YouTube.

LinkedIn.

Twitter.

Wikipedia.

Flickr.

Essas empresas nasceram em um mundo muito diferente daquele enfrentado pelas primeiras Dot-Com.

Agora existia:

banda larga.

computadores mais rápidos.

servidores mais baratos.

infraestrutura consolidada.

consumidores acostumados à Internet.

meios de pagamento mais seguros.

A primeira geração havia preparado o terreno.

A segunda pôde finalmente construir sobre ele.


Enquanto Isso... Os Mainframes Evoluíam Silenciosamente

Existe um aspecto pouco comentado dessa história.

Enquanto todos observavam o crescimento da Web, o universo corporativo também evoluía.

Mainframes passaram a oferecer:

Linux.

Java.

Serviços Web.

XML.

SOA.

Virtualização avançada.

Mais tarde vieram:

OpenShift.

Containers.

APIs REST.

Kubernetes.

Watsonx.

Aceleradores para Inteligência Artificial.

Ou seja...

O mainframe não ficou parado esperando o futuro.

Ele evoluiu junto com ele.

Talvez de maneira menos chamativa.

Mas extremamente consistente.


A Internet Aprendeu a Ganhar Dinheiro

Outra consequência importante da crise foi o amadurecimento dos modelos de negócios.

As empresas passaram a compreender melhor como gerar receita.

Publicidade segmentada.

Assinaturas.

Software como Serviço.

Marketplace.

Serviços financeiros.

Computação em nuvem.

Economia de plataforma.

Esses modelos praticamente definem a economia digital atual.

Curiosamente...

Quase todos foram refinados após o colapso das Dot-Com.


O Investidor Também Mudou

Os investidores aprenderam muito.

Antes financiavam praticamente qualquer startup.

Depois passaram a analisar:

modelo de negócios.

custos.

retenção de clientes.

receita recorrente.

fluxo de caixa.

capacidade de execução.

Não significa que novas bolhas nunca mais ocorreram.

Mas a qualidade das análises tornou-se muito maior.

Pelo menos durante algum tempo.


A Computação Entrou na Vida de Todos

Talvez a consequência mais profunda da crise tenha sido cultural.

Nos anos 1980, computadores eram ferramentas de especialistas.

Nos anos 1990, tornaram-se objetos domésticos.

Nos anos 2000, passaram a conectar pessoas.

Na década seguinte tornaram-se companheiros permanentes através dos smartphones.

Hoje...

A Inteligência Artificial amplia novamente essa transformação.

Tudo isso faz parte da mesma jornada iniciada muito antes da bolha.


O Paralelo com a Inteligência Artificial

Estamos vivendo algo parecido.

Existe enorme entusiasmo.

Investimentos bilionários.

Milhares de startups.

Novos modelos surgindo praticamente todos os meses.

Provavelmente veremos empresas desaparecerem.

Outras serão adquiridas.

Algumas mudarão completamente de estratégia.

Entretanto...

Mesmo que isso aconteça, a Inteligência Artificial continuará evoluindo.

Assim como aconteceu com a Internet.

A tecnologia não depende do destino individual de cada empresa.

Ela continua seu caminho.


A Grande Ironia da História

Se a bolha da Internet nunca tivesse existido...

Talvez a revolução digital fosse muito mais lenta.

Parece estranho afirmar isso.

Mas pense.

A euforia atraiu investimentos gigantescos.

Esses investimentos construíram infraestrutura.

Essa infraestrutura permaneceu.

Anos depois, novas empresas utilizaram exatamente essa base para criar produtos muito mais maduros.

Em outras palavras.

O dinheiro especulativo desapareceu.

Os cabos ficaram.

Os data centers ficaram.

Os engenheiros ficaram.

O conhecimento ficou.

As lições ficaram.

E foi exatamente isso que possibilitou o nascimento da Internet moderna.


Lições para o Padawan COBOL

Um programa COBOL raramente nasce perfeito.

Ao longo dos anos ele recebe correções.

Melhorias.

Novos módulos.

Integrações.

Refatorações.

Depois de décadas, muitas vezes continua executando sua função original, mas tornou-se muito mais robusto.

A Internet passou pelo mesmo processo.

A bolha das Dot-Com foi um enorme "debug" coletivo.

Ela eliminou erros de arquitetura empresarial, expôs modelos insustentáveis e obrigou toda a indústria a amadurecer.

No universo da Frota Estelar existe uma máxima entre os engenheiros da USS Enterprise:

"Nenhuma nave chega à classe Galaxy sem antes aprender com os erros das classes anteriores."

A Internet também.

A primeira geração abriu o caminho.

A segunda consolidou a economia digital.

A terceira trouxe computação em nuvem e smartphones.

A quarta nos conduz agora à era da Inteligência Artificial.

Cada geração parece completamente nova.

Na realidade...

Todas são capítulos da mesma história.

E é justamente essa continuidade que um bom engenheiro — seja de software, seja de sistemas mainframe — aprende a enxergar.

No próximo capítulo veremos como a bolha das Dot-Com mudou definitivamente a forma como investidores, empresas e governos passaram a avaliar tecnologia, inaugurando uma nova era de governança, gestão de riscos e inovação sustentável.

quinta-feira, 27 de agosto de 2020

Laboratório Prático — Primeiros Passos no TSO/ISPF

 

Bellacosa Mainframe laboratorio pratico TSO/IPSF

☕ Um Café no Bellacosa Mainframe

Laboratório Prático — Primeiros Passos no TSO/ISPF

Criando Data Sets no z/OS (PDS, PDSE e Sequential)

Este laboratório foi pensado para quem nunca utilizou o TSO/ISPF. O objetivo é ensinar a criar os tipos de datasets mais comuns utilizados por um desenvolvedor COBOL.

Ao final você saberá criar:

  • ✔ PDS FB 80

  • ✔ PDSE FB 80

  • ✔ PDS Undefined (U)

  • ✔ PDSE Undefined (U)

  • ✔ Sequential (QSAM) FB 200

  • ✔ Sequential (QSAM) VB 4000


Objetivos

Durante este laboratório você aprenderá

  • navegar pelo ISPF

  • utilizar o painel Allocate Dataset

  • entender RECFM

  • entender LRECL

  • entender BLKSIZE

  • compreender Directory Blocks

  • diferenciar PDS e PDSE


Pré-requisitos

Possuir acesso ao

  • TSO

  • ISPF

  • opção 3.2 (Data Set Utility)


Conceitos antes de começar

Dataset Sequential (PS)

Armazena um único fluxo de dados.

Exemplos

  • arquivos de entrada

  • arquivos de saída

  • arquivos temporários

Representação

USERID.CLIENTES

Dataset Particionado (PDS)

Funciona como uma pasta.

Dentro dele existem vários membros.

USERID.COBOL

   PROG001
   PROG002
   COPYCLI
   COPYEND

Dataset Particionado Estendido (PDSE)

É uma evolução do PDS.

Possui

  • melhor performance

  • reutilização automática do espaço

  • elimina compressão

  • maior confiabilidade

Hoje praticamente todos os ambientes novos utilizam PDSE.


O que significa RECFM?

RECFMSignificado
FBFixed Block
VBVariable Block
UUndefined

O que significa LRECL?

É o tamanho máximo lógico de cada registro.

Exemplo

FB 80

Registro 1 -> 80 bytes
Registro 2 -> 80 bytes
Registro 3 -> 80 bytes

VB 4000

Registro 1 -> 250 bytes

Registro 2 -> 1200 bytes

Registro 3 -> 3998 bytes

Laboratório 1

Criando um PDS FB 80

Entre no ISPF

===> 3

Depois

===> 2

Aparecerá

Data Set Utility

Informe

A

de Allocate

Digite o nome

USERID.COBOL

Pressione ENTER


Preencha

Data Set Name . . USERID.COBOL

Management class . . .
Storage class . . . .
Volume serial . . . .

Device Type . . . . . 3390

Space Units . . . . . TRACK

Primary Quantity . . . 5

Secondary Quantity . . 2

Directory Blocks . . . 10

Record Format . . . . FB

Record Length . . . . 80

Block Size . . . . . . 0

Data Set Organization PO

Pressione ENTER.

Dataset criado.


Conferindo

Na opção

3.4

Digite

USERID.COBOL

Deverá aparecer

PO
FB
80

Laboratório 2

Criando um PDSE FB 80

Repita o procedimento.

Nome

USERID.COBOL.PDSE

Preencha igual ao anterior.

A única diferença:

Data Set Organization

PO-E

ou

LIBRARY YES

(depende da versão do ISPF)

Resultado

PDSE
FB
80

Laboratório 3

Criando um PDS Undefined

Nome

USERID.LOADLIB

Parâmetros

Primary 5

Secondary 2

Directory 20

RECFM U

LRECL 0

BLKSIZE 32760

DSORG PO

Esse dataset normalmente armazenará

  • Load Modules

  • Program Objects (em alguns ambientes usa-se PDSE)


Laboratório 4

Criando um PDSE Undefined

Nome

USERID.LOADLIB.PDSE

Parâmetros

Primary 5

Secondary 2

Directory 20

RECFM U

LRECL 0

BLKSIZE 32760

PO-E

Este é o formato utilizado na maioria das LOADLIB modernas.


Laboratório 5

Criando um Sequential FB 200

Nome

USERID.CLIENTES

Parâmetros

Primary 5

Secondary 2

Directory 0

RECFM FB

LRECL 200

BLKSIZE 0

DSORG PS

Resultado

PS
FB
200

Muito utilizado para

  • arquivos batch

  • exportações

  • importações

  • QSAM


Laboratório 6

Criando um Sequential VB 4000

Nome

USERID.CLIENTES.VB

Parâmetros

Primary 10

Secondary 5

Directory 0

RECFM VB

LRECL 4000

BLKSIZE 0

DSORG PS

Observe

No VB o sistema adiciona automaticamente um RDW (Record Descriptor Word) de 4 bytes ao armazenamento físico de cada registro. Assim, embora o LRECL seja 4000, o tamanho físico máximo do registro é 4004 bytes.


Como verificar se tudo foi criado

Acesse

3.4

Digite

USERID.*

Você deverá visualizar algo semelhante a:

DatasetOrganizaçãoRECFMLRECL
USERID.COBOLPOFB80
USERID.COBOL.PDSEPO-EFB80
USERID.LOADLIBPOU0
USERID.LOADLIB.PDSEPO-EU0
USERID.CLIENTESPSFB200
USERID.CLIENTES.VBPSVB4000

Exercício Extra 1

Crie um membro chamado

HELLO

dentro do PDS.

Digite

ISPF 3.4

E USERID.COBOL(HELLO)

Escreva

OLÁ MAINFRAME

Salve usando

PF3

Exercício Extra 2

Crie um membro

COPYCLI

no PDSE.

Digite

IDENTIFICACAO DO CLIENTE

Salve.


Exercício Extra 3

Edite o arquivo sequencial

USERID.CLIENTES

Inclua algumas linhas com exatamente 200 caracteres (o editor exibirá uma régua para ajudar) e observe o comportamento do editor ao ultrapassar o LRECL.


Exercício Extra 4

Edite

USERID.CLIENTES.VB

Insira linhas de comprimentos variados:

  • 30 bytes

  • 120 bytes

  • 850 bytes

  • 2500 bytes

  • 3990 bytes

Perceba que, em um arquivo VB, cada registro pode ter um tamanho diferente, desde que não ultrapasse o LRECL definido.


Desafio Bellacosa Mainframe ⭐⭐⭐

Sem consultar este material, crie os seguintes datasets:

NomeTipoRECFMLRECL
USERID.JCLPDSFB80
USERID.CNTLPDSEFB80
USERID.COBOLPDSEFB80
USERID.COPYLIBPDSEFB80
USERID.DCLGENPDSFB80
USERID.LOADLIBPDSEU0
USERID.INPUTPSFB200
USERID.OUTPUTPSFB200
USERID.RELATORIOPSVB4000
USERID.LOGPSVB4000

Ao concluir, você terá criado a estrutura básica utilizada em grande parte dos projetos COBOL no IBM z/OS, compreendendo não apenas como criar cada dataset, mas também por que cada formato é escolhido em ambientes de produção. Esse conhecimento servirá de base para os próximos laboratórios, nos quais esses datasets serão utilizados em programas COBOL, JCL, utilitários e processamento QSAM.

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