segunda-feira, 20 de maio de 2013

Uma tarde no zoo de Lisboa

Aventuras com o Barbinha no Zoologico


Nao sou o melhor pai do mundo, a bem da verdade queria ter aprendido a ser melhor pai, mas de todos os meus conhecimentos essa parte sou medíocre.

Depois do meu divorcio é ida para Italia, de tempos em tempos voltava a Portugal para visitar meu filho. E nosso programa principal é a ida ao jardim Zoológico de Lisboa.

Pena que as restrições de audio tiraram toda a graça do show com os leões marinhos.



Para aqueles que não conhecem o Zoológico de Lisboa é pequenino, porém muito rico em atraçoes, possui uma área de shows com golfinhos e leoes marinhos (acredito que as primeiras memorias divertidas do meu filho, foram feitas aqui ganhando beijos do leão marinho).

Outras atraçoes existentes são o teleférico que circula todo o perímetro, o show de aves exóticas, demonstração de animais e diversos cativeiros construídos da forma mais humana possível, tentando reproduzir o habitat natural.

A principal vantagem deste zoológico é sua posição estratégica ao lado de uma estação conjugada de Trem/Metro/Ónibus e estar próximo ao centro da cidade. Evitando com isso grandes deslocações e perda de tempo em transportes.

Na área externa existe uma grande praça de alimentação com diversos restaurantes, fliperamas e brinquedos para os miúdos, com muita sombra para repousar



quarta-feira, 15 de maio de 2013

🧠⚙️ O Sistema Operacional Z — O que é z/OS?

 


🧠⚙️ O Sistema Operacional Z — O que é z/OS?

O sistema operacional que sustenta o mundo (e ninguém vê)

“Enquanto o mundo discute frameworks da moda,
o z/OS continua garantindo que o dinheiro chegue certo, no horário certo.”

Se você acha que z/OS é apenas “mais um sistema operacional”,
prepare-se para um choque de realidade.


🧱 O que é z/OS, afinal?

z/OS é o sistema operacional dos mainframes IBM Z.

Assim como:

  • Windows roda em desktops

  • Linux roda em servidores

👉 z/OS roda em computadores feitos para nunca parar.

Ele é responsável por coordenar, com precisão cirúrgica:

  • Hardware

  • Software

  • Aplicações

  • Usuários

  • Dados

  • Segurança

  • Performance

Tudo isso ao mesmo tempo, 24x7, 365 dias por ano.


🌍 Escala: onde o z/OS humilha qualquer comparação

Um sistema comum foi feito para:

  • Dezenas ou centenas de usuários

  • Alguns milhares de transações

O z/OS foi feito para:

👥 Milhares de usuários simultâneos
💳 Milhões de transações por segundo
📊 Volumes absurdos de dados sensíveis

E tudo isso:

  • Com isolamento

  • Com segurança

  • Com previsibilidade

  • Sem reboot de madrugada


⚖️ Gerenciamento de carga: o cérebro do sistema

Um dos maiores diferenciais do z/OS é o Workload Management (WLM).

Tradução Bellacosa:

O sistema decide quem merece CPU, quando e quanto.

O z/OS:

  • Prioriza aplicações críticas

  • Garante SLA

  • Evita que um JOB mal escrito derrube o sistema

  • Distribui recursos de forma justa e inteligente

No mundo distribuído, isso é “best effort”.
No z/OS, é engenharia de missão crítica.


🔐 Segurança: não é opcional, é DNA

z/OS nasceu em ambientes onde:

  • Um erro custa milhões

  • Um vazamento é inadmissível

  • Auditoria é rotina, não exceção

Ele integra nativamente:

  • RACF / ACF2 / Top Secret

  • Controle fino de acesso

  • Rastreabilidade completa

  • Separação real de ambientes

Aqui não existe:

“Depois a gente coloca segurança.”


🔄 Disponibilidade e recuperação: parar não é opção

Outro mantra do z/OS:

Falha acontece. Parada não.

O sistema foi projetado para:

  • Detectar falhas

  • Isolar problemas

  • Recuperar automaticamente

  • Continuar processando

É por isso que bancos confiam no z/OS para:

  • Compensação

  • Liquidação

  • Pagamentos

  • Crédito

  • Débito

  • Transferências globais


