✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

sexta-feira, 28 de fevereiro de 2020

☕🔥 “A ARQUITETURA QUE SEGURA O MUNDO” — OS 12 CONCEITOS QUE TODO PROFISSIONAL MAINFRAME USA… MESMO SEM PERCEBER

Bellacosa Mainframe e 12 conceitos importante para a arquitetura mainframe

☕🔥 “A ARQUITETURA QUE SEGURA O MUNDO” — OS 12 CONCEITOS QUE TODO PROFISSIONAL MAINFRAME USA… MESMO SEM PERCEBER

Quando alguém fala de:

microservices,
cloud-native,
autoscaling,
API Gateway,
event-driven,
sharding,
caching,

muita gente imagina:

“Kubernetes inventou isso.”

Mas aqui vem a verdade que pouca gente gosta de admitir:

☕ O MAINFRAME JÁ RESOLVIA MUITOS DESSES PROBLEMAS HÁ DÉCADAS.

Só que com outros nomes.

E frequentemente:

mais estabilidade,
mais previsibilidade,
mais segurança,
e MUITO menos caos operacional.

A imagem mostra 12 conceitos modernos de arquitetura.

Agora vamos traduzir isso para:

☕ IBM Z / zOS / COBOL / CICS / DB2 / MQ / Sysplex no estilo Bellacosa Mainframe.

☕ 1. LOAD BALANCING — “DIVIDIR A PRESSÃO ANTES DO COLAPSO”

No mundo distribuído:

Load Balancer distribui tráfego entre servidores.

No Mainframe:

WLM + Sysplex fazem isso há MUITO tempo.

🔥 Exemplo real

Você possui:

4 regiões CICS,
milhares de TPS,
milhões de usuários.

O Workload Manager:

distribui carga,
evita gargalo,
prioriza serviços críticos.

☕ O detalhe brutal

Na cloud:

Load Balancer frequentemente é “reativo”.

No z/OS:

WLM é orientado por política de negócio.

O sistema entende:

prioridade,
SLA,
criticidade,
classe de serviço.

Isso é absurdamente sofisticado.

☕ 2. CACHING — “NÃO BUSQUE DUAS VEZES O QUE JÁ ESTÁ NA MEMÓRIA”

🔥 Mainframe vive de cache

O IBM Z inteiro é obcecado por minimizar I/O.

Porque:

DISCO É CARO EM TEMPO

☕ Exemplos reais

DB2 Buffer Pool

Páginas ficam em memória.

VSAM Buffering

Evita leitura física excessiva.

CICS TSQ/Temporary Storage

Dados temporários rápidos.

Hiperspace / Dataspaces

Memória expandida ultra rápida.

🔥 O mantra do performance analyst

“Se foi ao disco demais…
já perdeu.”

☕ 3. CDN — CONTENT DELIVERY NETWORK

À primeira vista parece “coisa web”.

Mas no mainframe existe conceito parecido.

☕ No IBM Z isso aparece como:

replicação geográfica,
GDPS,
Sysplex Distributor,
caching distribuído,
data locality.

🔥 Exemplo bancário

Uma consulta:

não precisa cruzar o país inteiro,
pode ser atendida por nó mais próximo,
reduzindo latência.

☕ Filosofia importante

O Mainframe sempre entendeu:

mover dado custa caro.

☕ 4. MESSAGE QUEUE — “O SEGREDO DA DESCOPLAGEM”

Aqui entramos numa das áreas mais poderosas do IBM Z.

🔥 IBM MQ é praticamente o sistema nervoso corporativo

Ele desacopla aplicações.

☕ Exemplo clássico

Sistema A:

gera pagamento

Sistema B:

processa fraude

Sistema C:

envia PIX

Tudo via fila.

☕ O benefício monstruoso

Se um sistema cai:

mensagem continua na fila,
processamento continua depois,
nada se perde.

🔥 O mainframe odeia perda de transação

Esse é um ponto cultural importante.

☕ 5. PUBLISH/SUBSCRIBE — EVENT DRIVEN ANTES DA MODA

🔥 O mundo moderno chama:

event-driven architecture

O mainframe chama há décadas de:

MQ Pub/Sub,
eventos CICS,
triggers,
integração assíncrona.

☕ Exemplo real

Quando uma compra é aprovada:

antifraude recebe evento,
CRM recebe evento,
analytics recebe evento,
billing recebe evento.

Tudo desacoplado.

☕ 6. API GATEWAY — “A PORTA DE ENTRADA DO LEGADO”

Muita gente pensa:

“COBOL não fala REST.”

Erro clássico.

🔥 Hoje o Mainframe expõe:

REST APIs,
JSON,
SOAP,
GraphQL integration,
OpenAPI.

☕ Ferramentas

z/OS Connect
CICS Web Services
API Connect
MQ REST bridge

☕ O segredo

O COBOL continua fazendo:

regra de negócio,
consistência,
transação ACID.

A API só traduz o mundo externo.

☕ 7. CIRCUIT BREAKER — “EVITAR EFEITO CASCATA”

🔥 O Mainframe sempre teve paranoia com disponibilidade

Porque downtime custa milhões.

☕ Exemplo prático

Se DB2 degrada:

CICS pode limitar requests,
workload é redirecionado,
regiões são isoladas.

☕ Resultado

O problema não destrói o ecossistema inteiro.

🔥 Filosofia do z/OS

“Falha controlada é melhor que colapso generalizado.”

☕ 8. SERVICE DISCOVERY — “ENCONTRAR O SERVIÇO CERTO”

No cloud:

Kubernetes,
Consul,
Eureka.

No mainframe:

VTAM,
TCP/IP stacks,
CICSPlex SM,
Sysplex Distributor.

☕ O sistema descobre:

onde está a região disponível,
qual nó está saudável,
quem responde mais rápido.

☕ 9. SHARDING — “DIVIDIR O GIGANTE”

🔥 Mainframe já fazia particionamento gigantesco

Muito antes do hype NoSQL.

☕ Exemplos

DB2 Partitioning

Tabela gigantesca dividida.

VSAM split

Segmentação de dados.

GDG distribution

Separação temporal.

☕ Objetivo

reduzir contenção,
aumentar paralelismo,
melhorar throughput.

☕ 10. RATE LIMITING — “CONTROLAR O CAOS”

🔥 Mainframe é obcecado por governança

Você NÃO deixa qualquer workload destruir o ambiente.

☕ Exemplos reais

WLM

Controla prioridade.

CICS MAXTASK

Limita tasks simultâneas.

DB2 Thread Limits

Evita explosão de conexão.

MQ Queue Depth

Controla saturação.

☕ Resultado

O sistema continua respirando sob pressão.

☕ 11. CONSISTENT HASHING — “DISTRIBUIÇÃO INTELIGENTE”

🔥 Aqui aparece no:

Parallel Sysplex,
DB2 data sharing,
cache distribution,
workload routing.

☕ Objetivo

Distribuir carga:

sem destruir consistência,
sem mover tudo,
sem gerar caos.

☕ 12. AUTO SCALING — “O MAINFRAME ESCALA DIFERENTE”

Na cloud:

sobe VM

No Mainframe:

ativa engines,
redistribui workload,
muda prioridade,
usa Capacity on Demand,
explora Sysplex.

🔥 O detalhe mais impressionante

O IBM Z consegue crescer:

SEM PARAR O BANCO

Isso é engenharia absurda.

☕ O QUE O MAINFRAME ENSINA SOBRE ARQUITETURA

A cloud moderna popularizou vários conceitos.

Mas o IBM Z já conhecia muitos deles:

em escala gigantesca,
com confiabilidade extrema,
em ambientes mission critical.

🔥 O erro de muita gente

Pensar que:

Mainframe = tecnologia antiga

quando na prática:

Mainframe = engenharia corporativa refinada por décadas de guerra operacional.

☕ RESUMO BELLACOSA MAINFRAME

Conceito	No IBM Mainframe
Load Balancing	WLM + Sysplex
Caching	Buffer Pools + VSAM Buffers
CDN	Distribuição geográfica/Sysplex
Message Queue	IBM MQ
Publish/Subscribe	Event-driven corporativo
API Gateway	z/OS Connect + CICS
Circuit Breaker	Isolamento operacional
Service Discovery	CICSPlex + Sysplex
Sharding	DB2 partitioning
Rate Limiting	WLM + MAXTASK
Consistent Hashing	Distribuição de workload
Auto Scaling	Capacity on Demand

☕🔥 Frase final no estilo Bellacosa Mainframe

“A cloud reinventou vários conceitos.
O Mainframe apenas ficou quieto…
porque já fazia isso desde o século passado.”

quinta-feira, 27 de fevereiro de 2020

📌 O que é JCL (visão geral)

JCL — Job Control Language — é a linguagem de controle de jobs que instrui o sistema operacional IBM Mainframe sobre quais programas executar, com quais dados e recursos, em que sequência e como tratar saídas/erros. Wikipedia
Foi projetado para batch processing, declarando tudo explicitamente para evitar conflitos de recursos e permitir alocação antecipada de dispositivos/datasets. codedocs.org

🕰️ Linha do tempo da evolução do JCL

1) OS/360 – Introdução (1964–1966)

Data: meados da década de 1960 — cerca de 1964–1966. Grokipedia+1
Plataformas: OS/360 e DOS/360.
O que mudou:
- JCL original lançada com o OS/360 (e paralelo no DOS/360) para controlar jobs batch nos recém-lançados System/360.
- Sintaxe inicial baseada em cartões perfurados (JOB, EXEC, DD).
- Estabelece a base do modelo que persiste até hoje.
Observação: essa é a primeira e principal “release” histórica — não existiam versões numeradas de JCL separadas do sistema operacional; era evoluído conforme OS/360 evoluía. Grokipedia

📌 Curiosidade: Fred Brooks — um dos líderes do projeto OS/360 — brincou que JCL foi “a pior linguagem já criada” devido à sua complexidade e rigidez, mas ela persistiu porque funcionava dentro das restrições daquele hardware/era. Wikipedia

2) MVS (Multiple Virtual Storage) — Evolução do JCL (1974+)

Data: 1974 e anos subsequentes. Wikipedia
Plataformas: OS/VS2 avançou para MVS — a base para os sistemas 370 e além.
O que mudou:
- Introdução de virtual storage, multiprogramação e melhores capacidades de gestão de jobs.
- JCL foi mantido compatível com versões anteriores, mas ganhou novas opções para dataset allocation, múltiplos steps, procedures etc.
Notas:
- Nas versões MVS, o JCL permaneceu essencialmente o mesmo por compatibilidade, mas parâmetros novos foram adicionados conforme o sistema operacional expandiu funções (virtual storage, JES etc.). mainframemaster.com

3) OS/390 – Consolidando MVS (1995)

Data: 1995. Wikipedia
Plataforma: OS/390 (a evolução do MVS com pacotes completos — DFSMShsm, JES2/JES3 etc.).
O que mudou:
- JCL não teve uma revisão revolucionária aqui; mas foi formalizado junto ao pacote OS/390.
- Houve refinamentos de parâmetros e melhor suporte de integração entre subsistemas (JES, utilities, catalogação).
Importante: ainda não havia “JCL 2.0/3.0” no sentido de uma linguagem separada — as mudanças são ligadas à evolução dos operating systems.

4) z/OS – Era moderna (2000 até agora)

Data: 2000 (lançamento inicial do z/OS) até as releases atuais como z/OS 3.1, 3.2… (2020s). Grokipedia
Plataforma: z/OS (principal OS de mainframe IBM) com JES2/JES3.
O que mudou no JCL:
- Backward compatibility total com JCL legado (jobs escritos décadas atrás ainda rodam em z/OS). Wikipedia
- Novos parâmetros e recursos, como:
  - Manipulação de datasets inline e melhores constructs (ex: IF/THEN/ELSE no próprio JCL). Reddit
  - Suporte para novos dispositivos e sistemas de arquivos (Unix System Services).
  - Suporte a SYSIN/SYSOUT mais flexível e melhor integração com subsistemas modernos.
- Integração com ferramentas de desenvolvimento modernas (IDE, JCL linters, LSP, integração com Git via Zowe etc.). ibm.github.io

📋 Como contar “releases” do JCL?

Diferente de linguagens como C ou Java, JCL não tem uma lista de versões como “JCL 1.0, 2.0, 3.0” — sua evolução está intrinsecamente ligada às versões dos sistemas operacionais IBM para mainframes:

Ano / Período	Plataforma/Release	Principais mudanças no JCL
~1964–67	OS/360 / DOS/360	Introdução da JCL, JOB/EXEC/DD básicos, batch streams. Grokipedia
Anos 1970	MVS (OS/VS2 → MVS)	Virtual storage, procedures catalogadas, expansão de parâmetros. Wikipedia
1995	OS/390	Consolidação do pacote, recuperação de recursos e JES. Wikipedia
2000+	z/OS (3.x, 4.x…)	Back-compatibility, novo hardware, sistemas de arquivos modernos, integração com DevOps. ibm.github.io

📌 O que geralmente muda em JCL

Em termos gerais, as mudanças no JCL tendem a ser:

✔ Novos parâmetros de DD/EXEC/JOB conforme o OS adiciona recursos. mainframemaster.com
✔ Suporte a novas estruturas de dados ou subsistemas (ex: Unix System Services, datasets VSAM). IBM
✔ Aprimoramentos de controle condicional e procedimentos. Reddit
✔ Integração com ferramentas modernas (editores, validação, IDE). ibm.github.io

📌 Resumo (Estilo “Bellacosa Mainframe”)