🗂️ Batch e ⚡ Online: dois mundos, um sistema

O z/OS domina dois universos ao mesmo tempo:

🗂️ Batch Processing

  • Grandes volumes

  • Processamento pesado

  • Horários controlados

  • Eficiência máxima

⚡ Online Transaction Processing (OLTP)

  • Respostas em tempo real

  • Usuários simultâneos

  • Latência mínima

  • Alta disponibilidade

Ambos coexistem no mesmo sistema, sem briga, sem gambiarra.


🚀 Múltiplas aplicações, isolamento total

No z/OS:

  • Uma aplicação não derruba a outra

  • Um usuário não vê o que não deve

  • Um erro não vira efeito dominó

Isso não é mágica.
É arquitetura madura, construída ao longo de décadas.


🏦 Quem confia no z/OS (e por quê)

z/OS é a espinha dorsal de:

🏦 Bancos e instituições financeiras
🏛️ Sistemas governamentais
✈️ Companhias aéreas
🚆 Transporte e logística
🏢 Grandes corporações globais

Onde existe:

  • Dinheiro

  • Dados críticos

  • Responsabilidade legal

👉 Existe z/OS.


🥚 Easter-eggs do mundo z/OS

  • z/OS já era “cloud-like” antes da nuvem existir

  • Virtualização sempre foi nativa

  • Segurança sempre foi requisito, não feature

  • Alta disponibilidade nunca foi marketing


🎓 Recado final do El Jefe ao padawan

Aprender z/OS não é aprender o passado.
É aprender como o mundo realmente funciona.

Enquanto modas vão e vêm,
o z/OS continua lá:

  • Silencioso

  • Estável

  • Processando trilhões

  • Sustentando a economia global

terça-feira, 14 de maio de 2013

🧾 COBOL 4.00 no IBM Mainframe

 


🧾 COBOL 4.00 no IBM Mainframe

Guia para Iniciantes: Código Limpo, Seguro e Econômico

“COBOL 4 não perdoa código ruim.
Ele executa… e te cobra por isso.”


🕰️ Um Pouco de Contexto (Por que COBOL 4 importa)

O Enterprise COBOL 4.00 marcou uma virada de chave no mainframe:

  • Introduziu um novo compilador

  • Passou a gerar código mais próximo da arquitetura moderna

  • Começou a penalizar código antigo e relaxado

👉 Muitos programas antigos funcionam, mas:

  • Gastam mais CPU

  • Usam mais memória

  • Sofrem em batch pesado


🧱 Estrutura Básica de um Programa COBOL (Visão Rápida)

IDENTIFICATION DIVISION. ENVIRONMENT DIVISION. DATA DIVISION. PROCEDURE DIVISION.

Para iniciantes:

  • DATA DIVISION mal feita = desastre

  • PROCEDURE DIVISION confusa = CPU jogada fora



⚠️ Grandes Perigos para Iniciantes no COBOL 4

☠️ 1. Código que “funciona” mas custa caro

Exemplo perigoso:

PERFORM UNTIL EOF READ ARQ MOVE CAMPO-A TO CAMPO-B END-PERFORM

❌ MOVE desnecessário dentro do loop
❌ Loop sem controle de volume

✅ Melhor prática:

READ ARQ AT END SET EOF TO TRUE END-READ

E só mover o que for necessário.


☠️ 2. PERFORM Excessivo (Modular demais mata CPU)

Iniciantes adoram:

PERFORM TRATA-REGISTRO

dentro de loop com milhões de registros.

⚠️ Cada PERFORM é custo.

✔️ Dica:

  • Inline lógica crítica

  • Use PERFORM para controle, não para micro-rotinas


☠️ 3. Variáveis mal definidas (memória desperdiçada)

Erro clássico:

01 WS-VALOR PIC X(1000).

Quando só precisa de 10 bytes 😱

✔️ Regra de ouro:

  • PIC do tamanho exato

  • Evite campos genéricos “pra garantir”

📉 Menos memória = menos cache miss = menos CPU.


☠️ 4. Repetir cálculos desnecessários

Erro comum:

COMPUTE WS-TOTAL = WS-QTD * WS-VALOR

feito várias vezes no loop com os mesmos valores.

✔️ Dica:

  • Calcule uma vez

  • Armazene

  • Reutilize


🧼 Como Escrever Código Mais Limpo no COBOL 4

✅ Use nomes claros

WS-VALOR-TOTAL WS-FIM-ARQUIVO

❌ Evite:

WS-A WS-X1

✅ Evite lógica escondida

Código perigoso:

IF A = B MOVE X TO Y ELSE IF C = D MOVE Z TO Y END-IF END-IF

✔️ Melhor:

  • Clareza > esperteza

  • COBOL foi feito para ser legível


🚀 Performance no COBOL 4: Dicas Práticas

⚙️ 1. Tire código de dentro de loops

Cada instrução dentro de loop custa N vezes.


⚙️ 2. Use corretamente os níveis da DATA DIVISION

  • Campos agrupados bem definidos

  • Evite REDEFINES desnecessário

REDEFINES mal usado = bugs silenciosos.


⚙️ 3. Cuidado com STRING e UNSTRING

Eles são poderosos… e caros.

✔️ Use apenas quando necessário
✔️ Evite em loops grandes


⚙️ 4. Arquivos: leia com cuidado

  • READ sequencial é barato

  • READ aleatório é caro

  • Releitura custa CPU e I/O


🧠 Pontos de Atenção que Geram Bugs em Produção

ArmadilhaProblema
Campo não inicializadoResultado imprevisível
EOF mal tratadoLoop infinito
IF aninhado demaisErro lógico
REDEFINES confusoDados corrompidos
Índices fora do limiteABEND

🧙 Curiosidades & Easter Eggs COBOL 4

  • COBOL 4 foi o primeiro passo real rumo ao COBOL 5

  • Programas antigos compilam, mas podem custar o dobro de CPU

  • O compilador já “entende” melhor a arquitetura do zSeries


🧭 Primeiros Passos Recomendados para Padawans

  1. Aprenda estrutura limpa

  2. Evite copiar código velho sem entender

  3. Sempre pense:

    “Isso vai rodar quantas vezes?”

  4. Meça CPU quando possível

  5. Menos código = menos custo


🏁 Conclusão

COBOL 4.00 é:

  • Estável

  • Poderoso

  • Implacável com código mal escrito

“No mainframe, não existe código inocente.
Só código caro ou econômico.”

 

segunda-feira, 13 de maio de 2013

O Canal de Corinto, obra de engenharia fantastica.

Obras de arte na engenharia : Canal de Corinto

No passado um barco levava quase 3 dias para sair do Golfo de Corinto e contornar todo a península do Peloponeso.

Construído no século XIX em uma época em que não existiam as modernas maquinas de escavação, abriu-se um canal de mais de 6 quilometros com 21 de largura, permitindo a passagem de barcos de um lado a outro.



Os amantes de esportes radicais usam as pontes existente no Canal para fazerem bump jump e outras maluquices.

Outra curiosidade é q existe um semáforo nas entradas do canal que coordena o fluxo das embarcações.

sábado, 11 de maio de 2013

Navegação pelo Mar Adriático, viagem a Grécia.

O barco de ligação entre Bari (Italia) e Patras (Grécia)


Decidido retornar ao Brasil, após 11 anos vivendo fora resolvi fazer uma ultima grande aventura, para poder fechar este ciclo com chave de ouro.

Após perambular pelo sul da Itália, resolvi mover-me a leste até a cidade dos meus antepassados Bari, de la apanhei um barco com destino a Grécia.


Este navio é enorme funciona como uma balsa, fazendo ligação entre estes 2 países. Vejam pelo filme o tamanho do porão onde sao estacionados os carros e caminhoes, em cima alguns camarotes e outros luxos.

A viagem dura a noite toda, partindo as 5 da tarde e chegando por volta das 6 da manha. Recomendo chegarem cedo, pois podem escolher um bom lugar para montar seu acampamento.


quarta-feira, 10 de abril de 2013

Mexendo no motor: O que é ISPF?

 


Mexendo no motor: O que é ISPF?

A central de comando do desenvolvedor mainframe

“Ninguém sobrevive no z/OS apenas digitando comandos.”
Quem trabalha de verdade vive dentro do ISPF.

Se o IBM z/OS é o sistema operacional que move o mundo financeiro,
e o TSO é a porta de entrada…

Então o ISPF é, sem dúvida, o local onde o trabalho acontece.