1964–1966 – OS/360 & DOS/360: JCL nasce e define modelo. Grokipedia
1974+ – MVS: JCL cresce com virtual storage e multiprogramação. Wikipedia
1995 – OS/390: Pacote consolidado, refinamentos. Wikipedia
2000+ – z/OS (3.x, 4.x…): Evolução contínua, backward compatibility e suporte a tecnologias modernas.

quarta-feira, 26 de fevereiro de 2020

Paisagens de Van Gogh

Paisagens de Van Gogh: Paisagens de Van Gogh

Visita a Exposição “Paisagens de Van Gogh” no Shopping Iguatemi de Campinas Estamos comemorando os 40 anos do Shopping mais famoso de Campinas, e nesta festividade tivemos a oportunidade de visitar uma exposição do pintor holandês Vincent Van Gogh. Composto por 8 salas temáticas embaixo da famosa cúpula do shopping, passamos por replicas multimídias dos quadros mais vontades. Eu me diverti muito, tinha uma sala com óculos 3d e um mergulho dentro do quadro, em outra sala a pintura era projetada em tela em slide show, em outras havia recriação do ambiente com espigas de trigo, sons de ventos e corvos e muito mais. Veja no vídeo e se divirta, aproveite enquanto é tempo, visite o shopping Iguatemi e veja com os próprios olhos, meu conselho vá durante a semana, pois a fila e longa. #campinas #shoppingiguatemi #vangogh #exposição #paisagens #quadro #impressionista #espelhos #corvos #trigo #amendoeira #flores #selfie #3d #maquina #oculos #realidade #virtual #slideshow

terça-feira, 25 de fevereiro de 2020

☕💥 Os 10 Padrões Secretos de Arrays em COBOL Mainframe

Bellacosa Mainframe e 10 padroes secretos de arrays

☕💥 Os 10 Padrões Secretos de Arrays em COBOL Mainframe

Ou como descobrir que você já usava algoritmos de entrevistas do LeetCode muito antes deles virarem moda

Introdução

Existe uma curiosidade engraçada no mundo da programação.

Um desenvolvedor Java estuda LeetCode.

Um desenvolvedor Python assiste vídeos sobre algoritmos.

Um engenheiro C++ compra livros de Competitive Programming.

Enquanto isso...

Um programador COBOL de banco com vinte anos de experiência está processando 300 milhões de registros no Batch Noturno utilizando exatamente os mesmos algoritmos...

Mas chama tudo de:

"andar na tabela"

"fazer acumulado"

"pesquisa binária"

"comparar dois índices"

"janela de análise"

E provavelmente faz isso tomando café às 3 da manhã olhando um SDSF.

A verdade é que muitos dos algoritmos mais famosos ensinados atualmente em universidades e plataformas de entrevistas já existem no universo COBOL há décadas.

OCCURS.

INDEXED BY.

SEARCH.

SEARCH ALL.

SET UP.

SET DOWN.

ASCENDING KEY.

Tabelas auxiliares.

Acumuladores.

Áreas de trabalho.

Tudo isso forma um verdadeiro arsenal de algoritmos.

E hoje vamos conhecer os 10 padrões clássicos de Arrays, explicados para um Padawan COBOL.

Padrão 1 — Two Pointers

Os Dois Jedi da Tabela

É provavelmente o algoritmo mais antigo do mundo corporativo.

A ideia é simples.

Utilizamos dois ponteiros.

Um na esquerda.

Outro na direita.

Ou ambos andando em velocidades diferentes.

Exemplo

Verificar se uma tabela é simétrica.

01 TAB.

   05 ITEM OCCURS 100 TIMES
      INDEXED BY IDX1 IDX2.

77 MAX PIC 999 VALUE 100.



SET IDX1 TO 1
SET IDX2 TO MAX



PERFORM UNTIL IDX1 >= IDX2


   IF ITEM(IDX1) NOT = ITEM(IDX2)

      DISPLAY 'NAO SIMETRICO'

   END-IF


   SET IDX1 UP BY 1
   SET IDX2 DOWN BY 1


END-PERFORM

Onde aparece?

Remover duplicidade

Palíndromo

Conciliação bancária

Arquivos ordenados

Merge VSAM

Join Batch

Complexidade

O(n)

Padrão 2 — Sliding Window

A Janela Deslizante

Esse algoritmo parece sofisticado.

Mas todo programador financeiro já utilizou.

Exemplo

Últimos 30 dias.

Tabela

Janela

Primeira

10 20 15

Soma

Move.

20 15 40

Move.

15 40 50

105

COBOL


ADD ENTRADA(I)
TO SOMA


SUBTRACT ENTRADA(I-3)

FROM SOMA

Muito usado em:

Detecção fraude

PIX

Cartão crédito

Médias móveis

SMF

Complexidade

O(n)

Padrão 3 — Prefix Sum

O Acumulador Supremo

Padawan.

Você provavelmente já usou.

Só não sabia o nome.

Exemplo.

Tabela.

5 3 2 4 1

Prefix.

Consultar.

Posição.

2 até 5.

15 - 5

COBOL

ADD VALOR(I)

TO ACUM(I-1)

GIVING ACUM(I)

Utilização.

Analytics

RMF

SMF

Cobrança

Padrão 4 — Kadane

O Santo Graal das Séries

Maior sequência positiva.

Exemplo.

Resultado.

COBOL

IF SOMA < ZERO

MOVE ZERO TO SOMA

END-IF

Aplicações.

Lucro máximo

Oscilações

Bolsa

PIX

Cartões

Complexidade.

O(n)

Padrão 5 — Merge Intervals

Fundindo Períodos

Muito usado.

Principalmente bancos.

Exemplo.

Cliente bloqueado.

01-05

03-10

12-20

Resultado.

01-10

12-20

COBOL

Comparar.

Datas.

Mesclar.

Usado.

Seguros

Férias

Janelas batch

Padrão 6 — Cyclic Sort

A Ordem Cósmica

Pouco conhecido.

Mas genial.

Exemplo.

3 1 2

Cada número.

Vai para posição.

Correta.

Resultado.

1 2 3

Muito útil.

Detectar.

Ausentes.

Duplicados.

Padrão 7 — Hashing

O Cache Jedi

Python

Dict

Java

HashMap

COBOL

Tabela OCCURS

Exemplo.

Estados.

SP


RJ


MG

Pesquisar.

Instantaneamente.

Alternativa.

SEARCH ALL

Exemplo.

Tabela IR.

Códigos.

CEP.

Produtos.

Padrão 8 — Binary Search

SEARCH ALL

A arma secreta do COBOL.

Tabela ordenada.

SEARCH ALL CLIENTE

Complexidade.

O(log n)

1000000 registros.

Comparações.

Magia matemática.

Muito superior.

SEARCH.

500 mil leituras.

SEARCH ALL.

Padrão 9 — Monotonic Stack

O Mestre Esquecido

Pouco usado.

Mas poderoso.

Encontrar.

Próximo maior.

Próximo menor.

Exemplo.

Temperaturas.

Pergunta.