🧠 O que é ISPF, sem enrolação

ISPF significa Interactive System Productivity Facility.

Traduzindo para o dialeto Bellacosa:

ISPF é a camada de produtividade do mainframe.

Ele roda sobre o TSO e fornece:

  • Menus estruturados

  • Painéis padronizados

  • Editores poderosos

  • Ferramentas integradas

Tudo isso para que o usuário produza mais, com menos erro, em um ambiente altamente controlado.


🧱 TSO vs ISPF — cada um no seu papel

Vamos deixar isso claro, porque todo padawan confunde no começo:

  • TSO
    → Ambiente de comandos
    → Cria a sessão do usuário
    → Gerencia acesso e segurança

  • ISPF
    → Interface orientada a menus
    → Organiza o trabalho diário
    → Aumenta produtividade

Regra de ouro:

TSO funciona sem ISPF.
ISPF não funciona sem TSO.


📋 O que você faz dentro do ISPF

Na prática, quase tudo.

ISPF é usado para:

📋 Navegar pelo sistema com menus claros
📁 Criar, listar e gerenciar datasets e bibliotecas
✍️ Escrever e manter código COBOL, JCL, REXX
🗂️ Submeter JOBs e analisar outputs
⚙️ Acessar ferramentas como SDSF e utilitários do sistema

Em ambientes reais:

90% da vida do mainframeiro acontece no ISPF.


🚀 O coração do ISPF: o Primary Option Menu

Ao entrar no ISPF, você encontra o famoso Primary Option Menu.

Ali estão os atalhos para tudo que importa:

  • 1 → Browse (visualizar datasets)

  • 2 → Edit (editar código)

  • 3 → Utilities (copiar, renomear, apagar datasets)

  • 4 → Foreground

  • 5 → Batch

  • 6 → Command

  • 7 → Dialog Test

  • 8 → LM Facility

  • 9 → IBM Products

  • S → SDSF (dependendo da instalação)

Dica Bellacosa:

Quem domina o menu domina o ambiente.


⌨️ O editor ISPF: simples, mortalmente eficiente

O editor do ISPF pode parecer espartano…
mas ele é rápido, previsível e seguro.

Características que veteranos respeitam:

  • Colunas fixas (perfeitas para COBOL)

  • Comandos de linha (I, D, C, R)

  • Macros

  • Undo confiável

  • Performance absurda em arquivos gigantescos

Em produção:

Editor bonito não paga boleto.
Editor confiável sim.


📦 Gerenciamento de datasets sem dor

Com ISPF, você:

  • Cria datasets com controle fino

  • Copia bibliotecas inteiras

  • Compara versões

  • Apaga com segurança

  • Trabalha com PDS, PDSE, sequential

Tudo isso sem digitar comandos longos.

É produtividade com trilhos.


⚡ ISPF como acelerador de carreira

Aprender ISPF não é opcional.

Quem domina ISPF:

  • Trabalha mais rápido

  • Erra menos

  • Entende o ambiente

  • Ganha respeito do time

  • Vira referência

Padawan que ignora ISPF:

Sofre.
Digita demais.
Se perde.


🥚 Easter-eggs do cotidiano ISPF

  • PF3 é reflexo condicionado

  • Todo mundo já apagou dataset errado

  • Todo mundo ama =3.4

  • Todo mundo respeita SAVE antes do SUBMIT


🏁 Palavra final do El Jefe

ISPF não é “interface velha”.
É engenharia de produtividade em escala bancária.

Se:

  • TSO é o motor

  • ISPF é o painel

  • z/OS é o veículo

Então quem dirige bem…
chega longe.

sábado, 6 de abril de 2013

📉 Como Caçar MIPS Desperdiçado IBM Mainframe COBOL

 


📉 Como Caçar MIPS Desperdiçado

IBM Mainframe COBOL – Manual do Caçador de Custos para Padawans

“MIPS não somem sozinhos.
Alguém os está queimando.”


🧠 Antes de Tudo: O que é MIPS (na vida real)

  • MIPS = dinheiro

  • Não é performance “bonita”

  • É CPU faturada

  • Batch ruim = fatura triste 😭

☑️ Um programa pode estar correto
☑️ E ser financeiramente criminoso


🐘 Onde os MIPS se Escondem (Mapa do Crime)