Quando esquenta?

Em COBOL.

Pode ser implementado.

Com tabela OCCURS.

Muito usado.

Forecast.

Analytics.

IA.

Padrão 10 — Two Heaps

O Conselho Jedi

Min Heap.

Max Heap.

Encontrar.

Top 10.

Maior.

Menor.

Mediana.

Em COBOL.

Mais raro.

Mas possível.

Exemplo.

Ranking clientes.

SEARCH versus SEARCH ALL

Padawan.

Essa é importante.

Linear.

O(n)

SEARCH ALL

O(log n)

1000000 registros.

SEARCH.

500000 leituras.

SEARCH ALL.

INDEX versus Subscript

Subscript.

CLIENTE(I)

Índice.

INDEXED BY IDX

Mais rápido.

Menos cálculos.

Melhor cache.

SSRANGE

O Guardião das Tabelas

Sempre.

DEV.

TESTE.

QA.

Nunca acessar.

CLIENTE(1001)

Se existem.

SSRANGE salva vidas.

Quando usar DB2

Tabela enorme.

Não use OCCURS.

Quando usar OCCURS

Lookup.

UF.

IR.

CEP.

Parâmetros.

Cache.

Arquitetura Moderna

Hoje.

Programadores resolvem LeetCode.

Veteranos Mainframe.

Já faziam isso.

Em 1982.

Usando.

COBOL

VSAM

JCL

DFSORT

ICETOOL

DB2

Curiosidade Histórica

Década de 70.

IBM chamava isso.

Table Processing

Década de 80.

Performance Tuning.

Década de 90.

Binary Search.

Virou padrão.

Grandes bancos.

Década de 2000.

Java descobriu.

Collections.

Década de 2020.

LeetCode descobriu.

Década de 2030.

IA vai descobrir.

Que um programador COBOL aposentado em Campinas ou Itatiba já utilizava Prefix Sum desde 1989.

Easter Egg Bellacosa

Existe uma antiga profecia dos Sysprogs.

Ela diz:

"Chegará um dia em que um desenvolvedor júnior perguntará ao arquiteto qual algoritmo usar."

O arquiteto responderá:

Use Sliding Window.

O desenvolvedor pesquisará durante três horas.

Assistirá quatro vídeos.

Lerá cinco artigos.

Abrirá o ChatGPT.

Fará benchmarking.

Criará um POC.

E finalmente implementará.

Enquanto isso, um programador COBOL veterano sentado ao lado apenas dirá:

Ah...

Você queria uma média móvel.

Faço isso desde 1993.

Está no PROGFINC.

Linha 287.

Não mexe.

Funciona.

E agora pega um café.

Porque no Reino do Mainframe, muitas vezes os algoritmos mais modernos apenas receberam nomes mais bonitos para técnicas que os Cavaleiros COBOL já dominavam há décadas.

segunda-feira, 24 de fevereiro de 2020

MUSEUS PRÓXIMOS A LINHA: AZUL, VERDE, VERMELHA E AMARELA.

MUSEUS DA LINHA VERDE DO METRÔ

Metrô de São Paulo

**VILA MADALENA***
Museu da Pessoa
Museu do Objeto Brasileiro

***SUMARÉ***
Unibes cultural
Casa Guilherme de Almeida

***CLINICAS***
Museu Histórico Prof. Carlos da Silva Lacaz - FMUSP
Museu do Futebol

***CONSOLAÇÃO***
Instituto Moreira Sales
Cemitério da Consolação
Centro de Memoria da Faculdade Ibero Americana
Museu Ceroplástico

***TRIANON-MASP***
Museu de Arte de São Paulo
Centro de Pesquisa e Formação do SESC
Centro de Cultura FIESP

***BRIGADEIRO***
Museu Herculano Pires - Itaú Cultural
Acervo Historico Irmã Heinrich
Japan House
Museu do Óculos
Museu do BIxiga
Museu do instituo Pasteur
Casa das Rosas

***PARAÍSO***
Centro Cultural de São Paulo –CCSP

***ANA ROSA,CHÁCARA KLABI ou AACD-Servidor****
OCA
Obelisco
Lasar Segall
Casa Modernista
Museu Afro Brasil
Museu do Bombeiro
Museu de Arte Moderna
Planeta dos Insetos
Museu da Matemática
Museu do Instituto Biológico
Museu de Arte Contemporânea

***IMIGRANTES***
Museu Vicente de Azevedo

***ALTO DO IPIRANGA OU IPIRANGA ****
Museu do Ipiranga
Museu de Zoologia
Monumento a Independência
Casa do Grito

***SACOMÃ***
Museu Botânico

--MUSEUS PRÓXIMOS A LINHA AZUL DO METRÔ--

*METRÔ TUCURUVI
#museudojaçana
#museuflorestal

*METRÔ SANTANA
#sitiomorrinhos
#museuabertodearteurbana

*METRÔ CARANDIRU
#museupenitenciario
#museuabertodearteurbana

*METRÔ TIETÊ
#museuabertodearteurbana
#arquivodoestado
#museudodentista
#museudaportuguesa

*METRÔ ARMÊNIA
#museudotransporte

*METRÔ TIRADENTES
#museudeartesacra
#arquivomunicipal
#museudepoliciamilitar
#museudarota
#museudacavalaria

*METRÔ LUZ
#pinacoteca
#museudaenergia
#memorialdaresistencia

*METRÔ SÃO BENTO
#pateodocolegio
#correiocentral
#centrodememoriadocirco
#ccbb

*METRÔ SÉ
#caixacultural
#memorialde32
#solardamarquesa
#casadaimagem
#becodopinto
#museudamedicina
#cataventocultural
#museudafaculdadededireito

*METRÔ LIBERDADE
#museudajustiça
#museutribunaldejustiça

*METRÔ SÃO JOAQUIM
#museudaimigraçãojaponesa
#vilaitororo

*METRÔ VERGUEIRO
#centroculturalsaopaulo

*METRÔ PARAÍSO
#casadasrosas
#japahouse
#irmãbeata
#itaucultural

*METRÔ ANA ROSA OU VILA MARIANA
#museudeartecontemporanea
#museudoinstitutobiologico
#oca
#museudeartemoderna
#museuafrobrasil
#planetadosinsetos

*METRÔ SANTA CRUZ
#museudoindio
#museulasarsegall
#casamodernista
#memorialdobombeiro

*METRO JABAQUARA
#sitiodaressaca
#museudalampada

PS: TODOS GRÁTIS AOS SÁBADOS. — com Metro/Linha Azul - São Paulo/SP.

--MUSEUS NA LINHA AMARELA DO METRÔ----

METRÔ LUZ
Pinacoteca
Museu da energia
Sala São Paulo
Memorial da resistência
Museu de Arte Sacra

METRÔ REPUBLICA
Museu da Diversidade Sexual
Museu do Teatro Municipal
Centro de Memoria do Circo