ÁreaCrime comum
COBOLMOVE inútil, PERFORM em loop
SORTSort desnecessário
DB2Fetch linha a linha
I/OLeitura registro a registro
JCLClasses erradas
CompilaçãoParâmetro errado


🧪 1. O Maior Vilão: LOOP INÚTIL

🔥 Sintoma

  • CPU alto

  • Pouca E/S

  • Tempo absurdo

💀 Crime clássico

PERFORM 1000000 TIMES MOVE WS-A TO WS-B END-PERFORM

🛠️ Cura Bellacosa™

  • Elimine MOVE redundante

  • Tire código de dentro do loop

☑️ Código dentro de loop custa MIPS


🧪 2. MOVE em Cadeia (o Vampiro Silencioso)

🔥 Sintoma

  • CPU sobe

  • Programa “simples”

💀 Crime clássico

MOVE A TO B MOVE B TO C MOVE C TO D

🛠️ Cura Bellacosa™

MOVE A TO D

☑️ COBOL não cobra por linha… cobra por execução.


🧪 3. PERFORM CALLADO (Sem necessidade)

🔥 Sintoma

  • Modularização “bonita”

  • CPU feia

💀 Crime clássico

PERFORM CALCULA-VALOR

chamado milhões de vezes.

🛠️ Cura Bellacosa™

  • Inline lógica crítica

  • Evite PERFORM em massa

☑️ Modularidade demais custa caro.


🧪 4. SORT Burro (Quando não precisava)

🔥 Sintoma

  • CPU alto

  • Disco suando

💀 Crime clássico

  • SORT de arquivo já ordenado

  • SORT para eliminar duplicidade

🛠️ Cura Bellacosa™

  • Valide se já vem ordenado

  • Use controle lógico

☑️ SORT é um monstro de MIPS.


🧪 5. DB2: FETCH Um a Um (Pecado Mortal)

🔥 Sintoma

  • CPU altíssimo

  • SQL “simples”

💀 Crime clássico

FETCH CURSOR

milhões de vezes.

🛠️ Cura Bellacosa™

  • Use FETCH BLOCK

  • Aumente ARRAY FETCH

☑️ Banco pensa em bloco, não em linha.


🧪 6. COMMIT Mal Posicionado

🔥 Sintoma

  • Lock

  • Reprocesso

  • CPU extra

💀 Crime clássico

  • COMMIT a cada registro

  • COMMIT gigante demais

🛠️ Cura Bellacosa™

  • Commit por lote

  • Ajustar checkpoint


🧪 7. I/O Excessivo (Leitura Burra)

🔥 Sintoma

  • Muito tempo de execução

  • Pouca CPU útil

💀 Crime clássico

  • READ dentro de loop

  • Releitura desnecessária

🛠️ Cura Bellacosa™

  • Buffer

  • Carregar em memória quando possível

☑️ I/O custa caro e demora.


🧪 8. Compilação Errada = MIPS Perdido

🔥 Crime silencioso

  • Compilar COBOL 5 com PARMs antigos

🛠️ Cura Bellacosa™

OPTIMIZE ARCH(13+)

☑️ Compilador moderno gera código melhor.


🧪 9. JCL Mal Enquadrado

🔥 Sintoma

  • Job pequeno em classe errada

💀 Crime clássico

  • Classe de alto consumo

  • Prioridade indevida

🛠️ Cura Bellacosa™

  • Classe certa

  • WLM ajustado


🧪 10. Falta de Métrica = Cegueira

🔥 Erro fatal

  • “Acho que melhorou”

🛠️ Ferramentas

  • SMF

  • RMF

  • Accounting DB2

  • EXPLAIN PLAN

☑️ Sem métrica, não há tuning.


🧠 Checklist Rápido do Caçador de MIPS

☑️ Tirou código de loop
☑️ Reduziu SORT
☑️ Ajustou FETCH
☑️ Ajustou COMMIT
☑️ Compilou certo
☑️ Mediu antes e depois


🧙 Easter Eggs Bellacosa™

  • 1 MOVE em loop pode custar milhões por mês

  • Batch “simples” costuma ser o mais caro

  • Melhor otimização: não executar


🏁 Conclusão

“MIPS não se otimizam…
MIPS se caçam.”