METRÔ HIGIENOPOLIS-MACKENZIE
Chácara lane
Casa amarela
Biblioteca Monteiro Lobato
Museu da Santa Casa de Misericórdia
Museu de Arte Brasileira

METRÔ PAULISTA
Instituto Moreira Sales
Cemitério da Consolação
Centro de Memoria da Faculdade Ibero Americana
Museu Ceroplástico
Museu do Futebol
Museu Histórico Prof. Carlos da Silva Lacaz - FMUSP

METRÔ OSCAR FREIRE
Museu Oscar Freire
Centro Pro-memoria Club Américo Paulistano

METRÔ FRADIQUE COUTINHO
Fundação Ema Klabin
Museu da Imagem e do Som
Museu Brasileiro de Esculturas
Paço das Artes

METRÔ FARIA LIMA
Centro de Memoria Bunge
Tomie Ohtake
Museu da Casa Brasileira
Casa do Itaim bibi
Museu objeto da casa brasileira
Museu da pessoa
VOZOTECA

METRÔ PINHEIROS
Museu do Relógio

METRÔ BUTANTÃ
Casa do Bandeirante
Museu de Oceanografia
Museu da Policia Civil
Museu do Brinquedo
Museu de Microbiologia
Museu Biológico do Instituto Butantã
Museu de Anatomia Humana
Museu de Anatomia Veterinária
Museu de Arqueologia e Etnologia - MAE

METRÔ SÃO PAULO – MORUMBI
Capela do Morumbi
Palácio dos Bandeirantes
Casa bola
Casa de Vidro
Fundação Maria Luisa e Oscar Americano
Casa do Caxingui

--MUSEUS DA LINHA VERMELHA DO METRÔ--

* BARRA FUNDA
Memorial da America Latina
Memorial da Inclusão
Museu Geológico
Casa Mario de Andrade
Museu da Imprensa Automotiva

* SANTA CECILIA
Museu da Santa Casa de Misericórdia
Memoria Monteiro Lobato

* REPUBLICA
Museu da Diversidade Sexual
Centro de Memoria do Circo

* ANHANGABAÚ
Museu do Teatro Municipal
Praça das Artes

* SÉ
Solar da Marquesa
Casa da Imagem
Beco do Pinto
Caixa Cultural
Memorial de 32
Museu do Telefone
Pátio do Colégio
Centro de Memoria Sindical
Centro Cultral do Banco do Brasil

*Dom Pedro II
Catavento Cultural

*BRESSER-MOOCA
Museu da Imigração

* TATUAPÉ
Casa do Tatuapé

* CARRÃO
Casa do Regente Feijó

sábado, 22 de fevereiro de 2020

KISS Rules : Quando um Programador COBOL Descobriu que o Arquiteto da Matrix Não Vencia Pela Complexidade… Mas Pela Simplicidade

Bellacosa Mainframe apresenta o KISS rules

☕ Um Café no Bellacosa Mainframe

KISS Rules sem Mistérios

Quando um Programador COBOL Descobriu que o Arquiteto da Matrix Não Vencia Pela Complexidade… Mas Pela Simplicidade

"A maior demonstração de inteligência não é construir algo complicado. É construir algo tão simples que continue funcionando décadas depois."

Prólogo — O Código Secreto do Arquiteto

Depois de inúmeras batalhas contra o Agente Smith, Neo finalmente teve acesso ao núcleo da Matrix.

Esperava encontrar algoritmos impossíveis.

Equações gigantescas.

Milhares de níveis de abstração.

Mas encontrou algo completamente diferente.

O coração da Matrix era surpreendentemente simples.

Poucas regras.

Poucas interfaces.

Poucos componentes.

Neo olhou espantado para o Arquiteto.

— Isso é tudo?

O Arquiteto respondeu calmamente.

— A complexidade não está no código.

Está no mundo.

Nos usuários.

Nos negócios.

Nos requisitos.

Nos imprevistos.

Neo insistiu.

— Então por que não criar uma arquitetura extremamente sofisticada?

O Oráculo apareceu.

Serviu duas xícaras de café.

Depois colocou sobre a mesa dois relógios.

Um possuía centenas de engrenagens.

Outro tinha poucas peças.

Perguntou:

— Qual você acha que continuará funcionando daqui a cinquenta anos?

Neo sorriu.

Naquele instante compreendeu o verdadeiro significado do KISS.

O que significa KISS?

KISS significa:

Keep It Simple, Stupid

Em português:

"Mantenha tudo o mais simples possível."

Apesar do termo "Stupid" soar ofensivo em português, ele nasceu como uma forma bem-humorada de lembrar engenheiros de que a simplicidade costuma ser mais poderosa do que soluções excessivamente sofisticadas.

Hoje muitas empresas preferem versões como:

Keep It Simple
Keep It Short and Simple
Keep It Simple and Smart

Mas a essência permanece a mesma.

A origem do princípio

O princípio surgiu na década de 1960.

Foi popularizado pelo engenheiro Kelly Johnson, líder da famosa divisão Skunk Works, da Lockheed.

Johnson orientava sua equipe a desenvolver aviões militares extremamente eficientes, porém fáceis de manter em condições adversas.

Sua filosofia era simples:

Um mecânico em um campo de batalha deve conseguir reparar o avião com ferramentas comuns.

Se o projeto fosse complexo demais para ser mantido, ele já havia fracassado.

Décadas depois, esse princípio tornou-se um dos pilares da Engenharia de Software.

Matrix explica perfeitamente

Imagine duas versões da Matrix.

A primeira possui:

cinco componentes;
regras claras;
comunicação simples.

A segunda possui:

cinquenta frameworks;
cem microsserviços;
dezenas de filas;
múltiplas camadas;
configurações espalhadas.

Qual delas Neo conseguiria compreender primeiro?

Provavelmente a mais simples.

Simples não significa simplório

Esse é um dos maiores mal-entendidos.

KISS não significa fazer menos.

Significa fazer apenas o necessário.

Existe enorme diferença.

O COBOL nasceu seguindo KISS

Quando COBOL surgiu, seu objetivo era ser:

legível;
previsível;
próximo da linguagem humana.

Observe.

ADD VALOR
   TO SALDO.

Ou.

IF CLIENTE-ATIVO

Mesmo décadas depois.

Ainda conseguimos entender.

Essa clareza foi uma decisão arquitetural.

Como nasce a complexidade?

Ela raramente aparece de uma vez.

Primeiro surge um pequeno framework.

Depois outro.

Depois uma camada.

Depois uma abstração.

Depois uma exceção.

Anos depois.

Ninguém consegue explicar a arquitetura completa.

Matrix Reloaded

O Arquiteto mostra para Neo inúmeras versões anteriores da Matrix.

Cada uma tornou-se mais sofisticada.

Mas também mais difícil de controlar.

Quanto maior a complexidade.

Maior o número de efeitos colaterais.

O efeito psicológico

Existe um fenômeno curioso.

Profissionais iniciantes frequentemente acreditam que:

"Código complicado impressiona."

Profissionais experientes descobrem justamente o contrário.

Código simples impressiona muito mais.

Porque é difícil escrever algo realmente simples.

O Programador COBOL Padawan

Imagine duas soluções.

Primeira.

IF CLIENTE-ATIVO

Segunda.

IF CLIENTE-ATIVO
   AND WS-FLAG-01 = "S"
   OR WS-FLAG-02 = "N"
   AND WS-STATUS-XYZ NOT = ZERO
   ...

Qual será compreendida daqui a quinze anos?

O Agente Smith ama complexidade

Porque sistemas complicados escondem:

bugs;
inconsistências;
duplicações;
vulnerabilidades.

Quanto mais difícil entender.

Mais difícil corrigir.

Um exemplo inspirado na Matrix

Neo precisa abrir uma porta.

Versão simples.

Uma chave.

Versão complexa.

Quatro chaves.

Cinco senhas.

Três certificados.

Dois tokens.

Sete validações.

No final.

A porta continua sendo apenas uma porta.

O custo invisível

Complexidade gera:

treinamento maior;
documentação maior;
testes maiores;
manutenção maior;
risco maior.

Tudo cresce.

O impacto no Mainframe

Em ambientes IBM Z encontramos aplicações com quarenta anos de vida.

Sistemas assim sobrevivem porque muitos seguiram princípios como:

simplicidade;
modularização;
previsibilidade;
estabilidade.

Não porque eram sofisticados.

Curiosidade

Albert Einstein costuma receber a frase:

"Everything should be made as simple as possible, but not simpler."

Embora a autoria exata seja debatida, a ideia resume perfeitamente o KISS:

Simplifique.

Mas nunca elimine o essencial.

Quando KISS é ignorado?

Começam a surgir:

frameworks desnecessários;
padrões aplicados sem necessidade;
heranças enormes;
interfaces excessivas;
configurações infinitas.

Tudo para resolver problemas simples.

Um exemplo COBOL

Imagine um cálculo.

Versão simples.

COMPUTE TOTAL = PRECO * QUANTIDADE

Versão complicada.

Três programas.

Cinco CALLs.

Duas APIs.

Uma fila MQ.

Resultado idêntico.

Matrix e o Chaveiro

O Chaveiro representa uma lição interessante.

Ele cria chaves.

Não cem ferramentas.

Cada chave resolve exatamente um problema.

Essa é uma excelente representação do KISS.

Atenção!

KISS não significa evitar arquitetura.

Significa evitar arquitetura desnecessária.

A diferença

Arquitetura Elegante

Resolve o problema.

Arquitetura Complicada

Cria novos problemas.

O papel da simplicidade

Sistemas simples apresentam:

menos bugs;
menor custo;
maior previsibilidade;
onboarding mais rápido;
documentação menor.

Ferramentas ajudam

No universo IBM.

Ferramentas como:

IBM ADDI;
SonarQube;
COBOL Check;
Enterprise Analyzer;

ajudam a localizar:

duplicações;
complexidade ciclomática;
código morto;
módulos gigantes.

O papel da IA

A IA frequentemente sugere soluções sofisticadas.

Cabe ao engenheiro perguntar:

"Existe uma maneira mais simples?"

Essa talvez seja uma das perguntas mais importantes da profissão.

Os riscos

Quando KISS é ignorado.

Surgem:

overengineering;
manutenção cara;
dependências excessivas;
curva de aprendizado enorme;
baixa produtividade.

Erros clássicos

Adotar tecnologia apenas porque está na moda.
Aplicar Design Patterns em todo lugar.
Criar abstrações prematuras.
Usar cinco frameworks quando um resolveria.
Confundir inteligência com complexidade.

Boas práticas

Resolver primeiro o problema.
Medir antes de otimizar.
Escrever código legível.
Modularizar.
Eliminar duplicações.
Revisar continuamente.
Questionar toda nova dependência.

Aplicabilidade

KISS aparece em:

COBOL.
CICS.
Db2.
Java.
Python.
APIs.
Cloud.
Kubernetes.
Microsserviços.
IA.

É um princípio universal.

KISS e os outros princípios

Curiosamente.

KISS conversa diretamente com vários conceitos já vistos nesta série.

Ele reduz:

Spaghetti Code, porque incentiva clareza.
Lasagna Code, porque evita camadas desnecessárias.
Golden Hammer, porque escolhe apenas as ferramentas necessárias.
Big Ball of Mud, porque favorece organização.
Boiling Frog, porque dificulta o crescimento invisível da complexidade.
Death March, porque soluções simples costumam ser entregues e testadas mais rapidamente.

Não é apenas um princípio isolado.

É uma filosofia que influencia praticamente todos os demais.

O ensinamento do Oráculo

O Oráculo entrega dois mapas para Neo.

O primeiro possui centenas de símbolos.

Setas.

Anotações.

Cores.

Camadas.

O segundo mostra apenas três caminhos.

Neo escolhe imediatamente o segundo.

Ela sorri.

— Por quê?

Neo responde.

— Porque consigo entender para onde estou indo.

Ela coloca a mão sobre seu ombro.

"Um sistema que ninguém compreende deixa de servir às pessoas e passa a exigir que as pessoas sirvam a ele."

Lições para um Programador COBOL Padawan

Durante sua carreira você encontrará colegas extremamente inteligentes.

Alguns escreverão soluções impressionantes.

Mas observe atentamente os profissionais realmente admirados após vinte ou trinta anos de experiência.

Quase sempre eles possuem outra característica.

Escrevem programas fáceis de ler.

Escolhem nomes claros.

Criam módulos pequenos.

Documentam decisões.

Eliminam o desnecessário.

Esses profissionais sabem que a manutenção representa a maior parte do ciclo de vida de um software.

Quem simplifica hoje está ajudando um colega — ou a si mesmo — daqui a dez anos.

Curiosidades

O princípio KISS influenciou diretamente diversas metodologias modernas:

Agile, ao priorizar entregas simples e incrementais.
Extreme Programming (XP), com foco na solução mais simples que funciona.
YAGNI (You Aren't Gonna Need It), evitando funcionalidades imaginárias.
Lean Software Development, reduzindo desperdícios.
Unix Philosophy, que recomenda ferramentas pequenas fazendo uma única tarefa muito bem.

Embora tenham surgido em épocas diferentes, todas compartilham a mesma ideia: simplicidade gera sustentabilidade.

Conclusão — O Código Verde da Matrix Era Simples

Quando Neo finalmente enxergou o código verde da Matrix, ele percebeu que por trás de toda aquela realidade existiam padrões claros e elegantes.

Os sistemas mais duradouros seguem exatamente esse caminho.

O princípio KISS nos ensina que complexidade deve existir apenas quando ela é realmente necessária. Cada camada, cada framework, cada abstração e cada linha de código precisam justificar sua existência.

Para um Programador COBOL que trabalha com IBM Z, essa lição é ainda mais valiosa. Sistemas bancários, seguradoras e governos dependem de aplicações que continuarão sendo mantidas por décadas. Quanto mais simples, legíveis e previsíveis forem essas aplicações, maior será sua capacidade de evoluir sem perder confiabilidade.

No universo Bellacosa Mainframe existe uma máxima que certamente estaria escrita na parede da sala do Arquiteto:

"A verdadeira genialidade não está em criar uma Matrix impossível de compreender. Está em construir uma tão simples que qualquer Padawan consiga mantê-la funcionando mesmo cinquenta anos depois."

Porque, no fim, o software que atravessa gerações não é aquele que impressiona pela complexidade.

É aquele que continua resolvendo problemas quando todas as tecnologias da moda já ficaram para trás.

quinta-feira, 20 de fevereiro de 2020

A Psicologia por Trás do Programador COBOL

Bellacosa Mainframe e a psicologia por trás do programador Cobol

☕ Um Café no Bellacosa Mainframe

A Psicologia por Trás do Programador COBOL

Como as Grandes Teorias do Comportamento Explicam a Vida no IBM Z — Um Guia para o Programador COBOL Padawan Inspirado em Star Trek e no Dr. Spock

"A lógica é o começo da sabedoria, não o fim." — Dr. Spock

Existe uma curiosidade fascinante sobre o desenvolvimento de software.

Quando um programa COBOL apresenta um ABEND S0C7 pela terceira vez consecutiva, duas pessoas podem reagir de maneiras completamente diferentes.

Um iniciante pensa:

"Eu nunca vou aprender isso."

Um veterano pensa:

"Interessante... existe um padrão escondido."

O erro é exatamente o mesmo.

A diferença está no cérebro.

Mais especificamente, na forma como aprendemos, criamos hábitos, tomamos decisões, reagimos ao estresse e interpretamos o sucesso e o fracasso.

Curiosamente, quase tudo isso já havia sido estudado muito antes da existência do COBOL.

Muito antes do IBM System/360.

Muito antes da linguagem C.

Muito antes do Agile.

A psicologia comportamental, cognitiva e social explica boa parte do que acontece diariamente dentro de um projeto mainframe.

Hoje vamos visitar a ponte da USS Enterprise.

Nosso guia será o oficial de ciências mais famoso da ficção.

Dr. Spock.

Porque poucos personagens representam tão bem o equilíbrio entre lógica, emoção, aprendizado e disciplina quanto um vulcano.

Prepare seu tricorder.

Vamos explorar a mente do programador.

Capítulo 1 — O cérebro do programador COBOL

Quando um padawan chega ao IBM Z ele acredita que seu maior desafio será aprender:

COBOL
JCL
CICS
Db2
VSAM
IMS
RACF

Na verdade não.

Seu maior desafio será aprender...

...como funciona seu próprio cérebro.

Porque programar é uma atividade profundamente psicológica.

Todos os dias você precisa:

resolver problemas
aprender coisas novas
lembrar detalhes
controlar ansiedade
trabalhar em equipe
lidar com críticas
aceitar erros
persistir

Tudo isso é comportamento humano.

Capítulo 2 — Ivan Pavlov e os condicionamentos

Todo mundo conhece o cachorro de Pavlov.

O experimento era simples.

Campainha.

Comida.

Salivação.

Depois de repetir diversas vezes...

Somente a campainha já fazia o cachorro salivar.

Chamamos isso de:

Condicionamento clássico.

E no mainframe?

Você também foi condicionado.

Exemplos:

Abrir SDSF →

Ansiedade.

Receber e-mail do gerente →

Tensão.

Ver "ABEND" →

Frio na barriga.

Ou...

Ver JOB RC=0000 →

Satisfação.

Seu cérebro aprende associações constantemente.

Dica Bellacosa

Não associe erro à vergonha.

Associe erro ao aprendizado.

Veteranos fazem exatamente isso.

Capítulo 3 — Skinner e o condicionamento operante

B. F. Skinner mostrou que comportamentos recompensados tendem a aumentar.

Exemplo:

Você resolve um problema difícil.

Recebe elogios.

Seu cérebro libera dopamina.

Na próxima vez...

Você terá maior motivação.

No desenvolvimento COBOL

Quando um mentor diz:

"Excelente análise."

Você ganha confiança.

Quando ele apenas critica...

Seu aprendizado diminui.

Por isso grandes líderes ensinam.

Não apenas corrigem.

Easter Egg Star Trek

Capitão Kirk motiva.

Spock orienta.

McCoy apoia emocionalmente.

Uma boa equipe técnica possui exatamente esses três perfis.

Capítulo 4 — Albert Bandura e a aprendizagem observacional

Bandura revolucionou a psicologia.

Ele mostrou que aprendemos observando.

Nem sempre precisamos experimentar.

Podemos aprender vendo alguém fazer.

O veterano na tela 3270

Você observa um analista experiente.

Ele:

navega rapidamente
usa atalhos
identifica erros em segundos
conhece comandos escondidos

Você aprende apenas olhando.

Por isso pair programming funciona.

Shadowing funciona.

Mentoria funciona.

Curiosidade

Grande parte do conhecimento do mainframe nunca foi documentada.

Foi transmitida oralmente.

Como os mestres Jedi.

Capítulo 5 — Jean Piaget

Piaget estudou como construímos conhecimento.

Aprender não significa decorar.

Aprender significa reorganizar modelos mentais.

Exemplo

No início:

"JCL executa programa."

Depois:

"JCL conversa com JES."

Mais tarde:

"JES conversa com WLM."

Depois:

"SMS influencia datasets."

Depois:

"Tudo faz parte do sistema operacional."

Seu cérebro cria mapas mentais cada vez maiores.

Capítulo 6 — Lev Vygotsky

Talvez a teoria mais importante para um padawan.

Vygotsky criou a famosa:

Zona de Desenvolvimento Proximal.

Ou simplesmente:

ZDP.

Ela representa aquilo que você ainda não consegue fazer sozinho...

...mas consegue fazer com ajuda.

Exemplo

Você não sabe montar um BIND PACKAGE.

Com um mentor...

Consegue.

Depois de algumas semanas...

Faz sozinho.

É assim que ocorre o crescimento profissional.

Dica

Nunca estude completamente sozinho.

Mentores aceleram décadas de aprendizado.

Capítulo 7 — Carol Dweck e o Growth Mindset

Carol Dweck descobriu duas formas principais de pensar.

Mentalidade fixa

"Sou ruim em COBOL."

Fim.

Mentalidade de crescimento

"Ainda não domino COBOL."

Existe enorme diferença.

A palavra "ainda" muda tudo.

No IBM Z

Veteranos erram diariamente.

A diferença?

Eles sabem que aprenderão com o erro.

Spock diria

"A ausência de conhecimento atual não implica incapacidade futura."

Capítulo 8 — Daniel Kahneman

Prêmio Nobel.

Criador da teoria dos dois sistemas.

Sistema 1:

Rápido.

Automático.

Instintivo.

Sistema 2:

Lento.

Analítico.

Lógico.

Durante um ABEND

Sistema 1:

"Foi o Db2."

Sistema 2:

"Vamos verificar SQLCODE."

Ou:

"Vamos analisar SYSUDUMP."

Ou:

"Verifique o offset."

Grandes analistas usam o Sistema 2.

Capítulo 9 — Heurísticas

Nosso cérebro cria atalhos.

Eles economizam energia.

Mas produzem erros.

Viés da confirmação

"Tenho certeza que o erro está no COBOL."

Horas depois...

Era o JCL.

Ancoragem

"O último problema era VSAM."

Logo:

Todo problema agora parece VSAM.

Disponibilidade

Você lembra do último ABEND.

Então acredita que ele é o mais comum.

Mesmo não sendo.

Capítulo 10 — Maslow

A famosa pirâmide.

No mundo corporativo ela aparece diariamente.

Primeiro:

Segurança.

Depois:

Pertencimento.

Depois:

Reconhecimento.

Depois:

Autorrealização.

Um padawan inseguro

Tem medo de perguntar.

Tem medo de errar.

Tem medo de produzir.

Sem segurança psicológica...

Não existe inovação.

Capítulo 11 — Herzberg

Herzberg descobriu algo curioso.

Salário evita insatisfação.

Mas não gera paixão.

O que realmente motiva?

autonomia
crescimento
reconhecimento
propósito

Mainframe

Quem entende que processa milhões de salários, hospitais e bancos...

Encontra propósito.

Capítulo 12 — Csikszentmihalyi e o Flow

Flow.

O estado de concentração absoluta.

Você esquece o relógio.

Horas passam.

Você nem percebe.

Quando acontece?

Desafio equilibrado.

Nem fácil.

Nem impossível.

É exatamente onde um bom líder posiciona seus padawans.

Capítulo 13 — Charles Duhigg e os hábitos

Todo hábito possui:

gatilho
rotina
recompensa

Exemplo

Chegar ao trabalho.

↓

Abrir SDSF.

↓

Verificar jobs.

↓

Sensação de controle.

Em poucos meses...

Isso vira automático.

Dica

Crie hábitos saudáveis:

revisar código
comentar programas
ler manuais
testar antes do deploy

Capítulo 14 — Inteligência Emocional (Daniel Goleman)

Conhecimento técnico explica parte do sucesso.

Relacionamento explica o restante.

Grandes profissionais:

ouvem
perguntam
ajudam
compartilham

Nunca humilham iniciantes.

Curiosidade

Muitas empresas perderam especialistas...

Não por aposentadoria.

Mas porque ninguém quis aprender com pessoas difíceis.

Conhecimento sem empatia morre.

Capítulo 15 — Reforço Positivo na Revisão de Código

Imagine duas revisões.

Revisor A

"Está tudo errado."

Fim.

Revisor B

"Gostei da organização. Agora podemos melhorar estes três pontos."

Mesmo resultado técnico.

Impacto psicológico completamente diferente.

Capítulo 16 — O efeito Dunning-Kruger

Iniciantes frequentemente acreditam que sabem muito.

Depois descobrem quanto ainda falta aprender.

A confiança cai.

Mais tarde...

O conhecimento cresce.

A confiança volta.

Agora baseada em experiência.

Todo especialista já passou por essa curva.

Capítulo 17 — O poder da curiosidade

A curiosidade é um dos maiores motores do aprendizado.

Perguntas como:

Por que existe o SQLCA?
Por que o JCL usa DDNAME?
Por que o COBOL continua evoluindo?
Como o JES agenda milhares de jobs?
Como o WLM decide prioridades?

Cada resposta amplia seu mapa mental.

Os melhores profissionais raramente se contentam com "funciona". Eles perguntam "por que funciona?".

Easter Egg — A Ponte da USS Enterprise como um Projeto Mainframe

Imagine um grande sistema bancário.

Capitão Kirk é o gerente de projeto: toma decisões sob pressão e assume riscos calculados.
Dr. Spock é o arquiteto ou analista sênior: baseia-se em evidências, métricas e lógica.
Dr. McCoy representa RH, UX e liderança humana: lembra que sistemas existem para atender pessoas.
Scotty é o sysprog: mantém a infraestrutura IBM Z funcionando, faz milagres com CPU, memória e I/O.
Uhura é o middleware: garante que CICS, MQ, APIs e sistemas conversem.
Sulu é o operador: conduz a operação diária com precisão.
Chekov é o padawan curioso: aprende rápido, faz perguntas e cresce a cada missão.

Nenhum deles vence sozinho. A Enterprise funciona porque cada especialidade respeita as demais.

As Grandes Lições para um Padawan COBOL

Depois de conhecer essas teorias, fica claro que evoluir no mainframe depende de muito mais do que decorar comandos.

Os maiores aprendizados são:

Erros são dados para aprendizado, não motivos para vergonha.
Observe especialistas: modelagem é uma das formas mais rápidas de aprender.
Desenvolva uma mentalidade de crescimento e aceite o "ainda não".
Questione seus próprios vieses antes de concluir a causa de um problema.
Crie hábitos consistentes de estudo, testes e documentação.
Valorize mentores e também torne-se mentor quando adquirir experiência.
Cultive inteligência emocional: conhecimento compartilhado vale mais do que conhecimento guardado.
Busque o estado de flow, equilibrando desafio e capacidade.
Nunca pare de fazer perguntas.

Conclusão — O Verdadeiro Vulcano do IBM Z

No universo de Star Trek, muitos acreditam que Spock representa apenas a lógica. Mas essa é uma visão incompleta.

Spock estudou suas emoções para não ser dominado por elas. Ele sabia que lógica sem empatia se torna fria, enquanto emoção sem disciplina leva a decisões impulsivas. Sua força estava no equilíbrio.

O mesmo vale para um excelente profissional de mainframe.

Dominar COBOL, JCL, CICS, Db2, IMS, RACF ou z/OS é essencial, mas insuficiente. Os melhores especialistas também entendem como aprendem, como colaboram, como reagem à pressão, como recebem críticas e como transformam erros em experiência.

Em um datacenter, milhões de linhas de código mantêm bancos, hospitais, governos e empresas funcionando. Mas por trás de cada linha existe um ser humano tomando decisões. É aí que a psicologia encontra a engenharia.

Ao longo da carreira, você perceberá que os maiores desafios raramente serão técnicos. Eles envolverão comunicação, disciplina, curiosidade, paciência, liderança e aprendizado contínuo.

Como diria o Dr. Spock:

"Computadores são excelentes ferramentas para seguir instruções. Pessoas são extraordinárias porque conseguem aprender, adaptar-se e evoluir."

Essa talvez seja a tecnologia mais poderosa de todas.

Translate

sexta-feira, 28 de fevereiro de 2020